Minutes of the TCP Over Satellite (TCPSAT) BOF
Reported by: Mark Allman (mallman@cs.ohiou.edu).
Aaron Falk started the meeting with a brief overview of the agenda and meeting purpose. The BOF was called to determine if interest existed for the formation of a working group that would be charged with documenting the issues involved in using TCP on satellite channels.
Tim Shepard, BBN (shep@bbn.com) presented a view of the problem that satellite channels present:
· The big problem is the delay. · Generally receive windows are low in the net; an 8K receive window can provide maximum throughput of 128 kilobits/second. · This throughput is not bad in some situations (compared to a modem, for example). · But, to use all available bandwidth, we need bigger windows. · But, when using big windows, slow start can cause a large amount of packet loss. · Selective acknowledgments (SACKs) help this problem. · The problem is well understood on the receiver side. · We need to allow bigger windows with window scaling and PAWS (RFC 1323). · We need to generate selective acknowledgments (RFC 2018). · The problem is not well understood on the sender side; more research is needed. · A question was raised about whether RED queuing would help; answer: it might, but we don't know yet.
Yongguang Zhang, Hughes (ygz@isl.hrl.hac.com) presented some recent research results using the NASA ACTS system:
Experimental environment: · ACTS satellite · Reno/SACK FreeBSD machines · Workload: tcplib traffic · 24 KB windows · Avg. file size: 27 KB · Compared to a terrestrial network with 50 ms RTT · Measured useful traffic/hour · Terrestrial channel was able to better utilize the available network capacity when compared to the satellite channel Ongoing experiments: · ATM versus non-ATM on either side of the satellite channel · Other TCP versions (Tahoe, Reno, Vegas, 4K slow start proposal) · Testing under delay emulation
Shawn Ostermann, Ohio Univ. (ostermann@cs.ohiou.edu) presented some of the current solutions being proposed and studied:
· Short transfers do not work very well (small number of segments versus the long RTT and slow start are against us) · Long transfers have problems too (the windows are big, which make the congestion control algorithms take a long time to ramp up (either at the beginning of the transfer, or after a loss) · OU built a multiple connection FTP client and server (XFTP) · Was able to utilize 96% of available bandwidth
Lessons from XFTP:
· We need bigger windows · Need more buffering in the routers (and maybe alternate queuing, like RED) · Detecting and correcting loss
Can’t let pipe empty because:
· Takes 4 seconds to slow start to 100 KB · Takes 50 seconds to recover from one packet loss (using congestion avoidance) · We need to use fast retransmit and recovery · We need to use SACKs · We need to use MTU discovery so that we are sending as much data as possible in each segment
What we understand:
· Long connections with no loss do very well · Short and medium connections do not do well · Short transfers never leave slow start · Delayed ACKs make slow start even worse · What might help? (open issues) · Bigger initial windows (Floyd) · More aggressive window increase algorithm (Allman, et. al) · The slow start changes above have increased throughput and did not significantly decrease goodput or increase loss in tests at OU · Do not perform congestion control if a drop is due to corruption, rather than congestion · Use an ssthresh estimator · Use RED
Goal:
· Extend TCP while keeping backward compatibilityDo not introduce mechanisms that will hurt other types of networks
A question was asked about using indirect-TCP (i.e., breaking the TCP connection into 2 connection at the basestation); Shawn answered that it was an interesting idea that he did not know a lot about.Discussion:
Aaron started a discussion about whether or not a Working Group should be created to document the problems of using TCP over satellite links and some possible solutions. The proposed charter calls for cataloging problems and mitigating mechanisms
Out-of-scope:
· Non-interoperable TCP implementations · Substantial changes to the TCP protocol · Link-layer changes · Research
Some comments:
· What is the purpose of a working group? Use a mailing list, since the scope is small, the group will be short-lived and the deliverable is only one I-D/RFC · Allyn Romanow (co-area director for Transport Area) commented that there is already quite a bit of initiative involved in this group and that a staged approach is worthwhile to try out · Matt Mathis: unfocused WGs are unhealthy and this will be a very focused Working Group, so it is a good experiment · Fred Baker: this type of WG will make the net more useful in the third world and therefore, we should make the effort. Also, these are not just satellite questions but apply to high delay*bandwidth links everywhere. · Allyn conducted a straw poll which was in favor of creating the Working Group.
Goal: To deliver a document at the IETF meeting in Washington, DC (12/97).
WWW Site: http://www.isr.umd.edu/CCDS/IPoS/
TCP Over Satellite mailing list:
To access it send email to: majordomo@listserv.trw.com Include in the body of the message: subscribe tcp-over-satellite.
Interim meeting might be necessary.
Eric Travis outlined the contents of the draft that will be produced.
Purpose:
· Identify and explain performance problems, including pointers to simulation results, emulation results and experiments conducted over real satellites · Identify and explain mechanisms that help overcome the outlined performance problems · Categorize engineering problems and research problems · Discussion: · We need a document for people running real networks that outlines the problems and solutions for problems encountered in the satellite environment
Want to outline various network topologies that contain satellites (examples follow):
node-sat-nodenode-sat-net-nodenode-net-sat-net-nodenode-???-sat-???-node
Identify and describe:
· Large delay*bandwidth · Long feedback path · Asymmetric channels · Corruption · ???
Provide a problem statement and explanation of possible solutions for each of the aboveDiscussion (what do they provide to each environment outlined above)
· References to research results · Tag each area as an engineering or research problem · Validation of problem/solution · Outline interactions between mitigating techniques · Outline research areas · Provide recommendations
Outline the constraints, i.e., that the solutions should not have negative impacts on the Internet
We need to provide validation where possible. Maybe include something about application or network layer protocols, if they have an impact on TCP
1st draft target date: 6/30/972nd draft target date: last day to submit drafts before Munich meeting 3rd draft target date: post Munich4th draft target date: OctoberAaron asked people doing TCP over satellite research to drop a short note to the mailing list outlining their work.