Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/avt/avt-minutes-92jul.txt

Text File | 1993-02-17 | 13KB | 314 lines

CURRENT_MEETING_REPORT_


Reported by Steve Casner/USC-ISI

Minutes of the Audio/Video Transport Working Group (AVT)

The AVT Working Group met during three separate sessions.  The first
session began with presentations of candidate protocols for real-time
audio/video transport, followed by a lively discussion of the
differences among the candidates and the underlying questions implied by
those differences.  The discussion resumed in the second session and
part of the third, followed by live demonstrations of experimental
packet audio and video programs.

As part of the second IETF ``audiocast'', live audio and video from all
three sessions was transmitted via UDP and IP multicast to participants
at a number of locations around the world.  At least two remote
participants made multiple contributions to the Working Group
discussion.

1.  Presentations of Candidate Protocols

Steve Casner began with a quick review of the descriptions of the
Network Voice Protocol (NVP-II) data packet format and the first-cut
strawman protocol from the San Diego meeting, then presented a
second-cut strawman based on the discussions in San Diego.  The data
packet header contains the following fields:


   o Timestamp (16 bits of seconds + 16-bit fraction)
   o Packet Sequence Number (16 bits)
   o Flow Identifier (8 bits)
   o Options Length (8 bits)
   o Options


Since Van Jacobsen could not attend, Steve also described the protocol
used by the vat audio program, based on a protocol description sent by
Van to the rem-conf list.  The data packet header format is:


   o Protocol Version (2 bits)
   o Number of Site Identifiers to follow header (6 bits)
   o Start-of-Talkspurt Flag (1 bit)
   o Audio Format/Encoding (5 bits)
   o Conference Identifier (16 bits)
   o Timestamp (32-bit audio sample counter)
   o Site Identifiers (0 to 63; 32 bits each)


Both of these data packet formats depend on a session/control protocol
to carry information that is not required in every data packet.  Henning

                                   1





Schulzrinne described the extensions to the vat session protocol used in
his NEVOT audio program, in particular the periodic transmission of the
sender's state (the current time and how many samples have been
transmitted) to enable measurement of loss at the receiver.

Simon Hackett gave an impromptu overview of his Multimedia Data Switch
(MMDS) application and protocol.  For purposes of experimentation, Simon
chose to use large headers including a variety of fields to make the
data self-describing.  He also continues to send packet headers during
silence as a keep-alive, but just omits the data to reduce the
bandwidth.

See section 5 below for references on these protocols.

2.  Discussion of Protocol Differences

The goal of the discussion was to identify the issues that must be
resolved in order to produce a draft protocol.  The primary ones were:


   o Timestamp format, media sample clock or real time
   o Sequence number versus start-of-talkspurt flag
   o What multiplexing is required beyond address+port
   o Whether or not to indicate encoding format in data packets


The first two issues underlie a key question for the Working Group,
namely whether we should define one real-time transport protocol or
multiple application-specific protocols.  The rough concensus was for
the former, but this may conflict with ease of implementation.

The Working Group discussed timestamp formats at the last meeting and
this one, but the issue is still not finally decided.  For purposes of
synchronization among multiple media sources, the only practical means
is to relate all streams to real time (synchronized time of day).  This
would be simplified if the timestamps are in real time, but the
implementation of audio buffering is much easier with an audio sample
clock timestamp.  The timestamp format could be converted either at the
sender or receiver; what's needed is a detailed analysis of the
tradeoffs.

The strawman protocols propose a packet sequence number in addition to
the timestamp in order to differentiate lost packets from packets not
sent during silence.  The vat protocol uses a flag on the first packet
of a talkspurt because packet mis-ordering makes the sequence number
hard to use.  On the other hand, a sequence number may be required for
video applications that don't have talkspurts but require multiple
packets per frame all with the same timestamp.

The Flow ID in the strawman protocol serves two purposes:  it provides
multiplexing of multiple streams (e.g., audio and video) from the same
source on one IP multicast address and port, and it allows for different
encodings to be used, with each Flow ID bound to an encoding descriptor

                                   2





using the session/control protocol.  As defined, the vat protocol
includes an explicit encoding format field in the data packet, but the
Working Group deemed 5 bits to be too small a number.  The vat encoding
values could also be bound a dynamic set of encoding descriptors using a
control protocol.

The vat Conference ID discriminates among conferences in case of a
collision in random IP multicast address allocation and because many BSD
derived systems don't allow discriminating on the multicast destination
address.  The strawman assumes a repair of the BSD deficiency (which
seems feasible at this time for multicast capable systems) and assumes
some other method to avoid address collisions.

3.  Completeness and Compatibility with Connection Management

In addition to resolving differences among the protocol proposals, we
must consider whether the protocols are sufficiently complete.  Unlike
the audio and video conferencing applications, distributed simulation
and PBX trunking may require aggregation of multiple frames of data into
a single packet.  If the frames can all share the same header
information, then aggregation can be consigned to the next layer up; if
not then some additional encapsulating mechanism would be required.  We
did not consider this further.

Another extension would be flow control.  In previous Working Group
discussions, it has been assumed that network resource management
mechanisms and protocols would be available to allow real-time
applications to avoid congestion.  Christian Huitema pointed out that at
least over some paths we will probably need a feedback mechanism to
allow adjustable codecs to accommodate congestion.  The Group was unsure
whether an application-independent feedback mechanism could be defined.
Christian is to write a specification as a starting point.

