[tsvwg] Review comments on a careful read of the L4S ID

[Gorry Fairhurst <[e-mail]>]

Here are some review comments on a careful read of the L4S ID that I 
hope will help in preparation of a new revision of the draft. More 
details have been sent to the authors.


Best wishes,


Gorry

=================================================================

*1. Abstract needs to be corrected to accommodate ABE (RFC 8511).*

**

Abstract text says:

“ 'Classic' ECN marking is required to be

equivalent to a drop, both when applied in the network and when

responded to by a transport.”

**

⁃That’s no longer completely correct in light of ABE (RFC 8511), 
although the strong connection between this marking and reaction to 
drops is still the case.Perhaps: ‘Classic’ ECN marking is an enhancement 
to drop-based congestion control, both when applied …

=================================================================

*2 Abstract RTT variance*

**

Abstract text says:

“The two changes counterbalance each other so that the

throughput of an L4S flow will be roughly the same as a non-L4S flow

under the same conditions.”

**

⁃Please insert “comparable” before “non-L4S flow” to avoid bogus flow 
comparisons.

**

*3. The Abstract can be seen as marketing. In the past the IESG has 
taken exception to “claims” in an abstract of a standards-track document 
by marketing of “ultra-low”.*

Abstract text says:

so that _ultra-low and consistently low_

queuing delay (typically sub-millisecond on average) becomes possible

for L4S traffic without compromising link utilization.

⁃Please avoid the assertion of “ultra-low” since this seems like a 
marketing brag.

⁃The abstract is still long, and some of the comparison with ‘Classic 
ECN’ could be moved

⁃into the Introduction.

=================================================================

*4. Please be careful with the words here.*

This text:

“It gives an incremental

migration path so that suitably modified network bottlenecks can

distinguish and isolate existing traffic that still follows the

Classic behaviour, to prevent it degrading the low queuing delay and

low loss of L4S traffic.This specification defines the rules that

L4S transports and network elements need to follow_to ensure they_

_neither harm each other's performance nor that of Classic traffic_.“

⁃I suggest removing _"to ensure they_

_neither harm each other's performance nor that of Classic traffic"_


=================================================================

*5. Please be careful with the words here.*

**

This text:

“This specificationdefines _the protocol to be used for_ a new network

service called low latency, low loss and scalable throughput (L4S).”

**

⁃This document does not define a protocol, so the words "_the protocol 
to be used for" _should be removed.

=================================================================

*6. Add text to acknowledge ABE (RFC 8511)*

**

This text:

“RFC 3168 required an ECN mark to be equivalent to a drop, both when 
applied in the

network and when responded to by a transport.”

**

⁃ABE (RFC 8511) has already modified that drop equivalence.Revise this 
text accordingly.


=================================================================

*7. Introduction needs to sidestep RTT variance*

**

This text:

“Thetwo changes counterbalance

each other so that the throughput of an L4S flow will be roughly the

same as a non-L4S flow under the same conditions.”

**

⁃Please insert “comparable” before “non-L4S flow” to avoid bogus flow 
comparisons.

=================================================================

*8. Please be clear throughout that the IETF is NOT endorsing DCTCP 
spec. as an Internet Protocol, even if the underlying basis is important 
to the L4S transport.*

This text:

“An example of a scalable congestion control that would enable the L4S

service is Data Center TCP (DCTCP), _which until now has been_

applicable solely to controlled environments like data centres

[RFC8257], because it is too aggressive to co-exist with existing

TCP-Reno-friendly traffic. “

and later:

“Note that a transport such as DCTCP is

still not safe to deploy on the Internet _unless it satisfies the_

_requirements listed in Section _4.”

and later still:

“cause Classic ECN

congestion controls sharing the same queue to starve themselves,

which is why they have been confined to private data centres or

research testbeds_(until now)_.”

and

“It turns out that a congestion control algorithm like DCTCP that

_solves_ the latency problem also _solves_ the scalability problem of

Classic congestion controls.”

and

“The L4S service is

for more general traffic _than just_ DCTCP--“

The ID later states:

“As with all transport behaviours, a detailed specification (probablyan 
experimental RFC) will need to be defined for each congestion

