NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. 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>
Transport Area Advisor:
Allyn Romanow <allyn.romanow@eng.sun.com>
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:
· 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.
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. |
Internet-Drafts:
· Known TCP Implementation Problems
· Some Testing Tools for TCP Implementors
No Request For Comments
Minutes of the TCP/IP Implementor's Working Group Meeting
Reported by Steve Alexander and Vern Paxson
Steve Alexander presented an overview of recent changes that have been made to the "Known Problems" I-D. There were two, namely:
· A discussion of keepalive problems was added
· The "significance" category now includes a description of environments in which the problem is significant
Steve Parker then gave an overview of the current status of the "Testing Tools" I-D. For each tool listed, the document provides information on:
· name
· category
· availability
· description
· an overview of how automated the tool is
· other references
Currently the following tools are described:
· dummynet, netperf, orchestra, packet shell, tcpanaly, tcptrace,
· tcplook, treno
Feedback from the audience suggested two additions:
· Sock (Rich Stevens' test program); Kent Malave agreed to provide a description of this
· SPINS, a protocol verification package
The next item on the agenda was an overview of proposed changes to RFC 2001. 2001 is being revised to allow implementations which implement the required algorithms in an acceptable manner, but which may differ slightly from 4.3-BSD-Reno to be considered conformant to RFC 2001. At the same time, it is proposed that the initial slow-start window should be increased to two segments.
There is an internet draft written by Floyd/Allman/Partridge, which discusses some additional proposed changes. Craig Partridge gave an overview of terms:
· IW; initial congestion window
· RW; restart congestion window after idle
· LW; congestion window used after a loss
Sally Floyd indicated that more research was needed to ensure that the correct trade-offs are made between good scenarios and bad.
Craig Partridge asserted that no simulations done to date showed any problems with raising IW to two segments, but agreed that more cross-traffic simulation is probably a good idea.
Allyn Romanow pointed out that not all of the changes in the Floyd/Allman/Partridge draft were being considered for the RFC 2001 update; only increasing IW to two segments.
Van Jacobson gave a historical overview of the reasons for the IW being one segment initially, namely a very early ethernet card that could only buffer a single frame on receive. Van also pointed out that dropped SYNs were a large problem with current web traffic.
It was pointed out that if the congestion window oscillated between one segment and two, that this might be less bursty than with four.
Matt Mathis pointed out that the current spec (2001) isn't completely up-to-date with all of the latest TCP congestion control enhancements.
Craig agreed that more simulation should be done to ensure that fairness issues are handled correctly.
Van pointed out that timing is really used for congestion control. He explained that the RTT est. is not really used to estimate round trip time, but rather as a clock to determine when it is likely that a packet has left the network. Van suggested that using the max rtt might be better than using the single RTT, which is a lower bound.
Craig Partridge volunteered to write up the RTO algorithm (Karn's) as an RFC, since it is not currently documented in the RFC series.
Bob Braden mentioned that the reason that a lot of Van's early work is not explained in RFC 1122 is that the 1122 working group didn't think that they could explain it as well, and that it provided an incentive to read the paper and get the whole story. It was suggested that Van should convert the paper into an RFC; Van seemed amenable.
After the congestion control discussion ended, a list of outstanding problems for the "Known Problems" I-D was presented, and again, volunteers were solicited to contribute text to the I-D.
Bernard Volz mentioned a new problem, namely implementations that only send a FIN after all outstanding data has been ACKed; this should be added to the I-D.
A discussion of the IRTF End2end group's position on research vs. engineering was skipped. This was because the summary had been posted to the mailing list but generated little interest.
The meeting then adjourned.
Action items:
· Kent Malave, write up description of 'sock'
· Ian Heavens, write up issues around half-duplex close
· Van Jacobson, possibly write up latest SIGCOMM paper as RFC
· Craig Partridge, write I-D on Karn's algorithm
None Received
Roster Not Received