Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)
RFC 5827
Internet Engineering Task Force (IETF) M. Allman
Request for Comments: 5827 ICSI
Category: Experimental K. Avrachenkov
ISSN: 2070-1721 INRIA
U. Ayesta
BCAM-IKERBASQUE and LAAS-CNRS
J. Blanton
Ohio University
P. Hurtig
Karlstad University
April 2010
Early Retransmit for TCP
and Stream Control Transmission Protocol (SCTP)
Abstract
This document proposes a new mechanism for TCP and Stream Control
Transmission Protocol (SCTP) that can be used to recover lost
segments when a connection's congestion window is small. The "Early
Retransmit" mechanism allows the transport to reduce, in certain
special circumstances, the number of duplicate acknowledgments
required to trigger a fast retransmission. This allows the transport
to use fast retransmit to recover segment losses that would otherwise
require a lengthy retransmission timeout.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5827.
Allman, et al. Experimental [Page 1]
RFC 5827 Early Retransmit for TCP and SCTP April 2010
Copyright Notice
Copyright (c) 2010 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
1. Introduction
Many researchers have studied the problems with TCP's loss recovery
[RFC793, RFC5681] when the congestion window is small, and they have
outlined possible mechanisms to mitigate these problems
[Mor97, BPS+98, Bal98, LK98, RFC3150, AA02]. SCTP's [RFC4960] loss
recovery and congestion control mechanisms are based on TCP, and
therefore the same problems impact the performance of SCTP
connections. When the transport detects a missing segment, the
connection enters a loss recovery phase. There are several variants
of the loss recovery phase depending on the TCP implementation. TCP
can use slow-start-based recovery or fast recovery [RFC5681], NewReno
[RFC3782], and loss recovery, based on selective acknowledgments
(SACKs) [RFC2018, FF96, RFC3517]. SCTP's loss recovery is not as
varied due to the built-in selective acknowledgments.
All of the above variants have two methods for invoking loss
recovery. First, if an acknowledgment (ACK) for a given segment is
not received in a certain amount of time, a retransmission timer
fires, and the segment is resent [RFC2988, RFC4960]. Second, the
Show full document text