Subject: Re: [AVT] IETF 60 AVT minutes

From: Magnus Westerlund <[email-masked]>
Date: Fri, 03 Sep 2004 12:32:16 +0200

Attached is the final version of the AVT minutes. The only change in 
relation to the previous version are an update in the MPLS Header 
compression section, where the middle paragraph has been updated.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
Audio/Video Transport Working Group Minutes
60th IETF, San Diego

Reported by Magnus Westerlund and Colin Perkins

   The AVT working group met twice during the 60th IETF in San Diego. The
   working group discussed RTP payload formats for several new codecs, a
   new RTP payload format for generic FEC, the RTCP XR MIB, how to frame
   RTP on connection oriented transport, RTCP Extensions for SSM, header
   compression requirements for MPLS, requirements for video codec control,
   the new RTP profile for congestion control with TFRC, the RTP profile
   for extended RTCP feedback, a multiplexing mechanism for RTP using the
   SSRC, a proposed multi-flow RTP-like protocol, and issues with the use
   of MIME types to identify RTP payload formats.

Introduction and Status Update

   Since the last meeting the RTP specification and A/V profile (RFCs 3550
   and 3551) have been advanced to full Internet standards (STD 64 and STD
   65 - the RFC numbers are unchanged). The Secure RTP profile (RFC 3711)
   and the MIME type for 3GPP files (RFC 3839) have been published as RFCs.
   The iLBC codec and payload format (draft-ietf-avt-ilbc-codec-04.txt 
   and draft-ietf-avt-rtp-ilbc-04.txt) are with the RFC Editor awaiting
   publication. 
   
   The following working group drafts are in area director review:
   	draft-ietf-avt-uncomp-video-06.txt
	draft-ietf-avt-text-red-05.txt
   	draft-ietf-avt-rtp-retransmission-09.txt
   	draft-ietf-avt-rtp-dsr-codecs-03.txt
   	draft-ietf-avt-rtp-clearmode-05.txt
   all for eventual publication as Proposed Standard RFCs.

   The TCRTP specification (draft-ietf-avt-tcrtp-07.txt) is being updated
   to address IESG review comments, mostly due to obsolete references but
   also a few technical issues. 
   
   The RTP payload format for T.38 was updated by the ITU-T after we had
   forwarded it's MIME type registration to the IESG for publication. The
   changes altered the MIME parameters, so draft-jones-avt-audio-t38-05.txt
   was returned to the working group for further review. The revised draft
   is in working group last call.

   The RTP payload format for H.264 video (draft-ietf-avt-rtp-h264-10.txt)
   is completing working group last call.

   The RTP payload format for MIDI (draft-ietf-avt-rtp-midi-format-05.txt)
   and associated guidelines (draft-ietf-avt-rtp-midi-guidelines-05.txt)
   have received external review comments from MIDI expert Dominique Fober.
   An update to the draft is in preparation taking into account this review, 
   and is expected to be in good shape for working group last call.

   The update to the RTP payload formats for MPEG 1 and MPEG 2 video 
   (draft-ietf-avt-mpeg1and2-mod-00.txt) has expired: if you have interest
   in pursuing this work please contact the chairs, otherwise the work will
   be dropped. 

   The RTP payload format for Speex (draft-herlein-avt-rtp-speex-00.txt)
   has expired. It appears that there is no longer interest in pursuing
   this work within the group.

   The working group is shepherding MIME types registrations for the 3GPP2 
   file format (draft-garudadri-avt-3gpp2-mime-00.txt), and the MPEG4 file
   format (draft-lim-mpeg4-mime-02.txt) to ensure the drafts are well
   formed, before passing them on for MIME review.

   The payload format for ATRAC (draft-hatanaka-avt-rtp-atrac-family-02.txt) 
   was accepted as a working group item, by the meeting.

   In addition, the following five working group drafts exist but were not 
   discussed at the meeting:
 	draft-ietf-avt-rtp-bv-00.txt 
	draft-ietf-avt-profile-savpf-01.txt
   	draft-ietf-avt-ulp-10.txt, 
   	draft-ietf-avt-rfc2833bis-04.txt 
	draft-ietf-avt-rfc3119bis-02.txt

Charter Update

   There are several milestones on the AVT charter that are late. A charter
   and milestone update is needed, and can be expected in few weeks.

   The first late milestone is requirements for MPLS header compression:
   it was proposed that the draft be held in the working group while the
   protocol was defined to allow requirements to evolve, however after
   discussion with our area director it was decided to send the draft on
   for publication to enable more widespread review of the requirements. 

   The update of AVPF to draft standard will be rescheduled into the
   future, as the proposed standard is not yet published.  The update of
   SRTP can soon be started, but will rescheduled with a more reasonable
   time frame. The work on SAVPF will hopefully complete soon. 

   The working group has a milestone to update the RTP MIB due shortly.
   Alan Clark volunteered to start the work by doing some requirements
   capture, and Dan Romascanu volunteered as a MIB expert to work on this.
   We need to investigate if the RTP MIB has to be updated before the RTCP 
   XR MIB can be progressed. New milestones are needed for both tasks.

   In addition, milestones for the RTP profile for TFRC congestion control
   (previously accepted as a work item) need to be added to the charter.

