NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Vern Paxson <vern@ee.lbl.gov>
Mark Allman <mallman@lerc.nasa.gov>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:tcp-impl@lerc.nasa.gov
To Subscribe: majordomo@lerc.nasa.gov
Archive: http://tcp-impl.lerc.nasa.gov/tcp-impl
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.
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. |
Jun 98 |
|
Submit Internet-Draft on increasing TCP's initial window size for publication as an experimental RFC. |
Jul 98 |
|
Submit Internet-Draft of test catalogue to IESG for consideration as an informational RFC. |
Jul 98 |
|
Submit I-Ds in support of larger initial window I-D to IESG for consideration as an Informational RFCs |
Jul 98 |
|
Begin work on revisions to RFC 2001. |
Jul 98 |
|
Begin work on a security problems document (to be much like the known problems I-D currently being developed). |
Aug 98 |
|
Submit revised version of problems and fixes as an Internet-Draft. |
Oct 98 |
|
Submit problems and fixes document to IESG for consideration as an Informational RFC. |
Jan 99 |
|
Submit revision of RFC 2001 to IESG for publication as Proposed Standard. Most likely this will include changes to the initial window, reflecting experienced gained with the Experimental initial window RFC. May include changes to restart-after-idle behavior |
Jan 99 |
|
Submit I-D on TCP security issues to IESG for consideration as an Informational RFC. |
Feb 99 |
|
Conclude Working Group |
Internet-Drafts:
· Known TCP Implementation Problems
· TCP Implementation Problems That Need To Be Documented
Request For Comments:
RFC |
Status |
Title |
RFC2398 |
Some Testing Tools for TCP Implementors | |
RFC2414 |
E |
Increasing TCP's Initial Window |
RFC2415 |
Simulation Studies of Increased Initial TCP Window Size | |
RFC2416 |
When TCP Starts Up With Four Packets Into Only Three Buffers | |
TCPIMPL Meeting Minutes
December 9, 1998
Report by: Joe Touch (touch@isi.edu),
Mark Allman (mallman@lerc.nasa.gov),
Vern Paxson (vern@ee.lbl.gov)
The status of WG documents was reviewed, as follows:
Known Problems document is now with the AD for submission to the IESG for publication as Informational.
NewReno draft is in WG last call period. No major comments on this document to date. The plan is to submit it for Experimental at the same time that 2001.bis goes for Proposed.
2001.bis is under going several minor changes in response to comments during the WG last call period.
The re-start document is under heavy revision.
Peter Ford led a short discussion on raising the initial window size in 2001.bis (to be a proposed standard, as compared to RFC 2414 which is an experimental RFC that raises the initial congestion window) from 1 segment to "up to 2 segments". The basic argument in favor was that when developing RFC 2414, the only aspects of it that the WG had found merited further experimentation were the larger windows of 3 or 4 segments; support for 2 segments had been strong. In the subsequent discussion at the meeting, several people commented that they thought this was a good idea, nobody disagreed with the change, and the sense of the room was one of enthused support. The issue will also be discussed on the mailing list.
Jamshid Mahdavi presented a short report on the usefulness of the WG documents for debugging TCP stacks. In addition, he outlined two new problems: slow start being too aggressive and RTO that were not long enough. He also suggested that the known problems document would benefit from identifying problems as either "sender" or "receiver" bugs. These were judged as probably appropriate for an update of the known problems document, as the current version is now already with the AD.
Joe Touch outlined a new algorithm for preventing TCP from sending large bursts into the network. The algorithm needs to be documented in an internet-draft before the group considers it further.
Finally, Kevin Lahey led a short discussion on Path MTU Discovery issues. Kevin outlined several issues with path MTU discovery:
- BUGS
- using PMTU to determine MSS
- determining MTU on per-conn basis
- ACK frequency
- every 2 packets
- dynamic determination of segment size
- multihoming
- black-hole detection
Kevin outlined that an implementation can be within the specification, but still not optimal. First, some implementations reuse PMTU to determine MSS. For example, if you reopen a connection to the same place and reuse the MTU, you won't probe for higher MTU sizes. Second, some implementations rediscover the PMTU for each connection, which can induce high amounts of ICMP traffic and be inefficient, esp. for systems with high numbers of short connections (e.g. HTTP 1.0).
Kevin then outlined problems that arise when determining when to send a delayed ACK and how path MTU discovery complicates the situation. Consider two FDDI hosts, where the rings are interconnected by an ethernet. The MSS is 4KB, and the receiver ACKs after 2 MSS's. PMTU squeezes the packets down to 1.5 KB, and therefore, the ACK really ACKs 6 packets, not 2. Some systems solve this by ACKing every other packet, rather than for 2 MSS's. Others determine the ACK frequency using per-connection information.
The problems caused by multihomed hosts were then outlined. Consider a host with multiple interfaces with different MTUs. That host should advertise the largest MTU available, so that if the path to that host changes, connections can take advantage of the largest PMTU available.
Finally, Kevin outlined problems caused by black holes. RFC 1435 first mentions it - some routers suppress the "FRAGMENTATION NEEDED" ICMP reply, e.g., misconfigured routers or firewalls. The result looks like a black-hole - full-size packets just get lost, but pings and other small packets work fine. In this case, PMTU just freezes. There is no description of how to handle this - there is one implementation of a check timer at the upper layer protocol, but no generalized description of how to solve the problem. We need a spec to do this.
A discussion ensued about whether the WG should generate a document on this topic. Also, the floor was opened for other PMTU problems/issues. The chairs indicated that they would like to see a document on some of these subtle problems. However, the document needed to be expedited. Also, it was noted that this topic is slightly out of our charter and therefore, the AD's approval would be needed before officially working on this topic. It was also noted that IPv6 requires PMTU discovery and the ipng WG is having some related discussions, but has not yet solved the problem.
The consensus of the room was that a document on "experience with PMTU" would be useful & appropriate, with the chairs specifying that they would require a draft by January since the WG has wound down.
The meeting was adjourned noting that we do not plan to hold any further face-to-face meetings, but that the mailing list will remain active.
None received.