TCPSAT Minutes, August 11, 1997, Munich, Germany Reported by Dan Glover, Daniel.Glover@lerc.nasa.gov Aaron Falk (Aaron.Falk@trw.com) presented the agenda and discussed the working group charter, accomplishments, and status and plans. The agenda was presented as follows: Agenda Bashing 5 min Administrivia & WG overview 10 min Summary of I-D Topics 80 min -Applicable Environments -Issues & Potential Mitigations Related to TCP -Infrastructure & Application Issues and Mitigations Floor Discussion 25 min The agenda emerged unscathed from bashing. Aaron stated that the goal of the working group is to produce an informational RFC where TCP performance over satellite links and satellite link characteristics are discussed. The document will recommend best practices and catalog research issues. Accomplishments to date include: BOF held in Memphis, working group status acheived, and a detailed outline for the ID posted on the list on 8/4/97. Status and Plans: the working group missed the deadline for a draft ID this meeting, will try again for the Washington, DC meeting. Aaron discussed satellite characteristics and some basic satellite issues. Mark Allman (mallman@lerc.nasa.gov) presented a detailed outline for the draft ID beginning on chart #5. The charts were prepared by Eric Travis (e.j.travis@ieee.org) who was not present. The charts identified standards track (denoted by [ST]), research [R], and best common practice [BCP] issues. Around slide # 13, Van Jacobson said that the 4K initial window was a great idea. He also said that counting bytes rather than ACKs was a bad idea and would produce bursts. There is a need to spread timing at the sender. Ssthresh tells you the buffer limit in the bottleneck. Need the right solution to an intermediate small buffer. Sally Floyd said that these issues are correctly labeled as research [R] and are not recommended at this meeting. Van Jacobson said that byte counting without rate limiting won=92t help, if rate limit then don=92t have to do anything else. Sally said its worth leaving on the list. Van replied that it is a third order effect. Van Jacobson discussed results from 1986 or 87 from SATNET that are written down in some unspecified seminar notes. He suggested that an ACK spacing box at a downlink ground station could be used to clock the sender to avoid bursts. Tim Shepard pointed out that if a sender already has packet spacing it should turn it off if there is an intermediate ACK spacer box in the link. Van replied that his box would only space ACKs when it saw bursts. Fred Baker said that it has been a long time since routers only had 4K buffers, the median transfer is 10-20 packets, never gets out of slow start, all bursty. Van replied with two things: 1) Web transfers, slow start should never have been slow starting at the level it is now, threshold [initial window] really needs to be increased; 2) High delay*bandwidth need to space out packets. The answer is not 100MB buffers. Assuming large windows and SACK, what do we have to do to the routers? Can=92t put big buffers everywhere, tend to just fill up. [Spacing out segments decreases the amount of data the routers must hold, while not impacting the amount of data the network can hold (for example in satellite networks most of the packets should be propagating, not sitting in router buffers)] Mark Allman continued with the presentation of the outline. At chart #27, Van Jacobson claimed that the last two items on the chart were looking in the wrong place. He emphasized the need for Forward Error Correction (FEC) and stated that the first thing should be to make the link error-free. Aaron Falk replied that there are certain cases where you can=92t get a perfect link even with FEC. Van reiterated that you should engineer things so that all loss is congestive, the last two items shouldn=92t be on the list. Craig Partidge said that many satellite people say "we agree" with the goal of error-free links, a few do not. Tim Shepard pointed out that one of the few who do not foresee error-free links is the military who will have to contend with active jamming attempts. Aaron Falk announced that Mark Allman will be working as co-editor on the draft. Aaron proposed an interim meeting in October in LA with a date to be decided on the list. Craig Partridge pointed out October conflicts such as Interop. Craig also pointed out that it may take a little longer than December to get the draft finished. Craig announced that there is an ID on ACK spacing out: draft-partridge-e2e-ackspacing-00.txt ["ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering"]. Fred Baker asked for a summary which Craig provided. Van Jacobson said don=92t look inside the ACKs, just space them. The question is how much to space them apart. Craig said that every ACK triggers two packets, large flurries of ACKs stack up in the buffer, causing surging in the forward direction. Fred said that if you take the second ACK and delay it one packet you=92re cutting the rate in half. Van replied that that is only true if the window is not increasing. Aaron Falk opened the floor for comments. Van Jacobson pointed out that you don=92t want to do something that requires changes to all TCP implementations. One solution is one ACK spacing box per downlink. When it sees well interleaved traffic, it doesn=92t need to do spacing. Tim Shepard pointed out that the queue being overrun is at the bottleneck, memory at the bottleneck would help, and asked how does the box know the bottleneck rate. Van replied that that information is in the ACK spacing unless the ACKs have been compressed by the queue. The signature is a bunch of ACKs close together followed by a big gap. Research is needed on when the algorithm turns on and off. Van claimed the kick-in point can be fairly high. Peter Warren (working asymmetric links at GTE) said that ACK spacing looks good, but asked if a set of 20 in-line images in HTTP 1.0 would look like a burst to the algorithm. Van Jacobson replied that no, these would all be separate connections, but would have to sort out dynamics like 1.1 where you send some data then wait a bit and send some more. Van claimed that routers can easily buffer 32K windows, during that time can find the pattern, doesn=92t have to trigger too early. Van Jacobson stated that delayed ACKs wrongly implemented are a disaster. He said that the ACK spacing algorithm isn=92t going to trigger until fairly late in slow start, e.g., after seeing bursts on 15 or so ACKs, the window is open enough so delayed ACKs aren=92t affecting the number of ACKs in flight. Peter Warren claimed that the asymmetry of HTTP data is on the order of 6:1. He said this is a potentially serious bottleneck on the upstream link, would like to hear form others working on asymmetric links. The meeting was then adjourned.