The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
draft-ietf-tsvwg-ecn-l4s-id-29

[Ballot comment]
Thank you to Valery Smyslov for the SECDIR review.

Thanks for addressing my DISCUSS.

===

** Section 1.  Could the applicability domain be more strongly stated:
OLD
  Note that a scalable
  congestion control is still not safe to deploy on the Internet unless
  it satisfies the requirements listed in Section 4.

NEW
Note that a scalable congestion control described in this document MUST NOT be deploy on the Internet unless it satisfies the requirements listed in Section 4.

** Section 3.  Thanks for explaining the rationale for the list of “SHOULD-based” requirements.  Is the WG confident that some of these can’t be a “MUST”?  For example, “it SHOULD be visible at the IP layer”, if it isn’t visible at the IP layer what would this be?

** Section 4.3.  Bullet 5.
      A scalable congestion control SHOULD remain responsive to
      congestion when typical RTTs over the public Internet are
      significantly smaller because they are no longer inflated by
      queuing delay.

I’m having trouble parsing this sentence – “A scalable congestion control SHOULD remain responsive to congestion ...”.  Isn’t being responsive to congestion, the purpose of congestion control. 

The subsequent text seems to describe a qualifying situation of smaller RTTs?

** Section 4.3.  Bullet 7
      No normative requirement to limit bursts
      is given here and, until there is more industry experience from
      the L4S experiment, it is not even known whether one is needed -
      it seems to be in an L4S sender's self-interest to limit bursts.

This text questioning the need for this requirement seems to undermine it’s inclusion in a list of “MUST” items.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
CC @evyncke

Thank you for the work put into this document. Like well-written by Paul Wouters in another review, I am not a TSV person...

I also appreciate the experimental status with a description of the experiment itself.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Wesley Eddy for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS

### Update RFC 3168

No need to comment, but it was very smart for the authors of RFC 8511 to allow such experiments ;-)

There is some duplicate text in sections 1.3 and 2 on this though...

### Section 1

A lot of the content of this section appears to be identical or similar to the architecture draft. Consider removing some text ?

### BCP 14

Please use the right template for BCP14 in section 1.2.

### Section 5.4.1.1 unresponsive

Is `unresponsive traffic` a well-defined term ?

### Section 5.4.1.1 ARP, DNS

In the example for low-level traffic, ARP, DNS, I am unsure whether ARP is really routed through an IP network ;-) or are Ethernet switches also covered by this I-D? You may also qualify 'DNS' into 'DNS queries'.

### Section 6.2

```
  ... If a mix of L4S and Classic packets is sent into the same security
  association (SA) of a virtual private network (VPN), and if the VPN
  egress is employing the optional anti-replay feature, ...
```

Suggest to used IPsec in tunnel mode as they are many kinds of VPNs.




## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
CC @evyncke

Thank you for the work put into this document. Like well-written by Paul Wouters in another review, I am not a TSV person...

I also appreciate the experimental status with a description of the experiment itself.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Wesley Eddy for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

###

## COMMENTS

### Update RFC 3168

No need to comment, but it was very smart for the authors of RFC 8511 to allow such experiments ;-)

There is some duplicate text in sections 1.3 and 2 on this though...

### Section 1

A lot of the content of this section appears to be identical or similar to the architecture draft. Consider removing some text ?

### BCP 14

Please use the right template for BCP14 in section 1.2.

### Section 5.4.1.1 unresponsive

Is `unresponsive traffic` a well-defined term ?

### Section 5.4.1.1 ARP, DNS

In the example for low-level traffic, ARP, DNS, I am unsure whether ARP is really routed through an IP network ;-) or are Ethernet switches also covered by this I-D? You may also qualify 'DNS' into 'DNS queries'.

### Section 6.2

```
  ... If a mix of L4S and Classic packets is sent into the same security
  association (SA) of a virtual private network (VPN), and if the VPN
  egress is employing the optional anti-replay feature, ...
```

Suggest to used IPsec in tunnel mode as they are many kinds of VPNs.




## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# Internet AD comments for {draft-ietf-tsvwg-ecn-l4s-id-28}
CC @ekline

## Comments

### S1.2

* You could just replace the first paragraph with the standard text from
  RFC 8174 Section 2 (final paragraph).

[Ballot discuss]
Section 4.3.

In order to coexist safely with other Internet traffic, a scalable
  congestion control MUST NOT tag its packets with the ECT(1) codepoint
  unless it complies with the following bulleted requirements:

Based on the use of “MUST NOT”, my read of this text is that all subsequent list items must comply with this list.  List items #3, 5 and 6 include SHOULD clauses.  How an implementer mix the “MUST” and and SHOULD clause?

As simply fix might be to drop the "MUST NOT" in the preamble to the bulleted list.

[Ballot comment]
Thank you to Valery Smyslov for the SECDIR review.

** Section 1.  Could the applicability domain be more strongly stated:
OLD
  Note that a scalable
  congestion control is still not safe to deploy on the Internet unless
  it satisfies the requirements listed in Section 4.

NEW
Note that a scalable congestion control described in this document MUST NOT bed deploy on the Internet unless it satisfies the requirements listed in Section 4.

** Section 1.1.
  Even with a perfectly tuned AQM,
  the additional queuing delay at the tips of the sawteeth will be of
  the same order as the underlying speed-of-light delay across the
  network , thereby roughly doubling the total round-trip time.

Per “speed-of-light delay”, this technology isn’t appropriate for electrical impulses over copper (Cat-5e/6)?

** Section 3.  Thanks for explaining the rationale for the list of “SHOULD-based” requirements.  Is the WG confident that some of these can’t be a “MUST”?  For example, “it SHOULD be visible at the IP layer”, if it isn’t visible at the IP layer what would this be?

** Section 4.3
3.  In uncontrolled environments , monitoring MUST be implemented to
      support detection of problems with an ECN-capable AQM at the path
      bottleneck that appears not to support L4S and might be in a
      shared queue. Such monitoring SHOULD be applied to live traffic
      that is using Scalable congestion control. 

-- What is an “uncontrolled environment”?
-- What is “live traffic”?

** Section 4.3.  Bullet 5.
      A scalable congestion control SHOULD remain responsive to
      congestion when typical RTTs over the public Internet are
      significantly smaller because they are no longer inflated by
      queuing delay.

I’m having trouble parsing this sentence – “A scalable congestion control SHOULD remain responsive to congestion ...”.  Isn’t being responsive to congestion, the purpose of congestion control. 

The subsequent text seems to describe a qualifying situation of smaller RTTs?

** Section 4.3.  Bullet 7
      No normative requirement to limit bursts
      is given here and, until there is more industry experience from
      the L4S experiment, it is not even known whether one is needed -
      it seems to be in an L4S sender's self-interest to limit bursts.

This text questioning the need for this requirement seems to undermine it’s inclusion in a list of “MUST” items.

** Section 5.2.  Per “The relative strengths of L4S CE and drop are irrelevant ...”, is this the same as saying s/strengths/advantages/?

** Section 5.4.1.1.
  Examples of relevant non-ECN
  identifiers are:
...
  certain low data-volume applications or protocols  (e.g. ARP, DNS);

I was under the impression that the appeal of L4S is that it doesn’t require inspection beyond the IP header.  The architecture document says “However, the main innovation of L4S is the DualQ AQM framework that does not need to inspect any deeper than the outermost IP header, because the L4S identifier is in the IP-ECN field” in Section 8.5  How does one determine that something is a “low data-volume” without inspecting into the payload?

[Ballot comment]
# GEN AD review of draft-ietf-tsvwg-ecn-l4s-id-28

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/9zLPRZCsnpKY4Zi-XFmqMQ7Lvq0).

## Comments

### Section 1.1, paragraph 3
```
    The bufferbloat project has shown that excessively-large buffering
```
Cite bufferbloat.net?

### Section 1.2, paragraph 2
```
    Note: The L4S architecture [I-D.ietf-tsvwg-l4s-arch] repeats the
    following definitions, but if there are accidental differences those
    below take precedence.
```
Instruct the RFC Editor to remove this paragraph?

### Boilerplate

