The Eifel Response Algorithm for TCP
RFC 4015
|
| Document |
Type |
|
RFC - Proposed Standard
(February 2005; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4015 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jon Peterson
|
|
Send notices to |
|
<mankin@psg.com>, <jon.peterson@neustar.biz>
|
Network Working Group R. Ludwig
Request for Comments: 4015 Ericsson Research
Category: Standards Track A. Gurtov
HIIT
February 2005
The Eifel Response Algorithm for TCP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Based on an appropriate detection algorithm, the Eifel response
algorithm provides a way for a TCP sender to respond to a detected
spurious timeout. It adapts the retransmission timer to avoid
further spurious timeouts and (depending on the detection algorithm)
can avoid the often unnecessary go-back-N retransmits that would
otherwise be sent. In addition, the Eifel response algorithm
restores the congestion control state in such a way that packet
bursts are avoided.
1. Introduction
The Eifel response algorithm relies on a detection algorithm such as
the Eifel detection algorithm, defined in [RFC3522]. That document
contains informative background and motivation context that may be
useful for implementers of the Eifel response algorithm, but it is
not necessary to read [RFC3522] in order to implement the Eifel
response algorithm. Note that alternative response algorithms have
been proposed [BA02] that could also rely on the Eifel detection
algorithm, and alternative detection algorithms have been proposed
[RFC3708], [SK04] that could work together with the Eifel response
algorithm.
Based on an appropriate detection algorithm, the Eifel response
algorithm provides a way for a TCP sender to respond to a detected
spurious timeout. It adapts the retransmission timer to avoid
Ludwig & Gurtov Standards Track [Page 1]
RFC 4015 The Eifel Response Algorithm for TCP February 2005
further spurious timeouts and (depending on the detection algorithm)
can avoid the often unnecessary go-back-N retransmits that would
otherwise be sent. In addition, the Eifel response algorithm
restores the congestion control state in such a way that packet
bursts are avoided.
Note: A previous version of the Eifel response algorithm also
included a response to a detected spurious fast retransmit.
However, as a consensus was not reached about how to adapt the
duplicate acknowledgement threshold in that case, that part of the
algorithm was removed for the time being.
1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
We refer to the first-time transmission of an octet as the 'original
transmit'. A subsequent transmission of the same octet is referred
to as a 'retransmit'. In most cases, this terminology can also be
applied to data segments. However, when repacketization occurs, a
segment can contain both first-time transmissions and retransmissions
of octets. In that case, this terminology is only consistent when
applied to octets. For the Eifel detection and response algorithms,
this makes no difference, as they also operate correctly when
repacketization occurs.
We use the term 'acceptable ACK' as defined in [RFC793]. That is an
ACK that acknowledges previously unacknowledged data. We use the
term 'bytes_acked' to refer to the amount (in terms of octets) of
previously unacknowledged data that is acknowledged by the most
recently received acceptable ACK. We use the TCP sender state
variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA
holds the segment sequence number of the oldest outstanding segment.
SND.NXT holds the segment sequence number of the next segment the TCP
sender will (re-)transmit. In addition, we define as 'SND.MAX' the
segment sequence number of the next original transmit to be sent.
The definition of SND.MAX is equivalent to the definition of
'snd_max' in [WS95].
We use the TCP sender state variables 'cwnd' (congestion window), and
'ssthresh' (slow-start threshold), and the term 'FlightSize' as
Show full document text