From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pz0-f51.google.com (mail-pz0-f51.google.com [209.85.210.51]) (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 6B89720191C for ; Mon, 7 May 2012 13:55:07 -0700 (PDT) Received: by dajt11 with SMTP id t11so1636543daj.10 for ; Mon, 07 May 2012 13:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nj96jPoZSdU/1rlO0RFGBMAwfGc7B9Vx1S+NKI1aVWg=; b=soSlFZUP9ftgoj0jj2/bEAs8ZFbyLqKFlIt3YGIEYA2t00hkjnXuv8GJtAF4HuhwFE yLnp6swUJNvCgFWddLe+kO0SRkR1wzV+JxSJeR4XekNvRdtuz36jPH3t92EJHDk2J7+0 KEldf7siTI23Wfubi30zg2Oesky3MDV4bDjelgpe88rQdM5f/CumoAOA36unzuw3nQtq GOW7UmOrENdXL++kslso/w69xShZzTJGJru9JLvycs1S4pYLj3c/IYz23zG2Spqdzovz U684swgO2fufCVNYdDt7njYK/gZSo86D7GIyUcsUacArN5sH4DLSPOXCZ0yEdJDF/DPk aXnw== Received: by 10.68.132.34 with SMTP id or2mr263383pbb.118.1336424106569; Mon, 07 May 2012 13:55:06 -0700 (PDT) Received: from ?IPv6:2001:4f8:3:203::c001? ([2001:4f8:3:203::c001]) by mx.google.com with ESMTPS id oa5sm213200pbb.2.2012.05.07.13.55.04 (version=SSLv3 cipher=OTHER); Mon, 07 May 2012 13:55:05 -0700 (PDT) Message-ID: <4FA836A7.2030101@gmail.com> Date: Mon, 07 May 2012 13:55:03 -0700 From: dave taht User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.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; format=flowed 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: Mon, 07 May 2012 20:55:08 -0000 On 05/07/2012 01: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. My own testing with SFB as done was simultaneously with the "GSO by default" change to linux in Febuary of last year. The results were dismal. But: At the time I was unaware of the GSO change. I only stumbled across that commit months later, and I made sure all future testing disabled all offloading of any kind via the debloat script. At that point I'd thrown out all the data and started looking at other alternatives. I no longer feel Blue works worth a darn in the first place, anyway. The bloom filter is neat, and I like the idea of punishing unresponsive flows (particularly packets marked ecn but not responding to ecn indicators), but it just plain doesn't work. My low opinion of TSO/GSO/UFO GRO etc is well known, although I'd not mind them at all so long as a working AQM was in place on the card itself. I am glad to see that these offloads have improved a lot over the past year, however. >> 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. Yes, I'd like simulations with long RTTs. > So its probably better to leave ECN as an option. We can change the > default later. The incremental approach has been tried re this option for a decade. I'd prefer "on by default", and then find more ways to make ECN work, to automagically detect and workaround problems, but I realize I'm in a minority here, and am not going to push the point for mainline. CeroWrt, yes. On by default, and pursue this goal. > >