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.