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

From: Bob Briscoe <[email-masked]>
Date: Mon, 12 Apr 2021 15:43:43 +0100

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 Briscoehttp://bobbriscoe.net/

---

From: Greg White <[email-masked]>
Date: Mon, 12 Apr 2021 23:10:36 +0000

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 <[email-masked]>
Date: Monday, April 12, 2021 at 8:43 AM
To: Greg White <[email-masked]>
Cc: tsvwg IETF list <[email-masked]>
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/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'.

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).

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."

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/