NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
Aaron Falk <aaron.falk@trw.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Advisor:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:tcp-over-satellite@listserv.trw.com
To Subscribe: majordomo@listserv.trw.com
In Body: inbody: 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 which 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:
o Transport layer issues affecting TCP over satellite links o Existing TCP options o Compliant implementations which have some known improved performance over satellite links o Recommendation of well understood protocol changes o 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
· Ongoing TCP Research Related to Satellites
No Request For Comments
Minutes of the TCP Over Satellite (sat) Working Group
Recorded by Dan Glover
Aaron Falk opened the meeting a little after 9:00am. The agenda for the meeting included a presentation by Mark Allman on the Standard Mechanisms draft and the Research Issues draft, a presentation by Jeff Semke on Auto Tuning and a discussion on a suggestion to create a new draft on spoofing led by Aaron.
Aaron expressed a hope that issues raised on the mailing list in the last week would be discussed. The Standard Mechanisms draft is not ready for last call, but the plan is to be ready for the end of April. Aaron solicited more inputs for the Research Issues draft and for input on error rate experience with forward error correction (FEC) coding.
Mark Allman gave a presentation on the status of the Standard Mechanisms draft. The draft was in a similar state as at the DC meeting. Mark discussed four items:
1. 1)Beefing up the FEC portion of the document to reflect that FEC is not a panacea and that even with a perfect satellite link, noisy links elsewhere in the path will suffer from the long delay feedback path,
2. 2)Is Path MTU Discovery always a good thing for satellites?
4) Large windows have to be hand tuned on both sides of the connection, and
3. 4)Security - are there privacy concerns with the broadcast nature of satellites? Mark's Standard Mechanisms slides are available at: http://gigahertz.lerc.nasa.gov/~mallman/papers/la-tcpsat1.ps
Discussion from the floor on FEC expressed a consensus view that FEC, while helpful, is not a panacea. It is not always possible to get a perfect link (e.g., jamming). FEC requires a design trade on bandwidth and processing time.
Discussion from the floor on PMTU reached a consensus that PMTU should remain in the draft. It was pointed out that at some error rate smaller packets are better than bigger packets. Satellite channels tend to have short bursts of errors then a period of clear transmission. If there is one loss per window, then packet size doesn't matter. A larger packet size opens the window faster than smaller packets. Smaller packets are more efficient for store and forward systems. There is some "big" that is too big. A point that was well made was that the coding design should pick the appropriate MTU for the link and that Path MTU Discovery will find it. There may be some times where Path MTU Discovery is not beneficial (i.e., it requires several hops over the satellite to discover the proper MTU). There are some open issues with PMTU that are not limited to satellites. Processing in the satellite system also affects the proper packet size.
Mark Allman reiterated the goal of a last call on the Standard Mechanisms draft by the end of April. He will add a pointer to the PSC TCP implementation Web page and some words on security.
Jeff Semke of PSC gave a brief presentation on window size auto-tuning (eliminates the need to set TCP window size by hand) and will post pointers on the list to more information. PSC has submitted a paper and has a NetBSD implementation. [http://www.psc.edu/networking/auto.html]
Mark Allman then discussed the Research Issues draft. It is educational and does not recommend any mitigations. It only covers TCP or TCP-related mitigations and excludes application protocols and queuing algorithms. Mark asked for volunteers to write various sections of the draft and asked
for more topics or headings that were not presently in the draft, but should be. Mark's Research Issues slides are available at: http://gigahertz.lerc.nasa.gov/~mallman/papers/la-tcpsat2.ps
It was pointed out from the floor that turning off delayed ACKs during slow start or at any time is totally allowed.
Aaron Falk then led a discussion on spoofing.
Points from the discussion: Spoofing is used on satellite links and transoceanic cables. It prevents the end user from having to tweak their TCP. Some spoofing does not break the end-to-end semantics while other spoofing does. A definition of spoofing is needed. Issues of reliability, security, risks need to be addressed. Spoofing relies on information from headers that could disappear (i.e., due to IPSec). Proxies and firewalls can be thought of as spoofing. A proxy terminates a connection, relies on trust, could isolate noisy environments from clean. (Aaron provided a laser pointer for remarks from the floor noting that one always needs a laser pointer at a satellite meeting.) Large queues in satellite routers could be helpful. We don't want to say that spoofing is necessary. A security advisor is needed. [Hilarie Orman has volunteered to advise on security issues.]
There was a consensus to produce a draft outside of TCPSAT on spoofing perhaps leading to an informational RFC. A BOF in Chicago will be requested. [A mailing list to discuss spoofing has been set up with instructions available at http://tcppep.lerc.nasa.gov/tcppep/ ]
Aaron Falk adjourned the meeting at 10:20am.
TCPSAT - Agenda and Status
Enhancing TCP Over Satellite Channels Using Standard Mechanisms
Ongoing TCP Research Related to Satellites