NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 28-Oct-97
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: 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 tyo 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 (TCPSAT) WG
Reported by Dan Glover (Daniel.Glover@lerc.nasa.gov)
Charts and documents are available from the TCPSAT Web page at http://tcpsat.lerc.nasa.gov/tcpsat/
Aaron Falk opened the meeting at 9:30am and reviewed the agenda which was accepted without comments. Aaron asked for a show of hands on how many attendees were on the mailing list and estimated about 80% were.
Aaron reviewed the status of the working group. He stated his intention to forward the standard mechanisms draft for consideration as an informational RFC if consensus was reached. The research issues draft was not ready yet, so he presented a schedule change showing a meeting of the working group at the next IETF meeting. There was no comment on the proposed schedule that Aaron interpreted as general agreement.
Mark Allman gave a presentation on the standard mechanisms draft. He stated that he intended to provide a pointer to the PSC implementations information Web page, but did not intend to include details on specific implementations in the draft.
Luis Sanchez commented that security issues could be better addressed and agreed to write a paragraph on IP security issues related to TCP over satellite. A question on UDP was dismissed as out-of-scope by Aaron. A question on LEO satellites not having high delay*bandwidth was answered by pointing out that the draft's list of satellite characteristics was a general list and that any particular satellite would have a subset of those characteristics. There was a comment that asymmetric bandwidth cases did not appear to be addressed in detail.
There was a comment that bigger segments did not make sense in a high error environment. Questions were raised about Path MTU Discovery, that there had been past problems with routers that didn't support it, that some firewalls do not support it, that some implementations are broken over GRE tunnels, and that the discovery process could add significant time to a transmission.
Aaron asked if there was general consensus that the standard mechanisms draft should be forwarded for consideration as an informational RFC after some modification to the Path MTU Discovery section. There was a general nodding of heads and no dissent was noted.
Mark then gave a presentation on the research issues draft. He pointed out that the first draft of the document is incomplete. He asked for volunteers to help write the sections that have already been identified or any new sections using the same format as in the present draft.
Someone volunteered to write up the benefits of header compression for asymmetric channels. Comments were made that on asymmetric channels TCP rate limiting is needed to avoid bursts for byte counting, and that ACKs could be lost on uplink.
Aaron asked for general comments on the state of the research draft. Mark complained that the draft is nowhere near complete. TCP for Transactions was discussed at some length. Some felt that the benefits of T/TCP were outweighed by the complexity of implementation. Someone commented that Web servers would benefit from T/TCP, but was answered by another comment that HTTP 1.1 brings the same benefits as persistant connections by using one connection in place of many. A comment was made that denial of service using T/TCP would make it unsuitable for Web servers. There was discussion of the pros and cons of leaving T/TCP in the draft.
Comments were made that NACK and SCPS needed to be added to the list of research issues in the draft and that Van Jacobson's comments about byte counting at the last TCPSAT meeting should be addressed in the draft.
Aaron closed the meeting. The roster sheet had only made it around about halfway by this point, so Aaron urged attendees to sign the blue sheet on their way out.
TCPSAT - Status
Enhancing TCP Over Satellite Channels Using Standard Mechanisms
Ongoing TCP Research Related to Satellites