[Ecn-sane] [tsvwg] Comments on L4S drafts

[Sebastian Moeller]

> On Jul 19, 2019, at 20:33, Wesley Eddy <wes at mti-systems.com> wrote:
> 
> On 7/19/2019 11:37 AM, Dave Taht wrote:
> [...]
>> In particular conflating "low latency" really confounds the subject
>> matter, and has for years. FQ gives "low latency" for the vast
>> majority of flows running below their fair share. L4S promises "low
>> latency" for a rigidly defined set of congestion controls in a
>> specialized queue, and otherwise tosses all flows into a higher latency
>> queue when one flow is greedy.
> 
> I don't think this is a correct statement.  Packets have to be from a "scalable congestion control" to get access to the L4S queue.  

	With the current proposal, a packet needs to set the ECT(1) codepoint, there is _no_ checking whether there is a "scalable congestion control" operational on this flow. Even worse every CE-marked packet will be put into the L4S queue; the latter is a consequence of the currently preferred choice of using ECT(1) as L4S classifying bit. Sure the queue protection feature might help to demote flows not playing along the L4S rules back into the RFC3168 queue, but queue protection is advertized as optional....


> There are some draft requirements for using the L4S ID, but they seem pretty flexible to me.  Mostly, they're things that an end-host algorithm needs to do in order to behave nicely,

	Except there is no real enforcement/measurement whether flows "behave nicely", at least as far as I can see.


> [...]
> 
>> So to me, it goes back to slamming the door shut, or not, on L4S's usage
>> of ect(1) as a too easily gamed e2e identifier. As I don't think it and
>> all the dependent code and algorithms can possibly scale past a single
>> physical layer tech, I'd like to see it move to a DSCP codepoint, worst
>> case... and certainly remain "experimental" in scope until anyone
>> independent can attempt to evaluate it.
> 
> That seems good to discuss in regard to the L4S ID draft.  There is a section (5.2) there already discussing DSCP, and why it alone isn't feasible.  There's also more detailed description of the relation and interworking in https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02

	IMHO a new protocol ID is the solution:
See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#appendix-B.4"

'B.4.  Protocol ID


   It has been suggested that a new ID in the IPv4 Protocol field or the
   IPv6 Next Header field could identify L4S packets.  However this
   approach is ruled out by numerous problems:

   o  A new protocol ID would need to be paired with the old one for
      each transport (TCP, SCTP, UDP, etc.);

   o  In IPv6, there can be a sequence of Next Header fields, and it
      would not be obvious which one would be expected to identify a
      network service like L4S;

   o  A new protocol ID would rarely provide an end-to-end service,
      because It is well-known that new protocol IDs are often blocked
      by numerous types of middlebox;

   o  The approach is not a solution for AQMs below the IP layer;"


None of these points are show stoppers, IMHO:
1) Especially since in all likelihood only two new protocol IDs will be needed, "AIAD TCP" and "AIAD UDP". 
2) The IPv6 issue is a bit of a red herring as the next header field typically seems to contain the exact same number as IPv4's protocol field and chained headers are probably rare. Also if the primary next header is not of an L4S type, simply treating the flow as RFC3168 compliant seems like a safe option.
3) Okay that is a challenge, but ig L4S is worth its salt, it will offer enough incentives to overcome this hurdle, otherwise why waste ECT(1) on something that the market/the network community does not seem to want?
4)
Me: "Doctor it hurts if I put an AQM below the IP layer."
Physician: " Do not do that then!"
Honestly, how is an AQM below the IP layer (so L1/L2) going to act on IP's ECN code points as required for L4S, but going to fail to look at the protocol/next header field?

This is a really clean solution for L4S issues with the currently proposed badly fitting classifier, that solves all issues with interoperability with the rest of the current internet. 

[...]


Best Regards
	Sebastian