[tsvwg] A few editorial comments on L4S text.

[Gorry Fairhurst <[e-mail]>]

I suspect the L4S authors will be updating the specs for the next IETF. 
With that in mind I have a few editorial comments:

The following statement in the abstract of L4S arch seems bold 
advertisement. I have seen the IESG object to marketing new protocols, 
and in this case I agree would agree. I also have concerns that this is 
TCP-centric, and L4S may be applicable to other transports.

I wonder if the statement can be rephrased to say that using L4S can 
enable a transport to be scalable.

At the same
time L4S solves the long-recognized problem with the future
scalability of TCP throughput.

I also wonder about this earlier text:
Further, the network part is simple to
deploy - incrementally with zero-config.

Is it actually proven to be “simple” to deploy new classification and 
AQM methods, or is it better to state that L4S can be incrementally 
deployed (and explain zero config)?

===========

I wonder if you would consider rewording the folloiwng in L4S-arch?:

“ However, one queue for every flow can be
thought of as overkill compared to the minimum of two queues for
all traffic needed for the L4S approach. The overkill of per-flow
queuing has side-effects:”

- the words “overkill” seem unnecessary here and mostly unexplained. 
Could this perhaps better be explained by saying what the implications are:
e.g., is the decision to schedule per-flow queues is orthogonal (as in 
RFC XXXX) - although it is fair - I think - to note that per-flow queues 
do not scale to the large number of flows that are seen as traffic 
aggregates away from the edge.

===========

The citation to ABE is ourt of date [I-D.ietf-tcpm-alternativebackoff-ecn]

- please replace REF by RFC 8511.

Gorry