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