2.7.12 TCP Implementation (tcpimpl)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98


Vern Paxson <vern@ee.lbl.gov>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>

Transport Area Advisor:

Allyn Romanow <allyn@mci.net>

Mailing Lists:

General Discussion:tcp-impl@engr.sgi.com
To Subscribe: majordomo@engr.sgi.com
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:

o 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.

o 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.


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.

Goals and Milestones:

Feb 97


Working group formation. Decide on document editors.

Apr 97


Define schedule for producing the test suite catalog

Apr 97


First Internet-Draft of problems and fixes, and very rough first draft of catalogue of test suites.

Jul 97


Issue revised Internet-Draft documents.

Sep 97


Cut-off for determining whether clarification document is needed. If necessary, have interim meeting to focus effort on clarification document.

Dec 97


Submit Internet-Draft of test catalogue to IESG for publication as an RFC.

Dec 97


Submit Internet-Draft of problems and fixes to IESG for publication as an RFC.

Mar 98


Submit Internet-Draft clarifying RFCs 793, 1122, and 1323 to IESG for publication as an RFC.

Mar 98


CLose WG down.


No Request For Comments

Current Meeting Report

Minutes of the TCP Implementation (tcpimpl) Working Group

Minutes reported by Mark Allman and Vern Paxson.

I. Testing Tools I-D

Last call for the I-D found two problems. Vern outlined the modifications required before forwarding the I-D to the IESG. A section on the ns network simulator will be added to the draft. Also, a better security section is needed. The security considerations that will be included are:

II. Known Problems I-D

Vern noted the changes to the Known Problems I-D since the last meeting. These changes included a few general clarifications and a new section on the ``Failure to RST on close with data pending.''

III. Pending Problems

The problems that have not yet been documented in the known problems I-D have been classified as either serious, not-so-serious or security related. The goal behind the classification is to do triage on where our efforts should go in order to finalize the known-problems I-D.

The proposed serious problems were:

It was noted that first-hop PMTU discovery should not be special-cased, as it is a general path problem. Matt Mathis wondered if the MTU black hole is a bug or a research question. He further noted that MTU discovery should be done without ICMP due to security concerns (and, noted that this might fall under ``security problems'' rather than ``serious problems''). Matt suggested that we note the problem and state that we do not yet know how to solve it. Ran Atkinson suggested that MTU discovery is not a security problem as a host must be continuously jammed with ``too small'' ICMP messages for an attack to be successful. Matt suggested advocating that the IESG re-open PMTU Discovery as broken.

The less serious problems were then outlined:

It was pointed out that cwnd can stop growing when the window becomes too large using the standard algorithm during congestion avoidance and that this should be documented. Vern asked whether this has been observed in practice, and the answer was Yes.

The proposed security problems were:

Ran noted that forged unreachables is an IP problem not a TCP problem. Furthermore, he suggested that if we are planning to deal with unreachables we should also document forged redirects. Vern begged for volunteers to write up security problems.

IV. Re-starting Idle Connections

Amy Hughes presented an overview of mechanisms that can be used to prevent large line-rate bursts following an idle period during a TCP connection. Amy outlined three ways to detect bursts:

1. Receive Timer (if connection has not received a segment within the last RTO).
2. Send Timer (if the connection has not sent a segment within the last RTO)
3. Packet Counting (if the number of segments to be sent is larger than a given threshold)

Also, four methods of ``burst recovery'' were outlined:

1. Full restart (reset cwnd to 1 segment)
2. Window limiting (cwnd = outstanding + 1 segment (or initial value))
3. Burst limitation (cwnd unchanged; send X segments now)
4. Pacing (cwnd unchanged; send X segments now and schedule a timer for the next transmission of X segments)

Finally, four possible solutions were presented:

It was also noted in the presentation that bursting situations other than those that can follow idle TCP connections are handled by congestion window monitoring (CWM), maxburst limitations and rate based pacing, but not by the timer solution.

A discussion of the mechanisms followed. Some of the comments voiced:

V. ns' New Network Emulation Capabilities

Kevin Fall presented an overview of ns and ns-2's network emulation capabilities that are currently being researched. Kevin's slides are available at: http://www-nrg.ee.lbl.gov/kfall/tcpimpl98.ppt

VI. Increasing the Initial Window Size

Sally presented a short overview of the proposal to increase TCP's initial window size. Vern re-iterated the consensus of the last TCPIMPL meeting: That rough consensus was generated for an initial window of 2 segments and that 3 and 4 segment initial windows would be accepted at this meeting unless new evidence is shown or a convincing argument was made. A discussion followed. Below are some of the major points:

Vern called for a show of hands and it was determined that rough consensus exists for larger initial windows per the proposal.


None Received

Attendees List

go to list