This document uses the RFC2119 keywords ['RECOMMENDED', 'SHOULD NOT', 'MAY',
'SHALL', 'MUST', 'SHALL NOT', 'REQUIRED', 'MUST NOT', 'NOT RECOMMENDED',
'OPTIONAL', 'SHOULD'], but does not contain the recommended RFC8174
boilerplate. (It contains a variant of the RFC2119 boilerplate.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 1
```
-    This experimental track specification defines the protocol to be used
-        -------------------
```

### Outdated references

Reference `[RFC2309]` to `RFC2309`, which was obsoleted by `RFC7567` (this may
be on purpose).

Reference `[RFC6347]` to `RFC6347`, which was obsoleted by `RFC9147` (this may
be on purpose).

Reference `[RFC4960]` to `RFC4960`, which was obsoleted by `RFC9260` (this may
be on purpose).

### URLs

These URLs in the document did not return content:

* http://www.icir.org/floyd/red.html
* https://www.bell-labs.com/usr/koen.de_schepper
* http://www.hpcc.jp/pfldnet2009/Program_files/1569198525.pdf

These URLs in the document can probably be converted to HTTPS:

* http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6871352
* http://doi.acm.org/10.1145/1080091.1080098
* http://ee.lbl.gov/papers/congavoid.pdf
* http://bobbriscoe.net/
* http://dl.acm.org/citation.cfm?doid=2999572.2999578

### Grammar/style

#### Section 1.1, paragraph 2
```
creasing level of discard from the buffer the longer the queue persists abov
                                  ^^^^^^
```
It appears that a comma is missing.

#### Section 1.1, paragraph 6
```
e sawteeth cause minimal queue delay but the troughs underutilize the link,
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 1.1, paragraph 6
```
the troughs utilize the link better but then the tips cause more delay vari
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 1.1, paragraph 7
```
ariations it inflicts on itself. Therefore those applications that need to s
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 1.1, paragraph 13
```
svwg-l4s-arch] and in [RFC3649]. Therefore control of queuing and utilizatio
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 1.2, paragraph 6
```
(e.g. DNS, VoIP, game sync datagrams, etc). Reno-friendly: The subset of Clas
                                      ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 1.2, paragraph 11
```
update any standards track RFCs. Therefore it depends on [RFC8311], which is
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2, paragraph 7
```
ted space left in the IP header. Therefore a compromise will always be neces
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2, paragraph 8
```
s chosen as the best compromise. Therefore this scheme is defined in detail
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 4.2, paragraph 2
```
the sawtooth yields, on average it take this time to recover to its previou
                                    ^^^^
```
After "it", use the third-person verb form "takes".

#### Section 4.2, paragraph 4
```
ntrol algorithms in [RFC5033]. In addition it is expected to document these L
                                  ^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "addition".

#### Section 4.3, paragraph 14
```
receiver(s) when they send data. Therefore there might be ECT(1) packets in
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 4.3.1, paragraph 1
```
ers, nor that there will be rarity in future. - Per-Flow-queues with Classic
                                  ^^^^^^^^^
```
The phrase "in future" is British English. Did you mean: "in the future"?

#### Section 4.3.1, paragraph 2
```
apsulated within one flow ID. To summarize, the coexistence problem is confi
                                ^^^^^^^^^
```
Do not mix variants of the same word ("summarize" and "summarise") within a
single text.

#### Section 4.3.1, paragraph 13
```
the network doesn't know the RTTs of any of the flows, so it has to smooth ou
                                  ^^^^^^^^^
```
Consider simply using "of" instead.

#### Section 4.3.1, paragraph 13
```
ext (start-up, congestion avoidance, etc). Therefore, this document places n
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 4.3.1, paragraph 15
```
eatment as well, unless overridden by a another classifier or unless the exce
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 5.2, paragraph 2
```
hared by L4S and non-L4S traffic. Instead it will be called the low latency
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Instead".

#### Section 5.4.1.1, paragraph 8
```
ve its locally-applied exclusions in future, e.g. if it wishes to widen the b
                                  ^^^^^^^^^
```
The phrase "in future" is British English. Did you mean: "in the future"?

#### Section 5.4.1.3, paragraph 5
```
would be opportunities to alter the WiFi profiles sent out of any WiFi inter
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 5.4.1.3, paragraph 5
```
r the WiFi profiles sent out of any WiFi interfaces from the same device, in
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 5.4.1.3, paragraph 6
```
tigate incoming bursts of aggregated WiFi frames from other WiFi stations. 6
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 5.4.1.3, paragraph 7
```
of aggregated WiFi frames from other WiFi stations. 6. Behaviour of Tunnels
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 6.2, paragraph 2
```
ansport protocols (TCP, QUIC, RMCAT, etc)? Monitoring for harm to other traf
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 7, paragraph 1
```
is cut down, what becomes the 'second longest pole in the tent' (other than
                              ^^^^^^^^^^^^^^
```
It appears that a hyphen is missing.

#### Section 7.2, paragraph 2
```
ing TCP for Low Round Trip Delay", Masters Thesis, Uni Oslo , August 2019, <h
                                  ^^^^^^^
```
For an academic degree, use "Master's".

