NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Aaron Falk <aaron.falk@trw.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>
Transport Area Advisor:
Allyn Romanow <allyn.romanow@eng.sun.com>
Mailing Lists:
General Discussion: tcp-over-satellite@listserv.trw.com
To Subscribe: majordomo@listserv.trw.com
In Body: subscribe tcp-over-satellite
Archive:
Description of Working Group:
Satellites are being used to extend the Global Internet geographically and will be more ubiquitous in the next decade with the deployment of several proposed services capable of providing greater than T1 access to individual users anywhere in the world.
Yet, satellite links have a unique combination of characteristics that can affect the throughput of TCP traffic. Because of the high-bandwidth delay product, slow start and congestion control algorithms behave much differently when the path includes a satellite link than exclusively terrestrial ones.
The TCP over Satellite Working Group shall produce an informational RFC that describes the issues affecting TCP throughput over satellite links. It identifies the domains in which each issue applies, including network topology, satellite orbit (LEO, MEO, GEO), and link rates; fixes, both protocol and implementation, that ameliorate reduced throughput; and areas for further research. The purpose of including this information is to direct the research community to the areas in which show promise, not to perform the research or even advocate the results.
Scope:
The scope of this working group will include consideration of the following for inclusion in the Informational RFC:
· Transport layer issues affecting TCP over satellite links o Existing TCP options
· Compliant implementations which have some known improved performance over satellite links
· Recommendation of well understood protocol changes
· Identification of protocol changes that are potentially promising but require more further investigation in order to be well understood
Security:
The working group will consider in depth security issues that are relevant, describing risks and indicating how they may be addressed.
Goals and Milestones:
Jul 97 |
|
Post first Internet-Draft. |
Aug 97 |
|
Meet at Munich IETF to review Internet-Draft. |
Dec 97 |
|
Meet at DC IETF to achieve consensus on final version of Internet-Draft. |
Jan 98 |
|
Submit Internet-Draft to IESG for consideration as an Informational RFC. |
Internet-Drafts:
· Enhancing TCP Over Satellite Channels using Standard Mechanisms
No Request For Comments
Minutes of the TCPSAT Working Group Meeting
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, status and plans. The agenda was presented as follows:
I. Agenda Bashing 5 min
II. Administrivia/WG Overview 10 min
III. Summary of I-D Topics 80 min
a) -Applicable Environments
b) -Issues & Potential Mitigations Related to TCP
c) -Infrastructure & Application Issues and Mitigations
IV. 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 achieved, 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. Eric Travis (e.j.travis@ieee.org), who was not present, prepared the charts. 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 might 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 that 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.
TCPSAT - Introduction and Status