RTCP XR MIB 
draft-clark-avt-rtpmibv2-01.txt

   Alan Clark presented the updates and status of the RTCP XR MIB. The
   draft has been split from the combined RTP and RTCP XR MIB that was
   presented at the 58th IETF, but the draft has not yet been renamed to
   match the content.

   Alan noted that there is considerable interest in the RTCP XR extensions
   and that this is driving new monitoring applications that affect the RTP
   MIB. Dan Romascanu agreed and noted that application and usage scenarios 
   should be added to the draft. 

   Dan asked what happens when traffic is encrypted: should the monitoring 
   traffic also be encrypted, requiring the probes to share the secret of
   the session? Alan answered that if SRTP is used, a lot of relevant RTP
   header information is left unencrypted, and so he recommends that RTCP
   XR reports are left unencrypted. Dan commented that these considerations
   and limitations should be documented to ensure that these facts are
   understood. Alan replied that there is room for a good trade off between
   manageability and security in the available framework.

   Alan continued explaining that the SNMP syntax will need some more work,
   while the semantics is pretty in good shape. Further work that is needed
   is to extend the structure to allow for several nodes to report on the
   same session. Add event support, and possibility to provide some basic
   aggregated data. 

   There was discussion of taking this draft as a work item, although this
   is conditional on approval from the OPS area directors. It was suggested
   that the RTP MIB be updated in parallel, since the XR MIB depends on new 
   features in RTP since the MIB was last revised; this is appropriate.

   Dan Romascanu volunteered to be MIB advisor for the AVT working group,
   also subject to confirmation by the IESG.

RTP Payload format for Generic FEC-Encoded Time-Sensitive Media
draft-luby-avt-rtp-generic-fec-00.txt

   Ross Finlayson presented a new generic FEC proposal FEC for RTP, based
   on the work done in the Reliable Multicast Transport working group. It
   reuses the FEC building block defined in that group, and applies it to
   RTP traffic (or other types of streaming data).

   There are several technical open issues: 1) it is not clear how source
   blocks in the original RTP stream are arranged so that reconstruction 
   can take place and what (if any) synchronisation markers are needed;
   2) SDP signalling is poorly specified, in particular how the original
   RTP stream and FEC format are signalled; and 3) it is not clear how to
   signal the usage and necessary related information for non-RTP streams
   transported using this framework. Magnus Westerlund, Steve Casner and 
   Colin Perkins commented on these issues, noting also the importance of
   both clearly signalling the format of the content, and of limiting the
   possible content to time-sensitive RTP data. The latter is especially
   important, since the working group has previously been careful to avoid
   defining generic mechanisms, as RTP does not provide for all use cases.

   A procedural issue is the relation of this work to the ongoing FEC work
   within AVT (the ULP and UXP drafts). The ULP draft, updating RFC 2733, 
   is considered independent of this new work due to the separation of the 
   original and protection stream in that format, and because ULP provides
   much simpler FEC options than the new framework.

   The UXP draft, which defines a Reed-Solomon based protection scheme with
   unequal error protection, is similar to this new draft. The protection 
   method defined in the UXP draft could mostly be realised in this generic
   framework by defining a Reed-Solomon building block; indeed there is work
   in the RMT working group to do this. The unequal error protection seems
   more difficult to realise and would need further discussion on the need
   and usefulness. Stephan Wenger supported the continued inclusion of
   unequal error protection, since it is very useful for video encodings
   supporting data partitioning, however Michael Luby noted that it is not
   easy to specify in a format independent manner.

   Stephen Casner asked for clarification on the motivation and advantage
   of specifying a framework rather than continuing the ULP and UXP work.  
   Michael Luby responded that it gives an advantage in selecting the most
   appropriate scheme for a specific application. Colin Perkins and Magnus
   Westerlund commented that this proliferation of FEC schemes is not 
   necessarily a good thing and hinders interoperability.

   It was concluded that there is interest, but more work and discussion 
   is needed before this can be accepted as a working group draft.

RTP Payload Formats for H.261 and H.263 		
draft-ietf-avt-rfc2032-bis-01
draft-ietf-avt-rfc2429-bis-01

   Roni Even outlined the status of these drafts, and current open issues.
   
   One change in this version is to remove the infrequently used H.261 NACK 
   packets in favour of the mechanisms in the RTCP feedback mechanism draft.
   Colin Perkins and Steve Casner supported this, but noted that the draft
   needs to explain how this change affects the backwards compatibility.
   Stephan Wenger expressed concern that there may be implementations of
   some features, of which the group is unaware. How do we ensure that we
   are not removing features that are actually used?  Colin Perkins noted
   that we clearly can't be expected to find all implementations, however
   the important thing is that we must make a sufficient effort to identify
   widely used implementations and discuss the issues with removing any
   feature. Specifically, we should consult at industry interop events and
   with the more popular open source implementations.

   An open issue is that the default mode for H.261 and H.263 is currently 
   unspecified. Roni proposed that the default resolution be set as QCIF,
   Stephan Wenger proposed a default of 30 frames per second. Colin Perkins
   commented that there is need to define a reasonable default values, MIME
   parameters, to specify offer/answer considerations, and to note that
   these where not defined originally. Stephen Casner explained that at the
   time this format was originally defined, there where no negotiated usage
   and fewer optional modes of the codecs.

   Stephan Wenger commented that the video redundancy mode of the H.263+ is
   not used and can be removed. 

   Colin Perkins and Allison Mankin noted that the original payload format 
   for H.263 video (RFC 2090) should be classified as historic. To do this,
   a short draft explaining why implementation is discouraged is needed.
   Roni volunteered to write such a draft.

   It was noted that interoperability statements are needed before these
   drafts can be published as draft standard RFCs. The most likely course
   of action is to cycle these specifications as proposed standards while
   the interop results are collected, then reclassify the formats to draft
   standard.

