RACK: a time-based fast loss detection algorithm for TCP
draft-ietf-tcpm-rack-02
|
| Document |
Type |
|
Active Internet-Draft (tcpm WG)
|
|
Last updated |
|
2017-03-13
|
|
Replaces |
|
draft-cheng-tcpm-rack
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
Experimental
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
(wg milestone:
Sep 2017 - Submit document on a...
)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
TCP Maintenance Working Group Y. Cheng
Internet-Draft N. Cardwell
Intended status: Experimental N. Dukkipati
Expires: September 14, 2017 Google, Inc
March 13, 2017
RACK: a time-based fast loss detection algorithm for TCP
draft-ietf-tcpm-rack-02
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 http://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 September 14, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://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 extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Cheng & Cardwell Expires September 14, 2017 [Page 1]
Internet-Draft RACK March 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. 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 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 the last couple of years we have been observing several
increasingly common loss and reordering patterns in the Internet:
1. Lost retransmissions. Traffic policers [POLICER16] and burst
losses often cause retransmissions to be lost again, severely
increasing TCP latency.
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) 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
[RFC3517][RFC4653][RFC5827][RFC5681][RFC6675][RFC7765][FACK][THIN-
STREAM][TLP], 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 duplicate acknowledgments [RFC5681]. They can either detect
loss quickly or accurately, but not both, especially when the sender
is application-limited or under reordering that is unpredictable.
And under these conditions none of them can detect lost
retransmissions well.
Also, these algorithms, including RFCs, rarely address the
interactions with other algorithms. For example, FACK may consider a
packet is lost while RFC3517 may not. Implementing N algorithms
while dealing with N^2 interactions is a daunting task and error-
prone.
Cheng & Cardwell Expires September 14, 2017 [Page 2]
Show full document text