Proportional Rate Reduction for TCP
draft-ietf-tcpm-prr-rfc6937bis-01
TCP Maintenance Working Group M. Mathis
Internet-Draft N. Dukkipati
Obsoletes: 6937 (if approved) Y. Cheng
Intended status: Standards Track Google, Inc.
Expires: 26 August 2021 22 February 2021
Proportional Rate Reduction for TCP
draft-ietf-tcpm-prr-rfc6937bis-01
Abstract
This document updates the experimental Proportional Rate Reduction
(PRR) algorithm, described RFC 6937, to standards track. PRR
potentially replaces the Fast Recovery and Rate-Halving algorithms.
All of these algorithms regulate the amount of data sent by TCP or
other transport protocol during loss recovery. PRR accurately
regulates the actual flight size through recovery such that at the
end of recovery it will be as close as possible to the ssthresh, as
determined by the congestion control algorithm.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 August 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Mathis, et al. Expires 26 August 2021 [Page 1]
Internet-Draft Proportional Rate Reduction February 2021
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document and WG Information . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changes From RFC 6937 . . . . . . . . . . . . . . . . . . . . 5
4. Relationships to other standards . . . . . . . . . . . . . . 6
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Adapting PRR to other transport protocols . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Normative References . . . . . . . . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . 15
Appendix A. Strong Packet Conservation Bound . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
This document updates the Proportional Rate Reduction (PRR) algorithm
described in [RFC6937] from experimental to standards track. PRR
accuracy regulates the amount of data sent during loss recovery, such
that at the end of recovery the flight size will be as close as
possible to the ssthresh, as determined by the congestion control
algorithm. PRR has been deployed in at least 3 major operating
systems covering the vast majority of today's web traffic.
The only change from RFC 6937 is the introduction of a new heuristic
that replaces a manual configuration parameter. There have been no
changes to the behaviors of the algorithms or the previously
published results. The new heuristic only changes behaviors in
corner cases that were not relevant prior to the Lost Retransmission
Detection (LRD) algorithm which was not implemented until after RFC
6937 was published. This document also includes additional
discussion about integration into other congestion control and
recovery algorithms.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]
Show full document text