RTP Payload Format for JPEG 2000 Video Streams
draft-ietf-avt-rtp-jpeg2000-05.txt

   Andrew Leung discussed the RTP payload format for JPEG 200 video. Colin
   Perkins noted that there is IPR covering material contained in the draft
   and asked for clarification on the licensing terms. It is to be hoped
   that these are not more stringent than the terms covering the codec -
   the authors were requested to clarify.

   The major change to this payload format is the removal of the extension
   mechanism, as no clear idea on what to use it exists. A restriction to
   not change the packetization mode within the same RTP session has also
   been introduced.

   The main open issue is if the non-intelligent mode really is necessary:
   is the reduction in sender complexity worth additional complexity in
   receivers and loss of error tolerance? Colin Perkins noted that there
   are likely to be two types of senders: live senders where the payload
   packetization is negligible compared to media encoding, and senders
   which play back stored files where hint tracks tells the sender when 
   to split packets; in neither case is sender complexity an issue. Andrew
   maintained that the desired usage is for thin senders to thin clients.
   Colin requested that the authors do consider this, and may seek guidance
   from other people in the group that may have experience from similar
   systems.

   Otherwise, the authors plan to add further parameters to the MIME type
   definition, for example colour space and prioritization tables, and to
   clarify a number of editorial issues.

RTP Payload Format for VMR-WB audio 			
draft-ietf-avt-rtp-vmr-wb-01.txt

   Sassan Ahmadi noted that the VMR-WB codec is now complete, and reference
   software and the file format are soon to be released. The payload format
   has been updated to include offer/answer considerations, and to clarify 
   use cases when interoperating with AMR-WB. A mode-set parameter is added
   to help negotiation in when gatewaying to circuit switched networks and 
   for AMR-WB interoperation. 

   Magnus Westerlund noted that there is an upcoming VMR-WB codec extension
   that includes more modes. The group needs to decide if the VMR-WB payload 
   format should go forward now, or if it should be delayed to include the
   new modes in the codec extension.

   There was some discussion of file formats with Magnus Westerlund asking
   if it is necessary to define four different file formats with their own 
   magic numbers, or if a single file format can be used, parameterised to
   define the file contents. Sassan expressed the desire to retain the
   existing formats, since they are used by 3GPP2.

   Stephen Casner asked if all the work to provide multi-channel support
   for AMR was really needed? Magnus answered that he didn't know of any
   usage.  Sassan commented that as long as these features do not hurt
   interoperability there is no real harm with them. Stephen responded that
   the more optional features, the more likely interoperability problems
   would occur. Further if there are not two implementations of a feature,
   they will need to be removed when going to draft standard. Sassan
   commented that 3GPP2 is going to use VMR for streaming service, in which
   case stereo may be useful. 

   An update is expected shortly. There is a desire to finish this work
   quickly, to satisfy 3GPP2 dependencies.

RTP Payload Format for AMR-WB+ 
draft-ietf-avt-rtp-amrwbplus-01.txt

   Ari Lakaniemi started with presenting the Nokia IPR statement for RTP
   payload format. Colin Perkins asked if licensing terms for the payload
   format are more restrictive than for the codec. Ari, could not give a
   definitive answer, but was not expecting them to be.

   The draft has been significantly updated, mostly to match changes in the
   codec since February. The TOC has been changed to allow different mode
   indexes and ISFs to be used, the interleaving method has been changed to
   be more flexible by using a timestamp offset, and the MIME type has also
   been updated. Colin Perkins commented that there are several different
   things that are labelled as modes, a clearer terminology would make it
   easier to read and understand the format. 

   The codec is expected to be finalised in the 3GPP SA4 in mid-August, and
   finally approved in mid-September. The authors expect to complete the
   payload format specification shortly after that time.

   Stephen Casner made a general comment that the RTP payload formats are
   getting more complicated, and that this is not necessarily a good trend.
   Colin Perkins requested that authors do pay attention to simplicity and
   clarity of writing; many formats - not only this - are not easy for non
   experts to read.

RTP Payload Format for 3GPP Timed Text
draft-ietf-avt-rtp-3gpp-timed-text-04.txt

   Jose Rey discussed changes to the 3GPP timed text payload format. 

   A key change is that the aggregation and fragmentation rules have been 
   simplified. Colin Perkins reacted positively to these changes, but also
   requested that the draft be updated to mention the benefits of smart 
   fragmentation of modifier boxes, even though it does not require that
   an implementation be able to parse modifiers and perform any such smart
   packetisation (the aim is to encourage high quality implementations to 
   pay attention to application-level-framing, while still allowing dumb
   implementations).

   The draft recommends a 1000 Hz timestamp, but allows other values. There
   was concern expressed that too low values will prevent RTCP from working 
   correctly, and that the draft should explain the issue and recommend not
   to use low clock rates.

   Jose asked if it is appropriate to use screen layout parameters in a
   symmetric manner in multicast sessions? Magnus responded that this would
   depend on the use cases. 

   Colin Perkins commented that the MIME type video/3GPP-timed-text could
   maybe be text/3GPP-timed-text? It is clearly text, however quite fancy
   text, and if that is sufficient reason for registering this under video
   instead was unclear, and should be further discussed. Input into this
   question is solicited (see also the discussion of MIME types later in
   these minutes). 

