Last Modified: 2003-10-07
- to advance the main RTP specification and RTP Profile for Audio and Video Conferences with Minimal Control for publication as full Internet Standards
- to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified.
- to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering.
- to complete the forward error correction work in the ULP and UXP payload formats
- to extend RTP to work with Source-Specific Multicast sessions with unicast feedback
- to provide a framing mechanism for RTP over TCP and TLS
- to review the applicability of Compressed RTP operation on MPLS networks, developing extensions as necessary
- to develop a new RTP profile as the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF)
The group will also coordinate with the DCCP working group to ensure that RTP can be efficiently transported over DCCP.
The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard.
The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate.
Oct 03 | Review DCCP including prototypes and API; feedback to DCCP WG | |
Nov 03 | Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG | |
Dec 03 | Submit iLBC payload format for Proposed Standard | |
Dec 03 | Submit iLBC codec specification for Experimental | |
Dec 03 | Submit ULP Payload Format for Proposed Standard | |
Dec 03 | Submit RTCP/SSM draft for Proposed Standard | |
Dec 03 | Submit UXP Payload Format for Proposed Standard | |
Jan 04 | Advance RTP specification and A/V profile to Full Standard | |
Mar 04 | Finish requirements for ECRTP over MPLS; recharter for subsequent work | |
Mar 04 | Identify payload formats to classify as Historic | |
Mar 04 | Submit Framing of RTP for TCP and TLS for Proposed Standard | |
Jul 04 | Begin update of RTP/AVPF profile for Draft Standard RFC | |
Jul 04 | Begin update of SRTP profile for Draft Standard RFC | |
Jul 04 | Submit RTP/SAVPF profile for Proposed Standard | |
Aug 04 | Consider update of RTP MIB | |
Nov 04 | Collect RTP/AVPF implementation reports | |
Nov 04 | Collect SRTP implementation reports | |
Mar 05 | Submit RTP/AVPF for Draft Standard | |
Mar 05 | Submit SRTP for Draft Standard |
RFC | Status | Title |
---|---|---|
RFC1889 | PS | RTP: A Transport Protocol for Real-Time Applications |
RFC1890 | PS | RTP Profile for Audio and Video Conferences with Minimal Control |
RFC2035 | PS | RTP Payload Format for JPEG-compressed Video |
RFC2032 | PS | RTP payload format for H.261 video streams |
RFC2038 | PS | RTP Payload Format for MPEG1/MPEG2 Video |
RFC2029 | PS | RTP Payload Format of Sun's CellB Video Encoding |
RFC2190 | PS | RTP Payload Format for H.263 Video Streams |
RFC2198 | PS | RTP Payload for Redundant Audio Data |
RFC2250 | PS | RTP Payload Format for MPEG1/MPEG2 Video |
RFC2343 | E | RTP Payload Format for Bundled MPEG |
RFC2354 | I | Options for Repair of Streaming Media |
RFC2429 | PS | RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) |
RFC2431 | PS | RTP Payload Format for BT.656 Video Encoding |
RFC2435 | PS | RTP Payload Format for JPEG-compressed Video |
RFC2508 | PS | Compressing IP/UDP/RTP Headers for Low-Speed Serial Links |
RFC2733 | PS | An RTP Payload Format for Generic Forward Error Correction |
RFC2736 | BCP | Guidelines for Writers of RTP Payload Format Specifications |
RFC2762 | E | Sampling of the Group Membership in RTP |
RFC2793 | PS | RTP Payload for Text Conversation |
RFC2833 | PS | RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals |
RFC2862 | PS | RTP Payload Format for Real-Time Pointers |
RFC2959 | PS | Real-Time Transport Protocol Management Information Base |
RFC3009 | PS | Registration of parityfec MIME types |
RFC3016 | PS | RTP payload format for MPEG-4 Audio/Visual streams |
RFC3047 | PS | RTP Payload Format for ITU-T Recommendation G.722.1 |
RFC3119 | PS | A More Loss-Tolerant RTP Payload Format for MP3 Audio |
RFC3158 | I | RTP Testing Strategies |
RFC3189 | PS | RTP Payload Format for DV Format Video |
RFC3190 | PS | RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio |
RFC3267 | PS | RTP payload format and file storage format for the Adoptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs |
RFC3389 | PS | RTP Payload for Comfort Noise |
RFC3497 | PS | RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video |
RFC3550 | DS | RTP: A Transport Protocol for Real-Time Applications |
RFC3551 | DS | RTP Profile for Audio and Video Conferences with Minimal Control |
RFC3555 | PS | MIME Type Registration of RTP Payload Formats |
RFC3556 | PS | Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth |
RFC3557 | PS | RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding |
RFC3558 | PS | RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV |
RFC3545 | PS | Enhanced Compressed RTP (CRTP) for links with High Delay,Packet Loss and Reordering |
RFC3611 | Standard | RTP Control Protocol Extended Reports (RTCP XR) |
.Audio/Video Transport Working Group Minutes Reported by Magnus Westerlund and Colin Perkins The AVT working group met for two sessions during the 58th IETF. During these sessions the group discussed RTP considerations for DCCP, the SSM RTCP Extension, VoIP header compression over multiple hops and MPLS, one new RTP profile, video parameter and command signalling, and numerous RTP payload formats. Introduction and document status The working group has published 8 RFCs since the previous IETF meeting: RFC 3545, 3550, 3551, 3555, 3556, 3557, 3558, and 3611. There is also a document (draft-ietf-avt-mpeg4-simple-08.txt) in the RFC editors queue, and the RTP profile for security (draft-ietf-srtp-09.txt) was approved just prior to the meeting and will go on to the RFC editor. There are four working group drafts waiting for Area Director review, namely: draft-ietf-avt-rtp-retransmission-09.txt, draft-ietf-avt-tcrtp-07.txt, draft-ietf-avt-rtcp-feedback-07.txt and draft-burmeister-avt -rtcp-feedback-sim-02.txt. The working group has a number of documents, both working group and individual submissions that are not otherwise to be discussed in the meeting, and were instead reported on by the chairs: - Draft-ietf-avt-rtp-clearmode-03.txt and draft-jones-avt-audio-t38-01.txt are basically ready for working group last call. They have both received editorial comments, so after an update they will go to WG last call. Any comments was encouraged to be sent in before the end of the meeting week. - Tom Taylor is working on updating draft-ietf-avt-RFC2833bis-03.txt under Henning Schulzrinne's supervision. The document will receive an editorial reorganisation due to its growth from DTMF tone draft to a general tone signalling draft. There were also substantial comments raised by Tom Taylor and Andreasen Flemming that need to be addressed in the next version. An update is expected within a few months. - draft-ietf-avt-uxp-06.txt has been stalled for quite a while due to its connection with the ULP draft. It has been established that they are different enough to be able to progress on their own. The UXP draft seems to be fundamentally sound, however it requires significant editorial work before it can advance. - draft-kerr-avt-vorbis-rtp-03.txt has received minor updates since last meeting, and a more major update are expected. - draft-herlein-speex-rtp-profile-01.txt, and draft-ramalho-rgl-rtpformat-02.txt are both awaiting updates. - draft-ietf-avt-mpeg1and2-mod-00.txt is an update to the RTP payload format for MPEG1 and 2 video (RFC 2250) intended to be published as a draft standard RFC. Review is solicited. - draft-chen-rtp-bv-00.txt: there was a mix-up with the deadlines and submission, and two new versions can be expected directly after the meeting. Review is solicited. - draft-hatanaka-avt-rtp-atracx-03.txt has recently been discussed and seems to be needing some redesign. Document updates on behalf of the authors Several authors were not able to attend, but instead requested that the chairs present a brief update on their draft: - draft-ietf-avt-ulp-08.txt has been updated, with the main change being to move a number of fields from the RTP header to the payload section, making the mask field only 16 bits. This has been addressed by using a flag bit to indicate 16 or 48 bits of mask field. The draft is expected to advance rather quickly. - draft-ietf-avt-rtp-jpeg2000-04.txt has been updated with support for interlaced images. Other updates are text clarification, MIME and SDP section, and security consideration. The authors has request WG last call. Colin Perkins has at least some editorial comments, but the document can be expected to progress rather quickly. - draft-ietf-avt-midi-rtp-00.txt and draft-ietf-avt-midi-guidelines- 00.txt, the updated versions contains mostly editorial changes and have been renamed and republished as working group documents. John Lazarro plans to ensure he has finished his implementation before requesting working group last call to catch any final bugs in the specification. However, he expects to have finished this by the end of the year. - draft-lazzaro-avt-rtp-framing-contrans-02.txt, contains definition of framing of RTP and RTCP into connection oriented transport, intended to be interoperable with the definitions that were in RFC 1889. It was asked if we should continue this path, or develop a different protocol allowing for multiplexing of RTP and RTCP on the same TCP connection? Please review the draft and send any comments on this issue to the list. RTP payload format for AMR-WB+ <draft-sjoberg-avt-rtp-amrwbplus-00.txt > Ari Lakaniemi presented an introduction to AMR-WB+ codec and proposed RTP payload format. The codec specification is not yet finished, but is expected to be ready by March. The payload format is based on the payload format for AMR and AMR-WB (RFC 3267). The changes are removal of bandwidth-efficient mode, a RTP timestamp rate of 96 kHz, and the removal of the payload level multi-channel functionality. Colin Perkins commented that multi-channel usage has previously been signalled out of band, however AMR-WB+ uses a mode field to indicate if frames contains mono or stereo content. Magnus Westerlund commented that any future signalling in this area probably needs to be more general, since the ATRAC-X payload format proposes a similar thing. Colin Perkins had a further comment that there are interoperability considerations since AMR-WB+ is a superset of AMR-WB. If an AMR-WB+ capable end-point does not also offer AMR-WB in its initial offers, an AMR-WB only end-point would fail to understand that they should be able to communicate. The draft needs to address this concern. Allison Mankin, stressed that this work as being related to incomplete work in 3GPP, and may need technical changes later to match changes in the codec. It was further noticed that this payload format will not advance until the 3GPP AMR-WB+ codec specification is frozen. The future work from the authors will be to track the codec development to keep the payload format aligned with the codec. Comments about the design choices so far are solicited. The draft was accepted as an AVT work item in principle, subject to resolution of the signalling issues . RTP payload format for VMR-WB <draft-ahmadi-avt-rtp-vmr-wb-00.txt> Sassan Ahmadi made an overview of the Variable Multi-Rate Wide-Band speech codec which is an selected 3GPP2 CDMA 2000 codec since April 2003. It contains a interoperability mode that uses some modes identical to AMR-WB to enable interoperability with AMR-WB only end-points. This will allow for better quality and better efficiency by removing the need for transcoding. There is a clear interest for having two different circuit switched cellular networks using the same or interoperable speech codec to be connected with an IP network. The VMR-WB payload format is based on RFC3267 payload format. Most of the RFC 3267 functionality is maintained, except for anything related to Unequal Error Protection (UEP), as the speech encoder is design to work over network with equal error protection of the encoded speech bits. The main issue raised for both AMR-WB+ and VMR-WB formats is that they are super-sets of the AMR-WB codec. This may result in three MIME types existing for the same codec. How this signalling problem is resolved to avoid interoperability problems needs to be considered before either draft goes forward. Thomas Zeng asked if it is possible to come up with a single payload format that would work for all the three codecs (AMR, AMR-WB, AMR-WB+ and VMR-WB) to reduce implementation complexity. It could be desirable to have such a solution and it should be considered. Sassan requested that the work be accepted as an AVT work item. Colin Perkins commented that he has no principal problems of accepting this as a work item, as long as it is guaranteed that the codecs will be accepted, and the signalling issue is resolved. Sassan answered that the codec is currently undergoing characterisation tests and that final specification will be available in April 2004. RTP payload formats for ETSI DSR codecs <draft-ietf-avt-dsr-es202050-01.txt> <draft-xie-avt-xdsr-es202211-00.txt> <draft-xie-avt-xadsr-es202212-00.txt> Qiaobing Xie discussed the three ETSI DSR codecs without an RTP payload format so far. He outlined how that relate to the DSR codec that has a payload format in RFC 3557. From an RTP payload format the difference is two possible frame lengths and their internal frame definition that need to be indicated through signalling. It was previously suggested that the three drafts should be merged into a single document, as they are very similar. This question was asked to the group, but no comments were received. iLBC codec and RTP payload format <draft-ietf-avt-ilbc-codec-03> <draft-ietf-avt-rtp-ilbc-03> Alan Duric presented the most recent changes to the drafts. See the presentation slides for the list of changes. Alan requested that working group last call be issued for both drafts. Colin Perkins commented that beside some nits, the only substantial comment regards two statements in the both drafts, regarding the free-ware nature of iLBC and that CableLabs intends to include it in one of its specifications, since these conflict with IETF IPR disclosure rules (they should be in an IPR statement, not in the draft). As soon an updated versions are available it will be last called. The codec is intended to go to Experimental status, and the payload format for standards track as proposed. Allison Mankin promised to provide a boilerplate for the codec draft that specifies the intention of going to informational when more experience has been gathered regarding the codec. RTP payload format for conversational text <draft-hellstrom-avt-rfc2793bis-02.txt> Gunnar Hellström presented this update to RFC 2793, which both updates the payload format, and also defines a new format intended for gateway usage allowing for audio and text multiplexing in the same RTP session. There where some discussion regarding the RTP profile independency of the format, to avoid confusion. The registration of "text/red" should also be moved into a separate document. The new format for gateway use is signalled by the "audio/t140" MIME type with various parameters. It was noted that the signalled rate in characters-per-second cannot be guaranteed on the receiver side due to network jitter. The draft defines an internal block sequence number in addition to the RTP sequence number. Colin Perkins commented that when switching from audio to text, it is possible for the last packet of audio to be lost, but not detected. Henning Schulzrinne noted that this can be addressed by using RFC 2198 redundancy to lower that risk as done in RFC 2833. A further comment is that audio/t140 is capable of handling any of the redundancy mechanism, so both RFC 2733 and RFC 2198 can be used. Thus there is probably no need to mention either of them explicitly. Magnus Westerlund commented that the usage of RFC 2198 is quite restricted due to the small maximum timestamp offset for a redundancy packet (14 bits), resulting in that a 16kHz timestamp rate will only allow redundant block from the last second. Gunnar also pointed out that ITU-T SG 16 has a desire to have this format available in February 2004. To meet this goal there is need to move quickly, multiple revisions are probably needed before the end of the year. The consensus of the room was that it is appropriate to accept this as an AVT work item, however Colin James made an objection against the current solution because it hasn't been sufficiently reviewed, and he was not convinced that it was the simplest possible solution allowing for easiest implementation simplifying deployment. RTP payload format for 3GPP Timed Text <draft-rey-avt-3gpp-timed-text-01.txt> José Rey presented the open issues regarding the format. The main discussion has concerned if the format should be made generic, or specific for each timed text format. There is work in both MPEG and W3C to define additional timed text formats, however they are not yet ready. There is, however, a clear desire to finish this payload format for 3GPP timed text in the 3GPP Release 6 timeframe, i.e. by March 2004. To meet the deadline there is need to move much quicker than what has previously been done. An input in this discussion was email to AVT mailing list from Jan van der Meer, proposing that MPEG-4 SIMPLE payload format is used. Further discussion on the list is encouraged to allow for the working group to determine if there should be one payload format for all text usage or one for each "codec" definition? Another comment that was raised was is that it is very complex solution. We should consider if the format should rather be designed as transport format of the semantics, rather then being a transport of a file format. RTP payload format for Uncompressed Video <draft-ietf-avt-uncomp-video-04.txt> The changes to the draft were presented by Ladan Gharai. The change list is available in the presentation. A comment raised is that the draft probably should define the Gamma value the video. Magnus Westerlund asked if the authors has considered the usage of the IPv6 jumbogram and if the byte offset field will create any problem as being to small for really large picture sizes. Besides these, and some editorial comments, the draft seems to be in good shape, and a working group last call is expected when the next revision becomes available. Allison Mankin also asked if the draft had a strict wording (MUST) about the need of being congestion aware, due to comments received regarding RFC 3497. Colin Perkins responded that RFC 3497 has the requested strength in wording, and would ensure that also this draft has it. RTP payload format for H.264 Video <draft-ietf-avt-rtp-h264-03.txt> Magnus Westerlund outlined recent changes in the RTP format for H.264 video. There were two packetisation modes in the previous draft, one with decoding order numbers (DONs), and one without. The rules for when DONs should be used were unclear. The new version simplifies these rules: the DON is either always present, or never present. This gives three packetisation modes: single NAL unit mode, non-interleaved with STAPs, and interleaved with MTAPs. An additional interleaving parameter, max-don-diff, was added to help control interleaving. This gives the maximum displacement in terms of the DON, much in the style of the MPEG-4 payload format. Minor bug fixes include: assignment of DON values for STAP-B packets was corrected and clarified, derivation of the DON for MTAPs was changed to allow wraparound of values within one MTAP, the use of the RTP timestamp and picture timing SET message has been clarified, and Base64 encoding is now used in the "parameter-sets" MIME parameter. Dave Lindberg noted that network SLAs are often based on RTCP jitter, but H.264 bi-predictive slices disrupt the jitter calculation. This is common to many payload formats, and makes the RTCP jitter measurements useless for measuring network performance. Dave asked for a note to be inserted into the draft, to clarify the issue, and solicited input from network operators on how they intend to deal with this issue in the design of their SLAs. There are several open issues: the security section needs review; does the benefit of the max-don-diff parameter outweigh the complexity it brings; and should MIME parameters, similar to the H.241 CustomMaxMBPS, CustomMaxFS, CustomMAcDPB and customMaxBRandCPB, be added? On the later subject, Dave Lindberg - noting that he's the editor of H.241 in ITU - gave an "enthusiastic yes", since the profiles and levels in H.264 were designed for more traditional applications, and these parameters are very useful to support emerging applications. Colin Perkins asked about Nokia's IPR statement for this draft, which grants a royalty free license, provided the H.264 base also has a royalty free license. Does the H.264 base have such a license? No: it seems unlikely that any part of H.264 will be royalty free. The IPR conditions on the payload format appear to be no more restrictive than those on the codec. Thomas Zeng noted that the max-don-diff is undefined if not signalled, but that the receiver is expected to use this in the decoding process. Magnus said that this is a complex issue, and that it's not obvious what is the best buffering strategy for a receiver when interleaving is used. The max-don-diff parameter is expected to be used as an interleaving depth indicator, to simplify this process. Thomas complained about the complexity of the terminology, and clarification is probably needed. RTCP Extensions for SSM with Unicast Feedback <draft-ietf-avt-rtcpssm-05.txt> Jörg Ott updated the group on changes to the RTCP Extensions for SSM with Unicast Feedback <draft-ietf-avt-rtcpssm-05.txt> since the 57th IETF meeting. There are 2 open issues, besides security considerations, remaining: how to form compound packets and how to determine the RTCP bandwidth. RFC 3550 requires all RTCP packets to be compound packets, starting with either an SR or RR packet. This draft requires sources to send reception quality summary ("RSI") packets, but it's unclear if these should follow an SR or RR packet. Jörg suggested that it would be cleanest to include RSI packets in a compound RTCP packets with SR data, but this raises the issue of how to split RTCP bandwidth between sender and receiver, and means that the timestamp in RSI packets is redundant. Colin Perkins agreed that including RSI packets with SR packets is appropriate, since the reports are coming from the sender. There are two alternatives to control the RTCP bandwidth: distribute the current group size in RSI packets and let the receivers calculate their reporting interval, or notify receivers about the allowable bandwidth. The former is closer to the standard RTCP algorithm, the latter allows the sender to keep the group size confidential. The draft currently allows both alternatives, but this may not be ideal (and requires some clarification of the case were are signalled for a session). Input is solicited. Colin Perkins asked if there is an issue regarding step joins and leaves when the group size is explicitly conveyed? This is the reason why timer reconsideration was added to RTCP, and it may be necessary to define how the extensions interact with reconsideration. Next steps are to fix the editorial nits, provide more detail on how the distribution source generates RSI packets, and to rework security considerations section to give more explicit guidance to implementors. The aim is to complete the work by the end of December 2003. Extended Secure RTP Profile for RTCP-based Feedback <draft-ietf-avt-profile-savpf-00.txt> Jörg Ott outlined the new RTP/SAVPF profile, combining the Secure RTP profile and the RTCP feedback profile. The major implication of this combination is a potential impact on the timeliness of feedback since SRTCP adds some 10-20 bytes per packet (10-40%), which decreases the responsiveness of the feedback. Rules are provided for negotiation and inter-working, noting which combinations make sense, and ensuring that there are no bidding down attacks. The combination of these profiles is generally straight-forward, however. Review from the working group is solicited. RTCP Streaming Extended Reports <draft-tseng-avt-rtcp-streaming-extens- 00.txt> Alan Tseng introduced an extension to RTCP XR (RFC 3611) which reports more detailed statistics on re-buffering and packet corruption. This is intended to be useful for streaming media applications. There are several known issues with the draft: even the best measurement of corruption is only a best guess of "good" versus "bad" frames; and some existing application architectures may not support collection of the data to be reported. Comments are solicited on the mailing list - the authors are collecting feedback and sorting out the details of the proposal. Thomas Zeng asked for clarification on the frequency of the reports. Is it sufficient to report this information once, at end of the stream, or should it be reported periodically? Alan replied that it is viable to send the data only once, but sending periodic updates in conjunction with packet loss data would also be desirable. Will try to provide more recommendations and use cases in a future version of the draft. Victor Varsa asked if these reports were intended to be used for adaptation of the streaming, or just for offline collection? Alan replied that the original plan was to use a single report, but it seems to be useful for adjusting the feedback during the stream. Victor noted that the main advantage of sending these reports within RTCP is that they're synchronised with the media, this is only useful if the sender adapts in real-time. To allow this, it would be helpful if the draft included a description of how a sender could use the statistics to adapt. Colin Perkins noted that he would prefer these drafts to describe the reporting extensions in a normative manner, with separate drafts giving informative guidance on how the data could be used. Magnus Westerlund expressed scepticism on the use of the draft, since much of the information is available from other sources, or can be inferred. Michael Ramalho also wondered about the intended use of the work. He noted that it's important and useful to separate network events from client events, and agreed that it might be interesting to know that certain client events occurred and impacted the user experience, but couldn't see how the data was used - except as a reporting mechanism. If the data is only reported, and not used to drive adaptation, alternative transport mechanisms may be more appropriate. It was suggested that the work of the RMONMIB working group may be relevant to this problem. Details can be found at: http://www.ietf .org/html.charters/rmonmib-charter.html Datagram Congestion Control Protocol (DCCP) <draft-ietf-dccp-spec-05.txt> <draft-ietf-dccp-ccid2-04.txt> <draft-ietf-dccp-ccid3-04.txt><draft-ietf-dccp-ccid3-thin-00.txt> Eddie Kohler gave a short presentation on the Datagram Congestion Control Protocol. DCCP is under development as an alternative to UDP and provides a connection-oriented, congestion controlled, datagram transport service with partial checksums, mobility, DoS resistance, and support for explicit congestion notification (ECN). The target applications are those with long-lived flows that prefer timeliness to reliability: streaming media, Internet telephony, games, etc. DCCP allows applications to select from a range of congestion control algorithms (e.g. TCP-like, TFRC). It also decouples reliability from congestion control, to avoid the unconditional "buffer and retransmit" behaviour of TCP, and provides a range of data acknowledgement options including the ability to indicate that data was dropped due to buffer overflow in the application, rather than in the network. The partial checksum support in DCCP counts the number of 32 bit words of payload to be included in the checksum, up to a total of 56 octets. Eddie asked if this was sufficient for the applications people used? Thomas Zeng replied that this is probably sufficient for audio, but doubted that it was enough for video applications. Magnus Westerlund noted that DCCP also has an optional payload checksum feature, which can be used to provide more flexible checksums at the expense of additional overhead. DCCP provides an optional ACK vector, which allows applications to send a run-length encoded history of packets received. It also has a "data dropped" option, which allows a receiver to signal that certain packets were dropped due to non-network reasons (e.g. corruption, insufficient receive buffer space). Colin Perkins noted that this might duplicate some of the information provided by RTCP with the reporting extensions described earlier in the session. Finally, Eddie noted that there has been some discussion on the use of DCCP with TFRC congestion control for VoIP applications (and similar). In particular, there has been some discussion of protocol complexity, which has resulted in a low-complexity subset of DCCP ("CCID3-thin") being defined. There has also been discussion of the congestion control behaviour, with two related issues being raised: - The requirement for slow-start has been noted to be problematic for some applications. Eddie noted that DCCP allows 4 packets per RTT to be sent during slow start, allowing a 40ms packetisation interval for RTTs less than 160ms. He suggested that this was sufficient for audio applications, and solicited input. - There is also a congestion issue with applications slowing down during idle periods, for example silence suppression for voice. Applications which stop sending cannot just restart after an idle period, they must slow-start. Applications which send some traffic during idle periods will allow DCCP to maintain congestion state, allowing them to largely avoid this issue (since DCCP generally allows an application-limited flow to double its rate each RTT, up to the limit imposed by the congestion control). Again, Eddie asked if this was a feasible solution for multimedia applications. Magnus Westerlund expressed concern about the slow start, since audio with 20ms packets is common, and four packets per RTT requires an RTT that is difficult to obtain for many applications. Dave Lindberg asked if the factor of two increase in rate allowed when moving from an application limited regime to a congestion controlled regime is hard coded? At present it is, but there may be a small amount of flexibility. The factor of two may be a limiting for video, since the first frame after an idle period will be an I-frame, which is typically much larger than the P-frames which follow. Eddie continued his presentation, noting that the rate does not increase during an application limited period. An application can only determine if there is capacity to support a higher rate by trying to increase its rate (possibly incurring loss, if the higher rate cannot be supported). Eddie also noted that many applications have discrete rates, which may not necessarily match the reference rate suggested by the congestion controller. Again, it seems acceptable for an application to send at the closest discrete rate it can support to the reference rate, provided this is within a factor of two of the reference rate. [Eddie's slide stated "Variable rate considered harmful" here, followed by the clarification "Meaning: Continuously variable rate problematic for apps with discrete sending rates" - this caused some discussion/confusion as noted below]. Finally, Eddie noted that he'd received feedback that any rate change is harmful. There has been some discussion of using DCCP with applications that settle on one rate initially, then never change. Dave Lindberg asked why variable rates are considered harmful, and noted that some work on audio/video codecs was leading towards truly variable rate codecs. Eddie replied that they weren't planning on changing the protocol to require fixed rate applications, just that they wanted to support them if possible, and variable rate codecs are a good thing. There was some confusion, with Dave repeating his question and Eddie explaining the issues with supporting applications that can send only at discrete rates. Mark Handley and Michael Ramalho noted that Dave and Eddie were talking past each other: it's not that the DCCP people think that variable rate is harmful, it's that the people with discrete rate codecs think that being told to adapt to arbitrary variable rates due to congestion control is harmful. Mark explained: the DCCP congestion control scheme has a variable rate which it would like you to send at, to match the network capacity. The codec has a different (variable) rate, which it would like to send at. There may be a mismatch between the two rates, and this mismatch has to be bounded. Provided the mismatch is within a factor of two, things are okay. If the mismatch gets larger than that, the codec sending rate has to be adjusted to match the rate the network is capable of supporting. Michael accepted that, but explained the problem from the viewpoint of a codec designer: he could have been wasteful, and sent at the full rate all the time, but he's developed codecs which are efficient and usually send at low rates. However, every once in a while, they need to send a large burst of data, due to a scene change. He would claim that he is being a good citizen, by not sending all the data all the time, but he is getting penalised by the congestion control when the scene change happens. This doesn't feel correct, even though he understands the reason behind the congestion control algorithm. Roni Even noted that there are applications can only change their rate by completely switching codecs. These applications need the congestion control to signal them to adapt, so they can perform the application level signalling needed to change codec, rather than trying to directly influence the flow dynamics. Eddie noted that DCCP is supposed to give the application enough knowledge to support this. Tom Phelan noted that he's been working in the DCCP working group, to try to match VoIP applications onto DCCP. Some of his conclusions are "out of the norm" for what people usually consider good behaviour in the network: instead of "if you have nothing to say, say nothing", it may be more appropriate to say "use it or lose it" since if you send nothing, any TCP cross-traffic will take the unused capacity away from you. There may need to be a mindset change on the part of media application authors to effectively use DCCP. Dave Lindberg noted that the burst-to-average rate ratio for some video codecs is higher than 2:1, and that to keep the quality steady one needs to momentarily increase the bitrate. Ideally, one might convey a profile of the burst-versus-average characteristics of the application, so that the congestion control system can take that into account. Eddie noted the difficulties in doing this, which Dave accepted. However, it is clear that many codecs are bursty, and in order to lower the average rate, these bursts need to be somehow accommodated. Mark noted that there is a fundamental mismatch between what can safely be done to probe the capacity of the network, and what the codecs want to support bursts. The bounds in DCCP are fundamental for best effort networks, and reflect the limits of what the network can support. They are not something we have flexibility to change. Dave mentioned statistical multiplexing, which allows one to get bursts through in many cases. He also noted that TCP flows are not typically latency sensitive, so there may be some opportunity for some kind of trade-off. Nermeen Ismail asked if an application stops sending, and during that time there was no congestion in the network, would it make sense to allow it restart at the full rate? Theoretically, yes, but one can't figure out if there is congestion until one starts sending, so slow start is needed to provide enough feedback to make the system stable. The problem is that there is insufficient knowledge in the network to know if a change of rate is acceptable without trying it. It was noted that the MPEG community studied into this problem around 1998-2002, and may have produced useful references. Magnus Westerlund noted that some applications can smooth the bursts, depending on their latency requirements. However, if you need low latency, it may be necessary to reduce the quality of inter-frames and use a more incremental refresh strategy. This will reduce the quality, but will fit the dictates of congestion control and the network. Eddie noted that, to the extent that we'll have a solution, it will require sending some data during idle periods to maintain congestion state and knowledge of the network. Ladan Gharai noted that the issue was largely with live interactive applications, rather than with streaming applications which can use buffering to smooth their rate to match that of TFRC. She suggested that it may be appropriate to consider different congestion control for these two classes of application, rather than assuming - as has much of the discussion during the session - that a single congestion control algorithm can be used for both. The appropriate congestion control for live applications may be a research topic, rather than something we can engineer today. Mark Handley noted that an advantage of DCCP, compared to UDP, is that it has support for ECN built-in. This allows applications to react to congestion, before it becomes severe enough to cause packet loss, and may be a significant benefit of DCCP. Eddie concluded the discussion by giving pointers to the drafts. RTP Header Compression over Multi-Hop Paths <draft-ash-e2e-voip-hdr-comp-rqmts-01.t xt> Jerry Ash discussed the motivation and requirements for VoIP header compression over multiple-hop paths, in particular ECRTP over MPLS. The motivation for this work is that carriers are planning to converge their networks to use MPLS/IP with VoIP services. When using RTP there is a high overhead due to the RTP/UDP/IP headers, so there is a desire to use header compression. However, the compression is computationally complex, and it is desirable to find a multi-hop solution, rather than using hop-by-hop header compression. This may involve RTP compression across a multi-hop MPLS path, or compression over a series of IP hops. Jerry summarised the requirements as: - allow header compression over multiple-hop paths, possibly through an MPLS network - avoid hop-by-hop compression/decompression cycles - compress RTP/UDP/IP header by at least 50% - allow VoIP header compression over multiple-hop paths with delay not to exceed 400ms - allow VoIP header compression over multiple-hop paths with delay variation not to exceed toms - allow VoIP header compression over multiple-hop paths with packet loss not to exceed 0.001 - support various voice encoding schemes - be scalable up to 20000 simultaneous flows - be compatible with existing standards where possible Colin Perkins, Michael Ramalho, Dave Lindberg and Carsten Bormann all questioned if the numeric requirements were appropriate, and how they differed from those for VoIP traffic without header compression. There was general agreement that the draft may be better if it specifies the additional requirements caused by header compression, rather than generic requirements to support voice. Dave Lindberg asked if there a requirement for packet loss recovery, since one of the issues with CRTP is that a single packet loss can cause a whole RTT of data to be lost. This is something that concerns the authors, especially for multiple-hop paths, but they hope that ECRTP will be sufficiently robust. George Swallow's "simple" RTP header compression proposal also avoids these problems, but Colin Perkins noted that the group is not chartered to work on new compression algorithms at this time. Michael Ramalho asked if the compression was dealing with aggregate or single flows, since if aggregate flows are used there may be different solutions for recovery from errors. Both single and aggregate flows are considered. Magnus Westerlund noted that requirements for header compression over multi-hop MPLS paths may well be different than the requirements for header compression over multi-hop IP paths. The draft may be better written separating these out. Jerry noted that there are potential scalability issues with RSVP and label processing and binding at every MPLS node on the path. It's also not clear how to signal the context states within the label distribution protocol, and extensions to LDP may be needed. There was some discussion of the need to produce a standard for header compression on multi-hop IP paths, since routers which are compressing on both ingress and egress links can unilaterally decide to match CIDs and pass-through compressed flows without a compression-d ecompression. The chairs noted that there are significant issues to be resolved with the draft, and delayed accepting it as an AVT work item until they are understood. SDP parameters for supporting H.263 and H.261 options <draft-even-avt-h263-h261-options-00.tx t> <draft-nismail-mmusic-sdp-video-00.txt> Roni Even discussed new SDP parameters to support various optional features in H.261 and H.263 codecs. Features to be signalled include frame rate and resolution dependency, and optional features defined in various annexes to the codecs. The authors are looking for input on the parameters chosen, to see if all have been covered. The two drafts suggest different approaches, but the authors have come to consensus on using "a=fmtp:" rather than "a=gpmd:" to signal these parameters. Plans for the future are to combine the ideas from the two drafts, and revise the payload formats for H.261 and H.263 to include these new MIME parameters. It was also suggested to move RFC 2190 to historic at the same time. Eric Burger noted that there are several parameters which are not used, especially in H.261. Which revising the payload formats, we should remove these. Flemming asked about backwards compatibility, since care must be taken when adding new MIME parameters that won't be understood by old imple mentations. Victor Varsa asked how these new parameters relate to the concepts of profiles and levels? These are additional parameters, which signal combinations of parameters which cannot be represented by the profile and level indication. It was accepted to open the H.261 and H.263 payload formats for revision at this time, with the aim of producing draft standard RFCs. Requirements for transport of video control commands <draft-basso-avt-videoconreq-00.txt> Andrea Basso outlined some initial requirements work which is ongoing relating to the transport of video control commands. This is exploratory work, and it has not yet been decided which parts of it will continue in AVT, which in MMUSIC, and which maybe elsewhere. Andrea outlined the use cases described in the draft, leading to the need for reference frame requests, spatio-temporal tradeoff requests, freeze frame requests, max-rate requests and actual rate notification. He also described the wide range of requirements for transport of the different commands. Next steps are to trim the command list, to tighten up the list of transport requirements, and to decide a home for the various parts of the work. Dave Lindberg noted that H.241 supports many of these commands, and suggested that the work be harmonised between the ITU and IETF. Eric Burger suggested that we have to be careful not to blindly duplicate H.241, since many of the features can be signalled in other ways, or are not meaningful for SIP-based systems. Most important to harmonise the work, irrespective of how or where the work is done. The requirements capture and initial discussion for the codec commands will be done in AVT. It is not yet decided where the actual work will be done, that will depend on the outcome of the requirements discuss ion. Proposed additions to RTP MIB <draft-clark-avt-rtpmibv2-00.txt> The final presentation of the meeting was from Alan Clark on proposed additions to the RTP MIB. The rationale for these additions is to add support for the new RTCP XR and VoIP metrics. The draft does this by adding an rtcpXrVoipTable to the existing MIB, to support both basic call information and RTCP XR metrics. Several people expressed concern about adding new features to RFC 2959, suggesting instead that the additions are written as a separate draft, perhaps under a separate MIB root. Magnus Westerlund noted that the RTP MIB also needs to be updated for the changes between RFC 1889 and RFC 3550, and this may be an appropriate time to make these changes. - + |