#### Section 7.3, paragraph 4
```
TCP BBR v2 Alpha/Preview Release", github repository; Linux congestion contr
                                  ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

#### Section 8, paragraph 5
```
st, P. and J. Morton, "L4S Tests", github README, May 2021, <https://github.c
                                  ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

#### Section 10.2, paragraph 7
```
Rapid Acceleration in TCP Prague", Masters Thesis , May 2018, <https://ritepr
                                  ^^^^^^^
```
For an academic degree, use "Master's".

#### Section 10.2, paragraph 25
```
y Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, DOI
                              ^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text.

#### Section 10.2, paragraph 36
```
ReAM-L4S] Johansson, I., "SCReAM", github repository; , <https://github.com/E
                                  ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

#### Section 10.2, paragraph 43
```
endations in Section 4) have become know as the Prague L4S Requirements, bec
                                    ^^^^
```
Did you mean "known"?

#### "Appendix A.", paragraph 3
```
rhaps impossible) to determine whether or not the AQM is in a shared queue.
                              ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### "Appendix A.", paragraph 4
```
whether it is in a shared queue, summarized here. An L4S-enabled test server
                                  ^^^^^^^^^^
```
Do not mix variants of the same word ("summarize" and "summarise") within a
single text.

#### "A.1.5.", paragraph 13
```
n order stays roughly invariant. Therefore hosts have an incentive to detect
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### "A.1.5.", paragraph 14
```
is an exception, covered later). Therefore requiring L4S hosts to detect los
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### "A.1.5.", paragraph 16
```
the proportion of L4S traffic, the less of a scaling challenge they will ha
                                    ^^^^
```
The phrase "the less of" is not correct. Use a noun, not an adjective, between
"the" and "of".

#### "A.1.5.", paragraph 16
```
ing challenge they will have. To summarize, there is no reason for L4S hosts
                                ^^^^^^^^^
```
Do not mix variants of the same word ("summarize" and "summarise") within a
single text.

#### "A.1.6.", paragraph 3
```
trol packets and retransmissions. Similarly RFC 6679 precludes the use of ECT
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Similarly".

#### "A.1.8.", paragraph 15
```
ver a VPN will need to be able to recognize the symptoms of this problem, in
                                  ^^^^^^^^^
```
Do not mix variants of the same word ("recognize" and "recognise") within a
single text.

#### "A.1.8.", paragraph 16
```
packets, because an L4S AQM will recognize the ECT(0) packets as Classic and
                                  ^^^^^^^^^
```
Do not mix variants of the same word ("recognize" and "recognise") within a
single text.

#### "A.2.1.", paragraph 1
```
t years, or whether there will be in future. An algorithm for detecting a Cl
                                  ^^^^^^^^^
```
The phrase "in future" is British English. Did you mean: "in the future"?

#### "Appendix B.", paragraph 3
```
ction of congestion notifications in future. The ECN Nonce RFC [RFC3540] has
                                  ^^^^^^^^^
```
The phrase "in future" is British English. Did you mean: "in the future"?

#### "Appendix B.", paragraph 13
```
end-to-end use of the ECN field. Therefore a PCN region on the path would no
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### "Appendix B.", paragraph 14
```
viding help and reviewing this draft and thanks to Ingemar Johansson for rev
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tsvwg-ecn-l4s-id-26. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the ECN Field (Bits 6-7) registry on the Differentiated Services Field Codepoints (DSCP) registry page located at:

https://www.iana.org/assignments/dscp-registry/

the existing codepoint registration for 01 will be updated as follows:

Binary: 01
Keyword: ECT(1) (ECN-Capable Transport(1))[1]
Reference: [RFC8311] [RFC Errata 5399] [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-07-21):

From: The IESG
To: IETF-Announce
CC: Wesley Eddy , draft-ietf-tsvwg-ecn-l4s-id@ietf.org, martin.h.duke@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org, wes@mti-systems.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)) to Experimental RFC


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Explicit Congestion
Notification (ECN) Protocol for Very Low Queuing
  Delay (L4S)'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-07-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Among the 3 documents, this ECN one is where the specific usage of ECT(1) is discussed, that is the most contentious.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.  As a possible supplement for the limited ECN codepoints, the working group considered pros and cons of different means of using DSCP values, multiple times over the life of these documents.  Some participants preferred approaches relying on DSCP, based on their view of the tradeoffs.
