From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 0233521F0D8 for ; Sun, 5 Aug 2012 10:15:13 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so756199wib.10 for ; Sun, 05 Aug 2012 10:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=eeUrcaGs5dDgvqcY1w9RpReMHD0vIEuW0bnfwo4CjT4=; b=O+P0QyR8NEUfh+zY1KuM+oHxb4dnM7NMs939dJ67d9z13m9B5+puMt1LEYIFr0oPG1 UuZ0aN1RyX7BjXDtBbMG1Wwq9fTm3YYHWJJ+helbyFZvpYIDF+UOERWZDcwXRqi8XS8c uRvenBBHjDNZFOJqb/09QD+m7GTklMG60/G8NRbVGpZlnIZdWumcv+2OclEQBko0IyP2 y4yehRRIRKUFAmbPxS57asXtu0TfUPt+1sB8i9LTunVrG6+8F5QmeGHKXokuhQs+S19P 6FHU0kvQg4HeKdSvjos1j3qd7iIeUnU9TzXUbHzUAAESpcD6EJZfjwWDS2QkgXNod8W7 8CAg== Received: by 10.180.97.33 with SMTP id dx1mr11744718wib.18.1344186912173; Sun, 05 Aug 2012 10:15:12 -0700 (PDT) Received: from [172.30.42.18] (171.237.66.86.rev.sfr.net. [86.66.237.171]) by mx.google.com with ESMTPS id t8sm10756623wiy.3.2012.08.05.10.15.10 (version=SSLv3 cipher=OTHER); Sun, 05 Aug 2012 10:15:11 -0700 (PDT) From: Eric Dumazet To: Andrew McGregor In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Date: Sun, 05 Aug 2012 19:15:08 +0200 Message-ID: <1344186908.9299.1603.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 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 17:15:14 -0000 As far as CoDel is concerned, we could have two stages of control : The current one, to mark/drop packet as specified by Kathleen & Van Then, for marked (ecn) packets, pass a second codel stage, but dropping packets this time, to make sure we dont allow queue to become too large. On Sun, 2012-08-05 at 09:53 -0700, 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 ? > > > > > > >