RACK: a time-based fast loss detection algorithm for TCP
draft-ietf-tcpm-rack-07
|
| Document |
Type |
|
Active Internet-Draft (tcpm WG)
|
|
Last updated |
|
2020-01-17
|
|
Replaces |
|
draft-cheng-tcpm-rack
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
Proposed Standard
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
Martin Duke
|
| IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
Martin Duke <martin.h.duke@gmail.com>
|
TCP Maintenance Working Group Y. Cheng
Internet-Draft N. Cardwell
Intended status: Standards Track N. Dukkipati
Expires: July 20, 2020 P. Jha
Google, Inc
Jan 17, 2020
RACK: a time-based fast loss detection algorithm for TCP
draft-ietf-tcpm-rack-07
Abstract
This document presents a new TCP loss detection algorithm called RACK
("Recent ACKnowledgment"). RACK uses the notion of time, instead of
packet or sequence counts, to detect losses, for modern TCP
implementations that can support per-packet timestamps and the
selective acknowledgment (SACK) option. It is intended to replace
the conventional DUPACK threshold approach and its variants, as well
as other nonstandard approaches.
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 July 20, 2020.
Copyright Notice
Copyright (c) 2020 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
Cheng, et al. Expires July 20, 2020 [Page 1]
Internet-Draft RACK Jan 2020
to this document. Code Components 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.
1. Terminology
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. In this document, these words will appear
with that interpretation only when in UPPER CASE. Lower case uses of
these words are not to be interpreted as carrying [RFC2119]
significance.
2. Introduction
This document presents a new loss detection algorithm called RACK
("Recent ACKnowledgment"). RACK uses the notion of time instead of
the conventional packet or sequence counting approaches for detecting
losses. RACK deems a packet lost if it has not been delivered and
some packet sent sufficiently later has been delivered. It does this
by recording packet transmission times and inferring losses using
cumulative acknowledgments or selective acknowledgment (SACK) TCP
options.
In recent years we have been observing several increasingly common
loss and reordering patterns in the Internet:
1. Slow recovery due to lost retransmissions. Traffic policers
[POLICER16] and burst losses often cause retransmissions to be
lost again. This severely increases latency because the lost
retransmissions can only be recovered by retransmission timeouts
(RTOs).
2. Tail drops. Structured request-response traffic turns more
losses into tail drops. In such cases, TCP is application-
limited, so it cannot send new data to probe losses and has to
rely on retransmission timeouts (RTOs).
3. Reordering. Link-layer protocols (e.g., 802.11 block ACK), link
bonding, or routers' internal load-balancing can deliver TCP
packets out of order. The degree of such reordering is usually
within the order of the path round trip time.
Despite TCP stacks (e.g. Linux) that implement many of the standard
and proposed loss detection algorithms
Cheng, et al. Expires July 20, 2020 [Page 2]
Internet-Draft RACK Jan 2020
[RFC4653][RFC5827][RFC5681][RFC6675][RFC7765][FACK][THIN-STREAM],
we've found that together they do not perform well. The main reason
is that many of them are based on the classic rule of counting
Show full document text