Transport Area Director(s): o Allison Mankin: mankin@cmf.nrl.navy.mil Area Summary reported by Allison Mankin/Naval Research Laboratory Transport Area Directorate Dave Borman dab@cray.com Sally Floyd floyd@ee.lbl.gov Jim Hughes hughes@hughes.network.com Matt Mathis mathis@pele.psc.edu The Transport Area The Transport Area and the Service Application Area were separated from each other at the 26th IETF meeting in Columbus. The Transport Area deals with protocols and algorithms that provide end-to-end transmission services in the Internet. We maintain the notion of transport services, not just transport ``protocols,'' because of the increasing variety of end-to-end requirements that the Internet is meeting or will be expected to meet in the near future. TCP in itself supports applications of many different characteristics, from brief transaction-like exchanges in X-windows on through hypertext support (HTTP running over TCP) and many more. Then there is the range of distributed file systems, over transport services such as the combination of RPC and UDP. Then we come to audio and video, receiving their service in the MBONE from the new transport protocol under development in the AVT Working Group, supported by UDP over multicast IP. So far the Internet is not only holding its own with these major transport services, but they are continuing to spread and to multiply. The Transport Area includes AVT and the Multiparty Multimedia Session Control Working Group, which will lead to new ways in which multiparty services can be provided. The TCP Large Windows Working Group continues to refine the extensions that allow TCP to work effectively in gigabit networks. As to future Transport work areas, the Transport Area will be watching the progress of research work such as RSVP and will support such efforts when they are ready for engineering and deployment. We have recently received a proposal for work to begin on a mobile transport protocol. We hosted one BOF in Amsterdam, following email review of a proposal and draft specification. The TMUX BOF, chaired by Jim Barnes, gathered to work on decreasing the streams of small packets between host pairs that 1 are generated by terminal servers. These small packet streams cause there to be a perception that proprietary protocols can perform more efficiently than TCP/IP. The TMUX BOF is summarized further below. Transport Area Working Groups The Transport Area currently has three working groups: o Audio/Video Transport (AVT) This group did not meet in Amsterdam. Protocol specifications and experimental implementations are nearing completion. May have an interim meeting over the Internet. o Multiparty Multimedia Session Control (MMUSIC) Summarized below. o TCP Large Windows (TCPLW) Summarized below. TCP Multiplexing BOF (TMUX) One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. The Connection Multiplexing Protocol (CMP), an approach to decreasing the number of these by multiplexing between the application and TCP (draft-cameron-cmp-01.txt), was described by Peter Cameron, along with a brief description of some implementation results. After a general discussion of the proposal, Dave Crocker presented a counter proposal that did the multiplexing between IP and TCP instead. Discussion of the two proposals continued with advantages and disadvantages for each proposal. The consensus of those attending the BOF was that CMP addressed a valid problem, but at the wrong place. A request was made that the CMP developers try an implementation of the IP multiplexing proposal (TMUX) to determine whether that was a valid solution. Work continued soon after the Amsterdam meeting, with the result that a specification is now available (draft-cameron-tmux-00.txt by Pete Cameron and Dave Crocker). Multiparty Multimedia Session Control Working Group (MMUSIC) The MMUSIC Working Group met officially as a working group for the first time in Amsterdam. Two sessions were held that were multicast over the MBONE. The first meeting was used to set the context and to discuss the progress made since the BOFs held at the last IETF. After review of the 2 modified charter, we discussed proposals for a set of common terminology, an end-system architecture, the MMUSIC protocol requirements, implementation considerations and conference styles. To narrow the scope of the discussion, we emphasized the need to think in terms of a ``version 0'' negotiation protocol. During the second meeting, the foundations for the strawman protocol were discussed and included proposals for the definition of session state and for naming conference components. After thorough descriptions were given of the main protocol assumptions, we delved into the basic message types, examples of how they might be used, and default session policies. TCP Large Windows Working Group (TCPLW) The TCP Large Windows Working Group met for one session in Amsterdam. The major accomplishments were: o Review of draft-ietf-tcplw-extensions-00.txt o Consideration of advancing RFC 1323 to Draft Standard The reviewed document is a compilation of a few bug fixes and clarifications that need to be made to RFC 1323. It was compiled by Bob Braden. It also includes a pseudo-code presentation of the RFC 1323 TCP extensions. Bob and David Borman led a walk through of the document, to help explain it and to find out if any other changes that are needed to RFC 1323 were missed. The contents of the draft will be folded into the text of RFC 1323 before that specification is submitted for Draftt Standard status. 3