On Wed, Sep 28, 2011 at 5:47 AM, Matt Johnston m...@ucc.asn.au wrote:
Hi,
Thanks for the patch, it answers my commented question six
years later :)
I was stumped on this one for even longer than that, so I'm pushing
out the knowledge (and patches) as fast as I can.
What are the implications of stomping on
the ECN bit on pre-2.6.39 kernels?
pre-2.6.39, you could actually set the IPv6 ECN bits from userspace,
which was bad in most ways (good in another, in that you could
test ECN from userspace programs). Notably as ECN is a negotiated
inside-of-tcp option, then passed to the outside dscp field, calling
setsockopt to reset it to effectively *off* is not a problem.
setting ECN to *on* (e.g IP_TOS_LOWDELAY | 3) IS a problem,
but we're not doing that...
I tried to find ways to determine if I could find the existing ECN
setting, to or in the bits... and failed.
That said, ECN is not widely deployed (yet), and losing ECN
capability in this case (on older kernels) only reverts the tcp
connection to the default behavior of forcing a traffic shaper,
to drop, rather than ECN mark packets.
So there should be no ill effect on existing code with this change,
and treating ssh packets over ipv6 as interactive helps a lot in
the general case (and in the case of 6to4, the encapsulated
packet header is copied to the outer header, so encapsulated
6to4 packets also can get prioritized right)
I agree flags for SCP would make sense, I'll take a look
where to do that.
I think openssh does half the job (the scp side sets bulk),
I haven't looked at it yet (mostly working on cerowrt
right now)
I'm not sure how to handle SFTP since
lookup commands should remain responsive, especially for
things like sshfs. I don't know whether changing socket
options frequently works OK.
It would be a good experiment! I've got the current patch
working in a cerowrt smoketest, seeing it also do more of
the right thing in a sftp environment I can easily test.
The 'experimental' part is when the setsockopt change
would be asserted on the flow, thus reprioritizing packets
possibly in flight?
Cheers,
Matt
On Wed, Sep 28, 2011 at 04:58:24AM -0700, Dave Taht wrote:
Setting the TCLASS (TOS) field requires different setsockopt
params on ipv6 than ipv4.
as per:
http://www.bufferbloat.net/projects/cerowrt/issues/249
---
dbutil.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/dbutil.c b/dbutil.c
index b3a119f..2739d2f 100644
--- a/dbutil.c
+++ b/dbutil.c
@@ -161,10 +161,12 @@ static void set_sock_priority(int sock) {
val = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)val, sizeof(val));
- /* set the TOS bit. note that this will fail for ipv6, I can't find any
- * equivalent. */
+ /* bruteforce the TOS bit for ipv4 or ipv6. Note that for versions of
+ Linux prior to 2.6.39 this will stomp on the ECN bit under IPv6
*/
+
#ifdef IPTOS_LOWDELAY
val = IPTOS_LOWDELAY;
+ setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)val, sizeof(val));
setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)val, sizeof(val));
#endif
--
1.7.4.1
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
