From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 13D5C202213 for ; Mon, 7 May 2012 20:32:58 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0187.atlanta.hp.com (Postfix) with ESMTP id 5698C281B2; Tue, 8 May 2012 03:32:57 +0000 (UTC) Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 0C8281427C; Tue, 8 May 2012 03:33:12 +0000 (UTC) Message-ID: <4FA893E7.2010603@hp.com> Date: Mon, 07 May 2012 20:32:55 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jim Gettys References: <1336246349-20228-1-git-send-email-dave.taht@bufferbloat.net> <4FA7FBC7.2040501@hp.com> <1336410626.3752.2329.camel@edumazet-glaptop> <4FA805F9.20004@hp.com> <1336412079.3752.2333.camel@edumazet-glaptop> <4FA81549.5060609@freedesktop.org> <4FA8197C.4090909@freedesktop.org> <1336418211.3752.2353.camel@edumazet-glaptop> <4FA82422.9040500@freedesktop.org> <1336421020.3752.2359.camel@edumazet-glaptop> <4FA873A0.40803@freedesktop.org> <4FA87ABC.4080907@freedesktop.org> <4FA881F6.9080808@hp.com> <4FA88FA9.7030804@freedesktop.org> In-Reply-To: <4FA88FA9.7030804@freedesktop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Dumazet , Dave Taht , codel@lists.bufferbloat.net Subject: Re: [Codel] [PATCH 1/2] codel: Controlled Delay AQM 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: Tue, 08 May 2012 03:32:59 -0000 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