TCPSAT Minutes, August 11, 1997, Munich, Germany
Reported by Dan Glover, [email protected]
Aaron Falk ([email protected]) 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 ([email protected]) presented a detailed outline for the
draft ID beginning on chart #5. The charts were prepared by Eric Travis
([email protected]) 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�t help, if rate limit then don�t 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�t 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�t 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�t 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�t 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�re 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�t 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�t 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�t have to trigger too early.
Van Jacobson stated that delayed ACKs wrongly implemented are a disaster.
He said that the ACK spacing algorithm isn�t 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�t 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.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:30 EST