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

[Sebastian Moeller <[e-mail]>]

Hi Bob,

more below in-line.

> On Dec 31, 2019, at 17:55, Bob Briscoe <[e-mail]> wrote:
> 
> 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.

	[SM] Using ECT(1) as a classifier is sub-optimal for a number of reasons, that I will justify here for your entertainment:
1) For classifying between two classes one requires 2 states, or one full bit, ECT(1) however does not meet that criterion, it is a single code-point or colloquially speaking half a bit. Why the theory that ECT(1) can serve as a "classifier" is still maintained in spite of its objective insufficiencies boggles the mind. RFC3168 has an elucidating section giving rationale for the use of two full bits for ECNs two additional states instead of using just a single bit, that shines a pretty good light on this issue and why overloading too much information into a single bit has severe issues.
	Jusy in passing, in L4S classification breaks for packets carrying a CE mark, L4S proposes to carry all of these in the L4S-queue thereby risking increasing packet re-ordering for mis-classified non-L4S flows, fitting well in the L4S approach's tendency to move all the costs of dealing with the "impedance mismatch" between standards-compliant and L4S traffic onto standards-compliant traffic. This btw, is not a slur, this is an objective observation based on the L4S drafts.

2) In essence L4S defines a specific per-hop-behaviour for L4S-marked traffic, and for that purpose there are additional 6 bits reserved in the IPv4 and IPv6 headers, the diffserv bits. Let's have a look at rfc3168 on that topiic:
"One possibility might have been for the data sender to use the fourth
   ECN codepoint to indicate an alternate semantics for ECN.  However,
   this seems to us more appropriate to be signaled using a
   differentiated services codepoint in the DS field."
To which a number of reviewers already concurred.

So I justify the judgment that using ECT(1) as "classifier" is ABUSE, by two lines of argument:
a) does not really work well enough (it fails to act as a classifier under load)
b) it uses an ECN field for a purpose for which dedicated bits are already reserved.



@CHAIRS: For the potential experimental roll-out I propose a requirement/MUST that independent of the ECT(1) code point all L4S-senders also need to set a to-be-defined DSCP, so that the existing filtering and (de-)prioritization infrastructure in the field can be used to implement the desired PHB for L4S traffic.


Best Regards
	Sebastian





> 
> 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/