control, following the guidelines for specifying new congestion

control algorithms in [RFC5033].”

and Annexe A appears to confirm this.

⁃This would be significantly improved by replacing references to DCTCP 
as a protocol with references to the congestion control method/algorithm 
used by DCTCP: RFC8257 is informational and explicitly explained it is 
not EXP.To me this text in the ID provides many contradictions about 
implying DCTCP as a transport for the Internet. That’s something that 
really grates with me and I much prefer the much later statement in the 
IDthat “a detailed specification (probablyan experimental RFC) will need 
to be defined”. If the claim were different, relating to methods based 
on DCTCP, that might be more acceptable.

Making this a reference DCTCP as a CC method would be good to address my 
issue.

=================================================================

*9. More marketing at the end of the Introduction*

This text:

“It gives an incremental migration path so that suitably modified 
network bottlenecks can

distinguish and isolate existing Classic traffic from L4S traffic to 
prevent the former from

degrading the ultra-low delay and loss of the new scalable transports, 
without harming

Classic performance.”

⁃This is better than the corresponding Abstract text (see item 2 above), 
but still contains marketing – “ultra-low” needs to be changed to either 
“low” or “consistently low”. I suggest toi add  “at the modified network 
bottlenecks” after “without harming Classic performance.”to avoid the 
implication that the absence of harm is global (which is known not to be 
the case).


=================================================================

**

*10. Please avoid making a claim that the IETF is NOT making a statement 
about usability of DSCPs in this document.*

This text grates:

“ However, on access links dedicated to individual sites (homes, small

enterprises or mobile devices), often all traffic at any one time

will be latency-sensitive.Then, given nothing to differentiate

from, Diffserv makes no difference.“

⁃To me this is not balanced. It seems to suggest that setting a DSCP is 
useless. I don’t believe that is the consensus of tsvwg, although at 
some additional pain we can debate the merits of setting DSCPs for a 
traffic - such as the implications in enterprise networks; the 
implications on UP in access points, etc. I’m not against this 
discussion, but needing this to progress the draft seems unfortunate to 
me. “Then, given nothing to differentiatefrom, Diffserv makes no 
difference.” is gratuitous and should be removed.The paragraph continues 
with “Instead, we need to remove the causes of any unnecessary delay.” 
which can be combined into the previous sentence as: “ … will be 
latency-sensitive, making it imperative to remove the underlying causes 
of delay.”Nothing is lost here because the crucial comparison with 
Diffserv is picked up two paragraphs later: “Unlike Diffserv, which 
gives low latency to some traffic at the expense of others, AQM controls 
latency for _all_ traffic in a clas


=================================================================

*11.Reference TCP Cubic in addition to TCP Reno*

**

This text:

“ClassicCongestion Control:A congestion control behaviour that can

co-exist with standard TCP Reno [RFC5681] without causing

significantly negative impact on its flow rate [RFC5033].”

**

⁃This is one of a number of references to TCP Reno, which would be 
enhanced by also referencing TCP Cubic to avoid criticisms that 
comparison with TCP Reno is dated and limited.

=================================================================

*12.Remove “Consensus” from Section 2:*

**

This text:

“2._Consensus_ Choice of L4S Packet Identifier: Requirements

This subsection briefly records the process that led to a _consensus_

choice of L4S identifier, selected from all the alternatives in

Appendix B.”

**

⁃Both instances of the word “consensus” are inappropriate and 
incorrect.Both need to be removed, as IETF consensus is a matter for the 
IETF to determine.

**

=================================================================

**

*13. Position with respect to RFC4774 is rather unclear, which motivates 
a case for alternative semantics for carrier experiments*

This text:

“The L4S treatment is an experimental track alternative packet marking

treatment [RFC4774]”

•RFC4774 states: “The assumption of this document is that when alternate 
semantics are defined for the ECN field, a codepoint in the diffserv 
field is used to signal the use of these alternate ECN semantics to the 
router.” This text and position needs to be clarified, and is being 
discussed in a tsvwg email thread.


=================================================================

*14. Replace “network node”  (part 1)*

**

This text:

“ A network node that implements the L4S service always classifies

arriving ECT(1) packets for L4S treatment and by default classifies

