NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 17-Aug-98
Chair(s):
Vern Paxson <vern@ee.lbl.gov>
M. 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@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. |
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
· When TCP Starts Up With Four Packets Into Only Three Buffers
· Increasing TCP's Initial Window
· Simulation Studies of Increased Initial TCP Window Size
· TCP Implementation Problems That Need To Be Documented
Request For Comments:
RFC |
Status |
Title |
RFC2398 |
Some Testing Tools for TCP Implementors | |
TCPIMPL minutes
42nd IETF, Chicago
August 28, 1998
Reported by Evi Nemeth, with editing by the chairs & Sally Floyd.
Agenda:
1. Agenda bashing
2. Scott Bradner, intellectual property rights
3. Status
4. Known problems I-D
5. Security problems
6. RFC 2001 revision (congestion control)
7. WG closing after Orlando
1. Agenda bashing:
No changes to the agenda.
2. IPR (intellectual property rights) issues:
Scott Bradner reminded the group that if you know of intellectual
property issues in your company on a topic and don't say so, then
you cannot participate in the discussion and decisions regarding
that topic. This is outlined in RFC 2028.
3. Status
The testing tools document is done, RFC 2398. The larger initial window documents
have been approved by IESG, and the 3 drafts will soon become RFCs. Regarding the
restart of idle connections, see draft-ietf-tcpimpl-restart, which Joe Touch reports will
soon be revised for publication.
4. Known problems
7 new ones have been documented since the LA meeting. Bill Fenner described a new
bug: if during a bi-directional transfer you are sending and so is the other end, but
you're not reading the incoming data very fast, you can end up deadlocked with a full
buffer. For example, a multithreaded client-server where one thread is sending a lot,
another is receiving a lot, but using one tcp connection. The fix is to change an unsigned
to an int and recognize -1 as a valid value. Bill will explain it better and submit it.
There are 3 others which are less serious and also not yet addressed. The document will
be forwarded to the IESG without outlining these bugs.
5. Security problems
There is a list of known problems:
- Predictable initial sequence number
- SYN flooding
- Land attack
-
Phil Karn noted that the latter two are really denial of service attacks, and questioned the
title of the section.
6. RFC 2001 revision
High-level sketch of the revisions:
- removed ambiguities
- fixes for fast retransmit and fast recovery
- added discussion of SACK
- added larger initial window pointer
The discussion of the 2001 revision was a little chaotic at this point and went back and
forth between several topics. The comments about each topic have been grouped
together for the minutes, and therefore the comments are somewhat out-of-order.
Sally Floyd described two separate modifications to the Fast Retransmit and Fast
Recovery algorithms in RFC 2001. The first modification is the NewReno algorithm,
introduced in Janey Hoe's SIGCOMM 96 paper, which improves TCP's response to a
"partial ack" received during Fast Recovery, acknowledging some but not all of the
packets sent before Fast Recovery was initiated. The preferred TCP algorithms would
be those of Sack TCP. However, when the SACK option is not available, the NewReno
algorithm was described as a small but important change to make to Reno TCP, avoiding
Reno TCP's well-documented problems with retransmit timeouts when multiple packets
are dropped from a window of data.
The second modification described was the bugfix algorithm for avoiding unnecessary
multiple fast retransmits. This problem occurs in Reno when, after a retransmit timeout,
packets are retransmitted that have already been received at the receiver. When the
TCP sender receives three duplicate ACKs acknowledging three retransmitted packets,
the sender can incorrectly interpret this as a new instance of congestion. Simulations
showed that the NewReno algorighm and the bugfix for avoiding-multiple-fast-
retransmits are orthogonal - it is possible to implement one and not the other. However,
while it is possible to create scenarios with Reno or NewReno TCP where the bugfix for
avoiding-multiple-fast-retransmits would be helpful, it is not possible to create the
pathological scenarios that can occur with Tahoe TCP (e.g., TCP with Fast Retransmit
but without Fast Recovery).
Sally's slides can be found at: "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" (postscript),
and "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf" (PDF).
The chairs think that NewReno is a good thing; folks should implement it (solaris 2.6
might already) and put out an experimental RFC or include it (all or part) in 2001.
The decision was made to take this discussion to the mailing list and do an experimental
RFC with NewReno, rather than include it in the bugs list in RFC 2001.
There was then discussion of whether to include Sally's Reno modification for avoiding-
multiple-fast-retransmits in the RFC 2001 revision - how much experience with it do
we need to include it?
Vern suggested that an experimental document with Sally's modification could come
out at the same time, and be referenced by 2001.
Kacheong Poon (Sun) confirmed that some implementations of NewReno can behave
like stop and go during retransmission (like in Janey Hoe's paper). This occurs when
multiple packets are dropped from a window of data, and NewReno TCP recovers by
retransmitting at most one dropped packet per roundtrip time.
Sally said it is possible to implement NewReno with "stop and go" behavior, but that in
an alternate implementation, included as an option in the NS simulator, the retransmit
timer is reset on only the first retransmission. In this case, instead of slowly recovering
by retransmitting at most one dropped packet per roundtrip time, eventually the
retransmit timer times out and the sender slow-starts. The first-order fix for problems
with multiple packets dropped from a window of data is to use Sack, but when Sack is
not available, NewReno with this implementation should not perform worse than Reno.
Sally and Kacheong Poon agreed to confer on different possible implementations of NewReno.
Phil Karn asked if we want to make TCP more aggressive in the face of multiple packets
dropped. Sally answered: multiple packets dropped in a window of data is one instance
of congestion. So cut the window in half, do one retransmit; if retransmitted packets get
lost, then it's more serious and do slow start.
The RFC 2001 discussion continued with a discussion of ACKing every second full
sized segment being a MUST and not a SHOULD. A wording tweak is needed: that
ACKing is *at least* every second full-sized packet, since some systems ACK every
segment, and that's allowed.
Another issue arose concerning ACK every 2nd full sized segment -- there's no way for
the receiver to really know if the segments arriving are full-sized. Resolution: loosen
the language but word it so that today's TCPs are ok.
A question regarding definition of 3 duplicate ACKs - must they be consecutive?
Answer: yes, they need to be consecutive, but it's rare that they're not, so should not
cause an implementation to be labeled non-conformant.
7. WG closing after Orlando
2001 is almost done if NewReno is not included. The plan is to close the working group
after the next meeting (in Orlando). However, in discussion after adjournment, the issue
was raised of documenting PMTU discovery issues, which may merit keeping the WG
active for one more meeting.
None received.