RTCP Report Extension for Feedback Suppression
draft-wu-avt-retransmission-supression-rtp-07

Abstract

In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a media source or middlebox may experience transient overload if some event causes a large number of receivers to send feedback at once. This feedback implosion can be mitigated if the device suffering from overload can send a feedback suppression message to the receivers to inhibit further feedback. This memo defines RTCP extensions for feedback suppression, to suppress NACK and FIR feedback requests. It also defines associated SDP signalling."

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on May 12, 2011.

Copyright Notice

Copyright (c) 2010 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, as 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 are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Overview
4.  RTCP Feedback Report Extension
    4.1.  Transport Layer Feedback: NACK Suppression Report
    4.2.  Payload Specific Feedback: FIR suppression report
5.  SDP Signaling
6.  Example Use Cases
    6.1.  Source Specific Multicast (SSM) use case
        6.1.1.  Simple Feedback Model
        6.1.2.  Distribution Source Feedback Summary Model
    6.2.  Unicast based Rapid Acquisition of Multicast Stream (RAMS) use case
    6.3.  RTP transport translator use case
    6.4.  Multipoint Control Unit (MCU) use case
7.  Security Considerations
8.  IANA Consideration
9.  Acknowledgement
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

RTCP feedback messages [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),” July 2006.) allow the receivers in an RTP session to report events and ask for action from the media source (or a delegated feedback target). There are cases where multiple receivers may initiate the same, or an equivalent message towards the same media source. When the receiver count is large, this behavior may cause transient overload of the media source,the network or both. This is known as a "feedback storm" or a "NACK storm". One common cause of such a feedback storm is receivers utilizing RTP retransmission [RFC4588] (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.) as a packet loss recovery technique based, sending feedback using RTCP NACK messages [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),” July 2006.) without proper dithering of the retransmission requests.

Another use case involves video Fast Update requests. A storm of these feedback messages can occur in conversational multimedia scenarios like Topo-Video-switch-MCU [RFC5117] (Westerlund, M. and S. Wenger, “RTP Topologies,” January 2008.). In this scenario, packet loss may happen on an upstream link of an intermediate network element such as a Multipoint Control Unit(MCU). Poorly designed receivers that blindly issue fast update requests (i.e., Full Intra Request (FIR) described in [RFC5104] (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.)), can cause an implosion of FIR requests from receivers to the same media source.

RTCP feedback storms may cause short term overload and, and in extreme cases to pose a possible risk of increasing network congestion on the control channel (e.g. RTCP feedback), the data channel, or both. It is therefore desirable to provide a way of suppressing unneeded feedback.

One approach to this, suggested in [DVB‑IPTV] (ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” August 2009.), involves sending a NACK message from server to the client (or receiver). However NACK is defined as a receiver report sent from a client to the server and therefore exhibits a semantic mismatch when used as a suppression indication from the server (or intermediary) to the client. This document instead specifies a newly message for this function. It further is more precise in the intended uses and less likely to be confusing to receivers. It tells receivers explicitly that feedback for a particular packet or frame loss is not needed for a period of time and can provide an early indication before the receiver reacts to the loss and invokes its packet loss repair machinery.

Since feedback suppression interacts strongly with repair timing, it has to work together with feedback to not adversely impact the repair of lost source packets. One example is the middle box gets the retransmitted packet by sending a NACK upstream and sent it downstream. This retransmitted packet was lost on the downstream link.In order to deal with this, the downstream receiver can start a timeout in which it expected to get a retransmission packet. When this timeout expires and there is no retransmitted packet or a new suppression message, it can take its normal behavior as if there is no current retransmission suppression.In some cases where the loss was detected and repair initiated much closer to the source, the delay for the receiver to recover from packet loss can be reduced through the combination of intermediary feedback to the source and feedback suppression downstream. In all (properly operating) cases, the risk of increasing network congestion is decreased.

2.  Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Protocol Overview

