Re: [Codel] [PATCH 1/2] codel: Controlled Delay AQM

[Rick Jones <rick.jones2@hp.com>]

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