From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9358621F0A9 for ; Sun, 5 Aug 2012 09:58:35 -0700 (PDT) Received: from c-24-4-217-203.hsd1.ca.comcast.net ([24.4.217.203] helo=kmn.local) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1Sy49y-000Nsx-5o; Sun, 05 Aug 2012 16:58:34 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.4.217.203 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18QG2++L0HqSGTm/MeUKcGb3MKMNoPesHo= Message-ID: <501EA636.8040603@pollere.com> Date: Sun, 05 Aug 2012 09:58:30 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andrew McGregor References: <1344048299-26267-1-git-send-email-dave.taht@bufferbloat.net> <1344062738.9299.1453.camel@edumazet-glaptop> <501D99C4.20902@pollere.com> <7EB59257-1A8E-4567-8AD3-5016594565CC@gmail.com> <1344144623.9299.1557.camel@edumazet-glaptop> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target 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: Sun, 05 Aug 2012 16:58:35 -0000 So you want to provide an incentive to deploy ECN. This also provides an incentive to scam the network. I think a bigger question is what is gained by doing this? Is it more important to deploy something called ECN than to have a well-functioning network? Kathie On 8/5/12 9:53 AM, Andrew McGregor wrote: > Well, there's a lot of people at the IETF who really want to do other things with ECN, but it seems like the simple version is far too aggressive. > > So, I think the desirable properties are something like: > 1) Allow ECN flows to achieve the same or slightly higher throughput to maintain an incentive to deploy it. > 2) Still drop ECN flows eventually to avoid too much queue buildup. > 3) Account somehow for the fact that marking takes longer to control the queue (but we don't know how much longer). > > Maybe mark ECN instead of dropping, but if we end up trying to mark/drop twice in one round, drop the later packets? > > Oh, and ECN nonce deployment is negligible, to the extent that there are proposals in the IETF to reuse the bits for other things, and there is no pushback on that. > > Andrew > > On 4/08/2012, at 10:30 PM, Eric Dumazet wrote: > >> On Sat, 2012-08-04 at 20:06 -0700, Andrew McGregor wrote: >>> Well, thanks Eric for trying it. >>> >>> Hmm. How was I that wrong? Because I was supporting that idea. >>> >>> Time to think. >> >> No problem Andrew ;) >> >> Its seems ECN is not well enough understood. >> >> ECN marking a packet has the same effect for the sender : reducing cwnd >> exactly like a packet drop. Only difference is avoiding the >> retransmit[s]. >> >> It cannot be used only to send a 'small' warning, while other competing >> non ECN flows have no signal. >> >> As far as packet schedulers are concerned, there should be no difference >> in ECN marking and dropping a packet. I believe linux packet schedulers >> are fine in this area. >> >> Now, there are fundamental issues with ECN itself, out of Codel scope, >> thats for sure. >> >> How widely has been RFC 3540 deployed, anybody knows ? >> >> >>