Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)
draft-ietf-tsvwg-aqm-dualq-coupled-25

[Ballot comment]
# Security AD review of draft-ietf-tsvwg-aqm-dualq-coupled-24

CC @paulwouters

The queuing details are definitely outside my area of expertise. It seems reasonable but I would not add too much weight to this opinion.

## COMMENTS

### Abstract

The abstract is very long. I would cut it at "The coupling acts like a"

### Section 1 repetition

There is a lot of repeated text from the architecture document, eg
about speed of flows and 360 racing cameras that could probably
be omitted in this document and replaced with a "the reader should
be familiar with [L4S architecture doc]. That would cut out a lot
of Section 1 and make the document more readable to those readers
who (like me) just had to read the architecture document as well.

[Ballot comment]
** Section 1.1
  In the developed world, further
  increases in access network bit-rate offer diminishing returns,
  whereas latency is still a multi-faceted problem. 

Is there a reference for this assertion?  Generalizing to the “developed world” seems difficult.

** Section 4.1
  It also
  explains that, on the current Internet, scheduling usually enforces
  separation between 'sites' (e.g. households, businesses or mobile
  users), but it is not common to need to schedule or police individual
  application flows.

I have no data on this, but is this suggesting that carriers don’t have agreements to carry certain classes of traffic with more priority on a given pipe?

** Section 4.1. 

  By the above arguments, per-flow policing might not be necessary and
  in trusted environments  it is certainly unlikely to be needed.

Could the properties of a “trusted environment” be described in a bit more detail?

Nits
** Section 1.2. Please provide a reference to BBRv2.

** Section 1.4.  s/watchings/watching/

[Ballot comment]
# GEN AD review of draft-ietf-tsvwg-aqm-dualq-coupled-24

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1WR0V1l2Vh7yUfnVUwzS1t3H2MY).

## Comments

### Boilerplate

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

### 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 `traditionally`; alternatives might be `classic`, `classical`,
  `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`

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

### Outdated references

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

### URLs

Found non-HTTP URLs in the document:

* speedtest.net

These URLs in the document did not return content:

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

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

* http://dl.acm.org/citation.cfm?doid=2910017.2910633
* http://queue.acm.org/issuedetail.cfm?issue=2208917
* http://infocom2003.ieee-infocom.org/papers/27_04.PDF
* http://bobbriscoe.net/

### Grammar/style

#### Section 1.1, paragraph 4
```
euing delay of about 20ms on average but there are also regular 25ms delay s
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 1.1, paragraph 4
```
ems. DCTCP teaches us that two small but radical changes to congestion contro
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 1.2, paragraph 5
```
equires little extra processing. Therefore it is believed the Coupled AQM wo
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 1.3, paragraph 2
```
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.3, paragraph 6
```
e.g. DNS, VoIP, game sync datagrams, etc). The DualQ Coupled AQM behaviour i
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 1.3, paragraph 10
```
me throughput whichever it uses. Therefore both queues can feed into the ful
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 1.3, paragraph 13
```
on the path, for instance by legacy WiFi equipment. However, if L4S support
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 1.3, paragraph 14
```
uce the burstiness of the _incoming_ WiFi. Also, trials of WiFi equipment wit
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 1.4, paragraph 1
```
he _incoming_ WiFi. Also, trials of WiFi equipment with an L4S DualQ Coupled
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 1.4, paragraph 1
```
DualQ Coupled AQM on the _outgoing_ WiFi interface are in progress, and earl
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 1.4, paragraph 3
```
stick to the user's finger on the touch pad and the experience fed from the r
                                  ^^^^^^^^^
```
This word is normally spelled as one.

#### Section 1.4, paragraph 3
```
ves low latency to L4S traffic whether or not there is Classic traffic. The
                              ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### Section 2.1, paragraph 3
```
ue to prevent under-utilization. Therefore a separate queue is provided for
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2.4, paragraph 1
```
rienced by L4S and Classic traffic. Thus k indirectly determines the ratio be
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 2.4, paragraph 9
```
ffic is controlled by the coupling. Also there only has to be a coupling in o
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Also".

