[Iccrg] Why don't we stop treating ECN and loss similarly?

michawe@ifi.uio.no (Michael Welzl) Mon, 29 October 2012 07:57 UTC

From: michawe@ifi.uio.no
Date: Mon, 29 Oct 2012 07:57:42 +0000
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <1351445338-sup-8866@moonloop.syshex.com>
References: <920D98EE-EFEB-47E2-879C-84999F258771@ifi.uio.no> <1351445338-sup-8866@moonloop.syshex.com>
Message-ID: <2E6D3BD2-034D-4E2C-872B-D11A4C4330D9@ifi.uio.no>
X-Date: Mon Oct 29 07:57:42 2012

Hi,

inline:

On 28. okt. 2012, at 19:13, Jo?o Taveira Ara?jo wrote:

> Hi,
> 
> Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
>> Hi,
>> 
>> Here's an idea, inspired by something Bob Briscoe posted to the TSVWG  
>> list recently in a discussion of draft-carlberg-tsvwg-ecn-reactions.  
>> However, this possibly stupid idea is my own responsibility alone  :-)
>> 
>> 
>> According to RFC 3168, senders must react to ECN just as if packets  
>> had been dropped. This is to maintain fairness between ECN-compatible  
>> and non-compatible flows.
>> Because of this requirement, AQMs cannot ECN-mark packets more  
>> aggressively than it drops packets from non-ECN-capable flows - else  
>> ECN-marked flows would be at a disadvantage.
>> 
>> We have seen various non-standard congestion control behaviors can co- 
>> exist reasonably well with standard TCP in practice. If it was  
>> possible to have a milder congestion reaction to ECN-based reaction,  
>> it would also be possible to ECN-mark packets earlier, leading to a  
>> bigger advantage for everyone using ECN. And none of this is possible  
>> when we have the "treat an ECN mark just like loss" rule in place.
>> 
>> Hence, my question: to incentivize ECN usage and enable better  
>> behavior when it's used, shouldn't we remove this rule?
>> 
>> Note that this is not even about a more fine-grain interpretation of  
>> ECN feedback - it's more like an intermediate step.
> 
> With research hat off, I'd be wary of making such changes. 
> As you point out, the specification of ECN is overly conservative (more
> so than DECbit for example), but I believe TCP fairness alone was only 
> part of it. The Source Quench option had proved a debacle because
> gateways had no expectation on how hosts would react, and hosts had
> little indication on what the option was intended to signal. That SQ 
> ended being rendered useless through a myriad of interpretations may
> explain why ECN adhered so strictly to well understood principles and 
> concisely specified behaviour.

Hm, I can see that -

> 
> It would be simpler to answer your thought experiment if you take it one
> step further: what would you replace the rule with, and how would the
> coexistence of both not be detrimental to ECN as a standard?

... and THIS is interesting research to pursue!

Perhaps some of the ideas for reacting to a finer-grain ECN signal will lead to an answer to that.

Cheers,
Michael