Editor's note: These minutes have not been edited.
From: Steve Alexander <
[email protected]>
The TCP Implementation BOF was held at 3:30 PM, on Wednesday, December 11th.
The BOF was intended to determine whether or not consensus exists for forming
a working group for the purpose of making implementors aware of problems in
current TCP implementations.
The BOF was co-chaired by Steve Alexander (
[email protected]) from Silicon Graphics
and Vern Paxson (
[email protected]) of Lawrence Berkeley Labs.
Steve started off by presenting the BOF Agenda and then gave a motivation for
having the BOF. The idea (originally suggested by Jamshid Mahdavi and Matt
Mathis) is to help TCP implementors improve the quality of their products by
making them aware of problems in existing implementations and any tools or test
suites that might make the development process more productive.
Vern Paxson then gave a presentation on the results of several research studies,
which included work by Brakmo and Peterson; Comer and Lin; Stevens; Dawson,
Jahanian, and Milton; and Paxson.
The above studies showed that many TCP implementations exhibit bad behavior
at times, and that some of these problems can lead to a great deal of data
being needlessly retransmitted. Among the other problems mentioned were:
- Some TCP implementations send data after having reset the connection
- Some do not acknowledge zero-window probes
- Some throw away all data after a hole in the sequence space
- Wide variety of MSS values (some very bizarre)
- Many problems with keepalives
- Congestion avoidance algorithms such as slow-start are not ubiquitous
Vern wrapped up with an overview of two tools, ORCHESTRA, and tcpanaly.
ORCHESTRA (
http://www.eecs.umich.edu/~sdawson) is an x-kernel based tool that
allows instrumentation of networking code. It allows a developer to trace
packets and generate probe packets.
tcpanaly is a tool that Vern has developed for post-processing of tcpdump
traces. It can detect anomalies in a TCP connection, particularly WRT
congestion avoidance.
Steve Parker from SunSoft then gave a brief presentation on the Packet Shell,
which is a tool that he and Chris Schmechel have been developing. The packet
shell is a set of TCL extensions that allows packet-level tests to be developed
easily using the TCL scripting language. Steve presented several examples of
how this could be used to verify that a TCP is behaving correctly. The packet
shell is available at
ftp://playground.sun.com/pub/sparker.
After the presentations concluded, discussion turned to the proposed charter
and milestones for the working group, which were:
- Produce a compilation of known problems and their solutions. This will
raise awareness of these issues.
- (optional) 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:
Dec 96 Working group formation
Mar 97 Produce initial document describing problems and fixes
May 97 Produce I-D which clarifies 793, 1122, 1323, if necessary
May 97 Produce initial catalog of test suites, etc.
A large percentage of the discussion centered around publically naming vendors
with sub-optimal implementations. It was emphasized several times that the
group is targeted at developers, not at users or administrators. In that
context, it is not clear that mentioning implementors by name serves the
group's purpose. Allyn Romanow mentioned that the IESG is still determining
whether doing so has any legal ramifications. It was not clear that consensus
was reached on this issue.
Another potentially controversial issue has to do with handling security
issues. Steve Bellovin argued in favor of being as open as possible about such
matters.
Although the goal of updating the TCP specifications is potentially an
unbounded problem, several people felt that it will be necessary. In
particular, Dave Borman presented a list of several items that he felt needed
clarification. Although there were few other specific issues mentioned, there
seemed to be a growing belief that some enhancements to existing specifications
will be needed.
It was generally felt that the scope of the group will need to be carefully
defined in order to make forward progress. For example, drawing the line
between what is "research" and what is "production code" will be an issue.
Discussion with the IRTF might be useful in evaluating this issue.
There was some discussion on test suites and test tools, although it did not
appear that any conclusions were drawn. At the present time, it is not clear
that everyone agrees on what a test suite should do, or whether a test suite
could be a product of an IETF group.
Bob Braden suggested that the proposed dates were wildly optimistic. There
was general agreement on this point.
Several other specific issues were raised:
There was a brief mention of SACK, and whether or not it is implemented widely
enough to be addressed? (no consensus yet).
The question of issues surrounding asymmetric paths was raised as well.
Fred Baker raised the issue of performance over satellites as something that
mighe be appropriate (there was no clear consensus on this being appropriate
yet).
One concern was that a working group could become a perpetually ongoing effort.
Some felt that this group could never really finish as long as TCP
implementations keep evolving. The consensus seemed to be that this might be
true but that a first effort has to be successful prior to continuing on. If
the group cannot be productive initially, then the question is moot.
Some questions were raised about environmental assumptions present in the
specifications, namely are there some, and if so are they clear? It seems
that further discussion is needed on this topic.
It was suggested that another potential deliverable is a guide to
tuning/defaults for administrators. Again, this needs further discussion, and
may require working with the User Services area.
There seemed to be general agreement that a working group should be formed, but
many details remain to be worked out about the charter and deliverables.
Steve Alexander
------- =_aaaaaaaaaa0--
