From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (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 C647B201B70 for ; Mon, 7 May 2012 21:14:06 -0700 (PDT) Received: by qcsp15 with SMTP id p15so1572737qcs.16 for ; Mon, 07 May 2012 21:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=JQCW1k63Wy1WDdM4pypmY4o7U00az+R9jyYR3wUm/zc=; b=tPxonr26PZMkLENrMgDnnFdeeQurZQjEHt+D4u3BU+zdLg2q7xEFhxIQTaeQV6lnsT +cQ5KbjIlqisl7OdjzU+ZdBv8ZvVYsqulepzadAl2SJLF51r8yD7hzR7oVAgG+7G6+Vx J74P7pJc/Ka1xxTkFWZRlhUB29DfY8VJ8SoS/Ay2j4zIyW/xeODmcmkq4812WypqwCVd KARsyxZCM8ZcvL7luBKZqQNVXBBMP5XVmbj5t4bKs82kBs1HIqnU84grfzlt94+Pz6ZQ uFcnDI+0Dbqj+4ecIjZ81JmfMNjOxuLGVMoEy1qxQ6dAvV6nXTgZmjiodmGe/gbLdAPm 0r6w== Received: by 10.224.176.148 with SMTP id be20mr29029404qab.64.1336450445237; Mon, 07 May 2012 21:14:05 -0700 (PDT) Received: from [192.168.1.84] (c-50-138-162-108.hsd1.ma.comcast.net. [50.138.162.108]) by mx.google.com with ESMTPS id gw8sm1857798qab.7.2012.05.07.21.14.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 21:14:03 -0700 (PDT) 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> <4FA893E7.2010603@hp.com> In-Reply-To: <4FA893E7.2010603@hp.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A405) From: Jim Gettys Date: Tue, 8 May 2012 00:14:14 -0400 To: Rick Jones X-Mailman-Approved-At: Mon, 07 May 2012 21:22:11 -0700 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 04:14:07 -0000 On May 7, 2012, at 11:32 PM, Rick Jones wrote: > On 05/07/2012 08:14 PM, Jim Gettys wrote: >> There are three cases here: >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 op= en. >>=20 >> 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. >=20 > Then get the folks at queue.acm.org on the ball and get the paper publishe= d already :) :) :) >=20 > But I'm still confused. If Case 2 is "safe" is it safe only because no-on= e initiates ECN making Case 2 a noop? IE, it is not known to be safe to set= tcp_ecn=3D1? That being the case, I'd still think that codel going "if I s= ee ECT and would drop, I'll mark" is OK because it will only see ECT if the c= lient set tcp_ecn=3D1, and presumably then, the owner of the client will not= have set tcp_ecn=3D1 unless they know it is "safe" to do so. Particularly w= ith Eric's recent patch to upstream to only accept an ECN request in a SYN i= f the ECN bits in the IP header are clear. Too late tonight to try to resurrect what I remember from Steve. Barring un= foreseen events, he should be able to join the list then and better coming f= rom him anyway. Jim