This document extends the RTCP feedback messages defined in the Audio-Visual Profile with Feedback (AVPF) and define the Feedback Suppression message. The Feedback Suppression message asks a receiver to not send feedback messages for particular packets (indicated by their RTP sequence numbers) independent of whether the receiver detected the packet loss or detected a need for a decoder refresh point).

In order to detect packet loss before the receivers perceive it, one or more intermediate nodes may be placed between the media source and receiver. These intermediates are variously referred to as Distribution servers, MCUs, RTP translator, or RTP mixers, depending on the precise use case. These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification.

These intermediate nodes need to take into account such factors as the tolerable application delay, the network dynamics, and the media type. When the packet loss is detected upstream of the intermediary and additional latency is tolerable, the intermediate node may itself send a feedback message asking for the suspected lost packet or ask for the correct decoder refresh point. Because it has already provided the necessary feedback toward the source, the intermediate node can be reasonably certain that it will help the situation by sending a Feedback Suppression message to all the relevant receivers, thereby indicating that the receivers should not themselves transmit feedback messages for a period of time.

Alternatively, the media source may directly monitor the amount of feedback requests it receives, and send feedback suppression messages to the receivers.

When a receiver gets such a feedback suppression message, it should refrain from sending a feedback request (e.g., NACK or FIR) for the missing packets reported in the message for a period of time. A receiver may still have sent a Feedback message before receiving a feedback suppression message, but further feedback messages for those sequence numbers will be suppressed by this technique for a period time.Nodes that do not understand the feedback suppression message will ignore it, and might therefore still send feedback. The media source or intermediate nodes cannot assume that the use of a feedback suppression request actually reduces the amount of feedback it receives.

RTCP Feedback Suppression follows the same semantic model as RTCP NACK - it conveys the packet receipt/loss events at the sequence number level and considers missing packets as unrepaired. But unlike RTCP NACK, the Feedback Suppression messages can be generated at RTP middleboxs and sent to the corresponding receivers. Intermediaries downstream of an intermediary detecting loss obviously SHOULD NOT initiate their own additional feedback suppression messages for the same packet sequence numbers. They may either simply forward the Feedback Suppression message received from upstream, or augment (or replace) it with a feedback suppression message that reflects the loss pattern they have themselves seen.

4.  RTCP Feedback Report Extension

This document registers two new RTCP Feedback messages for Feedback Suppression. Applications that are employing one or more loss-repair methods MAY use Feedback Suppression together with their existing loss-repair methods either for every packet they expect to receive, or for an application-specific subset of the RTP packets in a session. In other words, receivers MAY ignore Feedback Suppression messages, but SHOULD react to them unless they have good reason to still send feedback messages despite having been requested to suppress them.

4.1.  Transport Layer Feedback: NACK Suppression Report

The NACK implosion Suppression message is an extension to the RTCP feedback report and identified by RTCP packet type value PT=RTPFB and FMT=TBD.

The FCI field MUST contain one or more NACK Suppression Early Indication (NSEI) entries. Each entry applies to a different media source, identified by its SSRC.

The Feedback Control Information (FCI) for NSEI uses the similar format of message Types defined in the section 4.3.1.1 of [RFC5104] (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.). The format is shown in Figure 1 (Message Format for the NSEI report).

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

SSRC (32 bits):

The SSRC value of the media source that is requested to send the lost packet.

Packet ID (PID): 16 bits

The PID field is used to specify a lost packet. The PID field refers to the RTP sequence number of the lost packet.

bitmask of proceeding lost packets (BLP): 16 bits

The BLP allows for reporting losses of any of the 16 RTP packets immediately following the RTP packet indicated by the PID. The BLP's definition is identical to that given in [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),” July 2006.).

4.2.  Payload Specific Feedback: FIR suppression report

The FIR implosion Suppression message is an extension to the RTCP receiver feedback report and identified by RTCP packet type value PT=PSFB and FMT=TBD.

The FCI field MUST contain one or more FIR suppression Early Indication (FSEI) entries. Each entry applies to a different media source, identified by its SSRC.

