Skip to main content

DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
draft-ietf-tsvwg-aqm-dualq-coupled-23

Revision differences

Document history

Date Rev. By Action
2022-05-04
23 Wesley Eddy Changed document external resources from: None to:

github_repo https://github.com/L4STeam/sch_dualpi2_upstream (reference Linux DulaPI2 implementation)
repo https://bitbucket.org/mpgs/coupled-dualq/ (draft XML source)
2022-05-04
23 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-23.txt
2022-05-04
23 (System) New version approved
2022-05-04
23 (System) Request for posting confirmation emailed to previous authors: Bob Briscoe <ietf@bobbriscoe.net>, Greg White <g.white@cablelabs.com>, Koen De Schepper <koen.de_schepper@nokia.com>, tsvwg-chairs@ietf.org
2022-05-04
23 Bob Briscoe Uploaded new revision
2022-04-07
22 Wesley Eddy
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 …
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.
2022-04-05
22 Wesley Eddy
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 …
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.
2022-04-05
22 Wesley Eddy
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 …
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.
2022-04-05
22 Wesley Eddy
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 …
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.
2022-03-17
22 Gorry Fairhurst The write-ups have been available for review, and have been updated based on feedback.
2022-03-17
22 Gorry Fairhurst Tag Doc Shepherd Follow-up Underway set.
2022-03-17
22 Gorry Fairhurst IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2022-03-04
22 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-22.txt
2022-03-04
22 (System) New version accepted (logged-in submitter: Bob Briscoe)
2022-03-04
22 Bob Briscoe Uploaded new revision
2022-03-01
21 Wesley Eddy
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 …
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.
2022-02-24
21 Wesley Eddy
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 …
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.
2022-02-21
21 Wesley Eddy
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 …
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.
2022-02-21
21 Wesley Eddy
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 …
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.
2022-02-15
21 Wesley Eddy
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 …
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.
2022-02-13
21 Wesley Eddy
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 …
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.
2022-02-13
21 Wesley Eddy
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 …
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.
2022-02-01
21 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-21.txt
2022-02-01
21 (System) New version accepted (logged-in submitter: Bob Briscoe)
2022-02-01
21 Bob Briscoe Uploaded new revision
2021-12-24
20 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-20.txt
2021-12-24
20 (System) New version accepted (logged-in submitter: Bob Briscoe)
2021-12-24
20 Bob Briscoe Uploaded new revision
2021-11-03
19 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-19.txt
2021-11-03
19 (System) Forced post of submission
2021-11-03
19 (System) Request for posting confirmation emailed to previous authors: Bob Briscoe <ietf@bobbriscoe.net>, Greg White <g.white@cablelabs.com>, Koen De Schepper <koen.de_schepper@nokia.com>, tsvwg-chairs@ietf.org
2021-11-03
19 Bob Briscoe Uploaded new revision
2021-11-01
18 Gorry Fairhurst Added to session: IETF-112: tsvwg  Mon-1430
2021-10-25
18 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-18.txt
2021-10-25
18 (System) New version accepted (logged-in submitter: Bob Briscoe)
2021-10-25
18 Bob Briscoe Uploaded new revision
2021-10-04
17 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-17.txt
2021-10-04
17 (System) New version accepted (logged-in submitter: Bob Briscoe)
2021-10-04
17 Bob Briscoe Uploaded new revision
2021-08-27
16 Wesley Eddy Started 7/29, should wrap up 8/27.
2021-08-27
16 Wesley Eddy IETF WG state changed to In WG Last Call from WG Document
2021-07-21
16 Gorry Fairhurst Added to session: IETF-111: tsvwg  Mon-1430
2021-07-07
16 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-16.txt
2021-07-07
16 (System) New version accepted (logged-in submitter: Bob Briscoe)
2021-07-07
16 Bob Briscoe Uploaded new revision
2021-05-23
15 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-15.txt
2021-05-23
15 (System) New version accepted (logged-in submitter: Bob Briscoe)
2021-05-23
15 Bob Briscoe Uploaded new revision
2021-03-10
14 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-14.txt
2021-03-10
14 (System) New version accepted (logged-in submitter: Bob Briscoe)
2021-03-10
14 Bob Briscoe Uploaded new revision
2021-03-09
13 David Black Added to session: IETF-110: tsvwg  Wed-1530
2020-11-17
13 Wesley Eddy Added to session: IETF-109: tsvwg  Wed-1430
2020-11-15
13 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-13.txt
2020-11-15
13 (System) New version accepted (logged-in submitter: Bob Briscoe)
2020-11-15
13 Bob Briscoe Uploaded new revision
2020-07-27
12 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-12.txt
2020-07-27
12 (System) New version accepted (logged-in submitter: Bob Briscoe)
2020-07-27
12 Bob Briscoe Uploaded new revision
2020-07-27
11 Wesley Eddy Added to session: IETF-108: tsvwg  Thu-1100
2020-04-21
11 Wesley Eddy
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 …
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?

