Network Working Group Q. Wu
Internet-Draft F. Xia
Intended status: Standards Track R. Even
Expires: May 12, 2011 Huawei
November 8, 2010
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
Wu, et al. Expires May 12, 2011 [Page 1]
Internet-Draft Feedback Suppression November 2010
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 May 12, 2011 [Page 2]
Internet-Draft Feedback Suppression November 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 6
4.1. Transport Layer Feedback: NACK Suppression Report . . . . 6
4.2. Payload Specific Feedback: FIR suppression report . . . . 7
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9
6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 10
6.1.2. Distribution Source Feedback Summary Model . . . . . . 11
6.2. Unicast based Rapid Acquisition of Multicast Stream
(RAMS) use case . . . . . . . . . . . . . . . . . . . . . 12
6.3. RTP transport translator use case . . . . . . . . . . . . 12
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Wu, et al. Expires May 12, 2011 [Page 3]
Internet-Draft Feedback Suppression November 2010
1. Introduction
RTCP feedback messages [RFC4585] 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] as a packet loss recovery technique based,
sending feedback using RTCP NACK messages [RFC4585] 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]. 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]), 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], 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
Wu, et al. Expires May 12, 2011 [Page 4]
Internet-Draft Feedback Suppression November 2010
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].
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.
Wu, et al. Expires May 12, 2011 [Page 5]
Internet-Draft Feedback Suppression November 2010
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
Wu, et al. Expires May 12, 2011 [Page 6]
Internet-Draft Feedback Suppression November 2010
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].
The format is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Message Format for the NSEI report
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].
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].
The format is shown in Figure 2.
Wu, et al. Expires May 12, 2011 [Page 7]
Internet-Draft Feedback Suppression November 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 2: Message Format for the FSEI report
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] 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 May 12, 2011 [Page 8]
Internet-Draft Feedback Suppression November 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.
6. Example Use Cases
The operation of feedback suppression is similar for all types of RTP
sessions and topologies [RFC5117], 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], 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
Wu, et al. Expires May 12, 2011 [Page 9]
Internet-Draft Feedback Suppression November 2010
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], 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] 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
Wu, et al. Expires May 12, 2011 [Page 10]
Internet-Draft Feedback Suppression November 2010
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.
Wu, et al. Expires May 12, 2011 [Page 11]
Internet-Draft Feedback Suppression November 2010
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]
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.
Wu, et al. Expires May 12, 2011 [Page 12]
Internet-Draft Feedback Suppression November 2010
6.4. Multipoint Control Unit (MCU) use case
In point to multipoint topologies using video switching MCU (Topo-
Video-switch-MCU) [RFC5117], 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] and AVPF
into SAVPF [RFC5124].
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
Wu, et al. Expires May 12, 2011 [Page 13]
Internet-Draft Feedback Suppression November 2010
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].
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
Wu, et al. Expires May 12, 2011 [Page 14]
Internet-Draft Feedback Suppression November 2010
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
[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.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Wu, et al. Expires May 12, 2011 [Page 15]
Internet-Draft Feedback Suppression November 2010
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
10.2. Informative References
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", November 2009.
[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".
Authors' Addresses
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
Wu, et al. Expires May 12, 2011 [Page 16]
Internet-Draft Feedback Suppression November 2010
Roni Even
Huawei
14 David Hamelech
Tel Aviv 64953
Israel
Email: even.roni@huawei.com
Wu, et al. Expires May 12, 2011 [Page 17]