The Feedback Control Information (FCI) for FSEI uses the similar format of message Types defined in the section 4.3.1.1 of [RFC5104] (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.). The format is shown in Figure 2 (Message Format for the FSEI report).

     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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Seq nr.   |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SSRC (32 bits):

The SSRC value of the media source that is requested to send a decoder refresh point.

Seq nr:8bits

Command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 modulo 256 for each new request.

Reserved: 24 bits

All bits SHALL be set to 0 by the media source and SHALL be ignored on reception.

5.  SDP Signaling

A new feedback value "fss" needs to be defined for the Feedback Storm Suppression message to be used with Session Description Protocol (SDP)[RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) using the Augmented Backus-Naur Form (ABNF)[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),” July 2006.).

The "fss" feedback value SHOULD be used with parameters that indicate the feedback suppression supported. In this document, we define two such parameters, namely:

• "fsei" denotes support of fir suppression early indication (fsei).
  
  
• "nsei" denotes support of NACK suppression early indication.

In the ABNF for rtcp-fb-val defined in [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),” July 2006.), there is a placeholder called rtcp-fb-id to define new feedback types. "fss" is defined as a new feedback type in this document, and the ABNF for the parameters for fss is defined here (please refer to section 4.2 of [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),” July 2006.) for complete ABNF syntax).

      rtcp-fb-val        =/ "fss" rtcp-fb-fss-param
      rtcp-fb-fss-param  = SP "nsei";nack suppression early indication
                          / SP "fsei";fir suppression early indication
                          / SP token [SP byte-string]
                                    ; for future commands/indications
   byte-string = <as defined in section 4.2 of [RFC4585] >

Refer to Section 4.2 of [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),” July 2006.) for a detailed description and the full syntax of the "rtcp-fb" attribute.

6.  Example Use Cases

The operation of feedback suppression is similar for all types of RTP sessions and topologies [RFC5117] (Westerlund, M. and S. Wenger, “RTP Topologies,” January 2008.), however the exact messages used and the scenarios in which suppression is employed differ for various use cases. The following sections outline the intended use cases for feedback suppression and give an overview of the particular mechanisms.

6.1.  Source Specific Multicast (SSM) use case

In SSM RTP sessions as described in [RFC5760] (Ott, J., Chesterfield, J., and E. Schooler, “RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback,” February 2010.), one or more Media Sources send RTP packets to a Distribution Source. The Distribution Source relays the RTP packets to the receivers using a source-specific multicast group.

In order to avoid the forms of NACK implosion described in section 1,the distribution source should choose to include the support for loss detection. How the packet loss detection works is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the distribution source creates a Feedback Suppression report and sent it to all the RTP receivers, over the multicast channel. Another possibility is when there may have multiple distribution source placed between the media source and the receivers, the upstream distribution source may inform downstream distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source forwards packet loss suppression report received from upstream to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers.

When there is only one distribution source with loss detection support between the media source and the receivers, redistribution of the feedback suppression report to all the receivers is trivial. When there are multiple distribution sources between the media source and the receiver, , each distribution source with loss detection support may create a Feedback Suppression Report using the similar format as conventional RTCP NACK packets at the RTP layer and send it to its downstream distribution source or forward one Feedback Suppression Report from upstream to its downstream distribution source or the receivers. Also each distribution source at the downstream of the other distribution source may also create additional Feedback Suppression Report and send it to the receivers.

The distribution source must be able to communicate with all group members in order for either mechanism to be effective at suppressing feedback.

As outlined in the [RFC5760] (Ott, J., Chesterfield, J., and E. Schooler, “RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback,” February 2010.), there are two Unicast Feedback models that may be used for reporting, - the Simple Feedback model and the Distribution Source Feedback Summary Model. The RTCP Feedback Suppression report extension specified in the section 4 of this document will work in both Feedback models. Details of operation in each are specified below.

6.1.1.  Simple Feedback Model