#### Section 2.4, paragraph 14
```
nsitive to link rate and it requires less operations per packet than RED. How
                                    ^^^^
```
Did you mean "fewer"? The noun operations is countable.

#### Section 2.5.1.1, paragraph 11
```
n a simple accumulating counter. Therefore the type of queue delay statistic
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2.5.2.1, paragraph 3
```
elay. This could be done with a small number of bins with configurable edges
                              ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 2.5.2.1, paragraph 8
```
ion in overload state is accumulated but no new report is generated until th
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 2.5.2.1, paragraph 10
```
s management requirements. The raison d'etre of the DualQ Coupled AQM is to
                              ^^^^^^^^^^^^^
```
"raison d'etre" is an imported foreign name or expression, which originally has
a diacritic.

#### Section 2.5.2.1, paragraph 11
```
ale with bandwidth-delay product. Therefore there is no need to repeat these
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 2.5.2.2, paragraph 6
```
avoid complexity and unintended side-effects with per-flow policing, it need
                                ^^^^^^^^^^^^
```
Did you mean "side effects" (=adverse effect, unintended consequence)? Open
compounds are not hyphenated.

#### Section 4.1, paragraph 4
```
g dequeued. There is then the question of whether to sacrifice L4S throughpu
                          ^^^^^^^^^^^^^^^^^^^^^^^
```
Wordiness: Consider shortening this phrase.

#### Section 4.1, paragraph 4
```
S throughput: By using weighted round robin as the conditional priority sche
                                ^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 4.2.2, paragraph 3
```
s-id]). Saturation raises the question of whether to relieve congestion by i
                          ^^^^^^^^^^^^^^^^^^^^^^^
```
Wordiness: Consider shortening this phrase.

#### Section 4.2.2, paragraph 7
```
S or Classic. This raises the question of whether and when to introduce drop
                          ^^^^^^^^^^^^^^^^^^^^^^^
```
Wordiness: Consider shortening this phrase.

#### Section 4.2.3.1, paragraph 1
```
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 5, paragraph 2
```
Coupled Active Queue Management", Masters Thesis, Dept of Informatics, Uni O
                                  ^^^^^^^
```
For an academic degree, use "Master's".

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

#### Section 7.2, paragraph 18
```
[SCReAM] Johansson, I., "SCReAM", github repository; , <https://github.com/Er
                                  ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

#### "Appendix A.", paragraph 1
```
ts, 1 MTU of space is always allowed and the limit is deliberately tested be
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### "A.1.", paragraph 22
```
on controllers conducted by Mishra _et al_ in Jul-Oct 2019 [CCcensus19], most
                                    ^^^^^
```
A period is misplaced or missing.

#### "A.1.", paragraph 24
```
tion of RTT_typ around its mean. Otherwise the target queue would only avoid
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### "A.1.", paragraph 24
```
ween a user and their local CDN. Currently no data is available on the varia
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### "A.1.", paragraph 25
```
g * f = 25ms * 0.38 * 2 = 19 ms. However a further adjustment is warranted,
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### "A.1.", paragraph 25
```
ranted, because target is moving year on year. The paper is based on data col
                                ^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### "A.1.", paragraph 25
```
(mobile) between 2020 and 2021. Therefore we recommend a default of target
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### "A.1.", paragraph 34
```
this value. The propagation delay half way round the planet and back in glass
                                  ^^^^^^^^
```
The adjective or adverb "halfway" is spelled as one word.

#### "A.1.", paragraph 45
```
hen the packet is dequeued. If time- stamping is not easy to introduce with c
                              ^^^^^^^^^^^^^^
```
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

#### "A.1.", paragraph 48
```
available space. The choice is a trade off; a shared buffer can use less mem
                                ^^^^^^^^^
```
When "trade-off" is used as a noun or modifier, it needs to be hyphenated.

#### "A.1.", paragraph 50
```
etails of both edge-cases added. Similarly Figure 8 repeats the core PI algo
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Similarly".

#### "A.1.", paragraph 66
```
ghted scheduler such as weighted round robin (WRR) is recommended. As long a
                                ^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### "B.1.", paragraph 27
```
k node cannot easily know the RTT of any of the flows anyway. RTT-dependence
                                  ^^^^^^^^^
