From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by huchra.bufferbloat.net (Postfix) with SMTP id 38C282021A8 for ; Mon, 6 Aug 2012 09:26:45 -0700 (PDT) Received: (qmail invoked by alias); 06 Aug 2012 16:26:44 -0000 Received: from unknown (EHLO srichardlxp2) [213.143.107.142] by mail.gmx.net (mp041) with SMTP; 06 Aug 2012 18:26:44 +0200 X-Authenticated: #20720068 X-Provags-ID: V01U2FsdGVkX18+G2oW8/c+E/Ba2PZ0V6/pfxDk3Lwkj5KulOrdum whlTE4cQEmNGGT Message-ID: <8860AEB6C5DB43649852D9A8B40E9B9F@srichardlxp2> From: "Richard Scheffenegger" To: "Eric Dumazet" , "Yuchung Cheng" References: <1344048299-26267-1-git-send-email-dave.taht@bufferbloat.net> <1344062738.9299.1453.camel@edumazet-glaptop> <501D99C4.20902@pollere.com> <7EB59257-1A8E-4567-8AD3-5016594565CC@gmail.com> <1344144623.9299.1557.camel@edumazet-glaptop> <4A256974B5054317913BC067C4E5FAE1@srichardlxp2> <1344187557.9299.1610.camel@edumazet-glaptop> <1344188112.9299.1614.camel@edumazet-glaptop> <1344192037.9299.1618.camel@edumazet-glaptop> Date: Mon, 6 Aug 2012 18:22:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Y-GMX-Trusted: 0 Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 16:26:45 -0000 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" To: "Yuchung Cheng" Cc: "Richard Scheffenegger" ; 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 >> 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. > > >