Re: [aqm] Gaming ECN

[Michael Welzl <[e-mail]>]

> On 21. mar. 2015, at 17.47, David Lang <[e-mail]> 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:
https://www.duo.uio.no/handle/10852/37381
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.


Cheers,
Michael