home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / tcplw / tcplw-minutes-93jul.txt < prev    next >
Text File  |  1993-09-14  |  7KB  |  189 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by David Borman/Cray Research
  5.  
  6. Minutes of the TCP Large Windows Working Group (TCPLW)
  7.  
  8. The TCP Large Windows Working Group met on Wednesday, July 14 at the
  9. 27th IETF meeting in Amsterdam.  The agenda was:
  10.  
  11.  
  12.    o Review of draft-ietf-tcplw-extensions-00.txt
  13.    o Consideration of advancing RFC 1323 to Draft Standard
  14.    o Status of SACK option
  15.  
  16.  
  17. The document draft-ietf-tcplw-extensions-00.txt is a compilation of bugs
  18. and clarification that need to be made to RFC 1323.  It was compiled by
  19. Bob Braden.  Bob and David Borman led a walk through of the document to
  20. help explain it and to find out if any other changes that are needed to
  21. RFC 1323 were missed.
  22.  
  23.  
  24. RTTM: Relationship to Karn's Algorithm
  25.  
  26. One of the items that Karn's algorithm addresses is how to get valid RTT
  27. values in the presence of lost data.  With current methods, the answer
  28. is that whenever data has to be retransmitted, no valid RTT estimate can
  29. be made in that window.  The reason for this is that when the ACK is
  30. received, it cannot be determined whether that ACK came from the
  31. original packet or the retransmitted packet.
  32.  
  33. With the use of the timestamps option, this ambiguity is removed, since
  34. the timestamp echoed in the ACK will always be from the data packet that
  35. caused the ACK of new data to be generated.
  36.  
  37. The other part of Karn's Algorithm, that of doing exponential back-off
  38. on retransmissions, still needs to be done.
  39.  
  40.  
  41. RTTM: Which TS to Echo
  42.  
  43. The discussion that took place during the session was a bit muddled.
  44. This summary provides a clearer explanation.
  45.  
  46. This is the one real bug in RFC 1323.  As stated currently, the TSval is
  47. only copied to TS.Recent when a packet is received that advances the
  48. left edge of the window.  The change allows the TSval to be copied when
  49. the left edge of the window is advanced, or if the packet is before the
  50. left edge of the window and it has a newer timestamp.
  51.  
  52. The scenario that this addresses is when a packet is sent, its ACK is
  53.  
  54.                                    1
  55.  
  56.  
  57.  
  58.  
  59.  
  60. lost, and so the packet is then resent.  The second packet will not
  61. advance the left edge of the window, but will cause a duplicate ACK to
  62. be generated.  To the sender, this will be the first ACK that is
  63. received, so it will want to use the timestamp in that packet to update
  64. the RTT estimate.  If the TSval is not copied from the resent packet,
  65. the the sender will get an inflated RTT estimate.
  66.  
  67. By making this change, with the use of timestamps for doing RTT
  68. measurements, it can be guaranteed that in the worst case, at least one
  69. RTT measurement can be made per window.  Without the timestamps option,
  70. in many TCP implementations one RTT estimate per window is the best
  71. case.
  72.  
  73. Additionally, this change fixes a problem with a long-lived
  74. unidirectional connection.  Since all the ACKs will have the same
  75. sequence number, they would never cause TS.Recent to be updated.  With
  76. this change, the string of ACK-only packets will cause TS.Recent to be
  77. kept up-to-date, and allow PAWS to work properly.
  78.  
  79.  
  80. TCP Options and MSS
  81.  
  82. The discussion of how the TCP MSS option interacts with the presence of
  83. TCP and/or IP options needed some clarification.  Since many TCP
  84. implementations us the MSS option to indicate how large of a packet can
  85. be received without fragmentation, and the MSS does not include the
  86. TCP/IP headers, the question is:  should it also be adjusted for the
  87. length of the options that will probably be in each packet?
  88.  
  89. The answer is no, and when sending data the sender should always assume
  90. that the MSS received did not account for the TCP and IP options, so the
  91. MSS should be reduced by the length of the TCP and IP options when
  92. determining how much data can be sent.  The following grid shows why:
  93.  
  94.  
  95.  
  96.                        |MSS is adjusted    |MSS is not adjusted
  97.         _______________|to_include_options_|to_include_options_
  98.          Sender adjusts |Packets are too    |Packets are the
  99.          length for     |short              |correct length
  100.         _options________|__________________|___________________
  101.          Sender doesn't |Packets are the    |Packets are too
  102.          adjust length  |correct length     |long
  103.          for options    |                  |
  104.  
  105.  
  106.  
  107. The goal is to not send IP datagrams that have to be fragmented by IP.
  108. Packets sent with the constraints in the lower right of this grid will
  109. cause IP fragmentation.  The only way to ensure that this doesn't happen
  110. is for the data sender to decrease the MSS by the length of the IP and
  111.  
  112.                                    2
  113.  
  114.  
  115.  
  116.  
  117.  
  118. TCP options.
  119.  
  120.  
  121. Modification to TCP Event Processing Rules
  122.  
  123. The draft document contains a new set of rules for how to process the
  124. TCP extensions.  Bob wanted feedback on whether or not the format was
  125. easy to read and understand.  The general feeling was that it was easy
  126. to read and understand.
  127.  
  128.  
  129. SACK
  130.  
  131. There was some discussion of the status of the SACK option.  Right now,
  132. there is not a lot of visible activity in this area.  There are some
  133. test implementations of the SACK option as originally defined in
  134. RFC 1072.  The plan is once there is some hard data on how well it
  135. works, then a new draft document will be generated on the SACK option.
  136.  
  137.  
  138. Action Items
  139.  
  140.    o Bob Braden will update RFC 1323 with the changes that are described
  141.      in draft-ietf-tcplw-extensions-00.txt.  The new document will be
  142.      sent to the mailing list for final review, and then sent to the
  143.      IESG for consideration for advancement to Draft Standard status.
  144.  
  145.    o Bob Braden will update draft-ietf-tcplw-extensions-00.txt to
  146.      include an updated description of which TS to echo to explain the
  147.      bug as described above, and then it will be published as an
  148.      Informational RFC.
  149.  
  150.    o David Borman will send out the current list of implementations, so
  151.      that people can send in updates.  The updated list will be given to
  152.      the IESG at the same time as the updated version of RFC 1323.
  153.  
  154.  
  155. Attendees
  156.  
  157. David Borman             dab@cray.com
  158. Jim Bound                bound@zk3.dec.com
  159. Robert Braden            braden@isi.edu
  160. Walid Dabbous            Walid.Dabbous@sophia.inria.fr
  161. Jeffrey Dunn             dunn@neptune.nrl.navy.mil
  162. Francis Dupont           francis.dupont@inria.fr
  163. Robert Enger             enger@reston.ans.net
  164. Joseph Godsil            jgodsil@ncsa.uiuc.edu
  165. Frank Hoffmann           hoffmann@dhdibm1.bitnet
  166. Phil Irey                pirey@relay.nswc.navy.mil
  167. Ronald Jacoby            rj@sgi.com
  168.  
  169.                                    3
  170.  
  171.  
  172.  
  173.  
  174.  
  175. Paolo Malara             malara@crs4.it
  176. Kent Malave              kent@bach.austin.ibm.com
  177. Allison Mankin           mankin@cmf.nrl.navy.mil
  178. Willi Porten             porten@gmd.de
  179. Henry Sanders            henrysa@microsoft.com
  180. Tim Seaver               tas@concert.net
  181. Keith Sklower            sklower@cs.berkeley.edu
  182. Robert Ullmann           ariel@world.std.com
  183. Willem van der Scheun    scheun@sara.nl
  184. Paul Zawada              Zawada@ncsa.uiuc.edu
  185.  
  186.  
  187.  
  188.                                    4
  189.