From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (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 189AA21F0DA for ; Sun, 5 Aug 2012 10:26:02 -0700 (PDT) Received: by wgbds1 with SMTP id ds1so881196wgb.4 for ; Sun, 05 Aug 2012 10:26:01 -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=FQkVwbTD1YdPorMJYRjAAMGhioJAXjGCO5jL2tu1tIU=; b=fv1o6N1FfiGTEyOgYMaWj1Z6tYZXpvX0DQUXzXYcJ3wkXyc6Shgiy0ZuFg9MrGiZtr jQ3CWNZtemG6Wq7yJhRx37/aEkgzzPB5R1YfoATCct4VLUO3THDdiEhkI5nAvVEWPfni MTQX3QWzvQy4BybdA1bISxH2pcveGK26Od5Qlim7P9RSSnRTJu1Js2kOWiovqnE8MdDJ 4pxTkXeivMf1CDEHUkyYAjVTAanhRlmkv7Vque1K6kf4gt8xwctv6W3LVrD4uBuFkF83 lS9Up7IqSfhr6AxlmSCBlGMwh4SWVzigrRxKajIKCRBFx5ljuzzvU+yhs0D0rvfyJ9J6 o8og== Received: by 10.180.81.38 with SMTP id w6mr11823016wix.10.1344187561079; Sun, 05 Aug 2012 10:26:01 -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 b7sm15833823wiz.9.2012.08.05.10.25.59 (version=SSLv3 cipher=OTHER); Sun, 05 Aug 2012 10:25:59 -0700 (PDT) From: Eric Dumazet To: Richard Scheffenegger In-Reply-To: <4A256974B5054317913BC067C4E5FAE1@srichardlxp2> 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> <4A256974B5054317913BC067C4E5FAE1@srichardlxp2> Content-Type: text/plain; charset="UTF-8" Date: Sun, 05 Aug 2012 19:25:57 +0200 Message-ID: <1344187557.9299.1610.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:26:03 -0000 On Sun, 2012-08-05 at 18:54 +0200, Richard Scheffenegger wrote: > Hi Eric, > > ----- Original Message ----- > From: "Eric Dumazet" > To: "Andrew McGregor" > Cc: > Sent: Sunday, August 05, 2012 7:30 AM > Subject: Re: [Codel] [RFC PATCH] codel: ecn mark at target > > > > 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]. > > That's true for the first mark; any subsequent mark (during the same window) > should have no effect - thus a high marking rate (marking fraction per > window) should not be that much worse... Of course, the queue can never know > the effective window of the tcp stream it is marking... > Once your cwnd is 1 packet, and RTT is 100ms, what can you get from this, if all your packets have ECN mark ? > As a test, when the marking is done really instead of drop, do you see > fairness betwenn the ecn and legacy tcp flows? (if not, the ecn > implementation may be faulty). Yes its fine as mentioned in my test : codel , and I get 50/50 split between my two flows. It could be a flaw in linux implementation, I admit we had so many bugs that it could very well be still buggy.