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.duma...@gmail.com>
To: "Yuchung Cheng" <ych...@google.com>
Cc: "Richard Scheffenegger" <rsch...@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.duma...@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.
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
