Network Working Group                                              Q. Wu
Internet-Draft                                                    F. Xia
Intended status: Standards Track                                 R. Even
Expires: April 28, 2011                                           Huawei
                                                        October 25, 2010


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

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 April 28, 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 April 28, 2011                 [Page 1]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                 [Page 2]


Internet-Draft            Feedback Suppression              October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   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 April 28, 2011                 [Page 3]


Internet-Draft            Feedback Suppression              October 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 and can provide
   an early indication before the receiver reacts to the loss and
   invokes its packet loss repair machinery.


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].




Wu, et al.               Expires April 28, 2011                 [Page 4]


Internet-Draft            Feedback Suppression              October 2010


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.

   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.  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.  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



Wu, et al.               Expires April 28, 2011                 [Page 5]


Internet-Draft            Feedback Suppression              October 2010


   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.

   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.  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.


4.  RTCP Feedback Report Extension

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

4.1.  Transport Layer Feedback:  NACK Suppression Report

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

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

   The Feedback Control Information (FCI) for NSEI uses the similar
   format of message Types defined in the section 4.3.1.1 of [RFC5104].
   The format is shown in Figure 1.





Wu, et al.               Expires April 28, 2011                 [Page 6]


Internet-Draft            Feedback Suppression              October 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                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            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 April 28, 2011                 [Page 7]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                 [Page 8]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                 [Page 9]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 10]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 11]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 12]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 13]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 14]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 15]


Internet-Draft            Feedback Suppression              October 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 April 28, 2011                [Page 16]


Internet-Draft            Feedback Suppression              October 2010


   Roni Even
   Huawei
   14 David Hamelech
   Tel Aviv 64953
   Israel

   Email: even.roni@huawei.com












































Wu, et al.               Expires April 28, 2011                [Page 17]