• Current Meeting Report
• Slides
• Attendees List

TCP Implementation (tcpimp)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s): 

Steve Alexander <sca@engr.sgi.com>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Director(s): 

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>

Area Advisor: 

Allyn Romanow <allyn.romanow@eng.sun.com>

Mailing Lists: 

General Discussion:tcp-impl@engr.sgi.com
To Subscribe: majordomo@engr.sgi.com
In Body: "subscribe tcp-impl" in the message body
Archive: ftp://ftp.sgi.com/other/tcp-impl/mail.archive

Description of Working Group: 

The objective of this group is to decide how to best address known problems in existing implementations of the current TCP standard(s) and practices. The overall goal is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is felt that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet. 

Examples of detected problems:

·   TCPs that retransmit all unacknowledged data at a single time. This behavior greatly adds to Internet load, at a time when the network is already under stress. The combination can lead to congestion collapse. 
·   TCPs that misinitialize the congestion window, leading to potentially enormous bursts of traffic when new connections begin. Such burstiness can greatly stress Internet routers.

In the BOF, it was generally agreed that problems of this class need to be fixed. 

Scope: 

The scope of this group must be carefully defined in order to ensure timely progress. To this end, TCP issues that still remain areas of research are considered out of scope for the WG. For example new improvements in congestion control algorithms are not within the WG scope. The WG will solicit input from the End-To-End research group of the IRTF on questions of whether a TCP implementation issue is considered research. 

The major objectives of this group will be to :

·   Produce a compilation of known problems and their solutions. This will raise awareness of these issues. 
·   Determine if any problems found are the result of ambiguities in the TCP specification. If necessary, produce a document which clarifies the specification. 
·   Catalog existing TCP test suites, diagnostic tools, testing organizations, and procedures that can be used by implementors to improve their code, and produce a document enumerating them.

· Known TCP Implementation Problems

No Request For Comments 

Current Meeting Report

Minutes of the TCP Implementation (TCPIMP) Working Group 

Reported by: Steve Alexander 

The first formal meeting of the TCP Implementor's Working Group was held at 1:30 PM on Monday, April 7th. The chairs of the group are Steve Alexander (sca@sgi.com) of Silicon Graphics and Vern Paxson (vern@ee.lbl.gov) of Lawrence Berkeley Labs. 

Vern started off the meeting by presenting the agenda. In order to ensure that the attendees were up-to-date, Vern presented a brief overview of the scope, charter, and deliverables of the group. 

A brief overview of the policy on naming of vendor names followed. The current policy is that it is acceptable to mention vendor names explicitly on the mailing list, or in informal discussions, but not in official products of the group, e.g., RFCs. In addition, naming names is inappropriate at formal Working Group meetings. In general, this is motivated by the belief that information about bugs in vendor releases tends to become out-of-date rather quickly, and that embedding such information in documents with a long lifetime is problematic. One exception to this rule is that it is generally felt that referring to "BSD" or "BSD-derived" in a generic sense would be acceptable. 

Vern presented an overview of the current format of the I-D on known TCP problems. This document is an enumeration of problem descriptions, with each description containing: 

· Name 

· Classification 

· Description 

· Significance (this is an impact, not a MUST/SHOULD/MAY) 

· Implications 

· Traces (if available) 

· Information about Detection 

· Suggested Fix 

· Any Specific Information pertaining to the problem 

Vern gave an overview of the current I-D status. At present, it has information about four problems: 

· No initial slow start 

· No slow start after retransmit due to timeout 

· Retransmission of different data 

· Failure to retain above-sequence data (violates SHOULD, not MUST)

The problems remaining to be documented include: 

· Initial RTO too low 

· Uninitialized congestion window 

· Slow-start with two segments 

· Violations of delayed ACK rules 

· Failure to correctly set PSH 

· Brakmo/Peterson header prediction bug 

· Brakmo/Peterson deflation bug 

· Fast retransmit with timestamp sends two segments 

· Dawson keepalive problem 

· Failure to correctly implement Nagle's algorithm 

· Keepalive behavior (0-byte/1-byte) 

· Failure to ACK above-sequence data 

· Predictable ISN security problem 

· SYN-flood security problem 

· Failure to implement fast retransmit/recovery 

· RTO estimation on slow links 

· Replies to random ACKs 

· ICMP error handling 

· Half-duplex close ignores subsequent data 

· Urgent pointer confusion 

At this point, Vern briefly enumerated issues surrounding test tools. The chairs are soliciting a list for compilation into an I-D. The current goal is to have a first draft of this I-D available by the Munich meeting in August. There are a few technical issues related to some of the existing tools, such as Steve Parker's Packet Shell. These are: 

· A portable "raw socket" interface for such tools to use 

· How to suppress responses from the host TCP 

These need to be discussed, either directly between the interested parties, or on the group mailing list. Vern closed with a request for volunteers to help with the following areas: 

· Reporting any problems not on the current list 

· Working on detailed descriptions of known problems for inclusion in the I-D 

· Developing new testing tools 

This concluded the formal agenda and open discussion began. The following issues were raised: 

Is the group formally attempting to survey all available implementations for the known problems, or in an effort to find new issues? Answer: Not really. 

Bob Braden asked what percentage of the attendees are or have been implementors. Roughly 30 indicated they are implementors, and another 10-15 that they were former implementors. Total attendance was recorded as ~70. 

It was suggested that perhaps bake-offs should be started up again. This was generally considered to be a good idea; it is not clear that this is the responsibility of the group, and this should be discussed on the list and with the IESG. 

Matt Mathis raised the issue of backward compatibility and suggested that workarounds for defective implementations should be well known, easy to test for, and easy to disable in the event that they cause performance overhead when not actually needed. He felt that the group should recommend that the workarounds be obsoleted. 

Jim Gettys brought up an issue with connections remaining in FIN-WAIT-2 indefinitely. This appears to be most common when using the Apache web server, but may have other causes as well. This should be added to the list of known issues. 

Perry Metzger brought up the issue of minimizing memory usage in stacks that fail to retain state after the application has closed. This probably requires further discussion on the mailing list. 

Bob Briscoe suggested the specification is ambiguous about slow-start after an idle period. This needs to be reviewed. 

Matt Mathis suggested that part of the above problem is due to failure to agree on what how long of a time value is used to determine whether or not the connection is "idle." He felt that substituting the term "long idle" for "idle" would help stress the point that implementations that don't slow-start even after an hour or so of being idle are out of spec. The precise definition of "long idle" vs. "short idle" is still an area for research, but an hour is clearly too long. 

Perry Metzger brought up the fact that RFC 1948 (Defending Against Sequence Number Attacks) is not currently a standards-track document. Vern suggested that perhaps the group should recommend it in one of the new documents. We should probably also investigate whether the status of the document could (or should) be changed, possibly to BCP. 

Ian Heavens raised the issue of problem taxonomy. This may just be an issue of how the current I-D is organized. We should discuss this on the list. 

The meeting concluded at this point. 

Slides

Attendees List