Proportional Rate Reduction for TCP
draft-ietf-tcpm-prr-rfc6937bis-14

PRR : draft-ietf-tcpm-prr-rfc6937bis

Thank you for providing this much needed specification to update the document describing PRR and to help move the specification to the Standards Track. I have a few Area Director comments below, that I would like to see addressed in a new revision of this I-D before it progresses to IETF LC, please see below:

---
Section 1.1
I fully understand the real value of 1.1 during development of the document. I was unsure of the final intent for 1.1. Document and WG Information when this is published as an RFC, please can you clarify the WG intent? (e.g. this could be moved to an appendix) - but I think in this case, the section: “Changes From RFC 6937” provides the necessary background so this section can be marked as to be removed by the RFC-Ed?
----
Section 3:
Please avoid “we” in a standards track document,: The words “we” introduce ambiguity about the consensus: “For [RFC6937] we published a companion paper”, could this be rephrased more neutrally, simply stating this was published, or if not state who published this?
---
RFC2119 Language:
1) I expected the definition for RFC2119 language, in a separate section, likely after section 3. Please consider moving this to section 5, and see (2) below.
2) I expected the definition to use the current boilerplate. Please would you consider using the latest boiler plate text:
“  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.”
---
Section 5:.
It seems the definition and the reference cited are juxtaposed in:
“[RFC9293]: snd.una (send unacknowledged).[RFC5681]: duplicate ACK, FlightSize, Sender Maximum Segment Size (SMSS).[RFC6675]: covered (as in "covered sequence numbers”).”
- For consistency, is it possible to rewrite each as a definition followed by the reference?
---
At the end of section 4, the I-D finally states:
“It is RECOMMENDED that PRR is implemented together with RACK-TLP loss recovery [RFC8985].”
1) Why is this not a MUST, i.e, please explain the conditions where the recommendation is not required, and WHAT are the implications?
2) I suggest placing this as the final sentence of section 4 concerns me that some people may overlook this important. I’d much rather this requirement was moved to the start of section 5
---
Section 6:
This section mentions TCP in the opening paragraph.
I suggest that although the spec is clearly targeted at TCP, we don’t need to explicitly state this is only for TCP senders. Is it possible to remove the word?
MSS is specifically a TCP number, is this actually MPS when using a transport that can detect the current maximum packet size, rather than the MSS negotiated at connection setup?
--
Please move and changing the following recommendation to a separate paragraph. Currently it is in a para marked as a note.
“As with common scenarios that could allow bursts, such as restarting from idle, it is RECOMMENDED that implementations use pacing to reduce the burstiness of traffic.”
- Would it be acceptable to state this something more like:
“It is RECOMMENDED that implementations use pacing to reduce the burstiness of traffic. This recommendation is consistent  current practice to mitigate bursts, e.g. pacing transmission bursts after restarting from idle. “
----
Section 7:
This example introduces TCP midway through the text and then mentions it several times.
1), if the intent is to scope to only TCP, please state this earlier at the start of the example
2) Could you anyway could you please replace “TCP  will send” by “the sender will send..” and similar “TCP immediately retransmits” to “the sender immediately retransmits”
---
Section 8:
This text mentions TCP, but I do not understand why this might not be generalised to any similar transport:
“PRR maintains TCP's ACK clocking” can this be “PRR maintains the sender’s ACK clocking”
“Note that as TCP approaches the end of recovery” can this be “Note that as the sender approaches the end of recovery”
“catches up while TCP is still in recovery, TCP will” could this be: “catches up while the sender remains in recovery, it will”
etc.
---
This section later also says:
“Although this burst might be viewed as being hard on the network,”
1)  could this be made clearer, e.g. something like:
“Although such a burst could negatively impact other sharing flows”, or similar?
2) I have a question: Is this type of behaviour limited when using methods such as CWV?
---
Please avoid “we” in a standards track document, instead please use the “editors” if you do strongly feel this is controversial for the WG as a whole, or if it had some consensus please just remove “we”:
“our earlier measurements [RFC 6937 section 6]” could this be: “earlier measurements [RFC 6937 section 6]”
---
“We claim that this Strong Packet Conservation Bound is the most aggressive algorithm that does not lead to additional forced losses in some environments.”, ought to be neutral as to who in the WG claim this, I suggest:
“This Strong Packet Conservation Bound is the most aggressive algorithm that does not lead to additional forced losses in some environments.”
---
“We demonstrate this property with a little thought experiment” , similarly  I suggest::
“ This property  is demonstrated with a thought experiment:”, similarly “we” can be rephrased in the remaining section, or if strictly necessary because there was no consensus, state that the editors claim this.
----

I hope that this set comments should be easy to address and I will start an IETF-wide Last Call that lasts 2 weeks (3 if overlapping an IETF meeting week). Several directorate reviews are also requested. These reviewers are usually not experts in the document’s topic, and come in with fresh eyes. You are usually responsible for answering these comments – however if any comment that comes up does not have a clear resolution, you should ask for the chairs and the working group’s help.