RTP Payload for Text Conversation
draft-ietf-avt-rfc2793bis-08.txt

   Arnoud van Wijk presented a short status update, as the draft finished
   working group last call the day before the meeting. Comments were mainly
   positive, but a few require minor text changes.

   Colin Perkins outlined a comment received from our area director, that
   it seems inappropriate to include both text/t140 and audio/t140c in the
   same document, since it ties them together to advance at the same rate. 
   The audio/t140c format is significantly less mature then the text format
   and leaving the two formats combined may delay the text/t140 in its
   progress to draft standard. Accordingly, the authors are requested to
   split the draft into two, one for each format. As this is an editorial
   request, it is hopefully not needed to have a new WG last call, unless
   technical content has been changed. 

RTP and MIME types
draft-ietf-avt-text-red-05.txt

   Colin Perkins reported on some discussion regarding registration of MIME
   content types for RTP payload formats. The working group chairs and some 
   area directors and MIME experts had a discussion about the registration
   of MIME types for RTP payload formats, triggered by the submission of
   the text/RED payload format for publication. The expert reviewers found
   a number of problems with the registration, which potentially affect
   other media type registrations for RTP formats.

   Some of the problems had to do with the more stringent requirements for
   registering text media type compared to audio and video types. The text
   formats are expected to be readable without any further processing, for
   compatibility with historical email usage. This requirement is clearly 
   not meet by text/RED. An RTP format like text/t140 is more arguable as
   meeting these requirements, since each datagram actually contains pure
   text. This lead to further discussion on the how we are registering MIME
   types for RTP payload formats, since RFC 2046 doesn't allow registration
   of formats with only limited domains of usage, as we have been doing for
   the last 5 years and is documented in RFC 3555. This issue clearly needs
   to be resolved.

   The resolution is that the MIME registration rules will be changed to
   allow registrations with limited domains of usage (for example, formats
   defined only for transfer using RTP). In addition, complex text formats 
   will be allowed, provided they have restricted domain of applicability,
   and do not affect backwards compatibility for email clients. This will
   require an update of the MIME registration rules, and most likely also
   changes to RFC 3555. These changes will be discussed on the IETF types
   mailing list <[email-masked]>.  We do not expect these changes to
   significantly impact how AVT is doing registration, however some update
   to templates and details is to be expected. As these changes will take
   some time, some of the AVT documents may be delayed, specifically the
   text/RED document (although that draft will be progressed in parallel
   with the rule changes, to reduce the delay as much as possible).

   Stephen Casner noted that the current MIME registrations published in
   RFCs for payload formats will most likely not need to be updated
   immediately, but rather at the point when the formats are updated to
   draft standard.

   The chairs noted that they will now require MIME review of all new RTP
   payload formats prior to working group last call. Expert review should
   be solicited on the <[email-masked]> mailing list, giving at least
   2-weeks review time. This requirement applies to all RTP payload format
   RFCs produced; either new or updating existing formats, no matter what
   MIME top-level types they are to be registered under. MIME reviews were
   previously solicited by the IESG as part of their document review, this 
   change in procedure simply means that it happens earlier, and is more
   visible to the working group.

Framing RTP and RTCP over Connection-Oriented Transport	
draft-ietf-avt-rtp-framing-contrans-03.txt

   Colin Perkins outlined the status of the connection oriented framing
   draft for John Lazzaro, who was unable to attend. This draft has been
   updated to match the changes in draft-ietf-mmusic-sdp-comedia-08.txt,
   but is otherwise stable. The only open issue is to decide if the draft
   should also define a mapping over secure connection oriented transport
   (e.g. over TLS). This was discussed in MMUSIC, with the conclusion that
   this is potentially useful, but that there is insufficient interest to
   complete the work at this time. Colin reported this result to the group, 
   noting that support for secure connection oriented transport would be
   dropped unless there is a volunteer to complete the work.

RTCP Extensions for SSM Sessions with Unicast Feedback
draft-ietf-avt-rtcpssm-07.txt

   Joerg Ott presented the revision of the draft, which clarifies the usage
   of buckets. A lot of editorial issues have been resolved. In addition it
   has been clarified what to do with the distribution source: this is now
   defined so that it works as an RTP receiver with its own SSRC, making it
   possible to have separation between sources and the distribution entity. 
   The drawback is minor, as it will use some more bandwidth with its own
   RTCP receiver report. Colin Perkins commented that this new concept is
   not completely clear in the draft, and a few examples could help. Joerg
   also noted that comments have been received from Magnus Westerlund, and
   will be addressed in the next revision. It is believed the protocol is 
   now stable, and that the draft will be complete once these comments are
   incorporated.