- Some WG participants do not like the ambiguity of meaning possible at different points in the network for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.
    - There is not full agreement on whether L4S with this use of ECN codepoints is safe for experimentation on either parts of the Internet, or the Internet as a whole.  The WG has a separate draft-ietf-tsvwg-l4s-ops document intended to help describe potential problems and how to avoid them when enabling L4S in networks.  Related to this, when the WG was polled in the May 2021 interim about suitability for experimentation in parts of the Internet, about 20 people agreed (over half of the ~35 attendees), and about a half dozen disagreed.  Minutes of this meeting are at: https://datatracker.ietf.org/doc/minutes-interim-2021-tsvwg-01-202105101100/.
  - The matter of safety was discussed in detail in WG meetings and mailing list threads.  Specific work on classic bottleneck detection was performed and documented, and the operator guidelines I-D added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation and tools available.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility, and want to resolve that incompatibility by obsoleting RFC 3168 at the present time.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - Several working group participants reject the design based on this, and have agreed with this logic described to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Related to this, several also would prefer that in conjunction with the required classic bottleneck detection, that realtime fallback should be mandatory for transports to implement and use.
      - Some believe that realtime fallback (rather than simply offline means) is needed for safety, noting that they don't think it is clear how a user would be notified of a safety problem or who they would contact in the event that one occurred.
      - On this topic specifically, one person said on the mailing list: "And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
      - Reasons why the WG was satisfied with a 'SHOULD' rather than 'MUST' for realtime fallback are explained in Section 4.3.1 and Appendix A.1.5 of this document.
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it is not fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Among the 3 documents, this ECN one is where the specific usage of ECT(1) is discussed, that is the most contentious.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.  As a possible supplement for the limited ECN codepoints, the working group considered pros and cons of different means of using DSCP values, multiple times over the life of these documents.  Some participants preferred approaches relying on DSCP, based on their view of the tradeoffs.
- Some WG participants do not like the ambiguity of meaning possible at different points in the network for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.
    - There is not full agreement on whether L4S with this use of ECN codepoints is safe for experimentation on either parts of the Internet, or the Internet as a whole.  The WG has a separate draft-ietf-tsvwg-l4s-ops document intended to help describe potential problems and how to avoid them when enabling L4S in networks.  Related to this, when the WG was polled in the May 2021 interim about suitability for experimentation in parts of the Internet, about 20 people agreed (over half of the ~35 attendees), and about a half dozen disagreed.  Minutes of this meeting are at: https://datatracker.ietf.org/doc/minutes-interim-2021-tsvwg-01-202105101100/.
  - The matter of safety was discussed in detail in WG meetings and mailing list threads.  Specific work on classic bottleneck detection was performed and documented, and the operator guidelines I-D added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation and tools available.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility, and want to resolve that incompatibility by obsoleting RFC 3168 at the present time.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - Several working group participants reject the design based on this, and have agreed with this logic described to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Related to this, several also would prefer that in conjunction with the required classic bottleneck detection, that realtime fallback should be mandatory for transports to implement and use.
      - Some believe that realtime fallback (rather than simply offline means) is needed for safety, noting that they don't think it is clear how a user would be notified of a safety problem or who they would contact in the event that one occurred.
      - On this topic specifically, one person said on the mailing list: "And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
      - Reasons why the WG was satisfied with a 'SHOULD' rather than 'MUST' for realtime fallback are explained in Section 4.3.1 and Appendix A.1.5 of this document.
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it is not fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Among the 3 documents, this ECN one is where the specific usage of ECT(1) is discussed, that is the most contentious.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.  As a possible supplement for the limited ECN codepoints, the working group considered pros and cons of different means of using DSCP values, multiple times over the life of these documents.  Some participants preferred approaches relying on DSCP, based on their view of the tradeoffs.
- Some WG participants do not like the ambiguity of meaning possible at different points in the network for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.
    - There is not full agreement on whether L4S with this use of ECN codepoints is safe for experimentation on either parts of the Internet, or the Internet as a whole.  The WG has a separate draft-ietf-tsvwg-l4s-ops document intended to help describe potential problems and how to avoid them when enabling L4S in networks.  Related to this, when the WG was polled in the May 2021 interim about suitability for experimentation in parts of the Internet, about 20 people agreed (over half of the ~35 attendees), and about a half dozen disagreed.  Minutes of this meeting are at: https://datatracker.ietf.org/doc/minutes-interim-2021-tsvwg-01-202105101100/.
  - The matter of safety was discussed in detail in WG meetings and mailing list threads.  Specific work on classic bottleneck detection was performed and documented, and the operator guidelines I-D added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation and tools available.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility, and want to resolve that incompatibility by obsoleting RFC 3168 at the present time.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - Several working group participants reject the design based on this, and have agreed with this logic described to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Related to this, several also would prefer that in conjunction with the required classic bottleneck detection, that realtime fallback should be mandatory for transports to implement and use.
      - Some believe that realtime fallback (rather than simply offline means) is needed for safety, noting that they don't think it is clear how a user would be notified of a safety problem or who they would contact in the event that one occurred.
      - On this topic specifically, one person said on the mailing list: "And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
      - Reasons why the WG was satisfied with a 'SHOULD' rather than 'MUST' for realtime fallback are explained in Section 4.3.1 and Appendix A.1.5 of this document.
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Among the 3 documents, this ECN one is where the specific usage of ECT(1) is discussed, that is the most contentious.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.  As a possible supplement for the limited ECN codepoints, the working group considered pros and cons of different means of using DSCP values, multiple times over the life of these documents.  Some participants preferred approaches relying on DSCP, based on their view of the tradeoffs.
- Some WG participants do not like the ambiguity of meaning possible at different points in the network for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.
    - There is not full agreement on whether L4S with this use of ECN codepoints is safe for experimentation on either parts of the Internet, or the Internet as a whole.  The WG has a separate draft-ietf-tsvwg-l4s-ops document intended to help describe potential problems and how to avoid them when enabling L4S in networks.  Related to this, when the WG was polled in the May 2021 interim about suitability for experimentation in parts of the Internet, about 20 people agreed (over half of the ~35 attendees), and about a half dozen disagreed.  Minutes of this meeting are at: https://datatracker.ietf.org/doc/minutes-interim-2021-tsvwg-01-202105101100/.
  - The matter of safety was discussed in detail in WG meetings and mailing list threads.  Specific work on classic bottleneck detection was performed and documented, and the operator guidelines I-D added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation and tools available.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility, and want to resolve that incompatibility by obsoleting RFC 3168 at the present time.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - Several working group participants reject the design based on this, and have agreed with this logic described to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Related to this, several also would prefer that in conjunction with the required classic bottleneck detection, that realtime fallback should be mandatory for transports to implement and use.
      - Some believe that realtime fallback (rather than simply offline means) is needed for safety, noting that they don't think it is clear how a user would be notified of a safety problem or who they would contact in the event that one occurred.
      - On this topic specifically, one person said on the mailing list: "And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
      - Reasons why the WG was satisfied with a 'SHOULD' rather than 'MUST' for realtime fallback are explained in Section 4.3.1 and Appendix A.1.5 of this document.
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Among the 3 documents, this ECN one is where the specific usage of ECT(1) is discussed, that is the most contentious.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.  As a possible supplement for the limited ECN codepoints, the working group considered pros and cons of different means of using DSCP values, multiple times over the life of these documents.  Some participants preferred approaches relying on DSCP, based on their view of the tradeoffs.
- Some WG participants do not like the ambiguity of meaning possible at different points in the network for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.
    - There is not full agreement on whether L4S with this use of ECN codepoints is safe for experimentation on either parts of the Internet, or the Internet as a whole.  The WG has a separate draft-ietf-tsvwg-l4s-ops document intended to help describe potential problems and how to avoid them when enabling L4S in networks.  Related to this, when the WG was polled in the May 2021 interim about suitability for experimentation in parts of the Internet, about 20 people agreed (over half of the ~35 attendees), and about a half dozen disagreed.  Minutes of this meeting are at: https://datatracker.ietf.org/doc/minutes-interim-2021-tsvwg-01-202105101100/.
  - The matter of safety was discussed in detail in WG meetings and mailing list threads.  Specific work on classic bottleneck detection was performed and documented, and the operator guidelines I-D added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation and tools available.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility, and want to resolve that incompatibility by obsoleting RFC 3168 at the present time.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - Several working group participants reject the design based on this, and have agreed with this logic described to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Related to this, several also agree with this specific point that was explained well on the list but not agreed:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Among the 3 documents, this ECN one is where the specific usage of ECT(1) is discussed, that is the most contentious.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.
