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
Chair(s):
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.
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
· Simulation Studies of Increased Initial TCP Window Size
· TCP Implementation Problems That Need To Be Documented
No Request For Comments
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:
· Tools could be used to create rogue packets and/or denial of service attacks
· Some tools require root access to run
· Some tools require bringing foreign code into kernel
· None of the tools evaluate security
· In order to run some tools, you may compromise the security of your system by running untrustworthy code
· Some tools require watching traffic, which can raise privacy and security concerns
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:
· Initial RTO too low
· CWND uninitialized
· Failure of window deflation due to header prediction
· Retransmission sends 2 packets
· First-hop PMTU Discovery
· MTU Black Holes
· RTO fails to back off
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:
· Failure to set PSH when send buffer drains
· Failure of window deflation due to fencepost error
· Failure to ACK above-sequence data
· Incorrectly setting ssthresh after a retransmission is lost
· Incrementing cwnd too aggressively during congestion avoidance
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:
· Predictable initial sequence number
· Ameliorating SYN flooding
· The Land attack
· Forged RSTs
· Forged ICMP unreachables
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:
1. Current Method, Jacobson & Karels - Send or receive timer with full restart.
2. Congestion Window Monitoring, Hughes, Touch and Heidemann - Packet counting with window limiting
3. Maxburst Limitation, Floyd - Packet counting with burst limiting
4. Rate Based Pacing, Visweswaraiah and Heidemann - Send timer or packet counting with pacing
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:
· Raj Jain noted that bursts may be preferable to clamping the congestion window with CWM in long-delay networks.
· Mark Allman noted that while losing cwnd on long-delay networks hurts performance, loss also hurts performance so it may be preferable to limit bursts in an attempt to limit loss.
· Vern asked if people thought that implementing timers in TCP was still considered a ``big deal''. It was noted that comparing timestamps is not a big deal, but if a new code path and additional resources are needed a new timer may be objectionable. Bill Simpson noted that timers are fine unless they expire (for instance the delayed ACK timer is OK, but a pacing timer is not). Bill argued that we should be focusing on making TCP work well in ``common'' environments and not tweaking TCP so that a single satellite connection runs well in satellite networks. Vern noted that the number one goal for TCP is stability not performance.
· Sally Floyd noted that maxburst limitation and CWM are very different mechanisms (one closes cwnd and the other does not). She noted that the studying the impact of these mechanisms is still a research issue.
· Vern stated that it would be nice if there was a solution that worked well across all environments.
· Tim Shepard noted that a single TCP can congest a network and therefore congestion control mechanisms are important to even a single TCP connection across a satellite network.
· Sally clarified maxburst as sending K segments in response to a single ACK.
· Matt Mathis noted another cause of bursting is the scheduler on high speed workstations.
· Tim Shepard asked what we were trying to decide. Vern responded that we are trying to decide the proper behavior of TCP connections after an idle period for the revision of RFC 2001.
· Tim stated that he likes CWM as it is more conservative than maxburst. But, he thinks it is still research issue.
· Spencer Dawkins noted that wireless links look worse than normal links and that a burst limiting mechanism is important to those environments.
· Scott Lawrence wondered if applications will attempt to not let TCP connections go idle.
· Sally noted that maxburst was not designed for use after an idle timeout, but may be appropriate for that use. She noted that research is needed in decaying the size of cwnd over the idle period.
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:
· A question about whether this mechanism has been studied in low bandwidth links was raised. Tim gave a brief overview of his dialup link simulations (a formal presentation was given at the 40th IETF meeting). Bill Simpson stated that he didn't believe the simulations or think the proposal is a good idea. He was particularly concerned with small Web transactions that would not suffer loss using an initial window of 1 but would with an initial window of 4.
· Matt suggested that TCP constants (like the initial window size) appear in the assigned numbers document. Vern argued that making these constants undergo a full review, as the current proposal has, makes changing the numbers harder and therefore less likely to be done in haste.
· A suggestion was given that if you know you are connected to a gateway with only a few buffers the host should simply advertise a small window. Bill stated that he thought this was a bad idea because of the problem of deploying such a tweak among a large installed base.
· It was noted that using compressed HTML a larger initial window may not be needed (or used).
Vern called for a show of hands and it was determined that rough consensus exists for larger initial windows per the proposal.
None Received