Proportional Rate Reduction for TCP
draft-ietf-tcpm-proportional-rate-reduction-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-05-06
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-04-24
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-04-05
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2013-03-26
|
04 | (System) | RFC Editor state changed to AUTH from EDIT |
2013-03-16
|
04 | Martin Stiemerling | Shepherding AD changed to Martin Stiemerling |
2013-03-11
|
04 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-03-11
|
04 | (System) | RFC Editor state changed to EDIT |
2013-03-11
|
04 | (System) | Announcement was received by RFC Editor |
2013-03-10
|
04 | (System) | IANA Action state changed to No IC |
2013-03-10
|
04 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-03-10
|
04 | Amy Vezza | IESG has approved the document |
2013-03-10
|
04 | Amy Vezza | Closed "Approve" ballot |
2013-03-10
|
04 | Wesley Eddy | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2013-03-10
|
04 | Wesley Eddy | Ballot writeup was changed |
2013-03-10
|
04 | Wesley Eddy | Ballot writeup was changed |
2013-03-10
|
04 | Wesley Eddy | Ballot writeup was changed |
2013-03-07
|
04 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2013-02-28
|
04 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2013-02-28
|
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-02-28
|
04 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-02-27
|
04 | Pete Resnick | [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 … [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. |
2013-02-27
|
04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-02-27
|
04 | Stephen Farrell | [Ballot comment] - " RFC 793: snd.una": too terse - Is it PRR+SSRB or PRR-SSRB? Using only one consistently is better. other typos: p3, … [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/ |
2013-02-27
|
04 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-02-27
|
04 | Wesley Eddy | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-02-26
|
04 | Stewart Bryant | [Ballot comment] I agree with Adrian this has more of an "Informational" feel about it. |
2013-02-26
|
04 | Stewart Bryant | Ballot comment text updated for Stewart Bryant |
2013-02-26
|
04 | Stewart Bryant | [Ballot comment] I agree with Adrian this has more of an information feel about it. |
2013-02-26
|
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-02-26
|
04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-02-26
|
04 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2013-02-26
|
04 | Benoît Claise | [Ballot comment] See Nevil's Brownlee's feedback (OPS Directorate) - - - - 1. Is the specification complete? Can multiple interoperable implementations be built … [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/ |
2013-02-26
|
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-02-26
|
04 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-02-26
|
04 | Adrian Farrel | [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 … [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. |
2013-02-26
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-02-26
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-02-25
|
04 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2013-02-25
|
04 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-02-24
|
04 | Russ Housley | [Ballot comment] The Abstract is quite long. I propose a shorter version: This document describes an experimental Proportional Rate Reduction (PPR) algorithm … [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. |
2013-02-24
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2013-02-22
|
04 | Pearl Liang | 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 … 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 |
2013-02-21
|
04 | Wesley Eddy | Ballot has been issued |
2013-02-21
|
04 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2013-02-21
|
04 | Wesley Eddy | Created "Approve" ballot |
2013-02-21
|
04 | Wesley Eddy | Ballot writeup was changed |
2013-02-14
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2013-02-14
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2013-02-14
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Simon Josefsson |
2013-02-14
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Simon Josefsson |
2013-02-12
|
04 | Amy Vezza | 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 … 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. |
2013-02-12
|
04 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-02-12
|
04 | Amy Vezza | Last call announcement was changed |
2013-02-11
|
04 | Wesley Eddy | Placed on agenda for telechat - 2013-02-28 |
2013-02-11
|
04 | Wesley Eddy | Last call was requested |
2013-02-11
|
04 | Wesley Eddy | Last call announcement was generated |
2013-02-11
|
04 | Wesley Eddy | Ballot approval text was generated |
2013-02-11
|
04 | Wesley Eddy | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-02-05
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-02-05
|
04 | Matt Mathis | New version available: draft-ietf-tcpm-proportional-rate-reduction-04.txt |
2012-12-05
|
03 | Wesley Eddy | Ballot writeup was generated |
2012-11-25
|
03 | Wesley Eddy | AD review comments sent to mailing list on 11/25 |
2012-11-25
|
03 | Wesley Eddy | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-11-25
|
03 | Wesley Eddy | State changed to AD Evaluation from Publication Requested |
2012-11-12
|
03 | Amy Vezza | (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? … (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. |
2012-11-12
|
03 | Amy Vezza | State changed to Publication Requested from AD is watching |
2012-11-12
|
03 | Amy Vezza | Note added 'Document Shepherd is Pasi Sarolahti .' |
2012-10-22
|
03 | Matt Mathis | New version available: draft-ietf-tcpm-proportional-rate-reduction-03.txt |
2012-07-16
|
02 | Matt Mathis | New version available: draft-ietf-tcpm-proportional-rate-reduction-02.txt |
2012-03-07
|
01 | Wesley Eddy | Intended Status changed to Experimental |
2012-03-07
|
01 | Wesley Eddy | IESG process started in state AD is watching |
2012-02-24
|
01 | (System) | New version available: draft-ietf-tcpm-proportional-rate-reduction-01.txt |
2011-10-24
|
00 | (System) | New version available: draft-ietf-tcpm-proportional-rate-reduction-00.txt |