CURRENT_MEETING_REPORT_ Reported by Steve Casner/USC-ISI Minutes of the Audio/Video Transport Working Group (AVT) Overview The meeting began with a brief report on the status of the Real-time Transport Protocol (RTP). The draft RTP specification was submitted with a request for IESG Last Call just before the previous IETF meeting in November. The review by the Transport Area Directorate called for several changes so that RTP would more closely follow the principles of Application Level Framing (ALF) and Integrated Layer Processing (ILP) proposed by David Clark and David Tennenhouse in their SIGCOMM 1990 paper. In two discussions between Steve Casner, Ron Frederick and Van Jacobson, in which the vat and nv programs were taken as design examples, the following list of proposed changes was constructed: o Carry the control and data traffic on separate ports o Move the application-level multiplexing of the channel ID to an encapsulation, for the cases where it is needed o Minimize the use of options o Make the definition of some fields application-specific (in particular, the timestamp clock rate and sync marker) o Use global rather than local IDs, to be able to detect loops o Specify more precisely how reception reports should be provided These changes were described in more detail by Steve Casner in a long message sent to the rem-conf@es.net mailing list on 21 March 1994. The first 90 minutes of the first session, and the beginning of the second session, were occupied by a presentation of these changes. The sections below interleave the main points from the presentation of proposed changes with issues from the discussion that followed. The working group generally agreed with the changes, although some remaining details were identified. A summary appears at the end of these minutes. Our task is now to complete the design to address these details, update the specification and get consensus from the working group via e-mail. Steve Casner will take responsibility for sending out a more complete draft of the proposed changes to start the discussion. Everyone is encouraged to participate. Please send e-mail if there were issues not addressed, to the rem-conf list or to Steve. The goal is to submit the draft for Last Call after review at the July IETF meeting in Toronto. After reviewing the RTP submission in November, the directorate recommended that the protocol be given Experimental status rather than Proposed Standard. However, John Wroclawski said that this was only a strategy for dealing with the differences of opinion about the protocol, and that with the proposed changes he believes the directorate would not have a preference. John and others expressed personal preferences for Proposed Standard status as the goal, once the details of the changes are completed and integrated into the specification. No objections were voiced. At the end of the second session, there were two additional presentations. Julio Escobar gave a report on the use of RTP to support the Synchronization Protocol developed at BBN. The only requirement not satisfied by RTP was the need to communicate the calculated synchronization delays among the destination processors; this could be added to the control packet as application-specific data. Don Hoffman gave a brief description of the two Internet-Drafts just released on encoding profiles for Cell-B and MPEG/MPEG-2. Cell-B was developed by Sun but is freely available. MPEG-2 is in development as an ISO/IEC standard. In the MPEG profile, two formats are proposed, one for interoperation with other transport mechanisms using the MPEG-2 Systems environment, and a second, simpler format intended for native Internet-style applications. Comments on the drafts were solicited. The drafts are: o ``RTP Encapsulation of Cell-B Video Encoding'' (draft-speer-cellb-rtp-encap-00.txt) o ``RTP Encapsulation of MPEG1/MPEG2'' (draft-hoffman-rtp-mpeg-encap-00.txt) These encoding profiles will be finalized after the RTP changes are resolved, and reviewed at the Toronto IETF meeting. There has also been further work on the JPEG encapsulation since the November meeting. It is now proposed that a small header be included at the start of the data area in each packet. This would be a more compact representation of some of the information in a JFIF header. With this header, decoding restarts would be possible, allowing partial frames to be decoded. Those who are interested in more details should send e-mail to Bill Fenner. Proposed Changes to RTP The sections below interleave the main points from the presentation of proposed changes with issues from the discussion that followed. However, much of the presentation of advantages and disadvantages has been omitted here; those who did not read the message describing the changes are advised to fetch it from ftp.isi.edu, in /mbone/avt/rtpv2-proposal.txt. In the same directory is rtpv2-presentation.ps which contains the slides from this meeting. 1. Control and Data on Separate Ports This change removes RTCP functions from RTP data packets and puts them into a separate packet stream on another port to streamline data processing and to allow monitoring programs to receive the control information without having to sort through the data. No issues regarding this point were brought up in the discussion. However, in e-mail, Jarmo Molsa expressed the concern that using separate ports would require an additional socket on many systems, and that on some systems the number of sockets is limited. 2. Remove Channel ID, Put Multiplexing into Encapsulations as Needed There has been quite a bit of debate about the channel ID in the past, but none during this meeting. Most applications that may have used multiple channel IDs could use multiple destination ports instead. 3. Replace Data Options with a Bit Field With the RTCP operations separated into another packet stream on a different port, there are only a few optional fields to be selected in data packets. That allows the optional fields to be indicated by bits in the fixed header. If the bits are also grouped together, it is possible to interpret them as a ``packet format,'' which is a single demultiplexing point for processing as a set of fixed formats if appropriate. The packet format method might not be used in software implementations, except perhaps for a fast-path when all options are off; however, for hardware, the bit-field approach would be much simpler than the option structure as defined in the current RTP specification. The RTP options would be replaced as follows: o CSRC (content source) -- A bit field of 5 or 6 bits in the fixed header to count the number of content source identifiers to follow, for packets produced by a bridge (mixer). Zero indicates that the packet did not come from a bridge. This count takes the place of the length field in the current CSRC option. o SSRC (synchronization source) -- It was decided that the SSRC identifier should always be included (see the discussion of global identifiers below), so this option becomes part of the fixed header. o BOS (beginning of sync unit) -- Eliminated as an option. o APP (application-specific) -- Application-specific functions could be defined in profiles as extensions to the RTP header, but there is no provision for one implementation of an application to define its own optional information in a way that other implementations can simply ignore. o SDST (sync destination, or reverse-path option) -- Reverse path packets would be eliminated because translators would not keep a table of source transport address to SSRC identifier mappings, and the SSRC/SDST would not be visible in encrypted packets. o ENC (encryption) -- When encryption is used, the whole RTP unit is encrypted (all of the RTP header and data). The receiver depends upon header validity checks (version, format, sequence number, and timestamp having reasonable values) to discard packets that should have been decrypted (or decrypted with a different key). There is no provision for an explicit initialization vector; instead, zero would be used with random initial values for the sequence number and timestamp to deter a known plain-text attack. The key and encryption algorithm would be specified by out-of-band information; key switching can be done by decrypting just the header with the old key first, and if the validity checks fail, then trying again with the new key. o MIC (authentication) -- An authenticated packet would be indicated by a bit in the header which would indicate the presence of an authentication field later in the header. With the global identifier scheme, the SSRC could be authenticated to have been set by one of the sources (but could still be false). The authentication method (covered by ENC, keyed, symmetrically encrypted, or asymmetrically encrypted), algorithm and key (if any) would be known from out-of-band information. As with encryption, key changes could be accomplished by trying with old and new keys in succession. Alternatively, a key descriptor could be included at the start of the authentication field. To allow some receivers to ignore the authentication without knowing the out-of-band information, a length field would be needed at the start of the authentication field. Some details for the encryption and authentication methods have not been fully specified. Encryption requires an indication of how much padding was added to the end of the data to round up the length to a multiple of the encryption block size. Christian Huitema also suggested that the authentication digest be appended as a trailer rather than a header encapsulation to allow for hardware processing or to allow a single loop through the data for decryption, authentication, and decompression, per the ILP design principle. It may be possible to use one bit in the header to indicate whether there is any trailer present, and then to structure the trailer to indicate padding and authentication digest. In e-mail, Mark Wahl brought up the desire to include a full NTP timestamp and sender description (e.g., distinguished name) within the authentication to minimize replay and support non-repudiation. These details are to be designed and presented later. The other fields in the first 32 bits of the RTP header are the version number, format, sync marker, and sequence number. It is proposed that the version number be bumped to 2 if these proposed changes are adopted. The format field would remain unchanged. The sync marker definition would change (see below), but would remain one bit. The sequence number should stay at 16 bits for arithmetic convenience, but could be trimmed if necessary. So, the resulting header bit count would be: 6 for CSRC count 1 for encryption/authentication trailer 2 for version 6 for format 1 for sync marker 16 for sequence number --- 32 Jon Crowcroft said that the UCL monitoring software uses sequence numbers to measure loss and reordering, so reducing the sequence number space to 8 bits would cause a problem for their sampling mechanism (over a long view, not looking at all packets). Van Jacobson commented that misordering by more than the sequence number space can still be corrected using the timestamp. The purpose of the sequence number is to detect gaps. Jon also requested that space be made for one additional bit to indicate the congestion probe options used in Ian Wakeman's congestion control scheme. Several others expressed concern in off-line comments that there should be some mechanism for adding functions or options to the data packets. This is an issue that needs further discussion. 4. Media-specific Timestamps To eliminate the requirement for RTP applications to know the time of day and some possible, but rare, off-by-one errors in timestamp tick rate conversion, it is proposed that the rate at which the clock ticks, instead of always being 65536 Hz, would become a parameter of the format. For some formats, such as the variable frame rate video we are now using, it may make sense to retain the 65536 Hz rate, while for most audio formats, the clock rate would be set to be the same as the sampling rate, as is done for the timestamp in vat. It is also proposed to remove the requirement for senders to make timestamp adjustments. For example, the timestamps would just follow the input device's sample counter. For senders that do know the time of day, control packets would carry both an RTP timestamp (sample clock) and the corresponding full 64-bit NTP timestamp to establish the relationship. Bill Fink noted that with the previous definition of the RTP timestamp as the middle 32 bits of an NTP timestamp, it would be simple for a recorder to replay an RTP stream with the original timing or to synchronize the playback of two RTP streams without any knowledge of the encodings. He asked if recorders would now have to be media-specific. There are several possibilities. A recorder can replay packets with the same timing as they were received simply by recording its own local timestamps along with the packets. However, that requires extra space, and does not remove the jitter induced on the path from the source to the recorder. The recorder can reconstruct the source's timing in several ways: 1) from the media timestamps and the nominal rate if it is known, 2) by calculating the nominal rate based on the difference between times in a pair of control packets relating media timestamps to real time, or 3) by calculating the nominal rate based on the arrival rate when the packets are received. 5. Application-specific Sync Marker Bit In the current RTP specification, the sync bit is defined to mark the last packet of a synchronization unit. The proposed change is to allow the meaning of the sync marker bit to be defined by an application profile. The application profile could further specify that the bit is defined by each of the encoding profiles to be used under that application profile. In e-mail, Henning Schulzrinne suggested that two sync marker bits be defined in the fixed header, one for start and one for end of synchronization unit, since both events are interesting, as opposed to making the one bit variable and requiring the application to define what it means. However, the general sentiment in the meeting was in favor of one flexible bit as proposed because there may be more than these two meanings, e.g., in video there may be a difference between sync unit and frame. The recommendation was to remove the word ``sync'' from the description of the bit, making it an application-specific marker to be defined as seen fit in the application profile. 6. Global Source Identifiers RTP currently uses locally unique source 16-bit identifiers to keep track of distinct sources when packets flow through translators and bridges and lose their original transport addresses. The identifiers are locally assigned by the translators and bridges and are remapped by successive translators or bridges. The proposed change is based on the scheme used by vat and wb in which sources assign 32-bit identifiers that are globally unique within a particular medium in a particular session. No remapping is required; loops can be detected. The way the proposed scheme would be specified is that the identifiers are 32-bit opaque numbers, and that there may be a variety of means to assign them, including choosing them randomly. Since there may be collisions in a distributed allocation mechanism, there is a collision resolution protocol, but the allocation mechanism should be such that the collision resolution protocol is typically exercised less than 1% of the time. Two mechanisms are proposed: o When a participant first joins a conference, the identifiers of the other participants are likely to be heard before the new participant transmits, so there is a chance to choose another random number if there is a conflict. o If a new site begins using an identifier in conflict with an existing one, then any site in the session can send a message challenging the new participant (since the owner of the identifier might not be in the session at that moment). Randomized delays would be used to prevent an implosion of responses. This challenge mechanism would need to be specified in the protocol. 6.1 Use of IPv4 Addresses The topic receiving the most discussion during the meeting was Van Jacobson's proposal that in the current Internet multicast environment, one way to assign unique identifiers is to use the IPv4 address of the host if there is only one source per host. Van argued that this is almost always the case because sessions tend to be associated with a particular set of hardware resources, for example, the mike and speaker associated with a particular workstation. Even if multiple X terminals that have audio hardware operate off a single workstation, the X terminal also has an IP address which can be used. For those cases where there are additional sources on one host, a identifier would be chosen at random from the ``class F'' IP address space (26 bits) so as not to conflict with assigned addresses. Christian Huitema pointed out that we could use the IP multicast class D space (28 bits) since a multicast address should never be a source address. However, a bit of additional analysis done since the meeting by Sally Floyd in response to a question from Steve Casner shows that it may be better just to choose the random numbers from the 32-bit space anyway. For a session with 2000 participants, the probability of collision is lower in the separate 26-bit space only if the number of random allocations is less than 60, and in that case the probability of collision is less than 0.00005 either way. Using the IPv4 address for most identifiers has two advantages: o The identifier field could be omitted and a single bit could be used in the RTP header to denote that the identifier was implicit in the common case where the identifier is the same as the source address of the packet (a significant reduction for audio). o Given that IP addresses are (generally) unique, this reduces the probability of identifier collisions by requiring fewer random allocations (compared to allocating all identifiers randomly). Since RTP may also be used over protocols other than IP, Jon Crowcroft suggested that the specification allow the use of unique addresses from any address space, for example, the bottom 32 bits of an IEEE 802 address. Unfortunately, this idea runs into trouble when we consider interoperation among multiple networks with different address spaces. Ron Frederick and Abel Weinrib pointed out that two spaces may have allocation patterns such that the rate of collision is much higher than would be the result of allocating all identifiers randomly. For example, consider a session involving multiple enterprises connected through firewalls and each using the small portion of the IPv4 space allocated to private networks as described in RFC 1597. Even when the session size is small, some individuals who communicate frequently might always collide (because the addresses are fixed). Therefore, only one address space can be allowed to us use non-random assignment unless the spaces can be arranged to be non-overlapping, and that seems impractical. It seems technically bad to give the optimization to IPv4 if we expect this protocol to live for a while, not to mention the political concern that anything that says ``IPv4 address'' in it is probably short-sighted. Ron also disagreed with Van's contention that the presence of multiple sources on one host would necessarily be infrequent. For example, one might run multiple copies of nv for multiple cameras or for a camera and an X screen capture source. Many applications would require the extra mechanism to support figuring out if the IPv4 address could be used or if a random identifier must be allocated. The conclusion was that the specification should not suggest the use of IPv4 addresses or any other fixed mapping of an address space to the 32-bit identifier space. Instead, applications should always allocate identifiers randomly in the full 32-bit space. A combination of the address and time might be used to seed the random number generator. Given that the synchronization source (SSRC) identifier is to be chosen randomly, that identifier must always be included explicitly in the RTP header. While many of us hate to see the header length increased from 8 to 12 bytes, there was a consensus that this was the right decision because it simplifies several other aspects of the protocol: it means we don't need a flag bit to indicate inclusion of the SSRC field, it allows translators to forward encrypted and/or authenticated packets without any special handling, and it eliminates any dependence upon the packet source address (e.g., IP address). 6.2 Permanence of Identifiers One of the advantages that may have been cited for using the IPv4 address as the identifier is its permanence. When an application using random identifiers is killed and restarted in the same session, a person may be identified as a new source unless the application stored the previously allocated identifier somewhere. However, it is also wrong to assume that the IPv4 address would serve as a persistent identifier for a participant. Van Jacobson pointed out that there may be multiple people using one machine serially in one session, and they should be identified uniquely; John Wroclawski noted that the IP address may change between application invocations due to mobile computing and dynamically assigned addresses. The specification must state that it is mandatory for an application that cares about reuse to provide a way to save the identifier itself, independent of what scheme was used to select the identifier in the first place. Ron Frederick said that even if IPv4 addresses were used as identifiers, some other source might allocate the same number randomly or through some other means. Therefore, applications must always be prepared to go through the collision resolution protocol. Abel Weinrib took the point further, saying that assumptions of permanence are dangerous. If an application saves an identifier and tries to reuse it sometime later, another source may have begun using that identifier in the meantime so the reuse would be seen as a collision and the first application would be stuck. For applications that require long-term permanence, or for which information ownership has serious consequences, a higher-level participant name, such as may be carried in the RTP control packet or a higher-level control protocol, should be the point of ownership and the RTP source identifiers should be considered transient. Bill Fink noted that the use of these identifiers is very dependent upon how the control protocol works and how the session and directory information is maintained. 6.3 Scaling Limit for Random Identifier Allocation The primary disadvantage of random identifier allocation is the possibility that two sources will choose the same number; this is the same as the ``birthday problem.'' Steve Casner presented two graphs of probability of collision based on analysis and bits of Mathematica supplied by Sally Floyd. For identifiers picked uniformly from a 32-bit space, the probability of there being at least one collision is 0.0001 for 1K identifiers chosen or 0.01 (1%) for 10K identifiers chosen. Considering that not all the identifiers in a session are chosen at once, it is useful to consider that the probability of collision is much smaller for adding one participant to a session in which the identifiers are already known not to conflict. So, for most applications, the maximum session size for which the random allocation scheme performs acceptably would be somewhere in the range 1K-10K. This is not a new constraint since it matches the limit on session size already imposed by the rate backoff limit for the sender identification and reception report packets. However, it is important to insure that the collision resolution protocol scales (or fails gracefully) when the expected limit is exceeded. Some sessions, such as IETF meetings and space shuttle missions, are already near 1K in the cumulative list of participants, though the maximum number of simultaneous participants is around 200-300. We are likely to reach the limit within the expected life of the protocol. To go beyond that will require some additional mechanism such as aggregation and hierarchy. Van Jacobson suggested that in a large, private broadcast system, one might assign customer identifiers as people sign up, and use those as globally unique identifiers. Or, in truly unidirectional systems, the receivers may not require unique identifiers because they cannot emit any packets. John Wroclawski believes there is a clear architectural understanding of how to make this scale to much larger systems, and there is some engineering work that's beginning to get underway. This may well be an appropriate future direction for this protocol and this working group, but we don't know the general solution yet. Perhaps the specification should include an applicability statement for the random identifier scheme as defined, along with some hints about the architectural ideas and work in progress, to encourage experimentation. 7. Control Packet Format/Reception Reports With control and data being carried on separate ports, the functions of the RTCP options would be moved into the control packets. The primary functions are: o Providing information about the sender, e.g., name. o Providing reception reports for all sources received since the last report, or round robin through the list for as many as will fit; reports should contain absolute information rather than deltas so it does not matter if a report is missed. o Relating the sender's media timestamp to real time for intermedia synchronization, also marking the time of the reception reports so rates can be calculated from differences in packet and byte counts. The format of control packets has not been as well defined as the other items in the proposed collection of changes. The header format for the control packets need not be exactly the same as for the data packets, but it may be useful to keep them similar. SSRC, CSRC, encryption and authentication are required for control packets as well as data packets, and the mechanisms should be the same. The general guideline for the construction of the control packet is to put more common information first so that application-independent monitors can process all the common information without having to know anything about the format of the application- or media-dependent information. The length of any application-dependent section would be implicit in the profile that defines the application. However, for those applications that may include media-dependent information, an identifier and possibly a length field for the particular media format would be required. 7.1 Mandatory Reception Reports In previous AVT meetings, it has been suggested that RTCP might be removed from the RTP specification entirely. However, Van Jacobson argues that in order for RTP to be used on a large scale in the Internet, we must provide mechanisms for network service providers as well as users to evaluate the distribution quality. The multicast data itself is the test traffic, and the reception reports are the monitoring mechanism. This mechanism needs to be considered a fundamental part of RTP covering all applications; its use should not be considered optional. The RTP specification and application profiles should be written such that any application using RTP will work in multicast mode, with unicast as a special case. In an IP multicast environment, reception reports must be sent by all receivers, including those that never send any data. The rate at which the reports are generated is scaled back as the number of participants increases so that the aggregate control traffic does not exceed the bandwidth of one data stream. The control packets would be sent too slowly to be useful beyond a session size somewhere in the 1K-10K range. This brought up the question of using RTP in truly unidirectional systems in which it is presumed that successful transmission is assured by some means and in which it may not be possible for receivers to send a report. In such a system, reception reports would not be required. The specification will need some applicability statements for those pieces that may not be architecturally relevant as we move into new applications. A profile may specify how to use RTP in a unidirectional environment. 7.2 Requirement for NTP Time in Control Packet Frank Kastenholz expressed concern about the requirement for an NTP timestamp in the control packet. This needs to be clarified: systems that do not know what time it is should not be required to put an absolute time into that field. However, if the calculation of the data rate and packet rate from the counts in the reception report depends upon the time field, then there may be a requirement for a time value that increments at close to real time even if it is not related to the time of day. An audio application might be able to keep track of time by referencing the sample counter, but what about applications with aperiodic data? 7.3 Congestion Control Jon Crowcroft and Christian Huitema would like to enable receivers to more quickly report that they are experiencing loss. Jon sought support for Ian Wakeman's congestion control scheme which selects receivers to report more frequently than the rate backoff of reception reports would allow in a large session. Christian wanted the reception report to include an explicit measurement of packet loss by the receiver so that when loss is observed in small sessions the sender can be advised to adapt. Van Jacobson claims that transients are not a concern, and that one cannot robustly make a better diagnosis than the proposed reception report mechanism allows without making the report size much larger. He offered to provide convincing arguments off-line. We are awaiting results of those discussions. 7.4 Reports for Multiple-priority Streams John Wroclawski asked whether the reception reports would provide an accurate estimate of overall loss rate for multi-priority schemes and layered encodings. One may only care about the highest priority packets, or one may want more information than the general reception report provides. Additional information could be added in the media-dependent section of the report, but this might not solve the problem for generic monitoring tools. Van Jacobson said that the different priority data streams should be sent on different multicast addresses so the loss rates can be reported separately. However, monitors would still need to know that the loss rate on lower priority streams is expected to be higher. This question needs more thought. 7.5 Additional Control Functions The sender description and reception report information correspond to the RTCP SDES and QOS options. In addition, if the functions of the FMT, BYE and APP options are to be retained, they need to be incorporated into the control packet structure in some way. These functions could be specified by different packet types in the control packet header, plus another type for the mandatory sender description/reception report. Greg Minshall suggested that there be some mechanism for tagging along additional information on the report packets that must be sent periodically anyway. One way would be to allow multiple control packets to be aggregated into one lower-layer packet. o FMT (format description) -- Allows format codes, which go in the 6-bit field in the data packet header, to be defined dynamically in addition to the small set that are predefined. FMT is not intended for redefinition of codes to allow switching among more than 32 formats in one session; applications needing to do that should define a format whose data field begins with a further specification of the format. FMT may be seldom used since a higher-layer session protocol, such as a session directory, would normally be used to select the formats for a session and define any format codes not already predefined. o BYE (goodbye) -- Indicates that a source is terminating its participation in a session. Since no source description or reception report information is required, this could be a separate (trivial) control packet format. Greg Minshall suggested that we might want the BYE packet to include the reason for leaving. o APP (application-specific controls) -- Application-specific sections of the sender information and reception reports in the control packet already provide a means to carry periodic information defined by an application profile. However, multiple implementations of a single application profile may interoperate but still need to communicate information that may be ignored by other implementations. Each profile could define on its own a mechanism to include implementation-dependent information, but it seems better to have a common mechanism. Implementation-specific data could be added at end of the reception reports after the media-dependent data. To avoid conflicts among multiple implementations each of which wanted to include its own information, some implementation identification such as the ASCII name in the existing APP option is required. A separate APP packet type would use the same implementation identification mechanism for transporting signals that are not periodic and have nothing to do with the sender information. Charley Kline asked whether we should simply require that applications use some more sophisticated session control protocol if they need to communicate any control information beyond what's in the sender description and reception reports. For many applications, it is likely to be more convenient to use the RTCP path. The basic question is, should we make a provision for RTP to operate in the absence of any higher-layer mechanism for some applications? Summary of Agreements and Open Issues The following items were agreed during the meeting: o Global identifiers would always be 32-bit random numbers; the IPv4 address should not be used. o The sync source (SSRC) identifier would always be included in a new field added to the fixed RTP header. o Encryption should cover the whole packet; zero would be used for the initialization vector, with random initial values for timestamp and sequence number. o The above agreements imply elimination of reverse-path packets. o The word ``sync'' would be dropped from the name of the marker bit; its meaning would be defined by the application profile. o The plan is to seek Proposed Standard status for the protocol. The following open issues were identified during the discussion: o Need to define how to indicate the length of padding required for encryption and the format of a trailer for authentication. o Should an optional congestion probe field be defined? o Should there be a means to add options to a data packet? o The control packet format needs to be defined in detail. o Specify how timestamps are used on systems that don't know time. o Should a receiver-calculated loss measure be in reception reports? o What is the effect of multi-priority streams on loss monitoring? o Should the FMT and APP options be included? (Should RTP be usable without a higher-layer session protocol?) o An applicability statement for RTP needs to be defined. Attendees Brian Adamson adamson@itd.nrl.navy.mil Kannan Alagappan kannan@sejour.lkg.dec.com Richard Bantel rb@mtsol.att.com Lou Berger lberger@bbn.com Steven Berson berson@isi.edu Jim Binkley jrb@cs.pdx.edu David Borman dab@cray.com Carsten Bormann cabo@informatik.uni-bremen.de Robert Braden braden@isi.edu Michael Bradley bradley@mdd.comm.mot.com Michael Bringmann michael@rd.qms.com Theodore Brunner ted.brunner@tek.com John Carlson johnc@cac.washington.edu Stephen Casner casner@isi.edu Andrew Cherenson arc@sgi.com Eric Chin-Li-Sun ericc@tera.com Richard Cogger R.Cogger@cornell.edu Eric Crawley kaufman@scrc.symbolics.com Jon Crowcroft jon@cs.ucl.ac.uk Roger Cyganer cygander@telebit.comm Sandip Dasgupta sandip@cup.hp.com Luca Delgrossi luca@ibmpa.awdpa.ibm.com Chuck deSostoa chuckd@cup.hp.com Julio Escobar jescobar@bbn.com William Fenner fenner@cmf.nrl.navy.mil Antonio Fernandez afa@bellcore.com William Fink bill@wizard.gsfc.nasa.gov Sally Floyd floyd@ee.lbl.gov Ron Frederick frederick@parc.xerox.com Thane Frivold frivold@erg.sri.com Mark Handley mhandley@cs.ucl.ac.uk Don Hoffman hoffman@eng.sun.com Christian Huitema Christian.Huitema@sophia.inria.fr Geoff Huston g.huston@aarnet.edu.au Phil Irey pirey@relay.nswc.navy.mil Steven Jackowski stevej@syzygycomm.com Van Jacobson van@ee.lbl.gov Kyungran Kang krkang@cosmos.kaist.ac.kr Frank Kastenholz kasten@ftp.com Alan Katz katz@adonis.com Andrew Knutsen andrewk@sco.com Robert Kummerfeld bob@cs.su.oz.au Paul Leach paulle@microsoft.com Arthur Lin yalin@srv.pacbell.com Chris Maeda cmaeda@cs.washington.edu Allison Mankin mankin@cmf.nrl.navy.mil David Marlow dmarlow@relay.nswc.navy.mil Ken Masica masic@es.net Yosi Mass yosi@ubique.co.il Greg Minshall minshall@wc.novell.com Steve Minzer minzer@bellcore.com Dennis Morris morrisd@cc.ims.disa.mil Luc Nguyen luc@bss.com Richard Paine painer@ct.si.cs.boeing.com Joseph Pang pang@bodega.stanford.edu Mark Prior mrp@itd.adelaide.edu.au J. Mark Pullen mpullen@cs.gmu.edu Robert Reschly reschly@brl.mil William Robertson rob@agate.berkeley.edu Francois Robitaille francois.robitaille@crim.ca Martina-Angela Sasse a.sasse@cs.ucl.ac.uk Eve Schooler schooler@isi.edu Dallas Scott scott@fluky.mitre.org Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp Ming-Jye Sheu msheu@vnet.ibm.com Michael Sorsen c02420MS@wuvmd.wustl.edu Michael Speer michael.speer@sun.com Michael St. Johns stjohns@arpa.mil Rodney Thayer rodney@world.std.com Dave Thompson davet@ncsa.uiuc.edu Kevin Thompson kev@gateway.mitre.org Akihiro Tominaga tomy@sfc.wide.ad.jp Jerry Toporek jt@mentat.com Jost Weinmiller jost@prz.tu-berlin.de Abel Weinrib abel@bellcore.com Linda Winkler lwinkler@anl.gov Dan Wood dwood@bbn.com John Wroclawski jtw@lcs.mit.edu Shinichi Yoshida yoshida@sumitomo.com Charles Young Charles.E.Young@att.com