[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