```
Consider simply using "of" instead.

#### "B.2.", paragraph 3
```
because we only use one point - at the the typical base RTT where the operato
                                  ^^^^^^^
```
Possible typo: you repeated a word.

## 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 reviewed draft-ietf-tsvwg-aqm-dualq-coupled-24, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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-aqm-dualq-coupled@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:  (DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)) to Experimental RFC


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'DualQ Coupled AQMs for Low
Latency, Low Loss and Scalable Throughput
  (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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2952/
  https://datatracker.ietf.org/ipr/3561/
  https://datatracker.ietf.org/ipr/3562/
  https://datatracker.ietf.org/ipr/2679/

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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 an even wider than typical energy level to go forward that spans the industry, including vendors, network operators, and congestion control researchers.

Regarding this DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

Likely based on a mistaken experimental setup, a concern was raised at the WGLC about potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
- Multiple experimental results and analysis from several participants on the list suggest that the concern stems from inadvertently disabling the congestion response in the original experiment.
  - Reference to results directly demonstrating this: https://mailarchive.ietf.org/arch/msg/tsvwg/MxCwKInvzCgSSor5JJG8OmIehas/
- In summary, there has been substantial work and experiments towards addressing this concern, and the working group as a whole does not seem to find it as an issue, though it hasn't been explicitly retracted by those that originally raised the concern.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 an even wider than typical energy level to go forward that spans the industry, including vendors, network operators, and congestion control researchers.

Regarding this DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

Likely based on a mistaken experimental setup, a concern was raised at the WGLC about potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
- Multiple experimental results and analysis from several participants on the list suggest that the concern stems from inadvertently disabling the congestion response in the original experiment.
  - Reference to results directly demonstrating this: https://mailarchive.ietf.org/arch/msg/tsvwg/MxCwKInvzCgSSor5JJG8OmIehas/
- In summary, there has been substantial work and experiments towards addressing this concern, and the working group as a whole does not seem to find it as an issue, though it hasn't been explicitly retracted by those that originally raised the concern.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 an even wider than typical energy level to go forward that spans the industry, including vendors, network operators, and congestion control researchers.

Regarding this DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern was explained during the WGLC about potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
- Multiple participants on the list believe that the experiments demonstrating this as an issue were flawed, and speculated this was due to inadvertently disabling the congestion response.
- The editors shared their own set of experimental results that appear consistent with the design, which did not demonstrate the same problematic property. The editors and other WG participants explained why the problem should not occur due to the coupled congestion signaling. 
- The discussion was complicated by digressions between other topics such as WRR scheduling weights, details of CoDel behavior, FQ, coupled queue explanation, unresponsive flows of different types.  The editors have replied to the points raised and shared their results and explanations.    At least one person thinks there might be some corner case of specific parameters where the concern is valid, but this remains hypothetical and does not seem to be a blocking concern.  As a result of the discussion, no others came out as sharing this throughput-bonus concern, and the experimental result motivating it was not able to be reproduced.
- In summary, there has been substantial work and experiments towards addressing this concern, and the working group as a whole does not seem to find it as an issue.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 an even wider than typical energy level to go forward that spans the industry, including vendors, network operators, and congestion control researchers.

Regarding this DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern was explained during the WGLC about potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
- Multiple participants on the list speculated that the experiments demonstrating this as an issue could have been flawed by inadvertently disabling the congestion response.
- The editors shared their own set of experimental results that appear consistent with the design ,did not demonstrate the same problematic property, and the editors explained why the problem should not occur due to the coupled congestion signalling. 
- The discussion was complicated by digressions between other topics such as WRR scheduling weights, details of CoDel behavior, FQ, coupled queue explanation, unresponsive flows of different types.  The editors have replied to the points raised and shared their results and explanations.    At least one person thinks there might be some corner case of specific parameters where the concern is valid, but this remains hypothetical and does not seem to be a blocking concern.  As a result of the discussion, no others came out as sharing this throughput-bonus concern, and the experimental result motivating it was not able to be reproduced.
- In summary, there has been substantial work and experiments towards addressing this concern, and the working group as a whole does not seem to find it as an issue.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern was explained during the WGLC regarding whether there is potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
- The editors shared their own set of experiment results that demonstrate different behavior, consistent with the design, and explained why this should not be an issue. 
  -  These results disagree with the earlier experiment presented by those raising the concern.  Multiple participants on the list speculated that the earlier experiment demonstrating an issue might have been flawed by inadvertently disabling congestion response.
  - There has been substantial work and experiments towards addressing this concern, and the working group as a whole does not seem to find it as an issue.
-  The discussion was complicated by digressions between other topics such as WRR scheduling weights, details of CoDel behavior, FQ, coupled queue explanation, unresponsive flows of different types.  The editors have replied to the points raised and shared their results and explanations.    At least one person thinks there might be some corner case of specific parameters where the concern is valid, but this remains hypothetical and does not seem to be a blocking concern.  As a result of the discussion, no others came out as sharing this throughput-bonus concern, and the experimental result motivating it was not able to be reproduced.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern was explained during the WGLC regarding whether there is potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
- The editors shared their own set of experiment results that demonstrate different behavior, consistent with the design, and explained why this should not be an issue. 
  -  These results disagree with the earlier experiment presented by those raising the concern.  Multiple participants on the list speculated that the earlier experiment demonstrating an issue might have been flawed by inadvertently disabling congestion response.
  - There has been substantial work and experiments towards addressing this concern, and the working group as a whole does not seem to find it as an issue.
-  The discussion was complicated by digressions between other topics such as WRR scheduling weights, details of CoDel behavior, FQ, coupled queue explanation, unresponsive flows of different types.  The editors have replied to the points raised and shared their results and explanations.  Although these may not have satisified all participants, no others came out as sharing this concern during discussion, and the experiment result motivating it was not able to be reproduced.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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 (explained further in response to Question 9 below).  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be good agreement that between this and the terms, the situation is acceptable for going forward.  Although there was one participant that still may have a concern with this, it does not appear to be shared by others.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern that was explained during the WGLC regard the potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
Those who raised this concern may not agree, but there has been substantial work and experiments designed to address this, and the working group as a whole does not seem to find it as an issue.
The discussion was complicated by digressions between the topics of WRR scheduling weights, details of CoDel behavior, FQ, coupled queue explanation, unresponsive flows of different types, etc..  The editors have replied to the points raised and shared their results and explanations.  Although these may not have satisified all participants, no others came out as sharing this as a concern during discussion.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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.  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list via David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern that was explained during the WGLC regard the potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
Those who raised this concern may not agree, but there has been substantial work and experiments designed to address this, and the working group as a whole does not seem to find it as an issue.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 queuing behavior, there can be 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.  These have been discussed at length in meetings and on the list.  One summary of concerns  was assembled after the working group last call and posted to the list by David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/
Of those concerns, I believe all have been understood and adequately worked through by the working group.  As noted in that email, the chairs agreed that some of the items specific to this DualQ document should not impact its publication as Experimental at this time.

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern that was explained during the WGLC regard the potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This was discussed following the WGLC in an interim, and then further on the mailing list in the thread started here:
https://mailarchive.ietf.org/arch/msg/tsvwg/avdsM2B_DAypCsqxh8wAe16J9-k/
Those who raised this concern may not agree, but there has been substantial work and experiments designed to address this, and the working group as a whole does not seem to find it as an issue.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected during publication.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 of the technology described, and several vendors and operators have plans to experiment with the specification.

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 queuing behavior, there can be 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.  These have been discussed at length in meetings and on the list.  A good summary after the working group last call was posted to the list by co-chair David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern that was explained during the WGLC regard the potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This may not have been specifically addressed or answered yet, though there were multiple past conversations around it.  The gist of why this should not be an issue is around proper configuration preventing there from being either harm done or any bonus achieved during the case of overload.  It might be agreed that more experimental work on tuning of parameters could be useful in looking at this more going forward, but the disagreement seems to be on whether it should block publication that there is possibility of there being a problem with un-tuned parameters.  The shepherd advice is to remember this is Experimental and operators enabling it are opting in to experiment.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
Some other participants agree with this point, though it is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected as part of the AD review.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 of the technology described, and several vendors and operators have plans to experiment with the specification.

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 queuing behavior, there can be 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.  These have been discussed at length in meetings and on the list.  A good summary after the working group last call was posted to the list by co-chair David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

A concern that was explained during the WGLC regard the potential for non-L4S traffic to abuse the L-queue for a "throughput bonus".  This may not have been specifically addressed or answered yet, though there were multiple past conversations around it.  The gist of why this should not be an issue is around proper configuration preventing there from being either harm done or any bonus achieved during the case of overload.  It might be agreed that more experimental work on tuning of parameters could be useful in looking at this more going forward, but the disagreement seems to be on whether it should block publication that there is possibility of there being a problem with un-tuned parameters.  The shepherd advice is to remember this is Experimental and operators enabling it are opting in to experiment.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
This is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected as part of the AD review.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 of the technology described, and several vendors and operators have plans to experiment with the specification.

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 queuing behavior, there can be 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.  These have been discussed at length in meetings and on the list.  A good summary after the working group last call was posted to the list by co-chair David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

One participant specifically asked to have their disagreement noted in this shepherd writeup, and indicated that they do not think L4S is ready for advancement based on the achieved results so far.  They specifically stated in email to the chairs:
"I do not think that L4S (as currently designed, implemented and described in the drafts) is the best solution for the whole internet, but it pretty much tailored to make the already pre-ratified low latency DOCSIS (LLD) compliant with IETF RFCs."
This is believed by the chairs to be "in the rough".

(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 in general 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 very minor ID nits that can be corrected as part of the AD review.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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.  The technology described is intended for experimental use in conjunction with L4S transports that are an active area of research.

(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 a framework for coupling the Active Queue
  Management (AQM) algorithms in two queues intended for flows with
  different responses to congestion.  This provides a way for the
  Internet to transition from the scaling problems of standard TCP
  Reno-friendly ('Classic') congestion controls to the family of
  'Scalable' congestion controls.  These are designed for consistently
  very Low queuing Latency, very Low congestion Loss and Scaling of
  per-flow throughput (L4S) by using Explicit Congestion Notification
  (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
  could only be deployed where a clean-slate environment could be
  arranged, such as in private data centres.  The coupling acts like a
  semi-permeable membrane: isolating the sub-millisecond average
  queuing delay and zero congestion loss of L4S from Classic latency
  and loss; but pooling the capacity between any combination of
  Scalable and Classic flows with roughly equivalent throughput per
  flow.  The DualQ achieves this indirectly, without having to inspect
  transport layer flow identifiers and without compromising the
  performance of the Classic traffic, relative to a single queue.  The
  DualQ design has low complexity and requires no configuration for the
  public Internet.

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 of the technology described, and several vendors and operators have plans to experiment with the specification.

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 queuing behavior, there can be 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.  These have been discussed at length in meetings and on the list.  A good summary after the working group last call was posted to the list by co-chair David Black:
https://mailarchive.ietf.org/arch/msg/tsvwg/zJESUt8a1mUBxSBVPCIiTKIXU4Q/

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.

(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 DualQ document specifically, there are other queueing approaches that can work within the L4S architecture (as described in the architecture I-D), so an implementer with any particular concern about DualQ has alternatives.

(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 in general 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 very minor ID nits that can be corrected as part of the AD review.  These are the instances reported of non-ASCII characters and the outdated references to the other L4S documents.

(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?

There is a normative reference to the L4S identifier document, which is advancing to be published in parallel to this one.

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

N/A.

(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 document correctly states there are no IANA considerations.

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

N/A.

(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 - The document does contain pseudocode, but it is not a formal language.

(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?

(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:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

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

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

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

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

(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?

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

Yes.  There is IPR filed in the tracker linked to this document.  It was discussed at length in the working group both on-list and in meetings.  Draft authors have actually discussed ways implementations can avoid the IPR claims, and there seems to be consensus that between this and the terms the situation is acceptable for going forward.  There is general consensus that it is not a concern, though there was one participant that still may have a concern, it does not appear to be shared.


(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?

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

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

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

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

(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?

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

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

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

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

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

(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?