- Some WG participants do not like the ambiguity of meaning possible at different points in the network for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility, and want to resolve that incompatibility by obsoleting RFC 3168 at the present time.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - At least one working group participant rejects the design based on this, and has described their logic to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Another working group participant with concern about this agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
- Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.
- Some WG participants do not like the ambiguity of meaning for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - At least one working group participant rejects the design based on this, and has described their logic to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Another working group participant with concern about this agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not full agreement.
-  Since the beginning of this work, it was well understood that enhancing ECN involves tradeoffs in the choice of header encodings selected, since there are limited options in terms of the header bits, codepoints, and other fields like DSCP that can be leveraged.  The working group went through a process of assessing the pros and cons of all of the options that were put on the table.  The different weights that participants attach to the importance of these tradeoffs seems to be a major source of the inability to unanimously agree on the particular L4S usage of ECT1 (and CE).  It was remarked in one WG meeting that we ideally would have 5 codepoints, but unfortunately need to live with 4 and engineer within that.
- Some WG participants do not like the ambiguity of meaning for CE and ECT1 that this draft introduces when L4S is deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - At least one working group participant rejects the design based on this, and has described their logic to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Another working group participant with concern about this agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some resolutions were not unanimously agreed with.

Document Quality:

There are multiple existing implementations of the technology described, and around 25 vendors and operators have indicated intentions to experiment with the overall L4S technology.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.  In addition, both other TSVWG co-chairs have closely reviewed and commented on earlier revisions of the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not fully agreement.
- Some WG participants do not like the ambiguity of CE and ECT1 that this draft introduces, when deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the potential for classic incompatibility.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in BCP 124 (RFC 4774).  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the BCP 124 (RFC 4774) advice as-written at that time and directly interpreted now.
  - At least one working group participant rejects the design based on this, and has described their logic to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Another working group participant with concern about this agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774's model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing inadequately scaled replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This condition was recognized in the WG as able to affect regular traffic without any intent of an attack.  It was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future BCP 124 (RFC 4774)may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some were not widely agreed with.

