RFC 6642

RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report

📅 published June 2012, from ietf

RFC 6642: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report 🎀

okay bestie, let's do the paperwork first 📋✨ This doc is RFC 6642, titled RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report. It's written by Q. Wu, Ed. (the editor 💅), F. Xia, and R. Even, all from Huawei 💼. It's a Standards Track document, ISSN 2070-1721, published in June 2012 🗓️. The header doesn't list anything it obsoletes or updates.

Abstract 🌸

picture a huge RTP session using the RTP Control Protocol (RTCP) feedback mechanism from RFC 4585 🎧 if some event makes a whole crowd of receivers send feedback at the exact same moment, the feedback target can get a transient overload 😭 people usually dodge this by forwarding feedback reports to everyone, so nobody has to send a duplicate. BUT there are cases where forwarding feedback is not recommended, and that can allow feedback implosion 💀 this memo digs into those cases and defines a brand new RTCP Third-Party Loss Report 🦋 it tells receivers that the feedback target is already aware of some loss event, so they can suppress their own feedback 🙈 there's also Associated Session Description Protocol (SDP) signaling defined here 📝

Status of This Memo 📜

this is an Internet Standards Track document ✨

it's a product of the Internet Engineering Task Force (IETF) 🌈 it represents the consensus of the IETF community, it got public review, and it was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚

info about the current status of this doc, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6642 🔗

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. please review these documents carefully, because they describe your rights and restrictions with respect to this document 🫶 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

1. Introduction ....................................................3
2. Terminology .....................................................3
   2.1. Requirements Notation ......................................3
   2.2. Glossary ...................................................4
3. Example Use Cases ...............................................4
   3.1. Source-Specific Multicast (SSM) Use Case ...................4
   3.2. Unicast-Based Rapid Acquisition of Multicast Stream
        (RAMS) Use Case ............................................5
   3.3. RTP Transport Translator Use Case ..........................5
   3.4. Multipoint Control Unit (MCU) Use Case .....................6
   3.5. Mixer Use Case .............................................6
4. Protocol Overview ...............................................6
5. Format of RTCP Feedback Messages ................................7
   5.1. Transport-Layer Feedback: Third-Party Loss Report (TPLR) ...8
   5.2. Payload-Specific Feedback:  Third-Party Loss Report (TPLR) .8
6. SDP Signaling ...................................................9
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgments ................................................11
10. References ....................................................12
   10.1. Normative References .....................................12
   10.2. Informative References ...................................12

1. Introduction ✨