CE packets for L4S treatment unless the heuristics described in

Section 5.3 are employed.”

⁃Use of “network node” is excessive and over-constrains implementations, 
e.g., the techniques in Sections 5.4.1.2 and 5.4.1.3 conflict with this 
sentence.Change “A network node that implements” to “An implementation 
of the L4S service” It would be nice to be at least clear this is 
marking behaviour, e.g. “An implementation that marks using L4S”, or 
something similar.

=================================================================

*15. Avoid attempting to predict the future: don’t use will.*

**

This text:

“ As with all transport behaviours, a detailed specification (_probably_

an experimental RFC) _will_ need to be defined for each congestion

control, following the guidelines for specifying new congestion

control algorithms in [RFC5033].In addition it _will_ need to

document these L4S-specific matters, specifically the timescale over

which the proportionality is averaged, and control of burstiness.”

⁃Please say why this is important to document, we have similar 
requirements in other transport specs.

⁃Reword in present tense - remove both instances of “will” and say “needs”

⁃Replace “probably” with “e.g.,”


=================================================================

*16. RFC 3168 coexistence*

**

This text:

“oA scalable congestion control MUST implement monitoring in order

to detect a likely non-L4S but ECN-capable AQM at the bottleneck.

On detection of a likely ECN-capable bottleneck it SHOULD be

capable (dependent on configuration) of automatically adapting its

congestion response to coexist with TCP Reno congestion controls

[RFC5681] (see Appendix A.1.4 for rationale and a referenced

algorithm).”

⁃This will have to be resolved in the WG, including details of what 
“coexist” means.

=================================================================

*17. RTT Bias: **implementation requirements to documentation requirements*

This text:

“A scalable congestion control MUST eliminate RTT bias as much as

possible in the range between the minimum likely RTT and typical

RTTs expected in the intended deployment scenario (see

Appendix A.1.5 for rationale).”

⁃A writing style that says: must... as hard as possible style is very 
hard to accept for me. Use of an RFC 2119 “MUST” is not appropriate 
here.Please do change “MUST” to “is expected to” as used in the last 
bulleted item. One possibility that would work for me is some rephrasing 
to say “needs to eliminate” and “specifications are REQUIRED to include 
methods that limit RTT bias, although I have no problem with saying “is 
expected to …”.


=================================================================

*18. Loss detection in time-based units.*

This text:

“oA scalable congestion control SHOULD detect loss by counting in

time-based units, which is scalable, as opposed to counting in

units of packets (as in the 3 DupACK rule of RFC 5681 TCP), which

is not scalable.As packet rates increase (e.g., due to new and/

or improved technology), congestion controls that detect loss by

counting in units of packets become more likely to incorrectly

treat reordering events as congestion-caused loss events (see

Appendix A.1.7 for further rationale).This requirement does not

apply to congestion controls that are solely used in controlled

environments where the network introduces hardly any reordering.”

⁃Please replace with text agreed to on the list.

=================================================================

*19. SHOULD document?*

In section 4.4:

“Nonetheless, the specification

of a particular L4S congestion control SHOULD describe how it smooths

the L4S ECN signals fed back to it from the receiver.”

⁃Why is this a RFC2119 SHOULD? I might be OK with requiring for a reason 
- or requiring because it is needed to explain how something is 
prevented, etc, but requiring to document seems very odd to me. Please 
justify or make it not RFC2119; or say SHOULD specify? I suggest do not 
use an RFC 2119 keyword herr or could just say “SHOULD smooth the L4S 
ECN signals fed back to it from the receiver” to talk about what an 
algorithm should do rather than what a document should say.

=================================================================

*20.Reduce “network node” scope (part 2)*

**

In section 5.1:

“A network node that implements the L4S service MUST classify arriving

ECT(1) packets for L4S treatment and, other than in the exceptional

case referred to next, it MUST classify arriving CE packets for L4S

treatment as well.”

⁃Please change to “An implementation of the L4S service MUST classify 
…”This removes conflicts with at least Sections 5.4.1.2 and 5.4.1.3.

=================================================================

*21. Reduce “network node” scope (part 3)*

This text:

“ For backward compatibility in uncontrolled environments, a network

node that implements the L4S treatment MUST also implement an AQM

treatment for the Classic service as defined in Section 1.2.”

⁃Change to “an implementation of the L4S service that supports the L4S 
treatment MUST also implement …”This removes conflicts with at least 
Sections 5.4.1.2 and 5.4.1.3.


=================================================================

*22. Update to include ABE (RFC 8511)*

**

This text:

“Note that, contrary to RFC 3168, a Dual Queue Coupled AQM

implementing the L4S and Classic treatments does not mark an ECT(1)

packet under the same conditions that it would have dropped a Not-ECT

packet, as allowed by [RFC8311], which updates RFC 3168.However, if

it marks ECT(0) packets, it does so under the same conditions that it

would have dropped a Not-ECT packet.”

**

⁃ABE (RFC 8511) has modified that drop equivalence.Revise this text 
accordingly.

=================================================================

*23. What about if a sender uses Not-ECT and ECT(0) in combination? 
Also, reduce “network node” scope (part 4)*

This text:

“Nonetheless, if an implementer is

willing to identify transport-layer flows at a network node, and if

the most recent ECT packet in the same flow was ECT(0), the node MAY

classify CE packets for Classic ECN [RFC3168] treatment.”

⁃Please tell us if you have thought about when the previous packet was 
not-ECT. Has this been considered and is it explicitly required to then 
send a CE mark via the L4S queue? I understand the next para to speak 
only about when next packet was ECT(1).

⁃See other note on “at a network node” and change “the node may” to “the 
implementation MAY”.This removes conflicts with at least Sections 
5.4.1.2 and 5.4.1.3.

⁃It would also help to change “if an implementer is willing” to “if an 
implementation is able”.

⁃If the latter is done, change “If an implementer uses” to “If an 
implementation uses” at the start of the next paragraph.

=================================================================

*24. Requirements in 5.4.1.*

“Such

non-ECN-based packet types _MUST be safe to mix with L4S traffic_

_without harming_the low latency service, where 'safe' is explained in

Section 5.4.1.1.1 below.”

⁃It is not clear what the MUST relates to, I think this needs to be more 
like (you’d still need to explain harm): “Non-L4S packets that are mixed 
with L4S traffic MUST NOT harm the low latency service, where 'safe' is 
explained in Section 5.4.1.1.1 below. and… Consider use of “SHOULD” 
here, as the consequences of not following it are stated, but not the 
current “MUST”.

“Therefore, a network element that

implements L4S in a shared queue MAY classify additional packets into

the L queue if they carry certain non-ECN identifiers.”

⁃This later sentence appears to be a requirement on the same thing, but 
isn’t the same

⁃“MAY classify additional packets” -> “MAY classify additional ‘safe’ 
packets” would provide consistency.

=================================================================

*25. Missing drop-only requirement for excluded traffic*

**

Section 5.4.1.2.Exclusion of Traffic From L4S Treatment – this text:

“The operator MUST NOT alter the end-to-end L4S ECN identifier from

L4S to Classic, because its decision to exclude certain traffic from

L4S treatment is local-only.”

**

⁃I think be the word /its/this/ .

⁃Please add a requirement that ECT(1) traffic excluded from L4S 
treatment MUST be handled as non-ECN traffic (e.g., all congestion 
signalling is via drops), as Classic AQM treatment and ECN marking 
produce the wrong results for such traffic.

=================================================================

*26. L4S Diffserv draft is not being pursued*

**

“[I-D.briscoe-tsvwg-l4s-diffserv] gives a number of examples of such

arrangements to address various requirements. 
[I-D.briscoe-tsvwg-l4s-diffserv]

describes how an operator might use L4S to offer low latency for all L4S 
traffic as well as

using Diffserv for bandwidth differentiation.It identifies two main types

of approach, …”

**

⁃If [I-D.briscoe-tsvwg-l4s-diffserv] is not being pursued, this is not a 
useful reference in a spec RFC.

References to it should be removed by rewriting the text, e.g., “There 
are two primary types of approaches, …”

=================================================================

*27. Appendix B and C
*

**

