Proportional Rate Reduction for TCP
draft-ietf-tcpm-proportional-rate-reduction-04

[Ballot comment]
The protocol itself seems buried in the definition of DeliveredData in section 2, and the pseudo-code in section 3. I really think you should separate out the description of the protocol. Getting independent interoperable implementations from the current document is likely to be difficult.

I agree with Adrian that this needs a bit more to be Experimental. The information in the document is helpful, but probably overkill for a specification of this sort.

[Ballot comment]

- "  RFC 793: snd.una":  too terse

- Is it PRR+SSRB or PRR-SSRB? Using only one consistently
is better.

other typos:
p3, s/slight difference/slight differences/
p3, s/discussions algorithms/discussions of algorithms/

[Ballot comment]
See Nevil's Brownlee's feedback (OPS Directorate)

- - - -

1. Is the specification complete?  Can multiple interoperable
    implementations be built based on the specification?

The Proportional Rate algorithm and two reduction bound algorithms
are described in some detail, with C source code and explanations
of what the variables represent.  I believe there's enough detail
to implement PRR-SSRB (PRR with Slow Start Reduction Bound) from
this draft.

2. Is the proposed specification deployable?  If not, how could it be
    improved?

The draft doesn't consider this, however I see no reason why a TCP
sender using PRR would not interwork properly with other TCP
implementations, e.g. TCP Reno.  It would be good to see some comment
in the draft to say that, or - better - reporting on such an
interoperability test.

3. Does the proposed approach have any scaling issues that could
    affect usability for large scale operation?

No.

4. Are there any backward compatibility issues?

No, but see (2) above.

5. Do you anticipate any manageability issues with the specification?

Since this draft proposes an update to TCP, it will be implemented
in Operating Systems.  Site managers will need to be aware of which OS
versions that use it, as one more thing to check on should any
TCP interoperation problems manifest themselves.

6. Does the specification introduce new potential security risks or
    avenues for fraud?

No.

A few typos:

- Early in the draft PPR is often used when it should be PRR
- last para page 4:
    missing comma, s/of RFC 3517 we are/of RFC 3517, we are/
    s/General discussions algorithms/General discussions of algorithms/
- section 4 last para:
    s/Bound in very appealing/Bound is very appealing/

[Ballot comment]
I appreciate this work and the open presentations of the results of
experimentation.  However, the document left me feeling that this was an
Informational report on an experiment rather than an Experimental
document where you wanted the IETF to participate in the Experiment.

The former is very useful, but would need the status to be changed to
Informational.  The latter, would, IMHO be a far better thing.  To get
there you need to describe the experiment you want to be undertaken,
the limits and risks (can it be done on the Open Internet? do both ends
need to know that the experiment is happening? are there interactions
with other algorithms in use through congested areas?), what feedback
you are looking for, and how/when the experiment will be judged.  While
this sort of explanation has not been conventionally present in
Experimental RFCs, I believe including it makes life simpler and clearer
for everyone.

[Ballot comment]

  The Abstract is quite long.  I propose a shorter version:

  This document describes an experimental Proportional Rate Reduction
  (PPR) algorithm as an alternative to the traditional Fast Recovery
  and Rate Halving algorithms.  These algorithms determine the amount
  of data sent by TCP during loss recovery.  PRP minimizes excess
  window adjustments and the actual window size will be as close as
  possible to the window size determined by the congestion control
  algorithm.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tcpm-proportional-rate-reduction-04,
which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

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

Thank you,

ICANN/IANA

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Proportional Rate Reduction for TCP) to Experimental RFC


The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'Proportional Rate Reduction for TCP'
  as Experimental
RFC

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

Abstract


  This document describes an experimental algorithm, Proportional Rate
  Reduction (PPR) to improve the accuracy of the amount of data sent by
  TCP during loss recovery.  Standard Congestion Control requires that
  TCP and other protocols reduce their congestion window in response to
  losses.  This window reduction naturally occurs in the same round
  trip as the data retransmissions to repair the losses, and is
  implemented by choosing not to transmit any data in response to some
  ACKs arriving from the receiver.  Two widely deployed algorithms are
  used to implement this window reduction: Fast Recovery and Rate
  Halving.  Both algorithms are needlessly fragile under a number of
  conditions, particularly when there is a burst of losses such that
  the number of ACKs returning to the sender is small.  Proportional
  Rate Reduction minimizes these excess window adjustments such that at
  the end of recovery the actual window size will be as close as
  possible to ssthresh, the window size determined by the congestion
  control algorithm.  It is patterned after Rate Halving, but using the
  fraction that is appropriate for target window chosen by the
  congestion control algorithm.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/ballot/


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

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

This document is requested for publication as Experimental
RFC, as indicated on the title page. During the working group
last call it was proposed that the document should be
published as Proposed Standard, but after the mailing list
discussion that followed the chairs concluded there is no
strong consensus to change the status (but no strong
opposition, either). Also the document authors supported
keeping the document as Experimental.

(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

This document describes an algorithm to improve the accuracy
of the amount of data sent by TCP during loss recovery. The
existing TCP recovery algorithms can make excess window
adjustments in some situations, such as in the presence of
heavy losses, and may result in abrupt TCP behavior in the
form of packet bursts or increased risk of
timeouts. Proportional Rate Reduction aims to minimize the
needed window adjustments, to result in more stable TCP
congestion control behavior in the presence of losses.

Working Group Summary

The document was adopted as Experimental TCPM working group
item by clear working group consensus, and no opinions against
it have been raised during its progress or in the working
group last call.

Document Quality

The algorithm specified in the document has been implemented
in Linux and integrated to the main kernel distribution. The
algorithm has also been evaluated through measurements, and
the evaluation results reported in a paper published in the
IMC'11 conference. Different versions of the document have
been thoroughly reviewed by TCPM working group members.

Personnel

Document Shepherd is Pasi Sarolahti .
Responsible Area Director is Wesley Eddy .

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

Document Shepherd has reviewed the document, including the
comments and the latest version, and thinks the document is
ready for publication without further changes.

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

No.

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

No.

(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 concerns with the document.

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

Yes.

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

No.

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

The document was reviewed and supported by multiple
individuals, and no one has raised opinions against it. The
chairs concluded that there is a solid WG consensus behind the
document.

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

No.

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

ID nits produced two warnings, but these appear to be
unnecessary. There are informative references to RFC 3517 that
was recently obsoleted by RFC 6675, but these are justified,
because they concern evaluations that were made prior to
publication of RFC 6675.

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

No formal reviews are required for this document.

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

Yes.

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

No.

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

No.

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

No.

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

The document does not involve any 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.

No new IANA registries are required.

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

There are no sections that would require formal validation.