home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / tcpsat / tcpsat-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  7KB  |  206 lines
  1. TCPSAT Minutes, August 11, 1997, Munich, Germany
  2. Reported by Dan Glover, Daniel.Glover@lerc.nasa.gov
  3.  
  4. Aaron Falk (Aaron.Falk@trw.com) presented the agenda and
  5. discussed the
  6. working group charter, accomplishments, and status and
  7. plans.  The agenda
  8. was presented as follows:
  9.  
  10. Agenda Bashing                   5 min
  11. Administrivia & WG overview     10 min
  12. Summary of I-D Topics           80 min
  13.  -Applicable Environments
  14.  -Issues & Potential Mitigations Related to TCP
  15.  -Infrastructure & Application Issues and Mitigations
  16. Floor Discussion                        25 min
  17.  
  18. The agenda emerged unscathed from bashing.  Aaron stated
  19. that the goal of
  20. the working group is to produce an informational RFC where
  21. TCP performance
  22. over satellite links and satellite link characteristics are
  23. discussed.  The
  24. document will recommend best practices and catalog research
  25. issues.
  26. Accomplishments to date include:  BOF held in Memphis,
  27. working group status
  28. acheived, and a detailed outline for the ID posted on the
  29. list on 8/4/97.
  30. Status and Plans:  the working group missed the deadline for
  31. a draft ID
  32. this meeting, will try again for the Washington, DC meeting.
  33.  
  34. Aaron discussed satellite characteristics and some basic
  35. satellite issues.
  36.  
  37. Mark Allman (mallman@lerc.nasa.gov) presented a detailed
  38. outline for the
  39. draft ID beginning on chart #5.  The charts were prepared by
  40. Eric Travis
  41. (e.j.travis@ieee.org) who was not present.  The charts
  42. identified standards
  43. track (denoted by [ST]), research [R], and best common
  44. practice [BCP] issues.
  45.  
  46. Around slide # 13, Van Jacobson said that the 4K initial
  47. window was a great
  48. idea.  He also said that counting bytes rather than ACKs was
  49. a bad idea and
  50. would produce bursts.  There is a need to spread timing at
  51. the sender.
  52. Ssthresh tells you the buffer limit in the bottleneck.  Need
  53. the right
  54. solution to an intermediate small buffer.
  55.  
  56. Sally Floyd said that these issues are correctly labeled as
  57. research [R]
  58. and are not recommended at this meeting.  Van Jacobson said
  59. that byte
  60. counting without rate limiting won=92t help, if rate limit
  61. then don=92t have to
  62. do anything else.  Sally said its worth leaving on the
  63. list.  Van replied
  64. that it is a third order effect.
  65.  
  66. Van Jacobson discussed results from 1986 or 87 from SATNET
  67. that are written
  68. down in some unspecified seminar notes.  He suggested that
  69. an ACK spacing
  70. box at a downlink ground station could be used to clock the
  71. sender to avoid
  72. bursts.  Tim Shepard pointed out that if a sender already
  73. has packet
  74. spacing it should turn it off if there is an intermediate
  75. ACK spacer box in
  76. the link.  Van replied that his box would only space ACKs
  77. when it saw bursts.
  78.  
  79. Fred Baker said that it has been a long time since routers
  80. only had 4K
  81. buffers, the median transfer is 10-20 packets, never gets
  82. out of slow
  83. start, all bursty.  Van replied with two things:  1) Web
  84. transfers, slow
  85. start should never have been slow starting at the level it
  86. is now,
  87. threshold [initial window] really needs to be increased; 2)
  88. High
  89. delay*bandwidth need to space out packets.  The answer is
  90. not 100MB
  91. buffers.  Assuming large windows and SACK, what do we have
  92. to do to the
  93. routers?  Can=92t put big buffers everywhere, tend to just
  94. fill up.  [Spacing
  95. out segments decreases the amount of data the routers must
  96. hold, while not
  97. impacting the amount of data the network can hold (for
  98. example in satellite
  99. networks most of the packets should be propagating, not
  100. sitting in router
  101. buffers)]
  102.  
  103. Mark Allman continued with the presentation of the outline.
  104. At chart #27,
  105. Van Jacobson claimed that the last two items on the chart
  106. were looking in
  107. the wrong place.  He emphasized the need for Forward Error
  108. Correction (FEC)
  109. and stated that the first thing should be to make the link
  110. error-free.
  111. Aaron Falk replied that there are certain cases where you
  112. can=92t get a
  113. perfect link even with FEC.  Van reiterated that you should
  114. engineer things
  115. so that all loss is congestive, the last two items shouldn=92t
  116. be on the
  117. list.  Craig Partidge said that many satellite people say
  118. "we agree" with
  119. the goal of error-free links, a few do not.  Tim Shepard
  120. pointed out that
  121. one of the few who do not foresee error-free links is the
  122. military who will
  123. have to contend with active jamming attempts.
  124.  
  125. Aaron Falk announced that Mark Allman will be working as
  126. co-editor on the
  127. draft.  Aaron proposed an interim meeting in October in LA
  128. with a date to
  129. be decided on the list.  Craig Partridge pointed out October
  130. conflicts such
  131. as Interop.  Craig also pointed out that it may take a
  132. little longer than
  133. December to get the draft finished.  Craig announced that
  134. there is an ID on
  135. ACK spacing out:  draft-partridge-e2e-ackspacing-00.txt
  136. ["ACK Spacing for
  137. High Delay-Bandwidth Paths with Insufficient Buffering"].
  138. Fred Baker asked
  139. for a summary which Craig provided.  Van Jacobson said don=92t
  140. look inside
  141. the ACKs, just space them.  The question is how much to
  142. space them apart.
  143. Craig said that every ACK triggers two packets, large
  144. flurries of ACKs
  145. stack up in the buffer, causing surging in the forward
  146. direction.  Fred
  147. said that if you take the second ACK and delay it one packet
  148. you=92re cutting
  149. the rate in half.  Van replied that that is only true if the
  150. window is not
  151. increasing.
  152.  
  153. Aaron Falk opened the floor for comments.  Van Jacobson
  154. pointed out that
  155. you don=92t want to do something that requires changes to all
  156. TCP
  157. implementations.  One solution is one ACK spacing box per
  158. downlink.  When
  159. it sees well interleaved traffic, it doesn=92t need to do
  160. spacing.  Tim
  161. Shepard pointed out that the queue being overrun is at the
  162. bottleneck,
  163. memory at the bottleneck would help, and asked how does the
  164. box know the
  165. bottleneck rate.  Van replied that that information is in
  166. the ACK spacing
  167. unless the ACKs have been compressed by the queue.  The
  168. signature is a
  169. bunch of ACKs close together followed by a big gap.
  170. Research is needed on
  171. when the algorithm turns on and off.  Van claimed the
  172. kick-in point can be
  173. fairly high.
  174.  
  175. Peter Warren (working asymmetric links at GTE) said that ACK
  176. spacing looks
  177. good, but asked if a set of 20 in-line images in HTTP 1.0
  178. would look like a
  179. burst to the algorithm.  Van Jacobson replied that no, these
  180. would all be
  181. separate connections, but would have to sort out dynamics
  182. like 1.1 where
  183. you send some data then wait a bit and send some more.  Van
  184. claimed that
  185. routers can easily buffer 32K windows, during that time can
  186. find the
  187. pattern, doesn=92t have to trigger too early.
  188.  
  189. Van Jacobson stated that delayed ACKs wrongly implemented
  190. are a disaster.
  191. He said that the ACK spacing algorithm isn=92t going to
  192. trigger until fairly
  193. late in slow start, e.g., after seeing bursts on 15 or so
  194. ACKs, the window
  195. is open enough so delayed ACKs aren=92t affecting the number
  196. of ACKs in flight.
  197.  
  198. Peter Warren claimed that the asymmetry of HTTP data is on
  199. the order of
  200. 6:1.  He said this is a potentially serious bottleneck on
  201. the upstream
  202. link, would like to hear form others working on asymmetric
  203. links.  The
  204. meeting was then adjourned.
  205.  
  206.