[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
- [Iccrg] Why don't we stop treating ECN and loss s… Mayutan A.
- [Iccrg] Why don't we stop treating ECN and loss s… Mikael Abrahamsson
- [Iccrg] Why don't we stop treating ECN and loss s… David Ros
- [Iccrg] Why don't we stop treating ECN and loss s… Michael Welzl
- [Iccrg] Why don't we stop treating ECN and loss s… ken carlberg
- [Iccrg] Why don't we stop treating ECN and loss s… Mikael Abrahamsson
- [Iccrg] Why don't we stop treating ECN and loss s… ken carlberg
- [Iccrg] Why don't we stop treating ECN and loss s… Mikael Abrahamsson
- [Iccrg] Why don't we stop treating ECN and loss s… Michael Welzl
- [Iccrg] Why don't we stop treating ECN and loss s… João Taveira Araújo
- [Iccrg] Why don't we stop treating ECN and loss s… João Taveira Araújo
- [Iccrg] Why don't we stop treating ECN and loss s… Lachlan Andrew
- [Iccrg] Why don't we stop treating ECN and loss s… Michael Welzl