Document Quality:

There are multiple existing implementations, and several network operators are planning experimental deployments based on this document.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not fully agreement.
- Some WG participants do not like the ambiguity of CE and ECT1 that this draft introduces, when deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the classic incompatibility.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in RFC 4774.  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the RFC 4774 advice as-written at that time and directly interpreted now.
  - At least one working group participant rejects the design based on this, and has described their logic to the working group in detail: https://mailarchive.ietf.org/arch/msg/tsvwg/BULldNtilkiChD7rPKDyEdssFlw/
  - Another working group participant with concern about this agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774’s model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future RFC 4774 may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some were not widely agreed with.

Document Quality:

There are multiple existing implementations, and several network operators are planning experimental deployments based on this document.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not fully agreement.
- Some WG participants do not like the ambiguity of CE and ECT1 that this draft introduces, when deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the classic incompatibility.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in RFC 4774.  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the RFC 4774 advice as-written at that time and directly interpreted now.  At least one working group participant rejects the design on these grounds, though did not comment specifically on the text addressing the situation.  Another working group participant with concern about this agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774’s model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."
- A potential vector for DoS of tunneled traffic was described, based on marking the traffic selectively, and causing replay windows (as in IPsec) to then be violated as some packets receive low latency and others do not.  This was addressed and is explicitly discussed in section 6.2, however, it may not be fully agreed upon as having been settled by some who raised the concern.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future RFC 4774 may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some were not widely agreed with.

Document Quality:

There are multiple existing implementations, and several network operators are planning experimental deployments based on this document.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a combined last call for this and the other two main L4S documents.  During that last call, it was clear that while a majority strongly supports the work and is eager to experiment with the technology, there are still also a number of participants who have concerns and/or prefer alternatives to L4S.  The working group devoted considerable time, including multiple focused interim meetings in order to understand objections and try to address or mitigate all concerns.  It is clear that while there are still some technical disagreements, there is a great deal of support and even wider than normal support for going forward with this work; spanning industry, including vendors, network operators, and congestion control researchers.