2020-04-05
11 Gorry Fairhurst Added to session: interim-2020-tsvwg-03
2020-03-09
11 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-11.txt
2020-03-09
11 (System) New version approved
2020-03-09
11 (System) Request for posting confirmation emailed to previous authors: Bob Briscoe <ietf@bobbriscoe.net>, Koen Schepper <koen.de_schepper@nokia.com>, tsvwg-chairs@ietf.org, Greg White <g.white@cablelabs.com>
2020-03-09
11 Bob Briscoe Uploaded new revision
2020-01-09
10 (System) Document has expired
2019-07-16
10 Gorry Fairhurst Added to session: IETF-105: tsvwg  Fri-1220
2019-07-08
10 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-10.txt
2019-07-08
10 (System) New version approved
2019-07-08
10 (System) Request for posting confirmation emailed to previous authors: Bob Briscoe <ietf@bobbriscoe.net>, Greg White <g.white@cablelabs.com>, tsvwg-chairs@ietf.org, Koen Schepper <koen.de_schepper@nokia.com>
2019-07-08
10 Bob Briscoe Uploaded new revision
2019-07-03
09 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-09.txt
2019-07-03
09 (System) New version approved
2019-07-03
09 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg-chairs@ietf.org, Ing Tsang <ing-jyh.tsang@nokia.com>, …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg-chairs@ietf.org, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2019-07-03
09 Bob Briscoe Uploaded new revision
2019-05-08
08 (System) Document has expired
2018-11-04
08 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-08.txt
2018-11-04
08 (System) New version approved
2018-11-04
08 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2018-11-04
08 Bob Briscoe Uploaded new revision
2018-10-22
07 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-07.txt
2018-10-22
07 (System) New version approved
2018-10-22
07 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2018-10-22
07 Bob Briscoe Uploaded new revision
2018-07-19
06 David Black Added to session: IETF-102: tsvwg  Thu-1810
2018-07-19
06 David Black Removed from session: IETF-102: tsvwg  Thu-1550
2018-07-19
06 David Black Added to session: IETF-102: tsvwg  Thu-1550
2018-07-18
06 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-06.txt
2018-07-18
06 (System) New version approved
2018-07-18
06 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2018-07-18
06 Bob Briscoe Uploaded new revision
2018-07-02
05 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-05.txt
2018-07-02
05 (System) New version approved
2018-07-02
05 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2018-07-02
05 Bob Briscoe Uploaded new revision
2018-03-22
04 David Black Added to session: IETF-101: tsvwg  Thu-1550
2018-03-05
04 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-04.txt
2018-03-05
04 (System) New version approved
2018-03-05
04 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2018-03-05
04 Bob Briscoe Uploaded new revision
2018-01-25
03 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-03.txt
2018-01-25
03 (System) New version approved
2018-01-24
03 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2018-01-24
03 Bob Briscoe Uploaded new revision
2017-10-30
02 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-02.txt
2017-10-30
02 (System) New version approved
2017-10-30
02 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2017-10-30
02 Bob Briscoe Uploaded new revision
2017-07-18
01 David Black Notification list changed to Wesley Eddy <wes@mti-systems.com>
2017-07-18
01 David Black Document shepherd changed to Wesley Eddy
2017-07-18
01 David Black Added to session: IETF-99: tsvwg  Tue-1330
2017-07-03
01 Bob Briscoe New version available: draft-ietf-tsvwg-aqm-dualq-coupled-01.txt
2017-07-03
01 (System) New version approved
2017-07-03
01 (System)
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko …
Request for posting confirmation emailed to previous authors: Koen Schepper <koen.de_schepper@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ing Tsang <ing-jyh.tsang@nokia.com>, Olga Bondarenko <olgabnd@gmail.com>
2017-07-03
01 Bob Briscoe Uploaded new revision
2017-05-10
00 Wesley Eddy This document now replaces draft-briscoe-tsvwg-aqm-dualq-coupled instead of None
2017-05-10
00 Koen De Schepper New version available: draft-ietf-tsvwg-aqm-dualq-coupled-00.txt
2017-05-10
00 (System) WG -00 approved
2017-05-10
00 Koen De Schepper Set submitter to "Koen De Schepper <koen.de_schepper@nokia.com>", replaces to draft-briscoe-tsvwg-aqm-dualq-coupled and sent approval email to group chairs: tsvwg-chairs@ietf.org
2017-05-10
00 Koen De Schepper Uploaded new revision