From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 08B0B202213 for ; Mon, 7 May 2012 20:14:53 -0700 (PDT) Received: by qadb33 with SMTP id b33so225363qad.16 for ; Mon, 07 May 2012 20:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JeslCOl5HrDMW5tJYl2oiF+7i9O0s9yg23QcC0gW8Ok=; b=hL5GYaAuUOGEFHrNMEjewAZF3ivm/vq3UCpSAqHoUsC4632y/HjFtE8cW7knMXtCkv 995wZkyWib0gpwtjPAHWobvvo0Y3Eqv6QfgwUouKvzM1YQ2Eg2p7BsCtz3Znfen3KUbR j6rvITIazw00ooCXaclVpSIf/7wVu1dfxrRTIsqQPbyiDKflHaJvkTI6DixCOVlqg5we 50eOErJ4YFpC7rtTvyuiOwKPNoZnQfkQHJzgd30QGDMSE3WoQOXmWgnRsz3bFmjTUKYj wIrxj+686ZUNh0lG3YlK/YXGFvy+J0SRvI+ATViOh++AqhDSWbUqEROYJusB59qDaWK4 fGAg== Received: by 10.229.136.79 with SMTP id q15mr8351343qct.56.1336446892758; Mon, 07 May 2012 20:14:52 -0700 (PDT) Received: from [192.168.1.81] (c-50-138-162-108.hsd1.ma.comcast.net. [50.138.162.108]) by mx.google.com with ESMTPS id b2sm1416162qaf.4.2012.05.07.20.14.50 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 20:14:51 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FA88FA9.7030804@freedesktop.org> Date: Mon, 07 May 2012 23:14:49 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Rick Jones 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> In-Reply-To: <4FA881F6.9080808@hp.com> Content-Type: text/plain; charset=ISO-8859-1 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:14:54 -0000 On 05/07/2012 10:16 PM, Rick Jones wrote: > On 05/07/2012 06:45 PM, Jim Gettys wrote: >> On 05/07/2012 09:20 PM, Andrew McGregor wrote: >>> Sure... but making the Linux codel ECN capable, and even on by >>> default with no configuration, will have no effect if the clients >>> don't use ECN. So there's no need to even make it optional, let >>> alone default to off. >>> >>> >> The problem is that the client may be managing it's outbound queue with >> codel. So you have to negotiate ECN and if you start marking, you may >> run into trouble. > > Are the odds really all that high that when the admin of the client > set tcp_ecn = 1 (or its non-Linux equivalent) that codel running on > his system would be the only thing actually marking and so "the" > reason for trouble? I'm inclined to agree with Andrew. If the client > is going to have trouble with ECN, it will have it once it sets > tcp_ecn = 1, codel being there or not. 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. - Jim