[Iccrg] iccrg status at IETF tsvwg meeting
Wesley Eddy
weddy at grc.nasa.gov
Wed Mar 22 21:45:36 GMT 2006
On Wed, Mar 22, 2006 at 05:15:11PM +0100, Michael Welzl wrote:
>
> For TCP beyond VJ algorithms, you could simply point to the
> Roadmap document of TCPM.
To save people from having to look this up and grep through the
document, here are the relevent extracts from the TCP Roadmap I-D. It
is interesting to note that in constructing the TCP Roadmap, we found it
difficult to distinguish between congestion control and loss recovery
functions. Some discussion of this follows in the pasted text. In my
opinion, the relation between these two functions should be further
considered by the ICCRG.
In Section 2 - "Basic Functionality":
"""
RFC 2581 S: "TCP Congestion Control" (April 1999)
Although RFC 793 did not contain any congestion control
mechanisms, today congestion control is a required component of
TCP implementations. This document [RFC2581] defines the current
versions of Van Jacobson's congestion avoidance and control
mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. RFC
2001 was a conceptual precursor that was obsoleted by RFC 2581.
A number of behaviors that together comprise what the community
refers to as "Reno TCP", are described in RFC 2581. The name
"Reno" comes from the Net/2 release of the 4.3 BSD operating
system. This is generally regarded as the least common
denominator among TCP flavors currently found running on Internet
hosts. Reno TCP includes the congestion control features of slow
start, congestion avoidance, fast retransmit, and fast recovery.
RFC 1122 mandates the implementation of a congestion control
mechanism, and RFC 2581 details the currently accepted mechanism.
RFC 2581 differs slightly from the other documents listed in this
section, as it does not affect the ability of two TCP endpoints to
communicate; however, congestion control remains a critical
component of any widely-deployed TCP implementation and is
required for the avoidance of congestion collapse and to ensure
fairness among competing flows.
"""
Since computation of the RTT and guessing a reasonable RTO is an important
part of congestion control, I would also include:
"""
RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)
Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer. It expands on the
discussion in section 4.2.3.1 of RFC 1122 and upgrades the
requirement of supporting the algorithm from a SHOULD to a MUST."
[RFC2988]
"""
In Section 3 - "Recommended Enhancements"
"""
RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
to IP" (September 2001)
This document [RFC3168] defines a means for end hosts to detect
congestion before congested routers are forced to discard packets.
Although congestion notification takes place at the IP level, ECN
requires support at the transport level (e.g., in TCP) to echo the
bits and adapt the sending rate. This document updates RFC 793 to
define two previously-unused flag bits in the TCP header for ECN
support. RFC 3540 provides a supplementary (experimental) means
for more secure use of ECN, and RFC 2884 provides some sample
results from using ECN.
3.1 Congestion Control and Loss Recovery Extensions
Two of the most important aspects of TCP are its congestion control
and loss recovery features. Since TCP traditionally (in the absence
of ECN) uses losses to infer congestion, there is a rather intimate
coupling between congestion control and loss recovery mechanisms.
There are several extensions to both features, and more often than
not, a particular extension applies to both. In this sub-section, we
group enhancements to either congestion control, loss recovery, or
both, which can be performed unilaterally - without negotiating
support between endpoints. In the next sub-section, we group the
extensions which specify or rely on the SACK option, which must be
negotiated bilaterally. TCP implementations should include the
enhancements from both sub-sections so that TCP senders can perform
well without regard to the feature sets of other hosts they connect
to. For example, if SACK use is not successfully negotiated, a host
should use the NewReno behavior as a fall-back.
RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
(January 2001)
Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection's
congestion window is small, or when a large number of segments are
lost in a single transmission window." [RFC3042]
Tests from 2004 showed that Limited Transmit was deployed in
roughly one third of the web servers tested [MAF04].
RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)
This document [RFC3390] updates RFC 2581 to permit an initial TCP
window of three or four segments during the slow-start phase,
depending on the segment size.
RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
Algorithm" (April 2004)
This document [RFC3782] specifies a modification to the standard
Reno fast recovery algorithm, whereby a TCP sender can use partial
acknowledgements to make inferences determining the next segment
to send in situations where SACK would be helpful, but isn't
available. While it is only a slight modification, the NewReno
behavior can make a significant difference in performance when
multiple segments are lost from a single window of data.
3.2 SACK-based Loss Recovery and Congestion Control
The base TCP specification in RFC 793 provided only a simple
cumulative acknowledgment mechanism. However, a selective
acknowledgment (SACK) mechanism provides performance improvement in
the presence of multiple packet losses from the same flight, more
than outweighing the modest increase in complexity. A TCP should be
expected to implement SACK, however SACK is a negotiated option and
is only used if support is advertised by both sides of a connection.
RFC 2018 S: "TCP Selective Acknowledgement Options" (October 1996)
This document [RFC2018] defines the basic selective
acknowledgement (SACK) mechanism for TCP.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (July 2000)
This document [RFC2883] extends RFC 2018 to cover the case of
acknowledging duplicate segments.
RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based
Loss Recovery Algorithm for TCP" (April 2003)
This document [RFC3517] describes a relatively sophisticated
algorithm that a TCP sender can use for loss recovery when SACK
reports more than one segment lost from a single flight of data.
While support for the exchange of SACK information is widely
implemented, not all implementations use an algorithm as
sophisticated as that described in RFC 3517.
"""
Then, in Section 4 - "Experimental Extensions", there are several
relevent entries, all of which represent tweaks to the congestion
control/loss recovery functions (or function):
"""
RFC 2140 I: "TCP Control Block Interdependence" (April 1997)
This document [RFC2140] suggests how TCP connections between the
same endpoints might share information, such as their congestion
control state. To some degree, this is done in practice by a few
operating systems; for example, Linux currently has a destination
cache. Although this RFC is technically informational, the
concepts it describes are in experimental use, so we include it in
this section.
A related proposal, the Congestion Manager, is specified in RFC
3124 [RFC3124]. The idea behind the Congestion Manager, moving
congestion control outside of individual TCP connections,
represents a modification to the core of TCP, which supports
sharing information among TCP connections as well. Although a
Proposed Standard, some pieces of the Congestion Manager support
architecture have not been specified yet, and it has not achieved
use or implementation beyond experimental stacks, so it is not
listed among the standard TCP enhancements in this roadmap.
RFC 2861 E: "TCP Congestion Window Validation" (June 2000)
This document [RFC2861] suggests reducing the congestion window
over time when no packets are flowing. This behavior is more
aggressive than that specified in RFC 2581, which says that a TCP
sender SHOULD set its congestion window to the initial window
after an idle period of an RTO or greater.
RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
(ABC)" (February 2003)
This document [RFC3465] suggests that congestion control use the
number of bytes acknowledged rather than the number of
acknowledgements received. This has been implemented in Linux.
The ABC mechanism behaves differently than the standard method
when there is not a one-to-one relationship between data segments
and acknowledgements. ABC still operates within the accepted
guidelines, but is more robust to delayed ACKs and ACK-division
[SCWA99][RFC3449].
RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003)
This document [RFC3522] suggests using timestamps to detect
spurious timeouts.
RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling
with Nonces" (June 2003)
This document [RFC3540] suggests a modified ECN to address
security concerns, and updates RFC 3168.
RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December
2003)
This document [RFC3649] suggests a modification to TCP's steady-
state behavior to efficiently use very large windows.
RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs)
and Stream Control Transmission Protocol (SCTP) Duplicate
Transmission Sequence Numbers (TSNs) to Detect Spurious
Retransmissions" (February 2004)
Abstract: "TCP and Stream Control Transmission Protocol (SCTP)
provide notification of duplicate segment receipt through
Duplicate Selective Acknowledgement (DSACKs) and Duplicate
Transmission Sequence Number (TSN) notification, respectively.
This document presents conservative methods of using this
information to identify unnecessary retransmissions for various
applications." [RFC3708]
RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion
Windows" (March 2004)
This document [RFC3742] describes a more conservative slow-start
behavior to prevent massive packet losses when a connection uses a
very large window.
RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)
This document [RFC4015] describes the response portion of the
Eifel algorithm, which can be used in conjunction with one of
several methods of detecting when loss recovery has been
spuriously entered, such as the Eifel detection algorithm in RFC
3522, the algorithm in RFC 3708, or F-RTO in RFC 4138.
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 can avoid - depending on the
detection algorithm - 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."
RFC 4015 is itself a Proposed Standard. The consensus of the TCPM
working group was to place it in this section of the roadmap
document due to three factors.
1. RFC 4015 operates on the output of a detection algorithm, for
which there is currently no available mechanism on the
standards track.
2. The working group was not aware of any wide deployment and use
of RFC 4015.
3. The concensus of the working group, after a discussion of the
known Intellectual Property Rights claims on the techniques
described in RFC 4015, identified this section of the roadmap
as an appropriate location.
RFC 4138 E: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and the Stream Control
Transmission Protocol" (August 2005)
The F-RTO detection algorithm [RFC4138] provides another option
for inferring spurious retransmission timeouts. Unlike some
similar detection methods, F-RTO does not rely on the use of any
TCP options.
"""
--
Wesley M. Eddy
Verizon Federal Network Systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060322/8db95495/attachment-0001.bin
More information about the Iccrg
mailing list