⁃Appendix B is lengthy, at best loosely connected with the rest of the 
draft, definitely out of date, and not aligned with current WG views of 
this area. This appendix can be removed prior to publication. Appendix C 
is unecessary to the final publication.

*These points below are Nits, but if you don’t think so, we can discuss 
more?*

**

=================================================================

**

*A. Applications?*

This text:

“it SHOULD survive end-to-end between source and destination applications”

⁃Unclear what applications mean here?

=================================================================

*B. List style uses semicolon at end of item?*

“oit SHOULD be visible at the IP layer”

⁃add semicolon to match style of list.

=================================================================

*C. Seems very similar, does it need to be repeated?*

This para in section 5.2, seems very similar to the para in section 5.1.

“Note that, contrary to RFC 3168, a Dual Queue Coupled AQM

implementing the L4S and Classic treatments does not mark an ECT(1)

packet under the same conditions that it would have dropped a Not-ECT

packet, as allowed by [RFC8311], which updates RFC 3168.However, if

it marks ECT(0) packets, it does so under the same conditions that it

would have dropped a Not-ECT packet.”

⁃Seems very similar, does it need to be repeated? Can this text be 
reduced/removed?

=================================================================

*D. Seems very similar, does it need to be repeated?*

In sect 5.2, can we remove:

“Also, L4S CE marking needs to be interpreted as an unsmoothed signal,

in contrast to the Classic approach in which AQMs filter out

variations before signalling congestion.“

⁃Could this simply refer to section 4.4?

=================================================================

*E. I don’t understand this:*

“_(or perhaps they comply with L4S behaviour and can respond to ECN_

_feedback, but perhaps cannot set the ECN field for some reason)_”

⁃What is the extra point here in brackets? and how can the flow be 
compliant but not set ECT(1) and so doesn’t respond… This all seems like 
a difficult point to pursue - or maybe it simply does not need to be 
said at all. Can we delete this parenthesis?

=================================================================

*F. NiT: lightweight*

“certain protocols that are usually _lightweight_

“

⁃I think we have elsewhere called these “Low Data-Volume Applications”. 
The term lightweight is used in other places in the IETF for other meanings.

=================================================================

*G. What does this sentence mean, and why say it?*

**

*“*Of course, a packet that carried both the ECT(1) codepoint and a non-

ECN identifier associated with the L queue would be classified into

the L queue.”

⁃This confuses me - is it saying that NQB would be classified to the L 
queue, even if ECT(1)-marked, which isn’t something you talk about. or 
is it implying more. If this is what you intend, I think it would be 
much clearer to say nothing, or explain more.

⁃The following paras are also maybe to exhaustive, maybe it is rather 
worth writing this simply.

=================================================================

*H. List style uses semicolon at end of item?*

In sect 6.2, and6.3. Theitems in the bullet list do not end in 
semi-colons; but do elsewhere.

=================================================================

*I. List style uses semicolon at end of item?*

Editorial Annex 1:

“ But they cannot

easily satisfy this loss recovery requirement._However, it is_

_believed they do not need to. _It is believed that such

implementations solely exist in controlled environments,…“

⁃GF: is the sentence with “however...” strictly required here? I fear it 
could be mistakenly read, and without it, the next sentence is clear 
about what is intended.

=================================================================

*J. Please don’t assume what TCPM will publish.*

“This means these packets

are not protected from congestion loss by ECN, which considerably

harms performance, particularly for short flows.

[I-D.ietf-tcpm-generalized-ecn] _counters each argument in RFC 3168 in_

_turn, showing it was over-cautious.Instead it _proposes experimental

use of ECN on all types of TCP packet as long as AccECN feedback

[I-D.ietf-tcpm-accurate-ecn] is available (which itself satisfies the

accurate feedback requirement in Section 4.2 for using a scalable

congestion control).”

⁃I don’t like this interpretation of what TCPM will finally conclude is 
useful. It’s OK to say this proposes something, if you want to say it 
concludes something then we need to block publication on the prior 
publication of the other ID. Can you please please remove “counters each 
argument in RFC 3168 in turn, showing it was over-cautious.Instead it “

=================================================================

*K. Typo?*

“to 4 4 Mb/s”

⁃is this correct?