Re: [Codel] [RFC PATCH] codel: ecn mark at target

["Richard Scheffenegger" <rscheff@gmx.at>]

Well, as long as the window is large enough, the delayed ACKs shouldn't 
matter, even if the ECE is delayed for 1 segment; the argument about delayed 
ACKs when cwnd is 1 is also true for non-ECN flows; they would run better 
when every segment is acked individually; but can the receiver tell, if the 
sender is running at cwnd=1?

Perhaps, if it tracks the RTT of the flow (which has to work without TS, as 
they are undefined for pure ACKs), and the number of segments seen during 
one RTT...

(Perhaps another performance tweak for linux TCP...)

Best regards,
   Richard

----- Original Message ----- 
From: "Eric Dumazet" <eric.dumazet@gmail.com>
To: "Yuchung Cheng" <ycheng@google.com>
Cc: "Richard Scheffenegger" <rscheff@gmx.at>; <codel@lists.bufferbloat.net>
Sent: Sunday, August 05, 2012 8:40 PM
Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target


> On Sun, 2012-08-05 at 11:14 -0700, Yuchung Cheng wrote:
>> On Sun, Aug 5, 2012 at 10:35 AM, Eric Dumazet <eric.dumazet@gmail.com> 
>> wrote:
>> > On Sun, 2012-08-05 at 19:26 +0200, Eric Dumazet wrote:
>> >
>> >> It could be a flaw in linux implementation, I admit we had so many 
>> >> bugs
>> >> that it could very well be still buggy.
>> >
>> > And at first glance, the following tcpdump seems suspect : We can see
>> > all ACK are delayed by about 40 ms
>> but RFC 3168 (sec 6.1.3) does not mandate immediate ACKs for ECE
>> marked ones? is this because ECN response is per round-trip?
>>
>
> We should IMHO not delay ACKS, exactly like we react to a dropped
> packet.
>
> If not specified in RFC 3168, it seems a forgotten point.
>
>
>