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

lists@syshex.com ( João Taveira Araújo ) Sun, 28 October 2012 18:07 UTC

From: lists@syshex.com
Date: Sun, 28 Oct 2012 18:07:30 +0000
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <920D98EE-EFEB-47E2-879C-84999F258771@ifi.uio.no>
References: <920D98EE-EFEB-47E2-879C-84999F258771@ifi.uio.no>
Message-ID: <1351445338-sup-8866@moonloop.syshex.com>
X-Date: Sun Oct 28 18:07:30 2012

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.

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?

Joao

> I'm curious what everyone thinks... am I missing something?
> 
> Cheers,
> Michael
>