Subject: [tcpm] 2581 implementation report

From: Mark Allman <[email-masked]>
Date: Mon, 24 Sep 2007 13:38:56 -0400

Folks-

Attached is a short implementation report to send to the IESG when the
WG is ready to forward 2581bis for publication as a draft standard.
Please take a look at it and let me know if you have anything to add
and/or have heartburn with anything in the writeup.

(I am just floating this by the WG for opinions.  Clearly we need to do
a WGLC on the document itself before anything is forwarded over to the
IESG.) 

Thanks,
allman

Background:

  + RFC 2581 is a re-write of RFC 2001.  RFC 2001 was a description
    of TCP's congestion control algorithms that was published long
    after these algorithms were in nearly ubiquitous deployment
    throughout the Internet (largely triggered by the congestion
    collapses of the mid-1980s).

  + While RFC 2001 was a description of the algorithms, RFC 2581 is
    a more traditional specification.  We stress that the RFC was
    written based on running code and experience.

  + The mechanisms in RFC 3042 (Limited Transmit) and RFC 3390
    (Larger Initial Congestion Window) are also rolled into the
    current document.  Both of these enhancements are Proposed
    Standards that have gathered wide consensus within the community
    based on deployment experience.

  + The traditional test of two interoperable implementations to
    move a Proposed Standard to Draft Standard is less obvious in
    the case of congestion control mechanisms.  Congestion control
    is about *when* to send a segment and not *what* that segment
    looks like, how to process it, how big fields are, etc.
    Therefore, it is difficult to assess "interoperability" in the
    traditional sense.  Below we cite several sources that show or
    suggest that multiple implementations of the mechanisms exist
    and seem to work as intended.

  + The new version of the document clarifies a number of small
    issues that implementers have asked about over the years, but
    does not make any large changes to the algorithms.

Known Implementations:

  + [WS95] discusses the BSD implementation of the core algorithms
    in RFC 2581 (slow start, congestion avoidance, fast retransmit
    and fast recovery).  This implementation has formed the basis of
    the TCP stack in numerous operating systems (NetBSD, FreeBSD,
    OpenBSD, SunOS 4.x, BSDI, etc.).  While various operating
    systems may have diverged in small details (some of which is
    documented in RFC 2581) the basic algorithms do not seem to have
    changed.

  + [Pax97] analyzes a number of implementations, finding both
    correct and incorrect behavior relative to RFC 2581 across a
    variety of implementations.  The incorrect behavior fed into
    [RFC2525].

  + [MAF05] tests for conformance along a number of angles by
    probing the TCPs of over 70K web servers with specialized packet
    streams that induce the stack to show how it handles various
    situations. The results include:

      + The vast majority of server reduce their congestion window
        by half in response to congestion (per RFC 2581's congestion
        avoidance).

      + The majority of the web servers used an initial congestion
        window of 1--2 packets.

      + Limited Transmit was used in over 20% of the servers.

      + While some servers do not use fast retransmit the
        overwhelming majority implement it.

      + Many web servers use the fast recovery algorithm (with a
        number using more advanced recovery such as NewReno
        [RFC3782] or SACK-based loss recovery techniques
        [RFC2018,RFC3517].

    (Note that [MAF05] updates some of the results of [PF01].  The
    newer results confirm the older results.)

References:

  [MAF05] Alberto Medina, Mark Allman, Sally Floyd.  Measuring the
    Evolution of Transport Protocols in the Internet.  ACM Computer
    Communication Review, 35(2), April 2005.

  [Pax97] Vern Paxson.  Automated Packet Trace Analysis of TCP
    Implementations.  ACM SIGCOMM, September 1997.

  [PF01] Jitu Padhye, Sally Floyd.  Identifying the TCP Behavior of
  Web Servers, SIGCOMM 2001, August 2001. 

  [WS95] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The
    Implementation", Addison-Wesley, 1995.
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Sep 2007 08:59:11 +0300 (EEST)

> a WGLC on the document itself before anything is forwarded over to the

Have all the features of the spec been implemented by at least two 
independent implementations?  I don't see the writeup clearly 
answering that question.

Half-aside: At different times, different folks have had varying views 
on what "all the features" mean -- whether it means every 
'may/should/must' (lower or uppercase) or something larger, at the 
very least some more detail than "fast retransmit -- check!" would 
likely be helpful.

Also, as most testing and observation references point to the work 
that was done prior to 2581 revision, you might want to add an 
explicit statement about how these changes should or shouldn't matter 
from the interoperability and implementation (i.e.: have the new 
modifications been implemented as well?) perspective.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings