| TOC |
|
This document specifies an extension to the RTCP feedback messages defined in the Audio-Visual Profile with Feedback (AVPF). This extension allows an intermediate node in the network (such as an RTP translator) inform downstream receivers that sending a feedback message concerning a specified set of RTP messages may be unnecessary, or even harmful. For example, in a source-specific multicast session with large fan-out, packet loss close to the media or distribution source of the session is detected as a loss by a large number of receivers. The RTCP NACK messages used to request retransmission of the missing packets are all addressed to the media sender, or a designated feedback target. This may result in a phenomenon known variously as a "NACK implosion" or "feedback storm". The Feedback Suppression message defined herein is used to notify receivers that packet loss was detected and that the sender of the report will either proactively recover, or no recovery is possible. Receivers respond to receipt of a feedback suppression message by not sending a feedback message (e.g. a NACK) that they otherwise would, This in turn reduces load on both the feedback target and on the network. This document registers two new RTCP messages for Feedback Suppression.
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 April 12, 2011.
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.
1.
Introduction
2.
Terminology
3.
Protocol Overview
4.
RTCP Receiver Feedback Report Extension
4.1.
Transport Layer Feedback Message
4.1.1.
NACK implosion Suppression Summary report
4.2.
Payload Specific Feedback Message
4.2.1.
FIR implosion Suppression Summary 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.
RTP transport translator use case
6.3.
Multipoint Control Unit (MCU) use case
7.
Security Considerations
8.
IANA Consideration
9.
Acknowledgement
10.
References
10.1.
Normative References
10.2.
Informative References
Appendix A.
Example scenarios for Retransmission Storm Suppression
A.1.
Scenario 1: One or more media sender,One distribution source
A.2.
Scenario 2:One media sender, Two distribution sources in cascade
A.3.
Scenario 3:One media sender, Two distribution sources in parallel
Appendix B.
Applicability of Feedback Storm Suppression
§
Authors' Addresses
| TOC |
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 sender (or a delegated feedback target). There are cases where multiple receivers may initiate the same, or an equivalent message towards the same sender. When the receiver count is large, this behavior may overload the sender or the network or both. One common case is receivers utilizing RTP retransmission as a packet loss recovery technique in a real-time application such as streaming video or audio.[RFC4588] (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.)Feedback is accomplished using the RTCP NACK message which conveys the RTP sequence number(s) of the lost packet(s). This information can then be used by the sender to retransmit the missing RTP packets using the RTP retransmission payload format[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.).
However, in topologies utilizing transport translators (Topo-Trn-Translator) or large-scale multicast transmission (Topo-Multicast) as defined in [RFC5117] (Westerlund, M. and S. Wenger, “RTP Topologies,” January 2008.), packet loss can occur on either an upstream link or a downstream aggregate link of the intermediate network element (e.g., Retransmission server, Distribution Source). Where there are many receivers, this may result in a NACK implosion towards the sender, i.e., large number of NACK requests to the same multicast sender for retransmission of the same RTP packets. This phenomenon goes by a number of alternate names, such as the “NACK storm” terminology of [DVB‑IPTV] (ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” August 2009.). In an attempt to increase its robustness against the loss of a NACK message or of retransmission packets, a receiver may send multiple NACKs for the same detected packet loss, which may aggravate the NACK implosion.
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). Receivers missing the packets issue fast update requests (i.e., Full Intra Request(FIR) described in [RFC5104]), which results in an implosion of FIR requests from receivers to the same media sender.
As these feedback storms propagate (e.g., NACK implosion or Fast update implosion), the network may be permeated with more and more feedback traffic, resulting in a positive feedback loop as the network is also saturated with media traffic. RTCP feedback storms pose a substantial risk of increasing network congestion, and in extreme cases to congestion collapse on the control channel (e.g. RTCP feedback), the data channel (i.e. RTP restransmission), or both.
In order to mitigate these behaviors, the current text in [RFC5760] (Ott, J., Chesterfield, J., and E. Schooler, “RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback,” February 2010.) allows the distribution source to filter out the NACK messages and [DVB‑IPTV] (ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” August 2009.) suggests sending a NACK message from sender to the receiver. However NACK is defined as a receiver report sent from a receiver to the sender and therefore exhibits a semantic mismatch when used as a suppression indication from the sender (or intermediary) to the receiver. 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 loss is not needed and can provide an early indication before the receiver reacts to the loss and invokes its packet loss repair machinery.
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 are placed between the media sender and receiver (e.g., Distribution server, MCU, RTP translator). 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 either initiate its own feedback toward the source to provoke a retransmission, send Feedback Suppression message towards the receivers as defined in this specification, or both.
Instead of using specialized intermediaries, another possibility is to instantiate one or more RTP receivers upstream of the loss region to act as immediate reporters as described in[DVB‑IPTV] (ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” August 2009.). 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 retransmission of 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. When the sender receives the request from the intermediate node, the sender resends the missing packets to the receivers by using the RTP retransmission payload format [RFC4588] (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.)or resends a new refresh point for FIR Initiator [RFC5104] (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.), depending on the type of feedback it received.
RTCP Feedback Storm 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 intermediate nodes who are not RTP receivers and sent to the corresponding receivers. Intermediaries downsteam 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.
Since feedback suppression interacts strongly with repair timing, it has to work together with feedback and retransmission to not adversely impact the repair of lost source packets. 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. 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.
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.
| TOC |
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.).
- Intermediate Source:
One intermediate node with logical function which is used to process or foward packet at the RTP layer. The intermediate Source is located between media sender and receivers. The examples of intermediate source are Distribution server, MCU, RTP translator.
- Upstream RTP Client:
An RTP Client located in the upstream from the intermediate source as described in [DVB‑IPTV] (ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” August 2009.). This Client is able to detect upstream packet loss impacting all the RTP receivers serviced by the intermediate source and receiving SSM service.
- Immediate reporting RTP Client:
An RTP Client located on a downstream aggregate link from the intermediate source as described in [DVB‑IPTV] (ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” August 2009.). This Client is able to detect downstream packet loss on the aggregate link or other nodes upstream of the aggregat link, thus impacting all the RTP receivers serviced by the intermediate source and receiving SSM service.
- Loss Reporter:
The Loss Reporter is one logical function which is used to detect the packet loss at the RTP layer and report it to the intermediate source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a intermediate source A, on ports n for the RTP channel and k for the RTCP channel, the unicast RTCP Feedback Target is identified by an IP address of intermediate source A on port k. The loss reporter MAY also be implemented in one or more entities different from the intermediate source. In this case, the loss reporter may be an upstream RTP client or immediate reporting RTP client located on a downstream aggregate link of the intermediate source.
| TOC |
In order to avoid the forms of NACK implosion described in section 1, the loss reporter is introduced. The loss reporter detects and reports packet loss, on both the upstream link and the downstream aggregate link. When upstream link or downstream aggregate link packet loss occurs, the Loss reporter may inform intermediate source of the detected packet loss using Feedback Suppression messages. In response, the intermediate source either forwards packet loss suppression report received from loss reporter or creates a Feedback Suppression report and sends it 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 intermediate source via retransmission, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media sender. The intermediate source then can (optionally) ask for retransmission of the lost packets from the media sender on behalf of all the RTP receivers. Upon receiving the lost packet via the RTP retransmission payload format, the intermediate source forwards the retransmitted packet to all the receivers.
When the loss reporter(s) are part of a feedback target collocated with the intermediate source, redistribution of the feedback suppression report is trivial. In such cases, the loss reporter function in the feedback target detects packet loss coming from an upstream link and informs the collocated intermediate source. Also the loss reporter may detect packet loss occurring within intermediate source itself and report to intermediate source using the same method. When the loss reporter(s) are physically and(or) topologically distinct from intermediate source, each loss reporter MUST create a packet loss report using the similar format as conventional RTCP NACK packets at the RTP layer and send it to the intermediate source . The loss reporters may be upstream client or downstream immediate reporter who is dedicated to detect and report packet loss.
The intermediate source must be able to communicate with all group members in order for either mechanism to be effective at suppressing feedback. The general architecture is displayed below in Figure 1.
The Intermediate Source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing
feedback. The general architecture is displayed below in Figure 1 (System Architecture)
+--------+ +------------+ Source-specific
|Media | | | Multicast
|Sender 1|<------->| | +----------------> R(1)
+--------+ |Intermediate| |
| SOURCE | +--+
+--------+ | | | |
|Media |<------->| | | +-----------> R(2)
|Sender 2| | Feedback |->+ +---- :
+--------+ |+ Target --+| | +------> R(n-1)
: || +---+ || | |
: || | R| || +--+--> R(n)
|| | E| ||
+--------+ || |L P| ||
|Media | || |O O| ||
|Sender M|<---- -->|| |S R| ||
+--------+ || |S T| ||
|| | E| ||
|| | R| ||
|| +---+ ||
|+----------+|
+------------+
Transport of packet loss informationfrom the Loss Reporter to the
Feedback Target is via unicast RTCP feedback if the two are not
co-located.
| Figure 1: System Architecture |
| TOC |
| TOC |
| TOC |
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 sender, 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 2 (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2: Message Format for the NSEI report |
- SSRC (32 bits):
The SSRC value of the media sender 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 following 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.).
| TOC |
| TOC |
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 sender, 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 3 (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3: Message Format for the FSEI report |
- SSRC (32 bits):
The SSRC value of the media sender 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 command.
- Reserved: 24 bits
All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
| TOC |
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:
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.
| TOC |
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.
| TOC |
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 Senders send RTP packets to a Distribution Source. The Distribution Source relays the RTP packets to the receivers using a source-specific multicast group.
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.
| TOC |
In the simple Feedback Model, the Loss reporter(s) are disjoint from the distribution source. In this case, an upstream client or immediate reporting receiver may be chosen as the loss reporter. Also in this model, the distribution source includes support for retransmission as part of the offered SDP and expects such support from the Media Sender.
As one dedicated receiver for packet loss reporting, the Loss reporter MUST listen on the corresponding RTP session for data. When the Loss reporter observes that a sequence of RTP packets from a Media Sender contains gaps (by checking the sequence number of packets), the Loss reporter 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 a receiver is eligible to transmit, it MUST send this Report packet to the distribution source via unicast feedback.
The Distribution Source (unicast Feedback Target) MUST listen for unicast RTCP data sent to the RTCP port. Upon receiving the unicast RTCP Feedback Report packet from the loss reporter, the Distribution Source MUST forward it to the group on the multicast RTCP session. Every RTCP packet from each Loss reporter MUST be reflected individually. If the loss reporter is part of group, the Distribution source MUST filter this packet out and not forward it back to this loss reporter.
If there are multiple loss reporters looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first loss reporter to the group impacted by packet loss.
This unicast RTCP Feedback Report lets the receivers know that feedback for this packet loss is not needed and should not be sent to the media sender(s). If the Media Sender(s) are part of the SSM group for RTCP packet reflection, the Distribution Source MUST filter this packet out. If the Media Sender(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 Sender(s).
When the receiver receives the RTCP packet, if the receiver understands the message it will not send feedback (e.g., NACK) for the missing packets reported in the message and will accept a retransmission packet (if forthcoming) transmitted from the Distribution Source. If it did not understand the Feedback Suppression report the receiver may of course still send feedback messages to the specified media sender. When the distribution source receives a feedback message reporting loss from one or more receivers after it has already detected packet loss or gotten a NACK feedback message from loss reporter, the distribution source MUST filter them out until the Retransmission stream is ready in the Distribution Source.
| TOC |
In the distribution source feedback summary model, the distribution source will include the support for retransmission as part of the offered SDP and will expect such support from the Media Sender, also the Loss reporter instance may be integrated in the distribution source or may be separated from the distribution source. In some cases, several loss reporter instances for the same session can exist at the same time, e.g., one loss reporter instance (loss reporter A) is implemented in the upstream client A, one loss reporter instance (loss reporter B) is implemented in the upstream client B, another loss reporter instance for the same session (loss reporter C) is part of feedback target within the distribution source. In this section, we focus on this generic case to discuss the distribution Source Feedback Summary Model.
The Loss reporter A and the Loss reporter B MUST listen on the RTP channel for data. When the Loss reporter observes RTP packets from a Media Sender are not consecutive by checking the sequence number of packets, the loss reporter generates NACK message described 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.) or generates the new RTCP Feedback Report packet described in the section 6, and then send either of them to the distribution source via unicast feedback.
The Distribution Source (unicast Feedback Target) MUST listen for unicast RTCP data sent to the RTCP port. Upon receiving the unicast RTCP Feedback Report packet from the loss reporter, the distribution source needs to filter them out, i.e., identify these unicast RTCP packets coming from the Dedicated receivers (i.e.,Loss Reporter A and Loss Reporter B)based on the IP address of loss reporters or dedicated RTCP port for loss report, then summarize the information received from all the RTCP Feedback Reports generated by the Dedicated receivers together with the information generated by the loss reporter integrated in the feedback target and then create the summary report to include all these information. In order to reduce the processing load at the distribution source, the individual instance of Loss Reporter may provide preliminary summarization report.
During the summary report creating, the Distribution Source 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 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 may filter them out if it already sent a packet loss request for the missing packet to the media sender. When the distribution source confirms packet loss reported by the receiver, the distribution source generates the summary report to include the packet loss information from the corresponding receiver (e.g., upstream client or loss reporter).
The distribution source 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 sender.
If the loss reporter is part of group, the Distribution source MUST not send the summary report back to this loss reporter.
If there are a couple of loss reporters 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 loss reporters and only append one copy of such information to the summary report.
When the host receives the RTCP packet, if the host understands this message it will not send packet loss request (e.g., NACK) for the missing packets reported in the message and will accept a retransmission stream transmitted from the Distribution Source. If it did not understand this new message, the host may send packet loss request(e.g., NACK messages) to the specified media sender. When the distribution source receives the packet loss request from the hosts after it has already detected packet loss or got packet loss report from loss reporter, the distribution source MUST filter it out until the Retransmission stream is ready in the Distribution Source.
| TOC |
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.
| TOC |
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.
| TOC |
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 Implosion Summary Suppression Indication with wrong sequence number of lost packet that makes missing RTP packets can not be compensated by retransmission mechanism.
Sending FIR Implosion Summary Suppression Indication 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.).
| TOC |
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 receiver 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 receiver 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 receiver 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 Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd. Nanjing, JiangSu 210001 China
| TOC |
The authors would like to thank David R Oran, Bill Ver Steeg, Ingemar Johansson S, Colin Perkins, Tom VAN CAENEGEM, WeeSan Lee for their valuable comments and suggestions on this document.
| TOC |
| TOC |
| [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 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [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 (TXT). |
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
| [RFC5117] | Westerlund, M. and S. Wenger, “RTP Topologies,” RFC 5117, January 2008 (TXT). |
| [RFC4588] | Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” RFC 4588, July 2006 (TXT). |
| [RFC4566] | Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT). |
| [RFC5234] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT). |
| [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 (TXT). |
| [RFC3711] | Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT). |
| [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 (TXT). |
| TOC |
| [DVB-IPTV] | ETSI Standard, “Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” ETSI TS 102 034, V1.4.1 , August 2009. |
| [I-D.hunt-avt-monarch-01] | Hunt, G. and P. Arden, “Monitoring Architectures for RTP,” August 2008. |
| [I-D.ietf-pmol-metrics-framework-02] | Clark, A., “Framework for Performance Metric Development.” |
| TOC |
Feedback Storm Suppression can be further extended when a distributed content distribution network (CDN) are considered. In these cases, several intermediate node and media senders may constitute hierarchical model. In the distributed content distribution environment, the Feedback Storm Suppression is used to suppress the neighboring node from sending packet loss request for the missing packets via unicast. How the neighboring node is discovered is beyond scope of this document.
| TOC |
The general architecture for scenario 1 is displayed below in Figure 4 (One media Sender, one Distribution Source). In this architecture, one or more Media
Senders send RTP packets to the RTP Receivers through the same
Distribution Source. The Distribution Source relays the RTP packets to
the receivers using a source-specific multicast channel. In the
reverse direction, the receivers transmit RTCP packets via unicast to
the distribution source. The Distribution Source in turn relays RTCP
packets to the media sender and then transmits the RTCP packets back
to the receivers, using source-specific multicast. When packet loss
happens in the upstream link or downstream aggregate link of
distribution source, it may result in massive retransmission request
for the same RTP packets from all the receivers using RTCP NACK to the
same multicast sender. We refer to it as Retransmission Storm.
+-------+
|---->|RTP_Rx1|
+--------+ | +-------+
| | +--------------+ |
| | | | | +-------+
| Media |-------| Distribution |-------|---->|RTP_Rx2|
| | | Source | | +-------+
| Sender | | | | .
| | +--------------+ | .
| | | .
+--------+ | +-------+
|---->|RTP_Rxn|
+-------+
| Figure 4: One media Sender, one Distribution Source |
| TOC |
+-------+
|---->|RTP_Rx1|
| +-------+
+------+ |
| | +------------+ +------------+ | +-------+
|Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2|
|Sender| | Source1 | | Source2 | | +-------+
| | +------------+ +------------+ | .
+------+ | .
| .
| +-------+
|---->|RTP_Rxn|
+-------+
| Figure 5: One media sender, Two distribution sources in cascade |
The general architecture for scenario 2 is displayed below in Figure 5 (One media sender, Two distribution sources in cascade). In this architecture, One media sender passes through two distribution source in cascading and sends RTP packets to all the RTP receivers. When packet loss happens in the upstream link or downstream aggregate link of distribution source1, it may result in massive retransmission request for the same RTP packets from all the receivers using RTCP NACK to the same multicast sender. We refer to it as Retransmission Storm. In this case, the distribution source 2 can be taken as one special RTP receiver located in the downstream direction of distribution source 1.
| TOC |
The general architecture for scenario 3 is displayed below in Figure 6 (One Media Sender, more distribution sources). In this architecture, one media sender and two
Distribution source constitute one hierarchical tree model. In this
model, one Media Senders send RTP packets to all the RTP receivers
through two different path respectively. When packet loss happens in
the upstream link or downstream aggregate link of distribution source,
it may result in massive retransmission request for the same RTP
packets from all the receivers using RTCP NACK to the same multicast
sender. We refer to it as Retransmission Storm.
+--------+
|---->|RTP_Rx11|
| +--------+
+--------------+ |
| | | +--------+
|--->| Distribution |----|---->|RTP_Rx12|
| | Source1 | | +--------+
| | | | .
+--------+ | +--------------+ | .
| | | | .
| | | | +--------+
| Media | | |---->|RTP_Rx1k|
| |---| +--------+
| Sender | | +--------+
| | | |---->|RTP_Rx21|
| | | | +--------+
+--------+ | +--------------+ |
| | | | +--------+
| | Distribution |----|---->|RTP_Rx22|
|--->| Source2 | | +--------+
| | | .
+--------------+ | .
| .
| +--------+
|---->|RTP_Rx2j|
+--------+
| Figure 6: One Media Sender, more distribution sources |
| TOC |
This document defines new RTCP Receiver feedback Report, which we refer to as Feedback Storm Suppression to deal with Retransmission Storm mentioned above. Here we give two examples to show how this new RTCP receiver feedback report is applied into three scenarios described in Appendix A (Example scenarios for Retransmission Storm Suppression) for Retransmission Storm Suppression.
Applicability of Retransmission Storm Suppression in Scenario 1
described in Figure 4 (One media Sender, one Distribution Source) is shown in the Figure 7 (Applicability of Feedback Suppression Early Indication). In this figure, the distribution source detect
the packet loss before the receiver perceive it and ask for
retransmission of the missing packets from the media sender, in the
meanwhile, the distribution source transmits the RTCP Retransmission
Storm Suppression Indication back to the receivers using source-specific
multicast channel. In this way, the delay for the receiver to recover
from the packet loss can be reduced and the risk of increasing network
congestion can be mitigated.
+------+ +--------------+ +--------+ |Media | | Distribution | | | |Sender| | Source | | RTP_Rx | +--+---+ +------+-------+ +---+----+ | | | | | | |------------------->|------RTP Multicast---->| | | | | | | | +--------+----------+ | | |Detect Packet Loss | | | |and Identify the SN| | | |of missing Packets | | | +--------+----------+ | |<-----RTCP NACK-----| | | | | | +--Multicast RTCP FSS--->| | RTP Retransmission | | |------------------->| | | |------RTP Multicast---->| | | Retransmission | | | | | | | | | |
| Figure 7: Applicability of Feedback Suppression Early Indication |
+------+ +-------+ +--------+ +-------+ +--------+ |Media | | | | RTP_Rx | | | | RTP_Rx | |Sender| | DS1 | | (DS1) | | DS2 | | (DS2) | +--+---+ +---+---+ +---+----+ +---+---+ +---+----+ | | | | | | |RTP Multicast | | | |----------->|------------->| | | | | | | | | | | |RTP Multicast| |------------------------------------------->|------------>| | | | | | | +--------+------------+ | | | | |Detect Packet Loss | | | | | |and Identify the SN | | | | | |of the missing Packets | | | | +--------+------------+ | | | | | | | | |<-RTCP NACK-| Multicast RTCP RSSI | | | |------------->| | | | | | | | | |-----Unicast RTCP RSSI-------->|Multicast RTCP FSS | | | |------------>| |RTP Retransmission | | | |----------->| | | | | | | | | | | RTP Retransmission | | |------------+--------------+--------------->| | | | | | | | | RTP Multicast| | RTP Multicast | |Retransmission| |Retransmission | |------------->| |------------>| | | | | | DS1: Distribution Source 1 DS2: Distribution Source 2
| Figure 8: Applicability of Retransmission Suppression Early Indication |
| TOC |
| Qin Wu | |
| 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 |