Re: [tsvwg] Review of draft-white-tsvwg-l4sops-02

[Greg White <[e-mail]>]

Bob,

Thanks for the detailed review and suggested edits.  I am working on a WG draft 00 and will take these suggestions (along with others provided on the list and a few offline comments) into account for that version.

-Greg


From: Bob Briscoe <[e-mail]>
Date: Monday, April 12, 2021 at 8:43 AM
To: Greg White <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>
Subject: Review of draft-white-tsvwg-l4sops-02

Greg,

Here's a review of draft-white-tsvwg-l4sops-02 that was recently adopted by the WG.

Abstract:
CURRENT:
This document is intended to provide additional guidance to operators of end-systems, operators of networks, and researchers beyond that provided in [I-D.ietf-tsvwg-ecn-l4s-id] and [I-D.ietf-tsvwg-aqm-dualq-coupled] in order to ensure successful deployment of L4S [I-D.ietf-tsvwg-l4s-arch] in the Internet. The focus of this document is on potential interactions between L4S flows and Classic ECN ([RFC3168]) flows in Classic ECN bottleneck links. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of [RFC3168] bottlenecks, and identifies opportunites to prevent and/or detect and resolve fairness problems in such networks.
PROPOSED:
This document is intended to provide guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck link. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers.
Rationale: Broken down first sentence into three more manageable chunks, and order changed to improve the logical progression.
Also
·         expanded L4S,
·         'opportunites' mistyped
·         citations removed (RFC style guide deprecates citations in the abstract).
1. Intro

CURRENT:
Although RFC3168 has been ... specified in [I-D.ietf-tsvwg-ecn-l4s-id], not all deployed queues have been updated accordingly ...
PROPOSED:
RFC3168 has been ... specified in [I-D.ietf-tsvwg-ecn-l4s-id]. However, any deployed RFC 3168 AQMs might not be updated, ...
Rationale: Shouldn't imply that equipment will ever be updated. Also, broken down long sentence.

"The root cause of the unfairness is ..."
Consider switching the order of the sentence, so that the new L4S is the root cause, not the old RFC3168.

s/implement legacy RFC3168 ECN/
 /implement RFC3168 ECN/
Rationale: RFC3168 is the stds track.

s/can also potentially occur in fq_codel [RFC8290] bottlenecks /
 /can also potentially occur with per-flow queuing, e.g. fq_codel [RFC8290], /

s/Additionally, this issue was considered and is discussed in Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id]./
 /<New para>This issue was considered when the WG decided on the identifier to use for L4S, as recorded in Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id]./

2. Per-Flow Fairness

s/capacity sharing between the applications used by one customer./
 /capacity sharing between the applications used by one customer site./
(The whole doc could refer to l4s-arch for terminology, which includes a definition of 'site'.)

I don't find the HotNets paper on harm a very useful reference. It overlooks large tracts of the existing literature which already said similar things, and it also overlooks other areas of the literature that said different things.
RFC5290 might be a better reference, altho not specifically about harm. It's on the independent stream, so that ought to be stated (i.e. it reflects only the opinions of the authors, not the IETF). It gives a lot of reasons why flow-rate fairness may not be correct or optimal, but it's just convenient.

CURRENT:
Most importantly, if there are situations in which the introduction of L4S traffic would degrade classic traffic performance significantly, i.e. to the point that it would be considered starvation, these situations need to be understood and either remedied or avoided.
PROPOSED:
Most importantly, if there are situations in which the introduction of L4S traffic would degrade both the absolute and relative performance of classic traffic significantly, i.e. to the point that it would be considered starvation while L4S was not starved, these situations need to be understood and either remedied or avoided.
Rationale: Distinguish between starvation of Classic when L4S is starving as well vs. when L4S isnt'.

3. Detection of Classic ECN Bottlenecks

s/VPN tunnels remain an issue for fq_codel deployments/
 /VPN tunnels remain an issue for FQ deployments/

s/in which case fq_codel implementations /
 /in which case FQ implementations /

========================================
Jumping over Section 4 for now...
========================================

 5.2. ECT(1) Tunnel Bypass

CURRENT:
Using an [RFC6040] compatibility mode tunnel, tunnel ECT(1) traffic through the [RFC3168] bottleneck with the outer header indicating Not-ECT.
PROPOSED:
Tunnel ECT(1) traffic through the [RFC3168] bottleneck with the outer header indicating Not-ECT, by using either an ECN tunnel ingress in Compatibility Mode [RFC6040] or a Limited Functionality ECN tunnel [RFC3168].
RATIONALE: If there's a legacy RFC3168 AQM on the node, there might be RFC3168 tunnelling code too.
Note that RFC6040 is a property of the tunnel ingress alone, whereas RFC3168 is a property of the tunnel (both ends).

5.3. Configure Non-Coupled Dual Queue

s/As a result it is a less prefered option./
 /As a result it is the less preferred option./
(Note: prefered was also misspelled)

5.5. Disable RFC3168 Support

s/Disabling [RFC3168] CE marking for both ECT(0) traffic and ECT(1) traffic/
 /Disabling an [RFC3168] AQM from CE marking both ECT(0) traffic and ECT(1) traffic/
Rationale: To be unambiguous that this does not mean wiping the ECT codepoints.

s/Clearly a downside to this approach is that .../
 /This is not recommended, given a downside to this approach is that clearly .../
Then add "This alternative is only mentioned in case there is no other way to reconfigure an RFC3168 AQM."

5.6 Re-mark ECT(1) to NotECT Prior to AQM

CURRENT:
While not a recommended alternative, remarking ECT(1) packets as NotECT (i.e. bleaching ECT(1)) ensures that they are treated identically to classic NotECT senders. However, this also eliminates the possibility of downstream L4S bottlenecks providing high fidelity congestion signals.
PROPOSED:
Remarking ECT(1) packets as NotECT (i.e. bleaching ECT(1)) ensures that they are treated identically to classic NotECT senders. However, this action is not a recommended because a) it would also prevent downstream L4S bottlenecks from providing high fidelity congestion signals; and b) it could lead to problems with future experiments that use ECT(1) in alternative ways to L4S. This alternative is only mentioned in case there is no other way to reconfigure an RFC3168 AQM.<New para>Note that the CE codepoint must never be bleached, otherwise it would black-hole congestion indications.
Rationale:
·         Makes the link between the recommendation and the reason for the recommendation.
·         Clarifies that ECT(1) means only ECT(1).
For both 5.5. & 5.6., I think it's necessary to say why the draft is even mentioning these options, given they are not recommended.


Bob


--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/