[Codel] [PATCH 1/2] codel: Controlled Delay AQM
Rick Jones
rick.jones2 at hp.com
Mon May 7 23:32:55 EDT 2012
On 05/07/2012 08:14 PM, Jim Gettys wrote:
> There are three cases here:
>
> 1. you initiate a TCP session;
> 2. you receive a TCP session;
> 3. you mark a packet in transit through a system (you are routing).
>
> Case 2 is known safe, and is deploying rapidly in the Internet. Linux
> defaults to 2): if you talk to it asking for ECN, it responds.
>
> The problem is that some networks screw up the ecn bits. And worse yet,
> there at least used to be some hardware out in the great internet that
> would go belly up if it saw marked packets.
>
> So it's 1 and 3 that we might get in trouble about. There is some way
> to turn on 1( in Linux already; using ECN is negotiated as part of the open.
>
> But we better not do 3) (mark for ECN rather than drop) without knowing
> if it "safe" to do so. Steve Bauer and his collaborators have more
> understanding than anyone yet on this list.
Then get the folks at queue.acm.org on the ball and get the paper
published already :) :) :)
But I'm still confused. If Case 2 is "safe" is it safe only because
no-one initiates ECN making Case 2 a noop? IE, it is not known to be
safe to set tcp_ecn=1? That being the case, I'd still think that codel
going "if I see ECT and would drop, I'll mark" is OK because it will
only see ECT if the client set tcp_ecn=1, and presumably then, the owner
of the client will not have set tcp_ecn=1 unless they know it is "safe"
to do so. Particularly with Eric's recent patch to upstream to only
accept an ECN request in a SYN if the ECN bits in the IP header are clear.
rick
More information about the Codel
mailing list