Network Working Group Q. Wu
Internet-Draft F. Xia
Intended status: Standards Track R. Even
Expires: December 12, 2010 Huawei
June 10, 2010
Proposal for an extension to RTCP Receiver Report for Feedback Storm
Suppression
draft-wu-avt-retransmission-supression-rtp-02
Abstract
This document specifies an extension to the RTCP messages defined in
the Audio-Visual Profile with Feedback (AVPF) designed to allow
intermediate node of the network side to suppress the feedback
implosion from the receivers. An example of feedback implosion is
NACK storm, i.e., a large number of RTCP NACK messages used to
request retransmission of the missing packets going to the same media
sender. The Feedback Storm Suppression receiver report is used to
carry the information regarding feedback suppression early indication
events to the receiver before the receiver detects an original packet
loss and all the packet loss repair methods are applied and filtering
of unnecessary feedback messages when the receivers have already send
out packet loss requests. By using feedback Suppression message
together with filter mechanism, the delay for the receiver to recover
from the packet loss can be reduced and the risk of increasing
network congestion can be mitigated. This document also registers
two new RTCP receiver reports for Feedback Storm Suppression.
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 December 12, 2010.
Copyright Notice
Wu, et al. Expires December 12, 2010 [Page 1]
Internet-Draft Feedback Storm Suppression June 2010
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.
Wu, et al. Expires December 12, 2010 [Page 2]
Internet-Draft Feedback Storm Suppression June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . 7
4. Simple Feedback Model . . . . . . . . . . . . . . . . . . . . 9
5. Distribution Source Feedback Summary Model . . . . . . . . . . 10
6. RTCP Receiver Feedback Report Extension . . . . . . . . . . . 11
6.1. Transport Layer Feedback Message . . . . . . . . . . . . . 11
6.1.1. NACK implosion Suppression Summary report . . . . . . 11
6.2. Payload Specific Feedback Message . . . . . . . . . . . . 12
6.2.1. FIR implosion Suppression Summary report . . . . . . . 12
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Example scenarios for Retransmission Storm
Suppression . . . . . . . . . . . . . . . . . . . . . 16
A.1. Scenario 1: One or more media sender,One distribution
source . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Scenario 2:One media sender, Two distribution sources
in cascade . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. Scenario 3:One media sender, Two distribution sources
in parallel . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Applicability of Feedback Storm Suppression . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Wu, et al. Expires December 12, 2010 [Page 3]
Internet-Draft Feedback Storm Suppression June 2010
1. Introduction
RTP retransmission is an effective packet loss recovery technique for
real-time applications with relaxed delay bounds [RFC4588],e.g.,
streaming media. The conventional RTCP feedback (NACK) message which
conveys the RTP sequence number of the lost packets can be used to
request the sender to compensate the missing RTP packets based on the
RTP sequence number of these packets [RFC4585].
However, in lots of multicast environments, packet loss occurs in the
upstream link or downstream aggregate link of the intermediate
network element (e.g., Retransmission server, Distribution Source)
due to oversaturated network link, faulty networking hardware or
corrupted packets rejected in-transit. It may result in NACK
implosion targeting at the same sender, i.e., massive NACK request to
the same multicast sender for retransmission of the same RTP packets
which is also known as "NACK storm" described in [DVB-IPTV]To
increase the robustness to the loss of a NACK or of a retransmission
packet, a receiver may also send multiple NACKs for the same packet
which may aggravate the NACK implosion.
A similar use case is video Fast Update request storm occurs in the
conversational multimedia scenarios. In this case, packet loss may
happen in the upstream link of intermediate network element like
Multipoint Control Unit(MCU) which results in massive fast update
request (i.e., Full Intra Request(FIR) described in [RFC5104]) from
receivers to the same media sender.
As these feedback storms progress (e.g., NACK implosion or Fast
update implosion), the network may be overwhelmed with constant
feedback traffic, in the worsening case, RTCP feedback storm poses a
risk of increasing network congestion, with excessive traffic and
degrading network performance, this can eventually lead to a complete
loss of network connectivity as such feedback packets proliferate,
the network may become unusable.
In order to solve this, the current text in [RFC5760] allows the
distribution source to filter out the NACK messages while this
document propose an option to let the receivers know that Feedback
for packet loss is not needed in the specified cases. i.e.,
generating one new generic RTCP receiver report message, which
reflects the packet receipt/loss events and feedback suppression
early indication events before the receiver detects an original
packet loss and all the packet loss repair methods are applied.
This new RTCP receiver report, which we refer to as Feedback Storm
Suppression, indicates suppressing feedback request for the packet
loss(e.g., request retransmission of lost packets or request decoder
Wu, et al. Expires December 12, 2010 [Page 4]
Internet-Draft Feedback Storm Suppression June 2010
refresh point) before the receiver sends a request to the media
sender for the missing packet. In order to detect the original
packet loss in the upstream direction before the receivers perceive
it, the intermediate node of network side located between the media
sender and receiver may monitor a certain packet loss by checking the
sequence number consistency of the original multicast packets or
configuring upstream RTP client or a small subset of RTP receivers to
act as immediate reporters described in [DVB-IPTV]. Also this
intermediate node should take into account such factors as the
tolerable application delay, the network environment, and the media
type. When the packet loss is detected and initial latency is
tolerable, in the upstream direction towards the sender, the
intermediate node may ask for retransmission of the lost packet from
the sender or ask for the correct decoder refresh point, meanwhile,
in the downstream direction from the sender, the intermediate node
may convey Feedback Suppression Indication to all the receivers
concerned to indicate that the receiver should not to transmit
feedback messages. When the sender receives the request from the
intermediate node, the sender resends the missing packets to the
receiver via RTP using retransmission payload format [RFC4588]or a
new refresh point for FIR Initiator [RFC5104]
Similar to RTCP NACK, the Feedback Storm Suppression also conveys the
packet receipt/loss events at the packet level and considers missing
packets as unrepaired. But different from RTCP NACK, the Feedback
Storm Suppression can only be forwarded by the intermediate node to
the receivers impacted by packet loss or generated directly at the
intermediate node and sent to the corresponding receivers.
Note that the feedback storm suppression should collectively work
together with feedback to repair the lost source packets. Thus, the
delay for the receiver to recover from the packet loss can be reduced
and the risk of increasing network congestion can be mitigated or
diminished. The receiver may send a Feedback message before
receiving the indication but will not need to resend the Feedback
message after receiving the indication. Also the idea of Feedback
Storm Suppression can be further extended when a distributed content
distribution network (CDN) are considered. That is to say several
intermediate node and media senders may constitute hierarchical
model. In this distributed content distribution environment, the
Feedback Storm Suppression not only can be used to suppress all the
receivers behind itself not to send packet loss request but also
suppress the neighboring node not to send packet loss request for the
missing packets via unicast. How the neighboring node is discovered
is beyond scope of this document.
This document registers two new RTCP receiver report messages for
Feedback Storm Suppression. Applications that are employing one or
Wu, et al. Expires December 12, 2010 [Page 5]
Internet-Draft Feedback Storm Suppression June 2010
more loss-repair methods MAY use feedback Storm Suppression together
with these loss-repair methods for every packet they receive or for a
set of specific packets they have received.
Note: The draft focus on the SSM case. The video MCU has similar
issue with packet loss since the MCU need to multi-unicast the stream
from the source to all participants and may have the same problem
when packets are lost between the source and the MCU. If the
consensus is that the only relevant use case is the NACK implosion we
can look at adding semantics to NACK for this case. Otherwise we can
expand the text on the video packet loss case.
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].
Upstream RTP Client:
The RTP Client located in the upstream from the distribution
source as described in [DVB-IPTV]. This Client is able to detect
upstream packet loss impacting all the RTP receivers serviced by
the distribution source and receiving SSM service.
Immediate reporting RTP Client:
The RTP Client located in the downstream aggregate link from the
distribution source as described in [DVB-IPTV]. This Client is
able to detect downstream packet loss in the aggregate link
impacting all the RTP receivers serviced by the distribution
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 distribution
source. The function of the loss reporter may be collocated or
integrated in the same entity. In this case, for a session
defined as having a Distribution 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 Distribution Source A on
port k. The loss reporter MAY also be implemented in one or more
entities different from the Distribution Source. In this case,
the loss reporter may be an upstream RTP client or immediate
reporting RTP client located in the downstream aggregate link of
distribution source.
Wu, et al. Expires December 12, 2010 [Page 6]
Internet-Draft Feedback Storm Suppression June 2010
3. Basic Operation
As described in [RFC5760], one or more Media Senders send RTP packets
to the Distribution Source. The Distribution Source relays the RTP
packets to the receivers using a source-specific multicast
arrangement. In case of upstream packet loss or downstream aggregate
link packet loss, the Loss reporter located in the upstream link or
downstream aggregate link may send extended receiver report described
in section 6 indicating the packet loss to the distribution source.
And then the distribution source creates packet loss suppression
report and transmits it to all the RTP receivers, using source-
specific multicast. The distribution source can ask for
retransmission of the lost packets from the media sender on behalf of
all the RTP receivers. Upon receiving the lost packet, the
distribution source forwards them to all the receivers which are
impacted by packet loss.
When the loss reporter(s) are collocated with distribution source,
redistribution of packet loss report is trivial. In such case, loss
reporter should detect contiguous packet loss coming from upstream
link by checking sequence number of RTP packets. Also the loss
reporter may detect contiguous packet loss occurring in the
collocated distribution source using the similar method mentioned
above. When the loss reporter(s) are physically and(or)
topologically distinct from distribution source, each loss reporter
MUST create packet loss report at the RTP layer and send it to the
distribution source. The loss reporters may be upstream client or
downstream immediate reporter who is dedicated to detect and report
packet loss.
The Distribution Source MUST be able to communicate with all group
members in order for either mechanism to work. The general
architecture is displayed below in Figure 1
Wu, et al. Expires December 12, 2010 [Page 7]
Internet-Draft Feedback Storm Suppression June 2010
+--------+ +------------+ Source-specific
|Media | | | Multicast
|Sender 1|<------->| | +----------------> R(1)
+--------+ | | |
| | +--+
+--------+ |DISTRIBUTION| | |
|Media |<------->| SOURCE | | +-----------> R(2)
|Sender 2| | |->+ +---- :
+--------+ | | | +------> R(n-1)
: | | | |
: | +--------+ | +--+--> R(n)
| |Feedback| |
+--------+ +---->| Target | |
|Media | | | +--------+ |
|Sender M|<----+-->| |
+--------+ | +------------+
|
|
|Unicast+--------+
+-------+ Loss |
|Reporter|
+--------+
Transport from the Loss Reporter to the Distribution
Source is via unicast feedback if they are not
co-located.
Figure 1: System Architecture
In this figure, we assume the distribution source is separated from a
particular media sender and the Feedback Target is collocated with
Distribution source. The communication between the Media sender and
the distribution source is compliant with the ways described in
[RFC5760]. Also besides following the configuration information
described in [RFC5760], the additional configuration information
should be supplied as follows:
o The Loss Reporters know the addresses of their respectively
responsible Feedback Targets.
As outlined in the [RFC5760], there are two Unicast Feedback models
that are used for reporting, i.e., Simple Feedback model and
Distribution Source Feedback Summary Model. The RTCP receiver report
extension specified in the section 6 of this document will work in
both two Feedback models.
Wu, et al. Expires December 12, 2010 [Page 8]
Internet-Draft Feedback Storm Suppression June 2010
4. Simple Feedback Model
In the simple Feedback Model, the Loss reporter(s) are disjoint from
distribution source. In this case, the upstream client or immediate
reporting receiver may be chosen as the loss reporter. Also in this
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
As one dedicated receiver for packet loss reporting, the Loss
reporter 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 MUST
use the same packet types as traditional RTCP feedback described in
[RFC3550]and generate Receiver 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
Receiver Feedback Report packet from the loss reporter, the
Distribution Source MUST forward it to the group on the multicast
RTCP channel. 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 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 the duplicated packet loss request out and only
forward one copy of the receiver Feedback report packet from the
first loss reporter to the group impacted by packet loss.
Because this unicast Receiver Feedback Report is used to let the
receivers/hosts know that Feedback for 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 packet, the
Distribution Source MUST not forward this RTCP packets received from
the receivers to the Media Sender(s).
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
Wu, et al. Expires December 12, 2010 [Page 9]
Internet-Draft Feedback Storm Suppression June 2010
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,
the distribution source MUST filter it out until the Retransmission
stream is ready in the Distribution Source.
5. Distribution Source Feedback Summary Model
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
integrated in 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] or generates the new Receiver 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
Receiver 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 Receiver Feedback Reports generated
by the Dedicated receivers together with the information generated by
the loss reporter integrated in the distribution source and then
create the summary report to include these information. In order to
reduce the processing load at the distribution source, the individual
instance of Loss Reporter may provide preliminary summarization
report.
In some case, the distribution source may receive RTCP NACK messages
Wu, et al. Expires December 12, 2010 [Page 10]
Internet-Draft Feedback Storm Suppression June 2010
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,
the distribution source MUST filter it out until the Retransmission
stream is ready in the Distribution Source.
6. RTCP Receiver Feedback Report Extension
6.1. Transport Layer Feedback Message
6.1.1. NACK implosion Suppression Summary report
The NACK implosion Suppression message is an extension to the RTCP
receiver 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
Wu, et al. Expires December 12, 2010 [Page 11]
Internet-Draft Feedback Storm Suppression June 2010
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].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLSN | LLSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Starting Sequence Number (SSN):16bits
The SSN field is used to specify the contiguous packet loss. The
SSN field refers to the RTP sequence number of the first lost
packet.
Last Sequence Number (LSN): 16 bits
The LSN field is used to specify the contiguous packet loss. The
LSN refers to the RTP sequence number of the last lost packet.
6.2. Payload Specific Feedback Message
6.2.1. FIR implosion Suppression Summary 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
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].
The format is shown in Figure 3.
Wu, et al. Expires December 12, 2010 [Page 12]
Internet-Draft Feedback Storm Suppression June 2010
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.
7. 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] using the Augmented Backus-Naur Form (ABNF)
[RFC4585].
The "fss" feedback value SHOULD be used with parameters that indicate
the feedback suppression supported. In this document, we define two
such parameters, namely:
o "fsei" denotes support of fir suppression early indication (fsei).
o "nsei" denotes support of NACK suppression early indication
In the ABNF for rtcp-fb-val defined in [RFC4585], 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] for complete ABNF syntax).
Wu, et al. Expires December 12, 2010 [Page 13]
Internet-Draft Feedback Storm Suppression June 2010
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] for a detailed description and the
full syntax of the "rtcp-fb" attribute.
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].
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:
Wu, et al. Expires December 12, 2010 [Page 14]
Internet-Draft Feedback Storm Suppression June 2010
Qin Wu
sunseawq@huawei.com
Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd.
Nanjing, JiangSu 210001 China
9. Acknowledgement
The authors would like to thank Tom David R Oran,Tom VAN CAENEGEM for
their valuable comments and suggestions on this document.
10. References
10.1. Normative References
[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.
[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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[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.
Wu, et al. Expires December 12, 2010 [Page 15]
Internet-Draft Feedback Storm Suppression June 2010
10.2. Informative References
[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".
Appendix A. Example scenarios for Retransmission Storm Suppression
A.1. Scenario 1: One or more media sender,One distribution source
The general architecture for scenario 1 is displayed below in
Figure 4. 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
Wu, et al. Expires December 12, 2010 [Page 16]
Internet-Draft Feedback Storm Suppression June 2010
A.2. Scenario 2:One media sender, Two distribution sources in cascade
+-------+
|---->|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. 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.
A.3. Scenario 3:One media sender, Two distribution sources in parallel
The general architecture for scenario 3 is displayed below in
Figure 6. 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.
Wu, et al. Expires December 12, 2010 [Page 17]
Internet-Draft Feedback Storm Suppression June 2010
+--------+
|---->|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
Appendix B. Applicability of Feedback Storm Suppression
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 for Retransmission Storm Suppression.
Applicability of Retransmission Storm Suppression in Scenario 1
described in Figure 4 is shown in the Figure 7. 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.
Wu, et al. Expires December 12, 2010 [Page 18]
Internet-Draft Feedback Storm Suppression June 2010
+------+ +--------------+ +--------+
|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
Applicability of Feedback Storm Suppression in Scenario 2 or 3
described in Figure 5 and Figure 6 is shown in the Figure 8. The
procedure in the Figure 8 is similar to the one in the figure
Figure 7. The only difference is distribution source should not only
notify all the receiver behind itself not to send NACK but also
propagate the retransmission suppression indication to the
neighboring distribution sources. In this way, all the receivers
behind all the neighboring distribution source can avoid sending
massive retransmission request to the media sender.
Wu, et al. Expires December 12, 2010 [Page 19]
Internet-Draft Feedback Storm Suppression June 2010
+------+ +-------+ +--------+ +-------+ +--------+
|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
Wu, et al. Expires December 12, 2010 [Page 20]
Internet-Draft Feedback Storm Suppression June 2010
Authors' Addresses
Qin Wu
Huawei
Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-25-84565892
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
Wu, et al. Expires December 12, 2010 [Page 21]