Loading ...
Sorry, an error occurred while loading the content.
 

San Jose TCP Implementation BOF Minutes

Expand Messages
  • Steve Alexander
    [ My apologies for being tardy with these ] The TCP Implementation BOF was held at 3:30 PM, on Wednesday, December 11th. The BOF was intended to determine
    Message 1 of 107 , Jan 9, 1997
      [ My apologies for being tardy with these ]

      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@...) from Silicon Graphics
      and Vern Paxson (vern@...) 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
    • Steve Alexander
      ... I think the issue probably has more to do with interpreting what the urgent pointer means. If I remember correctly, 793 was ambiguous (it said two
      Message 107 of 107 , Feb 19, 1997
        der Mouse <mouse@...> writes:
        >I don't think there _is_ any "correctly". TCP does not have OOB. What
        >it has is an urgent pointer. Some grad student who must have been
        >either on drugs or on a minimal understanding of TCP thought it would
        >be useful to take the byte the urgent pointer points to and treat it as
        >a byte in an out-of-band channel.

        I think the issue probably has more to do with interpreting what the urgent
        pointer means. If I remember correctly, 793 was ambiguous (it said two
        different things in two different places) and BSD picked the "wrong" one
        (having just re-read it, I probably would have too). If you follow 1122, then
        you disagree with BSD by one byte, which is a real pain. I don't know why the
        authors of 1122 didn't just admit defeat and codify the BSD practice ;->.

        -- Steve
      Your message has been successfully submitted and would be delivered to recipients shortly.