[tsvwg] ECN as a classifier (was: L4S vs SCE)

[Bob Briscoe <[e-mail]>]

Roland,

I just noticed that Koen's response (which I agreed with) snipped some 
of your responses that I ought to have addressed.
For this one, I've forked a new thread...

On 22/11/2019 02:32, Roland Bless wrote:
> Hi Bob,
>
> see inline.
>
> On 21.11.19 at 15:44 Bob Briscoe wrote:
>> On 21/11/2019 09:32, Roland Bless wrote:
>>> On 21.11.19 at 19:34 Bob Briscoe wrote:
>>>> On 20/11/2019 21:22, Roland Bless wrote:
> I find it architecturally cleaner to have an additional ECN codepoint
> used for indicating "SCE" rather than (ab)using it as classifier for the
> dualQ AQM.

The idea that it is abuse to use ECN as a classifier has never been 
justified, only asserted.

The actual position is pretty much the opposite. Below I explain why L4S 
follows the original way the architecture of the ECN field was defined. 
Whereas the way SCE uses the ECN field for 2-level marking is counter to 
the original ECN architecture.

The ECN field is unlike any other field in the IP header, because it 
conveys a value from the sender down the layers to L3 or L2 and it 
conveys a 'return' value from any node in the network back up the stack 
to the receiving endpoint.

Originally, in RFC3168:

  * for the sender->network interface, the ECN field was defined as a
    way for the sender to classify a packet between different code paths
    in AQM algorithms (drop for 00 vs. marking for the other 3
    codepoints). Certainly, it wasn't /envisaged/ that it would be used
    to classify between different queues. But /architecturally/ there is
    no difference.
  * for the network->receiver interface, the two semantically identical
    ECT(X)->CE transitions were defined as the only way for the network
    to signal congestion.

The two original standards track RFCs that originally defined ECN 
tunnelling [RFC3168] & [RFC4301] were both incompatible with 2-level 
marking like SCE. They required the decapsulation at the end of a tunnel 
to forward the inner header's ECN field unless the outer was CE. So they 
would strip any SCE signal applied to the outer header.

Around 2010, when I was rationalizing these two diverging tunnel 
definitions into one [RFC6040] (also standards track), I noticed that 
precluding 2-level marking was unnecessarily restrictive. So we defined 
the way ECN propagates to the forwarded header from the outer so that 
future tunnels would support either meaning of ECT(1): either equivalent 
to ECT(0) or a weaker congestion signal than CE, like SCE.

However, the original RFC3168 ECN architecture (that is incompatible 
with SCE) remains and will remain more widely supported in the Internet, 
probably for decades. Indeed, even today, the RFCs to make that change 
to all encapsulations (not just IP-in-IP tunnels) are not past the WG 
stage yet.

Tunnels and encapsulations are everywhere. Jonathan M says it doesn't 
matter if the SCE signal gets black-holed in tunnels and encapsulations. 
Eventually new ones compatible with the SCE architecture will be 
deployed everywhere (which will take decades). But it does matter - 
because SCE wants to claim the last available ECN codepoint, which L4S 
has already developed to give consistently low latency - within the 
original ECN architecture.


Regards



Bob

> Roland
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/