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 86FCE202213 for ; Mon, 7 May 2012 18:15:17 -0700 (PDT) Received: by qcsp15 with SMTP id p15so1485157qcs.16 for ; Mon, 07 May 2012 18:15:16 -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=dFOx7SExwmBo/2nomcqDv7K1r6EJ/uia1D4hQOPtYl8=; b=UMX3EhhgIY4kC+VlAn8/36WXC8Cdcf2Lh4YBePJKmE6CyRymAbOhqcs9OAeqjUJ7FW FtZMquZG5TBf52Sk9aiMl3h2E8aT+u9JM/kiwgN6JAPnFgM/zbzj07JbPJGXg29RbRWs LW09rBvcjen1+EHS9I7ICoTFrQBSwlXI3jA7J3+vAqI4EcwPO48swB1U161B4b3U1ORv Avlu0EvhNRUoyW48vYww29NagGGo8jhoR2BUfTpJCdqMyomxTwxCWsz+jYG7JFNeyb9n SGFjPgRae0FdLq1NhWzgAC1H0tG9PpN93b+D0KyxPJoFMJq/2ScQnyY/F+H7plXzmH1O wjpg== Received: by 10.224.34.9 with SMTP id j9mr22029762qad.14.1336439716127; Mon, 07 May 2012 18:15:16 -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 bs9sm1067134qab.2.2012.05.07.18.15.13 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 18:15:15 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FA873A0.40803@freedesktop.org> Date: Mon, 07 May 2012 21:15:12 -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: Eric Dumazet 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> In-Reply-To: <1336421020.3752.2359.camel@edumazet-glaptop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eric Dumazet , codel@lists.bufferbloat.net, Dave Taht 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 01:15:17 -0000 On 05/07/2012 04:03 PM, Eric Dumazet wrote: > On Mon, 2012-05-07 at 15:36 -0400, Jim Gettys wrote: > >> I think it is safe for it to behave the rest of the way Linux ECN >> support does right now: it only gets used if the peer requests it. >> >> Not clear to me there needs to be/should be any option at all: the last >> conversation I had with Steve Bauer was that something north of 20% of >> conversations were ECN capable. Is there one for the other instances of >> ECN support in Linux? If so, it should be keyed by the same variable, >> and not be a one-off for codel. >> > SFB, one of the latest qdisc added in linux has ECN support enabled. > > There is no option to disable it, because I felt it was safe. Maybe I > was a fool, but problem is I am not sure SFB is even used. Client initiated ECN may still be problematic. It is *fine* if a system responds to ECN that is sent to it. We know that is fine, as Linux has had the server side of ECN enabled for quite a few years, and those systems now are > 20% of servers on the internet. The issue is there are both networks and middleboxes that are misconfigured/broken. In some cases, it black-holes a connection and your data just doesn't go through; in others, ECN is ignored,; in others the ECN bits are cleared or mangled; and, most worryingly, there are some devices of order a decade old that just crash if they see an ECN marked packet. We do not know how common the last of these problems are. Anecdotal evidence: OpenWrt tried turning on the client side of ECN several years ago, and had to back off due to too many bug reports. CeroWrt is small enough (and time has passed), so I am all for Dave turning on ECN for CeroWrt and we can get a feeling for how common the problem still is. Steve Bauer has been studying ECN for the last couple years (and, at times, getting various networks fixed, beginning with MIT's own network, and later, some of the biggest commercial and academic networks fixed. There are several papers on what Steve (et. al.) have found, but I don't have the references handy. But it's crashing the end user boxes that has been most problematic, and we don't know how common that is. There *used* to be a database of such broken hardware, but it has bit-rotted. So let's check with Steve Bauer on this years results. > >> If you wanted to test ECN separately from drop with codel, then you'd >> just request ECN in the conversation (by default, OS's don't normally >> request ECN today, as the remaining brokenness gets sorted out). > Since ECN is not mentioned in Codel paper, this means no simulation was > done to study the possible effects. > > So its probably better to leave ECN as an option. We can change the > default later. Yup. Once we know if the current state of the net is good enough. What we don't want is to get a pile of codel bug reports that are really ECN related problems, of which we know there are quite a few. - Jim