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

[Jim Gettys <gettysjim@gmail.com>]

On May 7, 2012, at 11:32 PM, Rick Jones <rick.jones2@hp.com> wrote:

> 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.

Too late tonight to try to resurrect what I remember from Steve.  Barring unforeseen events, he should be able to join the list then and better coming from him anyway.

Jim