Editor's note: These minutes have not been edited. From: Steve Alexander 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 (sca@sgi.com) from Silicon Graphics and Vern Paxson (vern@ee.lbl.gov) 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--