Re: [aqm] Gaming ECN

Michael Welzl <> Sun, 22 March 2015 04:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C01DC1A0373 for <>; Sat, 21 Mar 2015 21:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qgJjG9tMqTm9 for <>; Sat, 21 Mar 2015 21:06:08 -0700 (PDT)
Received: from ( [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD2351A0141 for <>; Sat, 21 Mar 2015 21:04:58 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1YZX85-0003yM-5r; Sun, 22 Mar 2015 05:04:49 +0100
Received: from [] (helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from <>) id 1YZX84-0001ql-AL; Sun, 22 Mar 2015 05:04:49 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Michael Welzl <>
In-Reply-To: <>
Date: Sat, 21 Mar 2015 23:04:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <20150321012329.GU39886@verdi> <>
To: David Lang <>
X-Mailer: Apple Mail (2.2070.6)
X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 26692 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 49B20E6EE376EFC43D274FF0654A897D07189673
X-UiO-SPAM-Test: remote_host: spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 2 max/h 1 blacklist 0 greylist 0 ratelimit 0
Archived-At: <>
Cc: John Leslie <>, " list" <>
Subject: Re: [aqm] Gaming ECN
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Mar 2015 04:06:12 -0000

> On 21. mar. 2015, at 17.47, David Lang <> wrote:
> On Fri, 20 Mar 2015, John Leslie wrote:
>>> If you do #2, then flows with ECN effectively get priority over flows
>>> without ECN
>>  It's not "priority". It's an occasional packet which gets through
>> instead of being dropped.
> is it? or is it that in order to keep the link from being congeted, flows with ECN marked (but not honored) will consistantly get more packets through than ones wihtout ECN?
> If it' just an occasional packet, it's not a big deal, but if the non-ECN flows get slowed more because the ECN-marked flows are getting more packet through, that's a priority difference, not just an occasional packet.

Let's consider two cases:

1) an attacker who does not care about congestion control and just wants to flood.

Such a sender can get more packets into the queue with ECN, but sending way too many will eventually create drops at the physical queue limit. In contrast, without ECN, the sender would get occasional drops before it reaches the hard queue limit. How "occasional" these drops are depends on how aggressively the AQM mechanism drops packets - the more aggressive it is, the closer it becomes to operating like the hard queue limit that is there anyway.

This doesn't strike me as a convincing scenario for ECN being truly harmful.

2) an application developer who wants to be better off than everyone else by ECN-enabling packets but ignoring ECN marks.

This application developer cares about network performance, and will therefore want to do some form of congestion control (as illustrated by various applications deliberately doing it: Skype, Adobe's RTMFP, QUIC, ...). Will ECN give this application a persistently better behavior then?

I don't have an answer for the case when the queue is shared with others (but if /  when / how often is not known to the app programmer beforehand). If we consider only flows by this application, and assume TCP-like congestion control, we have example graphs:
see Figure 14.

=> because every ECN-capable packet enters the queue, it influences the dynamics of the AQM mechanism, and what then happens depends on how aggressive the AQM mechanism reacts. Note that these graphs vary quite a bit - they show a rather inconsistent behavior, and definitely do not show that TCP with ECN had persistently higher throughput. Also note that incorrect behavior might increase the delay, and clearly raw throughput is not the main metric of interest to all applications.

So that was ECN vs. no-ECN with TCP. What about applying a different congestion control mechanism to get a benefit?
Well - CUBIC is already more aggressive than standard TCP, with or without ECN, and will "win" against it because it increases faster and backs off by multiplying with 0.7, not 0.5. THIS gives you a higher priority - but you don't need ECN for that.

All in all, the "more throughput by gaming ECN" image seems to be blurry at best.