In the simple Feedback Model, there may have one distribution source with loss detection support. The distribution source must listen on the corresponding RTP session for data. When the distribution source observes that a sequence of RTP packets from upstream contains gaps (by checking the sequence number of packets), the distribution source must use the same packet types as traditional RTCP feedback described in [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) and create one new RTCP Feedback Report with information on the RTP sequence number of the lost packets and suppression early indication event. When the distribution source is eligible to transmit, it must send this Report packet to the the group on the multicast RTCP session.

Alternatively the distribution source should pass through any feedback suppression requests it receives from the upstream direction. Such a distribution source can also choose to not send feedback suppression messages if it's already seen similar messages with identical packet loss from upstream.

This RTCP Feedback Report lets the receivers know that feedback for this packet loss is not needed and should not be sent to the media source(s). If the media source(s) are part of the SSM group for RTCP packet reflection, the Distribution Source must filter this packet out. If the media source(s) are not part of the SSM group for RTCP packets, the Distribution Source must not forward this RTCP packets received from the receivers to the media source(s).

6.1.2.  Distribution Source Feedback Summary Model

In the distribution source feedback summary model, there may have multiple distribution sources and the Loss Detection instances are distributed into different distribution sources. In some cases, these Loss Detection instances for the same session can exist at the same time, e.g., one Loss Detection instance is implemented in the upstream distribution source A, another two Loss Detection instances for the same session is part of feedback target A and feedback target B respectively within the distribution source B. In this section, we focus on this generic case to discuss the distribution Source Feedback Summary Model.

The distribution source A must listen on the RTP channel for data. When the distribution source A observes RTP packets from a media source are not consecutive by checking the sequence number of packets, the distribution source A generates the new RTCP Feedback Suppression Report packet described in the section 6, and then send it to the distribution source B.

Two loss detection instances within the Distribution Source B must listen for RTCP data sent to the RTCP port. Upon receiving the RTCP Feedback Report packet from the Distribution Source A, the distribution source B needs to summarize the information received from all the RTCP Feedback Reports generated by the upstream distribution source together with the information generated by two loss detection instances witin the Distribution Source B and then create the summary report to include all these information. In order to reduce the processing load at the distribution source, each loss detection instance may provide preliminary summarization report.

During the summary report creating, the Distribution Source B must use its own SSRC value for transmitting summarization information and MUST perform proper SSRC collision detection and resolution.

In some case, the distribution source B may receive RTCP NACK messages from the receivers behind the Distribution Source before the distribution source detects the packet loss which may cause potential Feedback implosion. In such case, the distribution source B may filter them out if it already sent a packet loss request for the missing packet to the media source. When the distribution source B confirms packet loss reported by the receiver, the distribution source B generates the summary report to include the packet loss information from the corresponding receiver or upstream distribution source.

The distribution source B may send this new RTCP summary report described in the section 6 to the group on the multicast RTCP channel and in the meanwhile sending a packet loss request to the media source.

If there are a couple of distribution sources with loss detection support looking at the same RTP stream, then the loss may be identified by all and they will all send requests for the same packet loss. In this case, the distribution source must filter out the duplicated information from various distribution source and only append one copy of such information to the summary report.

When the host receives the RTCP Feedback Suppression message, if the host understands this message it will not send packet loss request (e.g., NACK) for the missing packets reported in the message. If it did not understand this new message, the host MAY send packet loss request(e.g., NACK messages) to the specified media source. When the distribution source receives the packet loss request from the hosts after it has already detected packet loss, the distribution source MUST filter it out until proactive recovery is complete.

6.2.  Unicast based Rapid Acquisition of Multicast Stream (RAMS) use case

In the typical RAMS architecture, there may have one distribution source placed between media source and BRS for relaying SSM stream from media source. The BRS will receive the SSM stream from the DS. Suppose there are several BRSes behind the distribution source or media source, there may be just one BRS that detects packet loss on its upstream link between the distribution source and BRS, but the others will perhaps not, as the packet loss took place on SSM tree branch that does not impact the other BRSes. In such case, the distribution source with loss detection functionality support can not detect packet loss at the downstream of itself, therefore the distribution source SHOULD NOT create new Feedback Suppression message and send it to all the BRS. If BRS impacted by packet loss has loss detection support, the BRS MAY choose to create new Feedback Suppression message and send it to the receivers behind this BRS.