RTP Profile for RTCP-based Feedback
draft-ietf-avt-rtcp-feedback-09.txt
draft-burmeister-avt-rtcp-feedback-sim-06.txt

   Joerg Ott continued by presenting the changes that have been made to the
   AVPF profile to address comments received as a result of IESG review. Two 
   technical changes have been made: 1) removed any hints that the feedback,
   as currently defined, can be used for congestion control; and 2) the
   generic ACK message has been removed, since it could be misunderstood to
   be part of reliable transport mechanism. Applications that need positive 
   acknowledge can define media specific ACKs for specific use cases. 

   Stephen Casner commented that the removal of the H.261 NACK message in
   the latest revision to that format is based on the belief that the AVPF
   profile will provide that service, but no codec specific message is
   defined. Joerg responded that it is intended that the generic NACK
   message present in the draft will be used. The bit fields of it are even
   modelled after the H.261 (RFC 2042) definition. Stephan Wenger commented
   that there is also a video specific NACK message that allows one to NACK
   specific macro blocks. 

   A few minor issues were missed during the update of the draft (see the
   IESG review comments). The draft will be updated to address these, and
   then will be go back to IESG for approval. 

RTP Profile for TCP Friendly Rate Control
draft-ietf-avt-tfrc-profile-01.txt

   Ladan Gharai outlined the changes in the latest RTP profile for TFRC,
   and summarised open issues.

   This version of the draft introduces a 16 bit quad RTT counter instead 
   of a 32 bit timestamp, to reduce the size of the profile extensions to
   the RTP header. Stephen Casner commented that it was intended that RTP
   header should be in units of 32 bits, and would recommend that this is
   maintained in the TFRC profile, making it difficult to use a 16 bit RTT
   counter. Colin Perkins suggested that using a send timestamp would allow 
   for correct jitter calculations and better buffer management, and solve
   an oft-noted limitation of RTP. This desire to reintroduce the sending
   timestamp was also supported by Steve Casner and Magnus Westerlund.

   Another issue is the size of the RTCP packets, since the minimum size of
   the RTCP feedback is 84 bytes.  When combined with a TFRC requirement to
   send one message per RTT (or one per packet, if sending at less than one
   packet per RTT) this can result in high feedback bandwidth. Indeed, if
   one adheres to the RTCP timing rules, there is only a limited range of
   RTT/bandwidth combinations that support TFRC feedback (see graph in the
   presentation slides). There are two options to increase the feasible use
   domain: allow feedback more often, or reduce the size of the feedback
   packets.

   There was some discussion of the amount of feedback generated, and how
   this compares to the feedback in a TCP connection, started when Stephen 
   Casner raised the concern that allowing frequent RTCP feedback could be 
   viewed as overly aggressive. This is possible, but Ladan explained that 
   this is a feature of TFRC, which sends feedback packets independently of
   the forward rate, unlike TCP where ACKs are clocked by forward traffic. 
   In addition, RTCP feedback packets used in this profile are considerably 
   larger than TCP ACKs, and cannot be piggybacked onto data packets. 

   Stephan Wenger commented that for higher video rates the feedback
   traffic packet sizes will be an order of magnitude smaller then the
   payload: wouldn't it make sense to specify a restriction, that the
   feedback traffic must not be bigger than some fraction of the forward
   traffic?  This would limit the usage from very low RTTs or for small
   forward packets. Stephen Casner commented that this limitation, which
   prevents it from being used in certain combinations, is not really
   workable.  Further one can't make assumptions that the forward and
   feedback path has the same bandwidth availability, thus comparing
   forward and backward packet sizes and rates are not a valid operation. 

   Discussion then moved onto the option of reducing the size of feedback
   messages by allowing them to be sent as non-compound RTCP packets.
   Stephan Wenger commented that this profile seems mostly useful for 
   high bit-rate usage and in those cases, for any network with more than a
   single hop, the RTT will be large enough that the feedback will be order
   of magnitudes less then the forward traffic. To keep things simple it
   would be preferable not to introduce different processing rules for
   feedback packets versus other RTCP packet types. Stephen Casner also
   commented that with the intention of going to experimental, it seems
   unnecessary to do optimisations until we know that this actually works
   and have plans to go beyond an experimental status. 

   Another question is if this profile needing to share the static payload
   type space with the RTP/AVP profile, or could the static definitions be 
   removed? 

   Finally, Colin Perkins asked if this profile should include security by
   default, rather than defining a non-secure version now and later an SRTP
   based version as yet another profile. Feedback from SRTP experts was
   solicited.

Requirements for transport of video control commands
draft-basso-avt-videoconreq-01.txt

   Andrea Basso presented the current status of the video codec control 
   requirements work. There have been a number of clarifications in the
   latest draft, videofastupadteGOB has been removed, and alignment with
   H.241 has been improved. It is hoped that the set of codec control
   commands is now final, so we can move rapidly ahead with requirements
   for their transport.

   Stephan Wenger raised the issues of congestion control and reliability 
   for codec control commands, noting that he is concerned that this work
   could develop into a reliable signalling protocol. The chairs reassured 
   him that the codec under control would be required to act in accordance
   with congestion control, and that reliable signalling protocols would
   not be developed in AVT. 

   Christer Holmberg commented that there is no need to finalise the
   requirements document at this time, and to instead let is evolve with
   the design work. Andrea responded that although requirements tend to
   evolve, there is significant experience in this area from other
   standards and conferencing applications.  Colin Perkins commented that
   there has been significant discussion earlier, and that we should start
   with what can currently be agreed on. In the future the list of commands
   can be extended if needed. 

   Roni Even commented that some of the requirements can be solved by
   existing protocols, and the draft should reflect this. Andrea, responded
   that this is good comment, and should be clarified in the next revision. 

   Stephen Casner commented that earlier in this discussion there where
   indications that some of the commands would fit RTCP, why others would
   clearly not: is it the intention to try to find a common solution for
   all of them? No, it appears rather clear that some can be implemented 
   on existing protocols, and some may need its own protocol. Roni Even
   commented that the direction of the commands is important and effect 
   how it would work.

   The plan is to finalise the requirements, so that we can figure out the
   charter item for AVT, or any other WGs. 

Header Compression over MPLS
draft-ietf-avt-hc-mpls-reqs-02.txt
draft-ash-avt-ecrtp-over-mpls-protocol-01.txt

   Jerry Ash outlined the current status of the requirements draft. This
   has completed working group last call on the mailing list, with the
   only open issue being if it should be sent to the IESG for publication
   now, or kept in the working group for possible update as solutions are
   developed. After discussion with the area director, it was agreed to
   send the draft forward for publication, after minor editorial work.

   Jerry also presented the updates to the solutions draft. Colin 
   Perkins commented that this draft does not tell you how it actually 
   addresses the requirements, and suggested that this be clarified in 
   the next version. Magnus Westerlund asked why it is necessary to have 
   a separate signalling protocol to negotiate the session context 
   identifiers (SCID) between ingress and egress nodes. Jerry answered 
   that in some cases several ingress nodes initiate flows to a given 
   egress node, and since the MPLS labels at the egress node are not 
   necessarily unique for each ingress node, the SCIDs are needed to 
   uniquely identify each flow. Someone asked if there is any connection 
   between the SIP call IDs and the SCIDs. Jerry answered that they are 
   independent, but related to the actual
   streams in the call. 

   The chairs noted that we need to recharter to find an appropriate long
   term home for the protocol work. This will be discussed with the area
   directors and other interested parties, and we will report back to the
   mailing list.

A Multiplexing Mechanism for RTP
draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt

   Jonathan Rosenberg presented an initial proposal on how to deal with the
   problem of firewall traversal for RTP, using SSRC multiplexing on well
   known ports, one per media type. Comments received on the mailing list
   indicated that this proposal was not liked, but Jonathan hoped that
   presentation would provide some further motivation and allow discussion
   on the issues. 

   Carsten Bormann asked why not use a different IP protocol number for
   RTP (much as Jonathan has previously proposed), with the new protocol
   number being used to determine the intended use of a packet. Minutes 
   of AVT at the 41st IETF meeting contain some reasons why this is not a
   favoured solution; it was also commented that most firewalls do not
   support UDP-Lite which uses a similar technique.

   Stephen Casner noted that using a well-known port doesn't provide any
   significant security benefit, since other applications can use the port.
   The security gain comes if only trusted application can use this port,
   which is not likely to be true. Jon Peterson noted this is the same as
   any firewall that uses ports to identify services. Flemming Andreasen,
   Magnus Westerlund and Dave Oran made similar points, noting that this
   proposal only addresses the access control list type of security, and
   that firewalls often contain additional mechanisms to impose more
   complex policies than can be expressed in terms of well-known media
   ports.
 
   Dave Oran also wondered if using well-known ports would not invite more
   attacks since it would make it easier to identify the media services?
   Jonathan answered that this is dual edged sword, since it also allows
   one to turn off all other services on that port, rather than worrying
   which dynamic port media services are using. It was noted that this
   rapidly leads to the idea of a hybrid solution, where inbound firewall
   holes are opened only when there is an active session (there is a clear
   temptation to colocate a STUN server with the firewall, and use this to
   control policy, although Jon Peterson noted that the security properties
   of STUN are not sufficient for this).

   There was some discussion on the appropriateness of SSRC multiplexing,
   led by Magnus Westerlund. RFC 3550 identifies some reasons why this is 
   not a good idea - and those are addressed in the draft - but there are
   others: how to signal valid SSRCs in dynamic sessions (e.g. in an XCON
   session with media mixing); and how to support SRTP without compromising
   security. None of these are insurmountable, but the signalling is not
   simple, and is complicated by the installed base on unaware systems.

   Colin Perkins concluded by noting that there is clearly an interest in
   this area, however many doubt that this is the right solution. It would
   be best to clarify the problem that one tries to solve, to gain a better
   understanding of the solution space. 

MRTP: A Multi-Flow Real-time Transport Protocol
draft-narayanan-mrtp-00.txt

   Sathya Narayanan presented a new proposal that intended for information
   and discussion by the IETF. The proposal has no official status and any
   progression is subject to the normal procedures of getting it chartered
   as a working group item somewhere, or conditional on the outcome of a
   BOF to start a new effort. 

   Jonathan Rosenberg questioned the benefits of MRTP compared to existing
   RTP mechanisms used along with source routing to select a network path,
   and with a smart implementation to handle striping across streams, and
   reconstruction of the result. Stephen Casner commented that RTP already
   has a layered concept, and that RTP implementations are often tightly
   linked with their applications: the normal kernel interface is often
   UDP. Due to this it should be considered if this is an API question,
   where a different API to the application could in fact encompass the
   necessary functionality.  

   There was some discussion regarding the ability to choose source routes
   for packets in existing networks, with Dave Oran noting that this is
   often not possible. This will restrict the applicability of MRTP to
   limited classes of (ad-hoc?) networks.

   Allison Mankin noted that this is not inherently a real-time protocol:
   the initial drivers have been real-time applications, but the main new
   feature is that the protocol takes multi-path into consideration.

   Sathya asked if there is interest to provide an application with an
   end-to-end transport service that handle multi-path with fragmentation
   and per flow and session feedback. Stephen Casner commented that it
   might be that applications actually like to have more influence of how
   the channels are utilised. Sathya commented that the MRTP proposal
   allows for both a default data partitioning and application specific
   ones.

   Colin Perkins concluded that there seem to be some interest, however it
   has clearly wider scope than this working group. Especially as there
   where some discussion on generalising the concept. Colin proposed that 
   a way forward could be to bring it up on the TSVWG mailing list. 

Management of RTP related functionality

   Alan Clark expressed the opinion that market research has found one of
   the major reasons why VoIP has not been deployed in enterprises, after
   security, is the lack of management and monitoring tools. The group
   should pay more attention to performance monitoring, perhaps going so
   far as to require new drafts to contain a section that explains how to
   do this? Stephen Casner commented that this would be desirable, however 
   he worried that our record with other required sections (e.g. security 
   and congestion control) is less than perfect. This is an indication that
   we probably would not do this as well as might be desired. Colin Perkins 
   concluded that the group should consider this as best as possible when
   creating new specifications.

				   - * -

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Ladan Gharai <[email-masked]>
Date: Tue, 7 Sep 2004 15:41:14 -0400

Hi Randell:

Thank you for the feedback. please see inline.

Ladan

On Sep 1, 2004, at 2:12 PM, Randell Jesup wrote:

> Magnus Westerlund <[email-masked]> writes:
>         TCP-friendly feedback in RTP (especially using current RTCP) 
> seems
> to have some serious issues with reverse-path bandwidth costs.  Unlike 
> TCP
> the acks are large and can't be piggybacked.  While TFRC is supposed to
> exist to "play nice" with other TCP and RTP streams (unlike raw RTP), 
> the
> additional reverse-channel bandwidth could conversely make things worse
> (overall), especially on asymmetric links or in two-way communication.

the reverse-path bandwidth costs is particularly problematic for low 
bandwidth flows and small RTTs (say <1Mbps with an RTT of 10 ms). This 
is currently an open issue and is discussed in latest version of the 
draft: draft-ietf-avt-tfrc-profile-02.txt (sections 8 and 9), 
specifically in section 9:

       o  RFC 3550 recommends that the percentage of control traffic
           relative to data, be fixed at 5%.  For some flows, the 
feedback
           traffic for AVPCC may exceed this recommendation.  Should 
AVPCC
           mandate a strict limit on the percentage of control traffic
           bandwidth?  At what point is feedback too much feedback?
           (i.e., does it make sense for control traffic be 50% of data
           traffic?)

           What are the implications of this limit, in terms of 
congestion
           control, for flows which cannot abide by the limit?  This is
           particularly the case for low bandwidth flows, under 1 Mbps, 
and
           RTTs of say less than 10 ms.

there are two obvious ways to reduce the reverse path bandwidth: (1) 
sending  smaller feedback packets; or (2) reducing the frequency of 
feedback packets. The second option would require investigating the 
impact of reduced feedback on  TFRC dynamics.

>
>         For one-way communication, piggyback isn't feasible of course, 
> but
> TCP keeps ack sizes and bandwidth down compared to TFRC & RTCP.  For
> two-way communication though it might be possible to piggyback the
> information in the RTP packets, at least a fair bit of the time, 
> perhaps

   piggybacking was never really considered because it is complicated to 
satisfy both the feedback timing requirements and send packet rate (on 
the reverse path). And at any rate the receiver must send the RTCP 
feedback.

> all the time (for steady packet-rate streams).  From the discussion it
> sounds like there's a possibility (argued over) that we may have 16 
> bits in
> the TFRC RTP header to use if we don't use 32-bit timestamps; those 
> could
> be used in some cases to reduce or eliminate the need for RTCP messages
> just to close the RTT loop.

   the latest version of the draft uses 32 bit send timestamps as there 
was consensus that they are generally useful, in particular for  jitter 
calculations.
>         Quite true, in fact in many non-corporate/university situations
> (DSL, cable, wireless, satellite) this is very much the case.  Even
> symmetric bandwidth is often very asymmetrically used.
>
>         Doesn't this involve some updating of RTP/RTCP stacks to make 
> use
> of this anyways?  And I don't see how not _requiring_ sender/receiver 
> reports
> and SDES items in every RTCP packet noticably complicates the 
> processing of
> RTCP.  Existing uses aren't affected because they're not doing TFRC 
> (though
> I wouldn't personally mind it spreading - for example it would reduce 
> the
> overhead for early RTCP feedback messages, doubly so if you're trying 
> to
> do ACKs with them.)

   I guess the difference would be that an RTCP packet for the AVPCC 