This Working Group's low-level protocol must also be compatible with
higher-level connection management protocols such as those under
discussion in the Remote Conferencing Architecture BOF. Provision of
encoding format selections from a conference directory server seems
straightforward.  However, the server must also have a means to acquire
an IP multicast address.  Lixia Zhang suggested (remotely!)  that we
really should consider a distributed system of servers to hand out
globally unique IP multicast addresses; this capability will be needed
by several groups considering multicast, not just ours.

4.  Software Encoding and Enumeration

The real-time transport protocol should be independent of the media
encoding algorithms and formats that belong to the next higher layer
except that the format must be identified by the lower layer.  However,
in keeping with the Working Group goal to foster interoperation and
experimentation with packet audio and video, it may be valuable to agree
on some (perhaps low performance) software compression techniques for
use until hardware is generally available.  This suggests that some of


                                   3





the encoding formats we need to identify will be non-standard and hence
not included in any standard enumeration.

The Working Group feels a strong need to pick up a task that has been
deferred by others, to define an IANA-managed enumeration or naming
convention for audio and video encoding algorithms to enable
interoperation.  The enumeration should not be part of the protocol
itself, but the protocol must provide the space to carry the encoding
identification.  There was substantial discussion of numeric vs
text/parametric identification of formats.  This issue was not resolved.

The third Working Group session was concluded with descriptions and
demonstrations of the software encoding algorithms developed by Working
Group participants.  Paul Milazzo gave an update on the protocol for the
BBN Desktop Video Conference program which was used to multicast packet
video from IETF. Christian Huitema showed the INRIA H.261 video
compression software.  Hans Eriksson described the packet audio and
video experiments at SICS.

5.  Further Discussion

While several issues were not resolved, we laid out the considerations
for each choice well enough to guide the design of a complete set of
consistent choices as the first draft protocol from this Group.  Our
(revised) goal is to have an Internet Draft protocol submitted by
November.  Further discussion by email will be required to make this
happen.

During the IETF meeting, some notes from the first session, including a
description of the strawman and vat protocols, was sent to the rem-conf
list.  It should be in the archive, or may be requested from
[e-mail].  A message from last March on MMDS is also available.

An extensive summary of the issues and a protocol recommendation has
been prepared by Henning Schulzrinne and is available from:


    gaia.cs.umass.edu:~ftp/pub/rtp/rtp.ps


This working paper will be made an Internet Draft for wider
distribution.

Thanks to Eve Schooler, Henning Schulzrinne and Christian Huitema for
taking the notes from which these Minutes were prepared.

Attendees

George Abe               [e-mail]
J. Allard                [e-mail]
John Batzer
Lou Berger               [e-mail]

                                   4





James Berry              [e-mail]
Luc Boulianne            [e-mail]
Scott Brim               [e-mail]
Alan Bryenton            [e-mail]
Randy Butler             [e-mail]
Stephen Casner           [e-mail]
Yee-Hsiang Chang         [e-mail]
Andrew Cherenson         [e-mail]
Robert Clements          [e-mail]
Michael Collins          [e-mail]
Steve Deering            [e-mail]
Tony DeSimone            [e-mail]
Jack Drescher            [e-mail]
Hans Eriksson            [e-mail]
Julio Escobar            [e-mail]
Roger Fajman             [e-mail]
Margaret Forsythe        [e-mail]
Osten Franberg           [e-mail]
Ron Frederick            [e-mail]
Jerry Friesen            [e-mail]
Robert Gilligan          [e-mail]
Simon Hackett            [e-mail]
Robert Hagens            [e-mail]
Christian Huitema        [e-mail]
Peter Kirstein           [e-mail]
Jim Knowles              [e-mail]
Padma Krishnaswamy       [e-mail]
Matt Mathis              [e-mail]
Cindy Mazza
Donald Merritt           [e-mail]
Paul Milazzo             [e-mail]
Robert Mines             [e-mail]
Donald Morris            [e-mail]
Ari Ollikainen           [e-mail]
Roger Osmond             bytex![e-mail]
Larry Palmer             [e-mail]
Michael Powell           [e-mail]
Russell Pretty           [e-mail]
K. K. Ramakrishnan       [e-mail]
Bradley Rhoades          [e-mail]
Allan Rubens             [e-mail]
Henry Sanders            [e-mail]
Eve Schooler             [e-mail]
Koichiro Seto            [e-mail]
Vincent Sgro             [e-mail]
Louis Steinberg          [e-mail]
Terrance Sullivan        [e-mail]
Sally Tarquinio          [e-mail]
Claudio Topolcic         [e-mail]
Mark Uhrmacher           [e-mail]
Andrew Veitch            [e-mail]
John Vollbrecht          [e-mail]
David Waitzman           [e-mail]
Sandro Wallach           [e-mail]

                                   5





Abel Weinrib             [e-mail]
Rick Wilder              [e-mail]
Walter Wimer             [e-mail]
Linda Winkler            [e-mail]
Jeff Wong                [e-mail]
Richard Woundy           [e-mail]
John Wroclawski          [e-mail]
Paul Zawada              [e-mail]



                                   6