Usually, IETF LC also necessitates document changes, and you will need to publish a new version of the draft. If those changes are major, the status won't change until that version is available.  I will then change your document's status to "IESG evaluation" to trigger the IESG to start reviewing the document, with an intention to publish as PS.

I look forward to any questions or a revised-ID.

Best wishes,

Gorry

(WIT Area Director)

I will review your document, and plan to do this in the next two weeks (subject to other constraints and document length). You should reply to any comments or questions, but replies from others in the WG are also welcome. If major issues are found, your document's progress will be blocked until they are disposed of (possibly requiring a new version of the draft).

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

# Document History

1) Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

There was a broad consensus in the WG on the document including from major OS
implementers such as Linux, FreeBSD and Windows as the previous version of
the algorithm has already been used by these OSes as the default.

2) Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

This draft specifies a congestion control algorithm during recovery period
which is the updated version of RFC6317 published 12 years ago.
The intention of the draft is to promote the specification to a proposed standard
based on the experiences accumulated over the period.

There were various suggestions and comments which improve the quality of the document,
however, most of them focused on improving clarity of the specification such as definitions
of the terms used in the documents or clarifying the applicability of the algorithm and
relationships with other congestion control standards.

One notable technical discussion point was the cwnd size at the end of the recovery period when
this algorithm is applied. Our consensus was to leave it to the congestion control
algorithms used prior to entering recovery process. This simplifies the
scope of the algorithm in the document.
We haven't observed any controversial opinions after this decision has been made.


3) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize 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.)

No one has threatened an appeal.


4) For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Linux and FreeBSD supports the specification of this draft.

# Additional Reviews

5) Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

We've received various feedback from the implementors of Linux and FreeBSD
as well as network protocol experts.

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

This document does not require any formal reviews.

7) If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation 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 RFC 8342?

The document does not contain a YANG module.


8) Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language verifications are necessary for the documents.

# Document Shepherd Checks

9) Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes, the document is clearly written and ready to be handed off.

10) Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issue has been identified.

11) What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status of the document is Proposed Standard as there is a strong consensus
in the WG. Datatracker state attributes correctly reflect it.

12) Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

We've confirmed from all authors that there is no IPR related to the contents
of the document.


13) Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, all five authors are willing to be listed as such.

14) Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

idnits 2.17.1 reports no errors in the document. There are some warnings, but
we've confirmed that we don't need to address them.

15) Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No, they are classified correctly.

16) List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None

17) Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

None

18) Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No such reference.

19) Will publication of this document change the status of any existing RFCs?

The document will obsolete RFC6937 as the new specification for PRR and
will move the specification to the Standards Track.

20) 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 aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

This document does not require any IANA actions.

21) List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

This document does not have any new IANA registries.

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

# Document History

1) Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

There was a broad consensus in the WG on the document including from major OS
implementers such as Linux, FreeBSD and Windows as the previous version of
the algorithm has already been used by these OSes as the default.

2) Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

This draft specifies a congestion control algorithm during recovery period
which is the updated version of RFC6317 published 12 years ago.
The intention of the draft is to promote the specification to a proposed standard
based on the experiences accumulated over the period.

There were various suggestions and comments which improve the quality of the document,
however, most of them focused on improving clarity of the specification such as definitions
of the terms used in the documents or clarifying the applicability of the algorithm and
relationships with other congestion control standards.

One notable technical discussion point was the cwnd size at the end of the recovery period when
this algorithm is applied. Our consensus was to leave it to the congestion control
algorithms used prior to entering recovery process. This simplifies the
scope of the algorithm in the document.
We haven't observed any controversial opinions after this decision has been made.


3) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize 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.)

No one has threatened an appeal.


4) For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Linux and FreeBSD supports the specification of this draft.

# Additional Reviews

5) Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

We've received various feedback from the implementors of Linux and FreeBSD
as well as network protocol experts.

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

This document does not require any formal reviews.

7) If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation 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 RFC 8342?

The document does not contain a YANG module.


8) Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language verifications are necessary for the documents.

# Document Shepherd Checks

9) Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes, the document is clearly written and ready to be handed off.

10) Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issue has been identified.

11) What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status of the document is Proposed Standard as there is a strong consensus
in the WG. Datatracker state attributes correctly reflect it.

12) Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

We've confirmed from all authors that there is no IPR related to the contents
of the document.


13) Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, all five authors are willing to be listed as such.

14) Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

idnits 2.17.1 reports no errors in the document. There are some warnings, but
we've confirmed that we don't need to address them.

15) Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No, they are classified correctly.

16) List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None

17) Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

None

18) Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No such reference.

19) Will publication of this document change the status of any existing RFCs?

The document will obsolete RFC6937 as the new specification for PRR and
will move the specification to the Standards Track.

20) 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 aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

This document does not require any IANA actions.

21) List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

This document does not have any new IANA registries.