profile with the RR extensions could still be processed by an AVP 
stack? even though no congestion control would take place and the RR 
extensions would simply be ignored.

>
>         (Yes, I know ACK was just removed because people were worried 
> it
> would be perceived as part of a reliable delivery method (or something 
> list
> that).  Since I was hoping to use ACK I'll have to use it as a
> "non-standard" message.  There are significant uses of ACK in error
> recovery, especially when combined with NACK.  NACK alone is too 
> limited
> for many situations.)
>
>
>         Just a few ideas/comments from a kibitzer/implementer.
>
> -- 
> Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
> [email-masked]
>
>

---

From: Randell Jesup <[email-masked]>
Date: 08 Sep 2004 10:53:38 -0400

Ladan Gharai <[email-masked]> writes:
>>         TCP-friendly feedback in RTP (especially using current RTCP) seems
>> to have some serious issues with reverse-path bandwidth costs.  Unlike TCP
>> exist to "play nice" with other TCP and RTP streams (unlike raw RTP), the
>bandwidth flows and small RTTs (say <1Mbps with an RTT of 10 ms). This is
>currently an open issue and is discussed in latest version of the draft:
>draft-ietf-avt-tfrc-profile-02.txt (sections 8 and 9), specifically in
>section 9:

        And especially bad for streams in the 10's or low 100's of Kbps
with relatively low RTT's (10's to 100ish).

>           relative to data, be fixed at 5%.  For some flows, the feedback
>           traffic for AVPCC may exceed this recommendation.  Should AVPCC
>           What are the implications of this limit, in terms of congestion
>           particularly the case for low bandwidth flows, under 1 Mbps, and
>feedback packets. The second option would require investigating the impact
>of reduced feedback on  TFRC dynamics.

        Or 3) in unicast (of course) 2-way streams, use a small number of
bytes in the reverse path data stream.  This could allow you to push 
TCP-friendly rate control down to almost any bandwidth and RTT.  Note that
VoIP and videophone streams are in this range, with RTT's in the low 10's to
150ish ms, and data bandwidths of 8-300Kbps (total BW of say 20-350K).

        Targeting high-bitrate (1Mbps+) streams is all well and good, but
as things like VoIP increase in use the number of low and
moderate-bandwidth RTP/UDP streams on intermediate links increases
dramatically, making rate control all the more important for those streams.
You may have dozens or hundreds of these streams sharing a link (with a
fair bit of TCP data traffic, but the ratio of streams to TCP traffic will
be changing due to VoIP/etc).

>>         For one-way communication, piggyback isn't feasible of course, but
>> information in the RTP packets, at least a fair bit of the time, perhaps
>
>satisfy both the feedback timing requirements and send packet rate (on the
>reverse path). And at any rate the receiver must send the RTCP feedback.

        Yes, but the RTCP is rarely needed to be frequent with exception of
something like this.  The "complication" here would be to piggyback it on
a data packet if the data packet goes out within some period of time of 
when the packet being acked was received; otherwise an RTCP (or other)
packet would need to be sent.  (For example, in variable-frame-rate
transmission or if there's silence suppression, or the equivalent.)
Without understanding better the algorithm here I can't comment on whether
this would work, but fundamentally it's not much different than scheduling
RTCP send-times.

>>>   Discussion then moved onto the option of reducing the size of
>>>   feedback messages by allowing them to be sent as non-compound RTCP
>>>   packets.  Stephan Wenger commented that this profile seems mostly
>>>   useful for high bit-rate usage and in those cases, for any network
>>>   with more than a single hop, the RTT will be large enough that the
>>>   feedback will be order of magnitudes less then the forward
>>>   traffic. To keep things simple it would be preferable not to
>>>   introduce different processing rules for feedback packets versus
>>>   other RTCP packet types. Stephen Casner also commented that with the
>>>   intention of going to experimental, it seems unnecessary to do
>>>   optimisations until we know that this actually works and have plans
>>>   to go beyond an experimental status.
>>
>>         Doesn't this involve some updating of RTP/RTCP stacks to make use
>> reports and SDES items in every RTCP packet noticably complicates the
>> processing of RTCP.  Existing uses aren't affected because they're not
>> doing TFRC (though I wouldn't personally mind it spreading - for example
>> it would reduce the overhead for early RTCP feedback messages, doubly so
>> if you're trying to do ACKs with them.)
>
>profile with the RR extensions could still be processed by an AVP stack?
>even though no congestion control would take place and the RR extensions
>would simply be ignored.

        Since you're adding an RTT field to the RTP header, you can't talk
directly to an AVP (or any general non-AVPCC RTP) stack anyways.  There is
a length field so the RTCP extensions to RR/SR should be ignored
("profile-specific extensions" as mentioned in RFC3550).

Also, according to RFC3550 you've stolen a bit from the payload type field
for "R" in RTP headers:

RFC 3550:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

TFRC draft:
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |V=2|P|X|  CC   |M|R|    PT      |      sequence number         |

Also, it isn't even clear whether you stole it from PT or sequence number
because your divider is in the "middle" of a bit.  If it's stolen from PT
you'll need to limit the payload values to <64 on a AVPCC media stream.

This 'R' bit and the RTP header is a serious inter-operation issue from
what I can see.  Perhaps I'm missing something...