6.3.  RTP transport translator use case

A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] (Westerlund, M. and S. Wenger, “RTP Topologies,” January 2008.) is typically forwarding the RTP and RTCP traffic between RTP clients, for example converting between multicast and unicast for domains that do not support multicast. The translator can identify packet loss from the upstream and send the Feedback Suppression message to the unicast receivers. The translator can also serve as a loss reporter on the multicast side as described in the SSM case.

6.4.  Multipoint Control Unit (MCU) use case

In point to multipoint topologies using video switching MCU (Topo-Video-switch-MCU) [RFC5117] (Westerlund, M. and S. Wenger, “RTP Topologies,” January 2008.), the MCU typically forwards a single media stream to each participant, selected from the available input streams. The selection of the input stream is often based on voice activity in the audio-visual conference, but other conference management mechanisms (like presentation mode or explicit floor control) exist as well.

In this case the MCU may detect packet loss from the sender or may decide to switch to a new source. In both cases the receiver may lose synchronization with the video stream and may send a FIR request. If the MCU itself can detect the mis-synchronization of the video, the MCU can send the FIR suppression message to the receivers and send a FIR request to the video source.

7.  Security Considerations

The defined messages have certain properties that have security implications. These must be addressed and taken into account by users of this protocol.

Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications:

Sending NACK Suppression Report with wrong sequence number of lost packet that makes missing RTP packets can not be compensated.

Sending FIR Suppression Report with wrong sequence number of lost packet that makes missing RTP packets can not be compensated by update request mechanism.

To prevent these attacks, there is a need to apply authentication and integrity protection of the feedback messages. This can be accomplished against threats external to the current RTP session using the RTP profile that combines Secure RTP [RFC3711] (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) and AVPF into SAVPF [RFC5124] (Ott, J. and E. Carrara, “Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF),” February 2008.).

Note that middleboxes that are not visible at the RTP layer that wish to send NACK/FIR suppression reports on behalf of the media source can only do so if they spoof the SSRC of the media source. This is difficult in case SRTP is in use. If the middlebox is visible at the RTP layer, this is not an issue, provided the middlebox is part of the security context for the session.

Also note that endpoints that receive a NACK/FIR suppression request would be well-advised to ignore it, unless it is authenticated via SRTCP or similar. Accepting un-authenticated NACK/ FIR suppression requests can lead to a denial of service attack, where the endpoint accepts poor quality media that could be repaired.

8.  IANA Consideration

New feedback type and New parameters for RTCP FSS receiver feedback report are subject to IANA registration. For general guidelines on IANA considerations for RTCP feedback, refer to [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),” July 2006.).

This document assigns one new feedback type value x in the RTCP feedback report registry to "Feedback Storm Suppression" with the following registrations format:

    Name:            FSS
    Long Name:       Feedback Storm Suppression
    Value:           TBD
    Reference:       This document.

This document also assigns the parameter value y in the RTCP FSS feedback report Registry to "NACK Suppression Early Indication ", with the following registrations format:

     Name:           NSEI
     Long name:      NACK Suppression Early Indication
     Value:          TBD
     Reference:      this document.

This document also assigns the parameter value z in the RTCP FSS feedback report Registry to "FIR Suppression Early Indication ", with the following registrations format:

     Name:           FSEI
     Long name:      FIR Suppression Early Indication
     Value:          TBD
     Reference:      this document.

The contact information for the registrations is:

  Qin Wu
  sunseawq@huawei.com
  101 Software Avenue, Yuhua District
  Nanjing, Jiangsu  210012, China

9.  Acknowledgement

The authors would like to thank David R Oran, Ali C. Begen, Colin Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, WeeSan Lee for their valuable comments and suggestions on this document.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses