CURRENT_MEETING_REPORT_ Reported by David Borman/Cray Research Minutes of the TCP Large Windows Working Group (TCPLW) The TCP Large Windows Working Group met on Wednesday, July 14 at the 27th IETF meeting in Amsterdam. The agenda was: o Review of draft-ietf-tcplw-extensions-00.txt o Consideration of advancing RFC 1323 to Draft Standard o Status of SACK option The document draft-ietf-tcplw-extensions-00.txt is a compilation of bugs and clarification that need to be made to RFC 1323. It was compiled by Bob Braden. Bob and David Borman led a walk through of the document to help explain it and to find out if any other changes that are needed to RFC 1323 were missed. RTTM: Relationship to Karn's Algorithm One of the items that Karn's algorithm addresses is how to get valid RTT values in the presence of lost data. With current methods, the answer is that whenever data has to be retransmitted, no valid RTT estimate can be made in that window. The reason for this is that when the ACK is received, it cannot be determined whether that ACK came from the original packet or the retransmitted packet. With the use of the timestamps option, this ambiguity is removed, since the timestamp echoed in the ACK will always be from the data packet that caused the ACK of new data to be generated. The other part of Karn's Algorithm, that of doing exponential back-off on retransmissions, still needs to be done. RTTM: Which TS to Echo The discussion that took place during the session was a bit muddled. This summary provides a clearer explanation. This is the one real bug in RFC 1323. As stated currently, the TSval is only copied to TS.Recent when a packet is received that advances the left edge of the window. The change allows the TSval to be copied when the left edge of the window is advanced, or if the packet is before the left edge of the window and it has a newer timestamp. The scenario that this addresses is when a packet is sent, its ACK is 1 lost, and so the packet is then resent. The second packet will not advance the left edge of the window, but will cause a duplicate ACK to be generated. To the sender, this will be the first ACK that is received, so it will want to use the timestamp in that packet to update the RTT estimate. If the TSval is not copied from the resent packet, the the sender will get an inflated RTT estimate. By making this change, with the use of timestamps for doing RTT measurements, it can be guaranteed that in the worst case, at least one RTT measurement can be made per window. Without the timestamps option, in many TCP implementations one RTT estimate per window is the best case. Additionally, this change fixes a problem with a long-lived unidirectional connection. Since all the ACKs will have the same sequence number, they would never cause TS.Recent to be updated. With this change, the string of ACK-only packets will cause TS.Recent to be kept up-to-date, and allow PAWS to work properly. TCP Options and MSS The discussion of how the TCP MSS option interacts with the presence of TCP and/or IP options needed some clarification. Since many TCP implementations us the MSS option to indicate how large of a packet can be received without fragmentation, and the MSS does not include the TCP/IP headers, the question is: should it also be adjusted for the length of the options that will probably be in each packet? The answer is no, and when sending data the sender should always assume that the MSS received did not account for the TCP and IP options, so the MSS should be reduced by the length of the TCP and IP options when determining how much data can be sent. The following grid shows why: |MSS is adjusted |MSS is not adjusted _______________|to_include_options_|to_include_options_ Sender adjusts |Packets are too |Packets are the length for |short |correct length _options________|__________________|___________________ Sender doesn't |Packets are the |Packets are too adjust length |correct length |long for options | | The goal is to not send IP datagrams that have to be fragmented by IP. Packets sent with the constraints in the lower right of this grid will cause IP fragmentation. The only way to ensure that this doesn't happen is for the data sender to decrease the MSS by the length of the IP and 2 TCP options. Modification to TCP Event Processing Rules The draft document contains a new set of rules for how to process the TCP extensions. Bob wanted feedback on whether or not the format was easy to read and understand. The general feeling was that it was easy to read and understand. SACK There was some discussion of the status of the SACK option. Right now, there is not a lot of visible activity in this area. There are some test implementations of the SACK option as originally defined in RFC 1072. The plan is once there is some hard data on how well it works, then a new draft document will be generated on the SACK option. Action Items o Bob Braden will update RFC 1323 with the changes that are described in draft-ietf-tcplw-extensions-00.txt. The new document will be sent to the mailing list for final review, and then sent to the IESG for consideration for advancement to Draft Standard status. o Bob Braden will update draft-ietf-tcplw-extensions-00.txt to include an updated description of which TS to echo to explain the bug as described above, and then it will be published as an Informational RFC. o David Borman will send out the current list of implementations, so that people can send in updates. The updated list will be given to the IESG at the same time as the updated version of RFC 1323. Attendees David Borman dab@cray.com Jim Bound bound@zk3.dec.com Robert Braden braden@isi.edu Walid Dabbous Walid.Dabbous@sophia.inria.fr Jeffrey Dunn dunn@neptune.nrl.navy.mil Francis Dupont francis.dupont@inria.fr Robert Enger enger@reston.ans.net Joseph Godsil jgodsil@ncsa.uiuc.edu Frank Hoffmann hoffmann@dhdibm1.bitnet Phil Irey pirey@relay.nswc.navy.mil Ronald Jacoby rj@sgi.com 3 Paolo Malara malara@crs4.it Kent Malave kent@bach.austin.ibm.com Allison Mankin mankin@cmf.nrl.navy.mil Willi Porten porten@gmd.de Henry Sanders henrysa@microsoft.com Tim Seaver tas@concert.net Keith Sklower sklower@cs.berkeley.edu Robert Ullmann ariel@world.std.com Willem van der Scheun scheun@sara.nl Paul Zawada Zawada@ncsa.uiuc.edu 4