From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.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 08390202295 for ; Sat, 4 Aug 2012 10:21:29 -0700 (PDT) Received: by weyx43 with SMTP id x43so2231270wey.16 for ; Sat, 04 Aug 2012 10:21:27 -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=lKO1BhPFxGSHSFsAxzqdQo1HNRfSBaPpMmEe/gSUKLc=; b=m6OIZ8p4fYgqB/1cpYEHUTtnYO19QRAEG9GS5BemwNIiVnz2uqVyi06wg7FeW0Nmpa /xSGxSDAc9dnj5oGxU2raqtk69bbvB7A8gcSDA2FiScUZ6BlETzeiZ8RBmR7jBiJelA7 8fyla/wU4vRzIHDF+mOB4ShVPXzYv4duXDktBr3FdlS8R7pSpOH27i90Vq8cDZDsQ3qW S4txGQmvo32ZrZETjXnSE8Bx20BW2bVjGBnB4sEG7VLNBRKJyDkAMBXlMqcX+AWC0UYm RuD7vXG7DNv5SSiu5C4vKYWuadGiLCztZAO6vEhHyj2k9Y2RhNf7KEre74h/3HQ08i7Q e+TA== Received: by 10.180.91.228 with SMTP id ch4mr5513364wib.7.1344100887794; Sat, 04 Aug 2012 10:21:27 -0700 (PDT) Received: from [172.28.91.192] ([74.125.122.49]) by mx.google.com with ESMTPS id w7sm4549694wiz.0.2012.08.04.10.21.25 (version=SSLv3 cipher=OTHER); Sat, 04 Aug 2012 10:21:26 -0700 (PDT) From: Eric Dumazet To: Richard Scheffenegger In-Reply-To: References: <1344048299-26267-1-git-send-email-dave.taht@bufferbloat.net> Content-Type: text/plain; charset="UTF-8" Date: Sat, 04 Aug 2012 19:21:22 +0200 Message-ID: <1344100882.9299.1545.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net, Bob Briscoe , Dave =?ISO-8859-1?Q?T=E4ht?= 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: Sat, 04 Aug 2012 17:21:30 -0000 On Sat, 2012-08-04 at 15:38 +0200, Richard Scheffenegger wrote: > Hi, > > My 0.02 EUR: > > mark every packet with a sojourn time above target is OK. > Thats insane. > The reaction of the congestion controller to ECN marks need to be more > differentiated; ECN can deliver much more fine-grained information about the > current state of the network. If a congestion controller (e.g. legacy 3168 > ECN TCP) chooses to overshoot in it's reaction, thats a problem for that > particular controller... But even if every packet of a window is marked, a > legacy TCP will only reduce cwnd once per window, reacting the same as is a > non-ECN had a single drop in that window... Thats would maybe work if all flows were ECN and kind. If you have a mix, then ECN flows are completely shut off. And I knew it before doing any experiment. What makes you think non ECN flows will drop at least one packet, while we ECN mark ECN flow ? How is cwnd 'known' by Codel exactly ? I did following experiment : link with HTB limit of 100Mbit/s One netperf TCP_STREAM to a non ECN enabled local target, duration 100s One netpert TCP_STREAM to a ECN enabled local target, duration 100s 1) Current Codel implementation non ECN target A : 50.55 Mbit/s (4336 dropped packets) ECN target B : 45.86 Mbits/s (3239 ecn marks) 2) Patch to mark all ecn-enabled packets above 'target' non ECN target A : 95.43 Mbit/s (2957 drops) ECN target B : 0.97 Mbit/s (2500 ecn marks) Yes, you see how wrong this idea is : Almost all packets to host B are marked, so throughput is horrible. It seems few people really understood CoDel 'target'. When a link is used, almost all packets are above target. Thats OK. If it was not OK, why would we use the sqrt(count) at all, I wonder. Codel intent is not to mark/drop _all_ packets above 'target'. ECN intent is to replace a drop by a mark, not marking packets that would not have been dropped at all if they were not ECN enabled.