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

draft minutes for Chicago meeting

Expand Messages
  • Vern Paxson
    Sorry these are so late ... Please send us comments over the next few days and then we ll finalize them. Vern TCPIMPL minutes 42nd IETF, Chicago August 28,
    Message 1 of 1 , Oct 8, 1998
    • 0 Attachment
      Sorry these are so late ... Please send us comments over the next
      few days and then we'll finalize them.


      TCPIMPL minutes
      42nd IETF, Chicago
      August 28, 1998

      Reported by Evi Nemeth, with editing by the chairs & Sally Floyd.

      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

      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.

      <There was a comment here about satellite environments which the
      note-taker didn't get recorded - anyone recall it?>

      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.