Regarding this ECN document specifically, there are a number of specific concerns that resulted in only a "rough" consensus and not fully agreement.
- Some WG participants do not like the ambiguity of CE and ECT1 that this draft introduces, when deployed alongside classic ECN queues or hosts.  This coexistence has been considered at length by the WG and accepted along with several mitigating factors that have been introduced.  Particularly there is a possibility to negatively impact non-L4S flows when a classic bottleneck is shared and L4S responds to the CE bits differently.  This was discussed in detail in WG meetings and mailing list threads, and specific work on classic bottleneck detection was performed and documented, plus the operator guidelines I-D for L4S added further considerations on the presence of classic bottlenecks.  The implementers and operators discussing deployments seem to understand the concern and are comfortable with the situation.
- A few WG participants favor making this Standards Track rather than Experimental, because of the classic incompatibility.  There was not wide support for this, and it is felt that that the WG is not yet ready to pursue this path of deprecating RFC 3168.  The WG may discuss deprecating 3168 in the future, in parallel with L4S experimentation, but not as a prerequisite to L4S experimentation.
- One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in RFC 4774.  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the RFC 4774 advice.  After polite discussion, one working group participant agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774’s model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future RFC 4774 may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

The working group largely supports and is enthusiastic about L4S technology, which this document is a part of.  It was last called along with 2 other L4S documents.  There is a wider than normal level of support that has been expressed for this work, but it is not unanimous.  There are also some WG participants who have concerns about L4S or prefer an alternative approach.  The working group had many long email threads and conducted several interim meetings focused on L4S, its goals, technical challenges, and concerns with the approach and potential impact on Internet safety.  Full agreement was not obtained in all cases, but significant work was done to address the issues that were agreed upon, and each concern was considered in detail by the working group, even if some were not widely agreed with.

Document Quality:

There are multiple existing implementations, and several network operators are planning experimental deployments based on this document.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

TODO

One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in RFC 4774.  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the RFC 4774 advice.  After polite discussion, one working group participant agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774’s model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future RFC 4774 may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations clearly describe one update to an existing registry, that is specifically identified and fully described.  There are no new registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental.  This is the proper type of RFC, and is indicated in the title page header.  There is an active area of research in transports that meet the requirements and use the L4S identifier described in this document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary: (from abstract)

  This specification defines the protocol to be used for a new network
  service called low latency, low loss and scalable throughput (L4S).
  L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
  layer that is similar to the original (or 'Classic') ECN approach,
  except as specified within.  L4S uses 'scalable' congestion control,
  which induces much more frequent control signals from the network and
  it responds to them with much more fine-grained adjustments, so that
  very low (typically sub-millisecond on average) and consistently low
  queuing delay becomes possible for L4S traffic without compromising
  link utilization.  Thus even capacity-seeking (TCP-like) traffic can
  have high bandwidth and very low delay at the same time, even during
  periods of high traffic load.

  The L4S identifier defined in this document distinguishes L4S from
  'Classic' (e.g. TCP-Reno-friendly) traffic.  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 with the intention
  that L4S flows neither harm each other's performance nor that of
  Classic traffic.  Examples of new active queue management (AQM)
  marking algorithms and examples of new transports (whether TCP-like
  or real-time) are specified separately.

Working Group Summary:

TODO

Document Quality:

There are multiple existing implementations, and several network operators are planning experimental deployments based on this document.

Personnel:

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document myself, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the document deals with transport protocols, congestion control, packet marking, and queuing behavior, there can be additional security, operations, internet, and routing area interests.  There has been a healthy mix of academic, industry/vendor, and operator participation in this work, and a breadth of reviews have been incorporated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no personal concerns of my own.  However, there have been concerns raised in the working group, discussed in question 9 below.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

TODO

One question that came up in the WG process was how this particular L4S identifier approach relates to the advice in RFC 4774.  After WG discussions, and work between the chairs and editors, new text was included to describe this was included in the document.  Although the WG feels it is safe and the most desirable available approach, the point remains that this does not have pure conformance with the RFC 4774 advice.  After polite discussion, one working group participant agreed they might be classified "in the rough" regarding one specific point:
"And rather than going in circles again, as I said originally I propose to agree to disagree on the one remaining point (re: SHOULD NOT be sent across classic queues, MUST NOT be so sent repeatedly and persistently).  I don’t think there’s enough evidence to claim that essentially all current and future deployed marking queues use a sufficiently good fq hash to allow for disregarding of RFC 4774’s model for new ECN semantics, nor that the problem-detection approach is robust enough (not even sure it’s coherent enough) to rely on as the basis for the key normative requirements for a safe operational congestion response."

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Some participants may feel strongly enough against L4S and this particular usage of ECN to consider an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are only small nits, that would be easy to handle after AD review.  There are outdated references to the other L4S and NQB documents, and warnings about non-ASCII characters.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.  During work on this document, it came up that in the future RFC 4774 may need to be updated, but this particular document does not do that.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

TODO

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A - no formal languages are used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.