the RTP Control Protocol (RTCP) feedback messages [RFC4585] let receivers in an RTP session report events and ask for action from the media source (or from a delegated feedback target when you're using unicast RTCP feedback with Source-Specific Multicast (SSM) [RFC5760]) 💫 sometimes multiple receivers start the same message, or an equivalent one, aimed at the same media source or the same feedback target. when the receiver count is big, that can cause transient overload of the media source, the network, or both 😩 this is known as a "feedback storm" or a "NACK storm" 🌪️

one scenario that can cause these storms involves video Fast Update requests 🎥 a storm of these feedback messages can happen in conversational multimedia scenarios like multipoint video switching conference [RFC4587], where lots of receivers may lose sync with the video stream all at once when the speaker changes mid-session 😵‍💫 receivers that issue Fast Update requests (i.e., Full Intra Request (FIR) described in RFC 5104 [RFC5104]) can cause an implosion of FIR requests to the same media source, since these requests currently have to be made blind, without knowing what other receivers already asked for 🙃

RTCP feedback storms can cause short-term overload and, in extreme cases, a possible risk of more network congestion on the control channel (e.g., RTCP feedback), the data channel, or both 💀 so it's desirable to have a way to suppress unneeded feedback 🧚 this document specifies a new Third-Party Loss Report for exactly that job 🦋 it supplements the existing use of RTCP NACK packets and is also more precise in the uses where the network is active to suppress feedback 💅 it tells receivers explicitly that feedback for a particular packet or frame loss is not needed, and it can give an early heads-up before the receiver reacts to the loss and invokes its packet loss repair machinery 👑 Section 3 has some example use cases of when to send the Third-Party Loss Report message 🍓

2. Terminology 📖

2.1. Requirements Notation

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶

2.2. Glossary

here's the glossary, bestie, every acronym you'll see 🔤

TPLR  - Third-Party Loss Report

TLLEI - Transport-Layer Third-Party Loss Early Indication

PSLEI - Payload-Specific Third-Party Loss Early Indication

PT    - Payload Type

FMT   - Feedback Message Type

FCI   - Feedback Control Information [RFC4585]

AVPF  - Audio-Visual Profile with RTCP-based feedback [RFC4585]

SSRC  - Synchronization Source

BRS   - Burst/Retransmission Source [RFC6285]

FIR   - Full Intra Request [RFC5104]

PLI   - Picture Loss Indication [RFC4585]

SSM   - Source-Specific Multicast [RFC5760]

RAMS  - Unicast-based Rapid Acquisition of Multicast Stream [RFC6285]

MCU   - Multipoint Control Unit [RFC5117]

3. Example Use Cases 🎬

the way feedback suppression works is pretty similar for all types of RTP sessions and topologies [RFC5117] 💖 however, the exact messages used and the scenarios where suppression is used are different for each use case 🌸 the sections below outline some of the intended use cases for the Third-Party Loss Report and give an overview of each 🦋

3.1. Source-Specific Multicast (SSM) Use Case

in SSM RTP sessions as described in "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback" [RFC5760], one or more media sources send RTP packets to a distribution source 📡 the distribution source relays those RTP packets to the receivers using a source-specific multicast group 🎀

as outlined in RFC 5760 [RFC5760], there are two Unicast Feedback models that may be used for reporting: the Simple Feedback Model and the Distribution Source Feedback Summary Model 🧠 in the Simple Feedback Model, there's no need for the distribution source to create the RTCP TPLRs. instead, RTCP NACKs get reflected by the distribution source to the other receivers 🔁 but in the Distribution Source Feedback Summary Model, the distribution source will not redistribute the NACK for some reason (e.g., to prevent revealing the identity or existence of a system sending NACK) 🤫 and it may send an RTCP TPLR message to the systems that were unable receive the NACK and won't receive the NACK via other means 📬 the RTCP TPLR can be generated at the distribution source when downstream loss is reported (e.g., downstream loss report is received), which indicates to the receivers that they should not transmit feedback messages for the same loss event for a certain time ⏳ so the distribution source in the Distribution Source Feedback Summary Model can be reasonably certain that it will help the situation (i.e., the distribution source is unable receive the NACK) by sending this RTCP TPLR message to all the relevant receivers impacted by the packet loss 💪

3.2. Unicast-Based Rapid Acquisition of Multicast Stream (RAMS) Use Case

the typical RAMS architecture [RFC6285] may have several Burst/Retransmission Sources (BRSs) sitting behind the multicast source, all placed at the same level 🧩 these BRSs receive the primary multicast RTP stream from the media source and cache the most recent packets after joining the multicast session 🗄️ if packet loss happens upstream of all the BRSs or downstream of the BRSs, one or all of the BRSs may send an RTCP NACK or RTCP TPLR message to the distribution source, where the SSRC in this RTCP NACK or RTCP TPLR message is the BRS that is sending the message 📨 the distribution source forwards/reflects this message down on the primary SSM 🔊 the details on how the distribution source deals with this message are specified in [RETRANS-FOR-SSM] 📖

3.3. RTP Transport Translator Use Case

a Transport Translator (Topo-Trn-Translator), as defined in RFC 5117 [RFC5117], is typically forwarding the RTP and RTCP traffic between RTP clients 🚚 for example, it converts from multicast to unicast for domains that don't support multicast 🌉 the translator may suffer a loss of important video packets 😬 in this case, the translator may forward an RTCP TPLR message received from upstream in the same way it forwards other RTCP traffic 🙌 if the translator acting as the monitor [MONARCH] is aware of packet loss, it may use the SSRC of the monitor as the SSRC of the packet sender to create a NACK message and send it to the receivers that are not aware of packet loss 🕵️‍♀️

3.4. Multipoint Control Unit (MCU) Use Case

when the speaker changes in a voice-activated multipoint video switching conference [RFC4587], an RTP mixer can be used to select the available input streams and forward them to each participant 🎤 if the MCU is doing a blind switch without waiting for a synchronization point on the new stream, it can send a FIR to the new video source 🙈 in this case, the MCU should send a FIR suppression message to the new receivers 💜 for example, when the RTP mixer starts to receive FIR from some participants, it can suppress the remaining session participants from sending FIR by sending out an RTCP TPLR message 🌈

3.5. Mixer Use Case 🎀

okay so a mixer (per RFC 5117 [RFC5117]) is the one that takes RTP streams from a bunch of session participants and blends them into one new RTP stream that goes back out to everyone 🎶. Here's the drama: video frames can get messed up on the way from the media source to the mixer, because of packet loss or late delivery 😭. When that happens, the mixer has to look at the video it's receiving and figure out whether the loss is going to make most of the group send PLI or FIR requests. If it is, the mixer may send FIR or PLI to the media source on behalf of everyone, and it also sends an RTCP TPLR message to the participants who may or are expected to send a PLI or FIR. 💅 Or, if some participants already started sending FIR or PLI and the mixer wants everyone else to stop, it can just pass one participant's FIR/PLI along to the others. Iconic multitasking 👑

4. Protocol Overview ✨

okay this document basically levels up the RTCP feedback messages from RTP/AVPF [RFC4585] by adding an RTCP Third-Party Loss Report (TPLR) message 🦋. The idea is that an intermediary can tell a receiver: "hey, the sender of this TPLR got reports that these packets were lost, so don't bother sending feedback about them." Intermediaries go by a bunch of names (distribution sources, Burst/Retransmission Sources, MCUs, RTP translators, or RTP mixers) depending on which use case from Section 3 you're in 🌸

The format is kind of a sibling of the RTCP NACK and Full Intra Request Command 💖. The difference is the meaning: a TPLR says the sender received reports that the packets were lost, while a NACK [RFC4585] just says the NACK sender saw the packets go missing. A TPLR can come from an intermediary that never saw the loss itself 🫶. It follows the same timing rule as NACK from RFC 4585 [RFC4585], and it can go in a regular full compound RTCP packet or an early RTCP packet, depending on the RTP/AVPF rules.

Now the important part 🔥. Intermediaries that receive an RTCP TPLR MUST NOT send their own extra Third-Party Loss Report messages for the same packet sequence numbers. They SHOULD just forward the RTCP TPLR they got from upstream to the receiver(s). They're allowed to make their own RTCP TPLR reporting losses they see that are different from the ones in the TPLR they received. Also, the RTCP TPLR does not have retransmission request [RFC4588] semantics, so it's not a retransmission request, periodt ✨

When a receiver gets an RTCP TPLR, it MUST follow the NACK suppression rules in RFC 4585 [RFC4585] and hold off on sending feedback requests (like NACK or FIR) for the missing packets listed in the message. This gets handled the same way as if it had received a NACK 🙈

Quick robustness move: the RTCP TPLR may be retransmitted to protect against it getting lost. If the extra TPLR shows up, the receiver SHOULD handle it the same way as the first TPLR for those packets, and the receiver doesn't need any extra behaviour for that 🧚

A receiver might have already sent feedback under the RTP/AVPF scheduling algorithm of RFC 4585 [RFC4585] before the RTCP TPLR arrived. That's fine, but any further feedback for those sequence numbers SHOULD be suppressed once the RTCP TPLR is received. Nodes that don't understand RTCP TPLR will just ignore it, so they might still send feedback on the AVPF schedule from RFC 4585 [RFC4585]. Which means the media source or intermediate nodes can't be sure the RTCP TPLR actually reduces the feedback they get 💀

5. Format of RTCP Feedback Messages 🌈

This document introduces two new RTCP feedback messages for Third-Party Loss Report. Applications that already use one or more loss-repair methods MAY use RTCP TPLR alongside those existing methods, either for every packet they expect to receive or for an application-specific subset of the RTP packets in a session 💜

There are two sections below, and each one defines an RTCP TPLR message. Both are feedback messages as defined in Section 6.1 of RFC 4585 [RFC4585] and use the header format from there. Each section explains how to fill in the PT, FMT, length, SSRC of packet sender, SSRC of media source, and FCI fields of that header 📝

5.1. Transport-Layer Feedback: Third-Party Loss Report (TPLR) 🦋

This TPLR message is identified by RTCP packet type values PT=RTPFB and FMT=7.

In the common packet header for feedback messages (as defined in Section 6.1 of RFC 4585 [RFC4585]), the "SSRC of packet sender" field tells you who the source of the request is, and the "SSRC of media source" field names the media sender of the flow whose indicated losses are being suppressed 🔥

The FCI field MUST contain one or more entries of Transport-Layer Third-Party Loss Early Indication (TLLEI). Every entry applies to the same media source, identified by the SSRC in the "SSRC of media source" field of the Feedback header. The length field in the TLLEI feedback message MUST be set to N+2, where N is the number of FCI entries 💅

The FCI field for TLLEI uses a message type format similar to the one in Section 6.2.1 of RFC 4585 [RFC4585]. Here's what it looks like, in Figure 1:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PID                |             BLP               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Syntax of an FCI Entry in the TLLEI Feedback Message

Packet ID (PID): 16 bits 🍓 The PID field is used to specify a lost packet. It refers to the RTP sequence number of that lost packet.

bitmask of lost packets (BLP): 16 bits 🌸 The BLP lets you report losses for any of the 16 RTP packets right after the RTP packet named by the PID. Its definition is identical to the one in Section 6.2.1 of [RFC4585].

5.2. Payload-Specific Feedback: Third-Party Loss Report (TPLR) ✨

This TPLR message is identified by RTCP packet type values PT=PSFB and FMT=8, which are used to suppress FIR [RFC5104] and PLI [RFC4585].

In the common packet header for feedback messages (as defined in Section 6.1 of RFC 4585 [RFC4585]), the "SSRC of packet sender" field indicates the source of the request. The "SSRC of media source" field is not used and SHALL be set to 0 🙃 The SSRCs of the media senders this message applies to are found in the corresponding FCI entries.

The FCI field for a Payload-Specific Third-Party Loss Early Indication (PSLEI) consists of one or more FCI entries. Each entry applies to a different media source, identified by its SSRC, and the content is shown in Figure 2. The length field in the PSLEI feedback message MUST be set to N+2, where N is the number of FCI entries 🎀

The format is shown in Figure 2:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Syntax of an FCI Entry in the PSLEI Feedback Message

Synchronization source (SSRC): 32 bits 🧚 This is the SSRC value of the media source that already knows, or is in the process of finding out, that some receiver lost synchronization with the media stream. The PSLEI receiver's own response to that error is suppressed for it.

6. SDP Signaling 💖

The Session Description Protocol (SDP) [RFC4566] attribute rtcp-fb is defined in Section 4 of RFC 4585 [RFC4585], and it can be used to negotiate the ability to handle specific AVPF commands and indications. The ABNF for rtcp-fb is described in Section 4.2 of RFC 4585 [RFC4585]. In this section, we extend the rtcp-fb attribute so it includes the commands and indications described for Third-Party Loss Reports in this document 🫶

In the ABNF [RFC5234] for rtcp-fb-val defined in RFC 4585 [RFC4585], the feedback type "nack" with no parameters means you're using the Generic NACK feedback format from Section 6.2.1 of RFC 4585 [RFC4585]. This document defines two parameters that signal third-party loss support for use with "nack":

  • "tllei" means support for Transport-Layer Third-Party Loss Early Indication.
  • "pslei" means support for Payload-Specific Third-Party Loss Early Indication.

The ABNF for these two parameters used with "nack" is defined here. For the full ABNF syntax, check Section 4.2 of RFC4585 [RFC4585] 🤓

        rtcp-fb-val        =/ "nack" rtcp-fb-nack-param
        rtcp-fb-nack-param = SP "tllei"
                                ;Transport-Layer Third-Party
                                ; Loss Early Indication
                            / SP "pslei"
                                ;Payload-Specific Third-Party
                                ; Loss Early Indication
                            / SP token [SP byte-string]
                                ; for future commands/indications
        token =     <as defined in Section 9 of [RFC4566]>
        byte-string = <as defined in Section 9 of [RFC4566]>

7. Security Considerations 🔒

😱 This section is serious business, bestie. Read every word.

The security considerations documented in [RFC4585] also apply to the TPLR messages defined in this document 🛡️

More specifically, spoofed or maliciously created TPLR feedback messages can stop missing RTP packets from being repaired in a timely fashion. They also add the risk of (undesired) feedback suppression at RTCP receivers that accept those TPLR messages. Any packet loss detected by a receiver that also gets a TPLR message for the same missing packet(s) will hurt the application that relies on timely RTP retransmission capabilities 💀

One solution to stop attacks with maliciously sent TPLR messages is to apply an authentication and integrity protection framework to the feedback messages. This can be done with the RTP profile that combines Secure RTP [RFC3711] and AVPF into SAVPF [RFC5124] 🔐

Also, intermediaries that aren't visible at the RTP layer and want to send Third-Party Loss Reports on behalf of the media source can only do that if they spoof the SSRC of the media source. That's hard if SRTP is in use. If the intermediary is visible at the RTP layer, this isn't an issue, as long as the intermediary is part of the security context for the session 🦋

8. IANA Considerations 💅

okay so IANA added two new values to the '"ack" and "nack" Attribute Values' sub-registry [RFC4585] of the 'Session Description Protocol (SDP) Parameters' registry 🎀

here's the registration for the nack attribute value 💖

   Value name:     tllei
   Long name:      Transport-Layer Third-Party Loss Early Indication
   Usable with:    nack
   Reference:      RFC 6642

   Value name:     pslei
   Long name:      Payload-Specific Third-Party Loss Early Indication
   Usable with:    nack
   Reference:      RFC 6642

next up, one FMT value got registered in the "FMT Values for RTPFB Payload Types" registry (http://www.iana.org/assignments/rtp-parameters) ✨

  RTPFB range
  Name           Long Name                         Value  Reference
  -------------- --------------------------------- -----  ---------
  TLLEI          Transport-Layer Third-Party         7    [RFC6642]
                 Loss Early Indication

and one more FMT value got registered in the "FMT Values for PSFB Payload Types" registry (http://www.iana.org/assignments/rtp-parameters) 🦋

  PSFB range
  Name            Long Name                        Value  Reference
  -------------- --------------------------------- -----  ---------
  PSLEI          Payload-Specific Third-Party        8    [RFC6642]
                 Loss Early Indication

9. Acknowledgments 🫶

the authors want to thank David R. Oran, Magnus Westerlund, Colin Perkins, Ali C. Begen, Tom Van Caenegem, Francis Dupont, Ingemar Johansson, Bill Ver Steeg, Jonathan Lennox, and WeeSan Lee for their valuable comments and suggestions on this document 💜 the whole review crew is iconic

10. References 📚

10.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 🌸
  • [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. 🍓
  • [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 🧚
  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. ✨
  • [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008. 🎀
  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐
  • [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. 💅

10.2. Informative References

  • [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011. 🦋
  • [MONARCH] Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures for RTP", Work in Progress, May 2012. 👀
  • [RETRANS-FOR-SSM] Van Caenegem, T., Ver Steeg, B., and A. Begen, "Retransmission for Source-Specific Multicast (SSM) Sessions", Work in Progress, May 2011. 🌈
  • [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. 🗺️
  • [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006. 📼
  • [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. 🎬

Authors' Addresses 🖋️

Qin Wu (editor)
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

EMail: sunseawq@huawei.com


Frank Xia
Huawei
1700 Alma Dr., Suite 500
Plano, TX 75075
USA

Phone: +1 972-509-5599
EMail: xiayangsong@huawei.com


Roni Even
Huawei
14 David Hamelech
Tel Aviv 64953
Israel

EMail: even.roni@huawei.com
📦 where this page comes from