Network Working Group                                              Q. Wu
Internet-Draft                                                    F. Xia
Intended status: Standards Track                                 R. Even
Expires: October 1, 15, 2012                                         Huawei
                                                          March 30,
                                                          April 13, 2012

               RTCP Extension for Third-party Loss Report
             draft-ietf-avtcore-feedback-supression-rtp-16
             draft-ietf-avtcore-feedback-supression-rtp-17

Abstract

   In a large RTP session using the RTCP RTP Control Protocol (RTCP) feedback
   mechanism defined in RFC 4585, a feedback target may experience
   transient overload if some event causes a large number of receivers
   to send feedback at once.  This overload is usually avoided by
   ensuring that feedback reports are forwarded to all receivers,
   allowing them to avoid sending duplicate feedback reports.  However,
   there are cases where it is not recommended to forward feedback
   reports, and this may allow feedback implosion.  This memo discusses
   these cases and defines a new RTCP third-party loss report that can
   be used to inform receivers that the feedback target is aware of some
   loss event, allowing them to suppress feedback.  Associated SDP signalling
   signaling is also defined.

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 October 1, 15, 2012.

Copyright Notice

   Copyright (c) 2012 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   3.  Protocol Overview  Example Use Cases  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Format of RTCP Feedback Messages
     3.1.  Source Specific Multicast (SSM) use case . . . . . . . . .  5
     3.2.  Unicast based Rapid Acquisition of Multicast Stream
           (RAMS) use case  . . . . . . .  6
     4.1.  Transport Layer Feedback:  Third-Party Loss Report
           (TPLR) . . . . . . . . . . . . . .  6
     3.3.  RTP Transport Translator use case  . . . . . . . . . . . .  6
     4.2.  Payload Specific Feedback: Third-Party Loss Report
           (TPLR) .
     3.4.  Multipoint Control Unit (MCU) use case . . . . . . . . . .  6
     3.5.  Mixer use case . . . . . . . . . . . . . . .  7
   5.  SDP Signaling . . . . . . .  6
   4.  Protocol Overview  . . . . . . . . . . . . . . . . .  8
   6.  Example Use Cases . . . . .  7
   5.  Format of RTCP Feedback Messages . . . . . . . . . . . . . . .  8
     5.1.  Transport Layer Feedback:  Third-Party Loss Report
           (TPLR) . .  9
     6.1.  Source Specific Multicast (SSM) use case . . . . . . . . .  9
     6.2.  Unicast based Rapid Acquisition of Multicast Stream
           (RAMS) use case . . . . . . . . . . . . . . .  8
     5.2.  Payload Specific Feedback: Third-Party Loss Report
           (TPLR) . . . . . . 10
     6.3.  RTP Transport Translator use case . . . . . . . . . . . . 10
     6.4.  Multipoint Control Unit (MCU) use case . . . . . . . .  9
   6.  SDP Signaling  . . 10
     6.5.  Mixer use case . . . . . . . . . . . . . . . . . . . . . . 11 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgement  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 14
     A.1.  draft-ietf-avtcore-feedback-suppression-rtp-01  draft-ietf-avtcore-feedback-suppression-rtp-17 . . . . . . 14
     A.2.  draft-ietf-avtcore-feedback-suppression-rtp-02  draft-ietf-avtcore-feedback-suppression-rtp-16 . . . . . . 14
     A.3.  draft-ietf-avtcore-feedback-suppression-rtp-03  draft-ietf-avtcore-feedback-suppression-rtp-15 . . . . . . 15 14
     A.4.  draft-ietf-avtcore-feedback-suppression-rtp-04  draft-ietf-avtcore-feedback-suppression-rtp-14 . . . . . . 15 14
     A.5.  draft-ietf-avtcore-feedback-suppression-rtp-05  draft-ietf-avtcore-feedback-suppression-rtp-13 . . . . . . 15
     A.6.  draft-ietf-avtcore-feedback-suppression-rtp-06  draft-ietf-avtcore-feedback-suppression-rtp-12 . . . . . . 16 15
     A.7.  draft-ietf-avtcore-feedback-suppression-rtp-07  draft-ietf-avtcore-feedback-suppression-rtp-11 . . . . . . 16 15
     A.8.  draft-ietf-avtcore-feedback-suppression-rtp-08  draft-ietf-avtcore-feedback-suppression-rtp-10 . . . . . . 16 15
     A.9.  draft-ietf-avtcore-feedback-suppression-rtp-09 . . . . . . 16 15
     A.10. draft-ietf-avtcore-feedback-suppression-rtp-10 draft-ietf-avtcore-feedback-suppression-rtp-08 . . . . . . 17 16
     A.11. draft-ietf-avtcore-feedback-suppression-rtp-11 draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 17 16
     A.12. draft-ietf-avtcore-feedback-suppression-rtp-12 draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 17 16
     A.13. draft-ietf-avtcore-feedback-suppression-rtp-13 draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 17 16
     A.14. draft-ietf-avtcore-feedback-suppression-rtp-14 draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 17
     A.15. draft-ietf-avtcore-feedback-suppression-rtp-15 draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 18 17
     A.16. draft-ietf-avtcore-feedback-suppression-rtp-16 draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 18
     A.17. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1.  Introduction

   RTCP

   The RTP Control Protocol (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 when using unicast
   RTCP feedback with SSM [RFC5760]).  There are cases where multiple
   receivers may initiate the same, or an equivalent message towards the
   same media source or the same feedback target.  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 scenario that can cause of such a feedback storms involves video Fast
   Update requests.  A storm is receivers
   utilizing RTP retransmission [RFC4588] as a packet loss recovery
   technique, sending feedback using RTCP NACK messages [RFC4585]
   without proper dithering of the retransmission requests (e.g., not
   implementing the RFC 4585 dithering rules or sending NACKs to a
   feedback target that doesn't redistribute them to other receivers).

   Another use case involves video Fast Update requests.  A storm of
   these of these feedback messages can occur in
   conversational multimedia scenarios like multipoint video switching
   conference [RFC4587].  In
   this scenario, the receiver [RFC4587], where many receivers may simultaneously lose
   synchronization with the video stream when the speaker is changed in
   the middle of a session.  Poorly
   designed receivers  Receivers that blindly issue fast update requests
   (i.e., Full Intra Request (FIR) described in RFC5104 [RFC5104]), can
   cause an implosion of FIR requests from receivers to the same media source.
   source since these requests must currently be made blind, without
   knowledge of requests made by other receivers.

   RTCP feedback storms may cause short term overload, and in extreme
   cases to pose a possible risk of increasing network congestion on the
   control channel (e.g. (e.g., RTCP feedback), the data channel, or both.  It
   is therefore desirable to provide a way of suppressing unneeded
   feedback.  This document specifies a new third-party loss report for
   this function.  It supplements the existing the use of RTCP NACK
   packet and further is more precise in the uses where the network is
   active to suppress feedback.  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.  Section 6 3 provides
   some examples example use cases of when to send the Third-Party Loss Report
   message.

2.  Requirements Notation

   The key words "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 [RFC2119].

2.1.  Glossary
   TPLR  - Third-Party Loss Report
   TLLEI - Transport Layer Third-Party Loss Early Indication
   PSLEI - Payload Specific Third-Party Loss Early Indication
   FCI   - Feedback Control Information [RFC4585]
   AVPF  - The Audio-Visual Profile with RTCP-based feedback [RFC4585]
   SSRC  - Synchronization Source
   BRS   - Burst/Retransmission Sources [RFC6285]
   FIR   - Full Intra Request [RFC5104]
   PLI   - Picture Loss Indication [RFC4585]
   SSM   - Source Specific Multicast [RFC5760]
   RAMS  - Unicast based Rapid Acquisition of Multicast Stream [RFC6285]
   MCU   - Multipoint Control Unit [RFC5117]

3.  Protocol Overview

   This document extends the RTCP  Example Use Cases

   The operation of feedback suppression is similar for all types of RTP
   sessions and topologies [RFC5117], however the exact messages defined used
   and the scenarios in which suppression is employed differ for various
   use cases.  The following sections outline some of the intended use
   cases for using the RTP/
   AVPF [RFC4585] defining a RTCP Third-Party Loss Report (TPLR)
   message.  The RTCP TPLR message can be used by for feedback suppression
   and give an overview of the intermediaries particular mechanisms.

3.1.  Source Specific Multicast (SSM) use case

   In SSM RTP sessions as described in "RTP Control Protocol (RTCP)
   Extensions for Single-Source Multicast Sessions with Unicast
   Feedback" [RFC5760], one or more Media Sources send RTP packets to
   inform a
   Distribution Source.  The Distribution Source relays the receiver that RTP packets
   to the sender of receivers using a source-specific multicast group.

   As outlined in the RTCP TPLR has received
   reports RFC5760 [RFC5760], there are two Unicast Feedback
   models that may be used for reporting, the indicated packets were lost, Simple Feedback model and asks
   the receiver
   not to send feedback to it regarding these packets.  Intermediaries
   are variously referred to as Distribution source, Burst/
   Retransmission Sources (BRS), MCUs, RTP translator, or RTP mixers,
   depending on Source Feedback Summary Model.  In the precise use case described Section 6.

   RTCP TPLR follows simple
   Feedback Model, there's no need for distribution source to create the similar format of message type as
   RTCP NACK or
   Full Intra Request Command.  However, the TPLRs, instead, RTCP TPLR is defined as an
   indication that NACKs are reflected by the sender of distribution
   source to the feedback has received reports that other Receivers.  However in the indicated packets were lost, while NACK [RFC4585] just indicates
   that Distribution Source
   Feedback Summary model, the sender of distribution source will not redistribute
   the NACK observed that these packets were lost.
   The for some reason(e.g., to prevent revealing the identity or
   existence of a system sending NACK)and may send an RTCP TPLR message is generated by an intermediary
   to the systems that may not
   have seen were unable to receive the actual packet loss.  It is sent following NACK, and won't
   receive the same
   timing rule as sending NACK defined in RFC4585 [RFC4585]. via other means.  The RTCP TPLR message may can be sent in a regular full compound RTCP packet or in
   an early RTCP packet, as per generated at
   the RTP/AVPF rules.  Intermediaries in distribution source when downstream loss is reported (e.g.,
   downstream loss report is received), which indicates to the network receivers
   that receive a RTCP TPLR SHOULD NOT send their own
   additional Third-Party Loss Report they should not transmit feedback messages for the same packet
   sequence numbers.  They SHOULD simply forward loss
   event for a certain time.  Therefore the distribution source in the
   feedback summary model can be reasonably certain that it will help
   the situation (i.e., unable receive the NACK) by sending this RTCP
   TPLR message
   received from upstream direction to all the receiver(s), additionally,
   they may generate their own RTCP TPLR that reports a set of the
   losses they see, which are different from ones reported in relevant receivers impacted by the RTCP
   TPLR they received. packet
   loss.

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

   The RTCP TPLR does not typical RAMS architecture [RFC6285] may have several Burst/
   Retransmission Sources(BRS) behind the retransmission
   request [RFC4588] semantics.

   When a receiver gets a RTCP TPLR message, it MUST follow the rules
   for NACK suppression in RFC4585 [RFC4585]and refrain from sending a
   feedback request (e.g., NACK or FIR) for the missing packets reported
   in the message,which is dealt with in multicast source (MS) placed
   at the same way as receiving NACK.

   To increase level.  These BRSes will receive the robustness to primary multicast
   RTP stream from the loss of a TPLR, The RTCP TPLR may
   be retransmitted. media source and cache most recent packets after
   joining multicast session.  If the additional TPLR arrives packet loss happens at receiver, the
   receiver SHOULD deal with upstream of
   all the additional TPLR in BRSs or the same way as
   receiving downstream of BRSes.  One of the first TPLR for BRSes or all the same packet and no additional
   behavior for receiver is required.

   A receiver
   BRSes may have sent a Feedback send an RTCP NACK or RTCP TPLR message according to the RTP/AVPF
   scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP
   TPLR message, but further feedback messages for those sequence
   numbers SHOULD be suppressed after receiving DS, where the
   SSRC in this RTCP TPLR.  Nodes
   that do not understand the NACK or RTCP TPLR message will ignore it, and
   might therefore still send feedback according to is the AVPF scheduling
   algorithm of RFC4585 [RFC4585].  The media source or intermediate
   nodes cannot be certain BRS that is
   sending the use of a RTCP TPLR message.  The DS forwards/reflects this message actually
   reduces down on
   the amount of feedback it receives.

4.  Format of RTCP Feedback Messages

   This document introduces two new RTCP Feedback messages for Third
   Party Loss Report.  Applications that are employing one or more loss-
   repair methods MAY primary SSM.  The details on how DS deal with this message is
   specified in [RETRANSMISSION-FOR-SSM].

3.3.  RTP Transport Translator use case

   A Transport Translator (Topo-Trn-Translator), as defined in RFC5117
   [RFC5117] is typically forwarding the RTP and RTCP TPLR together with their existing
   loss-repair methods either traffic between
   RTP clients, for every packet they expect example converting from multicast to receive,
   or unicast for an application-specific subset of the RTP packets in a
   session.
   domains that do not support multicast.  The following two sections each define translator may suffer a
   loss of important video packets.  In this case, the translator may
   forward RTCP TPLR message.  Both
   messages are feedback messages as defined message received from upstream in section 6.1 the same way as
   forwarding other RTCP traffic.  If the translator acting as the
   monitor [MONARCH] is aware of RFC4585
   [RFC4585], and packet loss, it may use the header format defined there.  Each section
   defines how to populate the PT, FMT,length SSRC of
   monitor as packet sender, sender SSRC of media source, and FCI fields in that header.

4.1.  Transport Layer Feedback:  Third-Party Loss Report (TPLR)

   This TPLR to create NACK message is identified by RTCP packet type value PT=RTPFB and FMT=TBA1.

   Within send it to
   the common receivers that are not aware of packet header for feedback messages (as defined in
   section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field
   indicates loss.

3.4.  Multipoint Control Unit (MCU) use case

   When the source of speaker is changed in a voice-activated multipoint video
   switching conference [RFC4587], an RTP mixer can be used to select
   the request, available input streams and forward them to each participants.
   If the "SSRC of media source"
   denotes MCU is doing a blind switch without waiting for a
   synchronization point on the media sender of new stream it can send a FIR to the flow for which new
   video source.  In this case the indicated losses
   are being suppressed.

   The Feedback Control Information (FCI) field MUST contain one or more
   entries of transport layer third-party loss Early Indication (TLLEI).
   Each entry applies MCU should send a FIR suppression
   message to the same media source identified by new receivers: e.g., when the SSRC
   contained RTP Mixer starts to
   receive FIR from some participants it can suppress the remaining
   session participants from sending FIR by sending out an RTCP TPLR
   message.

3.5.  Mixer use case

   A Mixer, in accordance with RFC5117 [RFC5117], aggregates multiple
   RTP streams from other session participants and generates a new RTP
   stream sent to the SSRC of session participants.  In some cases, the video
   frames delivery may get damaged, for example due to packet loss or
   delayed delivery, between media source field of Feedback header.  The
   length field in and the TLLEI feedback message MUST be set mixer.  In such case,
   the mixer need to 2+1*N,
   where N is check if the number packet loss will result in PLI or FIR
   transmissions from most of FCI entries.

   The FCI field for TLLEI uses the similar format of message Types
   defined in group by analyzing the section 6.2.1 of RFC4585 [RFC4585].  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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            PID                |             BLP               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Syntax of an FCI Entry in received video.
   If so the TLLEI Feedback Message

   Packet ID (PID): 16 bits

      The PID field is used to specify a lost packet.  The PID field
      refers to mixer may initiate FIR or PLI towards the RTP sequence number media source on
   behalf of all the lost packet.

   bitmask of lost packets (BLP): 16 bits

      The BLP allows for reporting losses of any of session participants and send out an RTCP TPLR
   message to these session participants that may or are expected to
   send a PLI or FIR.  Alternatively, when the 16 RTP packets
      immediately following mixer starts to receive
   FIR or PLI from some participants and like to suppress the RTP packet indicated remaining
   session participants from sending FIR or PLI by forwarding the PID.  The
      BLP's definition is identical FIR/
   PLI from one session participant to that given others.

4.  Protocol Overview

   This document extends the RTCP feedback messages defined in the section 6.2.1
      of [RFC4585].

4.2.  Payload Specific Feedback: RTP/
   AVPF [RFC4585] defining an RTCP Third-Party Loss Report (TPLR)

   This
   message.  The RTCP TPLR message is identified by RTCP packet type value PT=PSFB and
   FMT=TBA2, which is can be used by the intermediaries to suppress FIR [RFC5104] and PLI [RFC4585].

   Within
   inform the common packet header for feedback messages (as defined in
   section 6.1 of RFC4585 [RFC4585]), receiver that the "SSRC sender of packet sender" field
   indicates the source of RTCP TPLR has received
   reports that the request, indicated packets were lost, and asks the "SSRC of media source"
   is receiver
   not used and SHALL be set to 0.  The SSRCs of the media senders send feedback to
   which this message applies it regarding these packets.  Intermediaries
   are in the corresponding FCI entries.

   The FCI field for a Payload Specific Third-Party Loss Early
   Indication (PSLEI) consists one or more FCI entries.  Each entry
   applies variously referred to a different media Source, identified by its SSRC. as Distribution source, Burst/
   Retransmission Sources (BRS), MCUs, RTP translator, or RTP mixers,
   depending on the
   content of which is depicted in Figure 2.  The length field in precise use case described Section 3.

   RTCP TPLR follows the
   PSLEI feedback similar format of message MUST be set to 2+1*N, where N is type as RTCP NACK or
   Full Intra Request Command.  However, the number of
   FCI entries.

   The format RTCP TPLR 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                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Syntax of defined as an FCI Entry in
   indication that the PSLEI Feedback Message

   Synchronization source (SSRC):32 bits

      The SSRC value sender of the media source feedback has received reports that is already aware, or in
   the process of being made aware, indicated packets were lost, while NACK [RFC4585] just indicates
   that some receiver lost
      synchronization with the media stream and for which sender of the PSLEI
      receiver's own response to any such error is suppressed.

5.  SDP Signaling NACK observed that these packets were lost.
   The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb, RTCP TPLR message is generated by an intermediary that may not
   have seen the actual packet loss.  It is sent following the same
   timing rule as sending NACK defined in the Section 4 of RFC4585 [RFC4585] and [RFC4585].  The RTCP
   TPLR message may be used to
   negotiate sent in a regular full compound RTCP packet or in
   an early RTCP packet, as per the capability to handle specific AVPF commands and
   indications.  The ABNF for rtcp-fb is described RTP/AVPF rules.  Intermediaries in section 4.2 of
   RFC4585 [RFC4585].  In this section, we extend
   the rtcp-fb attribute network that receive an RTCP TPLR MUST NOT send their own
   additional Third-Party Loss Report messages for the same packet
   sequence numbers.  They SHOULD simply forward the RTCP TPLR message
   received from upstream direction to include the commands and indications receiver(s), additionally,
   they may generate their own RTCP TPLR that reports a set of the
   losses they see, which are described for third-
   party loss report different from ones reported in the present document.

   In RTCP
   TPLR they received.  The RTCP TPLR does not have the ABNF [RFC5234] retransmission
   request [RFC4588] semantics.

   When a receiver gets an RTCP TPLR message, it MUST follow the rules
   for rtcp-fb-val defined NACK suppression in RFC4585 [RFC4585],
   the [RFC4585]and refrain from sending a
   feedback type "nack", without parameters, indicates use of the
   Generic request (e.g., NACK feedback format as defined or FIR) for the missing packets reported
   in Section 6.2.1of RFC4585
   [RFC4585].  In this document, we define two parameters that indicate the third-party loss supported for use message, which is dealt with "nack", namely:

   o  "tllei" denotes support of transport layer third-party in the same way as receiving
   NACK.

   To increase the robustness to the loss early
      indication.

   o  "pslei" denotes support of payload specific third-party loss early
      indication. a TPLR, The ABNF RTCP TPLR may
   be retransmitted.  If the additional TPLR arrives at receiver, the
   receiver SHOULD deal with the additional TPLR in the same way as
   receiving the first TPLR for these two parameters the same packet and no additional
   behavior for "nack" receiver is defined here (please
   refer required.

   A receiver may have sent a Feedback message according to section 4.2 the RTP/AVPF
   scheduling algorithm of RFC4585 [RFC4585] before receiving an RTCP
   TPLR message, but further feedback messages for complete ABNF syntax).

           rtcp-fb-val        =/ "nack" rtcp-fb-nack-param
           rtcp-fb-nack-param = SP "tllei"
                                   ;transport layer third party
                                   ; loss early indication
                               / SP "pslei"
                                   ;payload specific third party
                                   ; loss early indication
                               / SP token [SP byte-string]
                                   ; for future commands/indications
           token =     <as defined in section 9 of [RFC4566]>
           byte-string = <as defined in section 4.2 of [RFC4585] >

   Refer those sequence
   numbers SHOULD be suppressed after receiving the RTCP TPLR.  Nodes
   that do not understand the RTCP TPLR message will ignore it, and
   might therefore still send feedback according to Section 4.2 the AVPF scheduling
   algorithm of RFC4585 [RFC4585] for a detailed description
   and [RFC4585].  The media source or intermediate
   nodes cannot be certain that the full syntax use of an RTCP TPLR message actually
   reduces the "rtcp-fb" attribute.

6.  Example Use Cases

   The operation amount of feedback suppression is similar for all types it receives.

5.  Format of RTP
   sessions and topologies [RFC5117], however the exact RTCP Feedback Messages

   This document introduces two new RTCP Feedback messages used
   and the scenarios in which suppression is employed differ for various Third
   Party Loss Report.  Applications that are employing one or more loss-
   repair methods MAY use cases.  The following sections outline some of the intended use
   cases RTCP TPLR together with their existing
   loss-repair methods either for using the Third-Party Loss Report every packet they expect to receive,
   or for feedback suppression
   and give an overview application-specific subset of the particular mechanisms.

6.1.  Source Specific Multicast (SSM) use case

   In SSM RTP sessions as described in "RTP Control Protocol (RTCP)
   Extensions for Single-Source Multicast Sessions with Unicast
   Feedback" [RFC5760], one or more Media Sources send RTP packets to in a
   Distribution Source.
   session.

   The Distribution Source relays following two sections each define an RTCP TPLR message.  Both
   messages are feedback messages as defined in section 6.1 of RFC4585
   [RFC4585], and use the RTP packets header format defined there.  Each section
   defines how to populate the receivers using a source- specific multicast group.

   As outlined PT, FMT, length, SSRC of packet sender,
   SSRC of media source, and FCI fields in the RFC5760 [RFC5760], there are two Unicast Feedback
   models that may be used header.

5.1.  Transport Layer Feedback:  Third-Party Loss Report (TPLR)

   This TPLR message is identified by RTCP packet type value PT=RTPFB
   and FMT=TBA1.

   Within the common packet header for reporting, feedback messages (as defined in
   section 6.1 of RFC4585 [RFC4585]), the Simple Feedback model and "SSRC of packet sender" field
   indicates the Distribution Source Feedback Summary Model.  In source of the simple
   Feedback Model, there's no need for distribution source to create the
   RTCP TPLRs, instead, RTCP NACKs are reflected by the distribution
   source to the other Receivers.  However in request, and the Distribution Source
   Feedback Summary model, "SSRC of media source"
   denotes the distribution source will not redistribute media sender of the NACK flow for some reason(e.g., to prevent revealing which the identity indicated losses
   are being suppressed.

   The Feedback Control Information (FCI) field MUST contain one or
   existence more
   entries of a system sending NACK)and may send a RTCP TPLR message
   to the systems that were unable to receive the NACK, and won't
   receive the NACK via other means.  The RTCP TPLR can be generated at
   the distribution source when downstream loss is reported (e.g.,
   downstream Transport Layer Third-Party loss report is received), which indicates Early Indication (TLLEI).

   Each entry applies to the receivers
   that they should not transmit feedback messages for the same loss
   event for a certain time.  Therefore media source identified by the distribution SSRC
   contained in the SSRC of media source field of Feedback header.  The
   length field in the TLLEI feedback summary model can be reasonably certain that it will help
   the situation (i.e., unable receive the NACK) by sending this RTCP
   TPLR message MUST be set to all the relevant receivers impacted by N+2, where
   N is the packet
   loss.

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

   The typical RAMS architecture [RFC6285] may have several Burst/
   Retransmission Sources(BRS) behind the multicast source (MS) placed
   at FCI field for TLLEI uses the same level.  These BRSes will receive similar format of message Types
   defined in the primary multicast
   RTP stream from section 6.2.1 of RFC4585 [RFC4585].  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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            PID                |             BLP               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Syntax of an FCI Entry in the media source and cache most recent packets after
   joining multicast session.  If packet loss happens at TLLEI Feedback Message

   Packet ID (PID): 16 bits

      The PID field is used to specify a lost packet.  The PID field
      refers to the upstream RTP sequence number of
   all the BRSs or the downstream lost packet.

   bitmask of BRSes.  One lost packets (BLP): 16 bits

      The BLP allows for reporting losses of any of the BRSes or all the
   BRSes may send a RTCP NACK or RTCP TPLR message to 16 RTP packets
      immediately following the DS, where RTP packet indicated by the
   SSRC PID.  The
      BLP's definition is identical to that given in this RTCP NACK or RTCP the section 6.2.1
      of [RFC4585].

5.2.  Payload Specific Feedback: Third-Party Loss Report (TPLR)

   This TPLR message is the BRS that identified by RTCP packet type value PT=PSFB and
   FMT=TBA2, which is
   sending the message.  The DS forwards/reflects this message down on used to suppress FIR [RFC5104] and PLI [RFC4585].

   Within the primary SSM.  The details on how DS deal with this message is
   specified in [RETRANSMISSION-FOR-SSM].

6.3.  RTP Transport Translator use case

   A Transport Translator (Topo-Trn-Translator), as common packet header for feedback messages (as defined in RFC5117
   [RFC5117] is typically forwarding the RTP and RTCP traffic between
   RTP clients, for example converting from multicast to unicast for
   domains that do not support multicast.  The translator may suffer a
   loss
   section 6.1 of important video packets.  In this case, the translator may
   forward RTCP TPLR message received from upstream in the same way as
   forwarding other RTCP traffic.  If the translator acting as RFC4585 [RFC4585]), the
   monitor [MONARCH] is aware "SSRC of packet loss, it may use sender" field
   indicates the SSRC source of
   monitor as packet sender SSRC to create NACK message the request, and send it to the receivers that are not aware "SSRC of packet loss.

6.4.  Multipoint Control Unit (MCU) use case

   When the speaker media source"
   is changed in a voice-activated multipoint video
   switching conference [RFC4587], an RTP mixer can be not used to select
   the available input streams and forward them SHALL be set to each participants.
   If the MCU is doing a blind switch without waiting for a
   synchronization point on 0.  The SSRCs of the new stream it can send a FIR media senders to the new
   video source.  In
   which this case message applies are in the MCU should send corresponding FCI entries.

   The FCI field for a FIR suppression
   message Payload Specific Third-Party Loss Early
   Indication (PSLEI) consists one or more FCI entries.  Each entry
   applies to a different media source, identified by its SSRC. the new receivers. e.g., when
   content of which is depicted in Figure 2.  The length field in the RTP Mixer starts
   PSLEI feedback message MUST be set to
   receive FIR from some participants it can suppress N+2, where N is the remaining
   session participants from sending FIR by sending out a RTCP TPLR
   message.

6.5.  Mixer use case

   A Mixer, number of
   FCI entries.

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

      Figure 2: Syntax of an FCI Entry in accordance with RFC5117 [RFC5117], aggregates multiple
   RTP streams from other session participants and generates a new RTP
   stream sent to the session participants.  In some cases, PSLEI Feedback Message

   Synchronization source (SSRC): 32 bits

      The SSRC value of the video
   frames may get badly screwed up between media source that is already aware, or in
      the process of being made aware, that some receiver lost
      synchronization with the media stream and for which the mixer.
   In PSLEI
      receiver's own response to any such case, error is suppressed.

6.  SDP Signaling

   The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb,
   is defined in the mixer need Section 4 of RFC4585 [RFC4585] and may be used to check if
   negotiate the packet loss will result capability to handle specific AVPF commands and
   indications.  The ABNF for rtcp-fb is described in PLI or FIR transmissions from most section 4.2 of
   RFC4585 [RFC4585].  In this section, we extend the group by analyzing rtcp-fb attribute
   to include the
   received video.  If so commands and indications that are described for third-
   party loss report in the mixer may initiate FIR or PLI towards present document.

   In the
   media source on behalf ABNF [RFC5234] for rtcp-fb-val defined in RFC4585 [RFC4585],
   the feedback type "nack", without parameters, indicates use of the
   Generic NACK feedback format as defined in Section 6.2.1of RFC4585
   [RFC4585].  In this document, we define two parameters that indicate
   the third-party loss supported for use with "nack", namely:

   o  "tllei" denotes support of Transport Layer Third-Party Loss Early
      Indication.

   o  "pslei" denotes support of Payload Specific Third-Party Loss Early
      Indication.

   The ABNF for these two parameters for "nack" is defined here (please
   refer to section 4.2 of RFC4585 [RFC4585] for complete ABNF syntax).

           rtcp-fb-val        =/ "nack" rtcp-fb-nack-param
           rtcp-fb-nack-param = SP "tllei"
                                   ;transport layer third party
                                   ; loss early indication
                               / SP "pslei"
                                   ;payload specific third party
                                   ; loss early indication
                               / SP token [SP byte-string]
                                   ; for future commands/indications
           token =     <as defined in section 9 of all the session participants and send out a
   RTCP TPLR message to these session participants that may or are
   expected [RFC4566]>
           byte-string = <as defined in section 4.2 of [RFC4585] >

   Refer to send Section 4.2 of RFC4585 [RFC4585] for a PLI or FIR.  Alternatively, when the mixer starts
   to receive FIR or PLI from some participants detailed description
   and like to suppress the
   remaining session participants from sending FIR or PLI by forwarding full syntax of the FIR/PLI from one session participant to others. "rtcp-fb" attribute.

7.  Security Considerations

   The security considerations documented in [RFC4585] are also
   applicable for the TPLR messages defined in this document.

   More specifically, spoofed or maliciously created TPLR feedback
   messages cause missing RTP packets to not be repaired in a timely
   fashion and add risk of (undesired) feedback supression suppression at RTCP
   receivers that accept such TPLR messages.  Any packet loss detected
   by a receiver and where this RTP receiver also receives a TPLR
   message for the same missing packet(s), will negatively impact the
   application that relies on the (timely) RTP retransmission
   capabilities.

   A solution to prevent such attack with maliciously sent TPLR
   messages, is to apply an authentication and integrity protection
   framework for the feedback messages.  This can be accomplished using
   the RTP profile that combines Secure RTP [RFC3711] and AVPF into
   SAVPF [RFC5124].

   Note that intermediaries that are not visible at the RTP layer that
   wish to send the Third-Party Loss 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 intermediary is
   visible at the RTP layer, this is not an issue, provided the
   intermediary is part of the security context for the session.

8.  IANA Consideration

   This document instructs IANA to add two values to the '"ack" and
   "nack" Attribute Values' sub-registry [RFC4585] of the 'Session
   Description Protocol (SDP) Parameters' registry.

 The value registration for the attribute value "nack":

      Value name:     tllei
      Long name:      Transport Layer Third-Party Loss Early Indication
      Usable with:    nack
      Reference:      RFC 4585.

      Value name:     pslei
      Long name:      Payload Specific Third-Party Loss Early Indication
      Usable with:    nack
      Reference:      RFC 4585.

   The following value have been registered as one FMT value in the "FMT
   Values for RTPFB Payload Types" registry located at the time of
   publication at: http://www.iana.org/assignments/rtp-parameters

     RTPFB range
     Name           Long Name                         Value  Reference
     -------------- --------------------------------- -----  ---------
     TLLEI         Transport Layer Third-Party         TBA1   [RFCXXXX]
                   Loss Early Indication

   The following value have been registered as one FMT value in the "FMT
   Values for PSFB Payload Types" registry located at the time of
   publication at: http://www.iana.org/assignments/rtp-parameters

     PSFB range
     Name            Long Name                        Value Reference
     -------------- --------------------------------- -----  --------
     PSLEI         Payload Specific Third-Party       TBA2   [RFCXXXX]
                   Loss Early Indication

9.  Acknowledgement  Acknowledgments

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

10.  References
10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", 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.

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

   [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

   [RFC6285]  Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
              Based Rapid Acquisition of Multicast RTP Sessions",
              June 2011.

   [MONARCH]  Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures
              for RTP", June 2011.

   [RETRANSMISSION-FOR-SSM]
              Caenegem, T., Steeg, B., and A. Begen, "Retransmission for
              Source-Specific Multicast (SSM) Sessions", May 2011.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

   [RFC4587]  Even, R., "RTP Payload Format for H.261 Video Streams",
              RFC 4587, August 2006.

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

Appendix A.  Change Log

   Note to the RFC-Editor: please remove this section prior to
   publication as an RFC.

A.1.  draft-ietf-avtcore-feedback-suppression-rtp-01  draft-ietf-avtcore-feedback-suppression-rtp-17

   The following are the major changes compared to previous version:

   o  Remove  Editorial changes based on Gen-ART review.

   o  removes the merge report discussion of improper dithering that is less of
      motivation of the current version.

   o  change of the normative language from SSM SHOULD NOT to MUST NOT in
      the protocol overview section.

   o  Move Example use case and additional text section right after Introduction section.

A.2.  draft-ietf-avtcore-feedback-suppression-rtp-16

   The following are the major changes compared to
      address report merging issue. previous version:

   o  Some Editorial changes.

A.3.  draft-ietf-avtcore-feedback-suppression-rtp-15

   The following are the major changes compared to previous version:

   o  Some Editorial changes.

A.4.  draft-ietf-avtcore-feedback-suppression-rtp-14

   The following are the major changes compared to previous version:

   o  Two References moving to normative references.

   o  Revise IANA section 3 and to clarify whether to create new registry or
      add new value to the existing registry.

   o  Revise Security section 6 to address FEC packet dealing issue
      and Leave how clarify ill effect of accepting
      unauthenticated messages.

   o  Add a glossary to repair packet loss beyond fix acronym issue.

   o  Other Editorial changes.

A.5.  draft-ietf-avtcore-feedback-suppression-rtp-13

   The following are the major changes compared to previous version:

   o  Additional Editorial changes.

A.6.  draft-ietf-avtcore-feedback-suppression-rtp-12

   The following are the scope. major changes compared to previous version:

   o  Modify  Additional Editorial changes.

A.7.  draft-ietf-avtcore-feedback-suppression-rtp-11

   The following are the SSM use case and RAMS use case major changes compared to focus on uses. previous version:

   o  Other  Additional Editorial changes.

A.2.  draft-ietf-avtcore-feedback-suppression-rtp-02

A.8.  draft-ietf-avtcore-feedback-suppression-rtp-10

   The following are the major changes compared to previous version:

   o  In Section 4.1, fix typo: change Section 4.3.1.1  Fix the definition of Synchronization source for TPLR in section
      [RFC5104] to section 6.2.1 of [RFC4585].
      4.2.

   o  In Section 3: Clarify how to deal  Associate SDP parameters tllei and pslei with downstream loss using
      Third-party "nack".

   o  Remove the packet loss report and upstream recovery from TPLR loss using NACK. handling part.

   o  Update title and abstract  Other typo fixed.

A.9.  draft-ietf-avtcore-feedback-suppression-rtp-09

   The following are the major changes compared to focus on third-party loss report. previous version:

   o  In Section 6.1: Update this section to explain how third party
      loss report is used  Clarify to deal suppression interval with downstream loss.

   o  In section 6.1.2: Update this section regard to explain how third party
      loss report is used long to deal with downstream loss.

   o  In section 6.2: Rephrase receive
      the text to discuss how BRS deal with

      retransmitted packet.  Treating TPLR in the
      third-party loss report.

A.3.  draft-ietf-avtcore-feedback-suppression-rtp-03 same way as receiving
      NACK.

   o  Replace timer based approach with timeless based approach.

A.10.  draft-ietf-avtcore-feedback-suppression-rtp-08

   The following are the major changes compared to previous version:

   o  In Appendix A, fix typo: Appendix A.  Appendix A.  -> Appendix A.  Clarify which RTT is used and how timer is refreshed in the
      section 3.

   o  Update abstract  Editorial changes to clarify when third-party loss reports should be
      sent instead of NACKs. the Introduction, Protocol Overview, SDP

      Signaling, Message Format, Use case, Security Consideration and
      IANA sections.

   o  Update section 3 Paragraph  Remove Seq Nr field in the figure 2 to differentiate when a third-party
      loss report should be used for payload specific feedback.

   o  References reorganizing.

A.11.  draft-ietf-avtcore-feedback-suppression-rtp-07

   The following are the major changes compared to a NACK. previous version:

   o  Update  Restructuring the protocol overview section 3 Paragraph 3 to explain when media source clarify the round
      trip

      time calculation and receiver behavior to send
      a third-party loss. the additional TPLR.

   o  Move specific rules for section 6.1.1 and  Restructuring the SSM use case section 6.1.2 to section
      6.1 as generic rules focus on the use of
      TPLR.

   o  Editorial changes to the abstract, introduction, message format,
      use cases and delete section 6.1.1.

A.4.  draft-ietf-avtcore-feedback-suppression-rtp-04 IANA sections.

   o  References update

A.12.  draft-ietf-avtcore-feedback-suppression-rtp-06

   The following are the major changes compared to previous version:

   o  Reference Update.

   o  Clarify the use of  A few Editorial changes to the third-party loss report in section 3 and
      section 6.1.1.

A.5. whole document.

A.13.  draft-ietf-avtcore-feedback-suppression-rtp-05

   The following are the major changes compared to previous version:
   o  Remove 3rd and 4th paragraphs of section 6.1 and replaced them
      with 2nd and 3rd paragraphs of section 3.

   o  Remove section 6.1.1.1.

   o  Revise the last paragraph of section 1 to clarify the rationale of
      using new message.

   o  Update RTP transport translator case in section 6.3 to correct the
      use of the third-party loss report.

   o  Update MCU case in section 6.4 to correct the use of the third
      party loss report.

   o  Revise SSM use case to address multiple DS issue.

   o  References Update.

   o  Move one rationale on preventing sending unicast NACK in
      introduction section to SSM case section.

   o  Other Editorial changes to section 6.1, 6.1.1, 6.2.

A.6.  draft-ietf-avtcore-feedback-suppression-rtp-06

   The following are the major changes compared to previous version:

   o  A few Editorial changes to the whole document.

A.7.  draft-ietf-avtcore-feedback-suppression-rtp-07

   The following are the major changes compared to previous version:

   o  Restructuring the protocol overview section to clarify the round
      trip

      time calculation and receiver behavior to the additional TPLR.

   o  Restructuring the SSM use report.

   o  Update MCU case in section 6.4 to focus on correct the use of
      TPLR.

   o  Editorial changes to the abstract, introduction, message format, third
      party loss report.

   o  Revise SSM use cases and IANA sections. case to address multiple DS issue.

   o  References update

A.8.  draft-ietf-avtcore-feedback-suppression-rtp-08

   The following are the major changes compared to previous version: Update.

   o  Clarify which RTT is used and how timer is refreshed  Move one rationale on preventing sending unicast NACK in the
      introduction section 3. to SSM case section.

   o  Other Editorial changes to the Introduction, Protocol Overview, SDP

      Signaling, Message Format, Use case,Security Consideration and
      IANA sections.

   o  Remove Seq Nr field in the figure 2 for payload specific feedback.

   o  References reorganizing.

A.9.  draft-ietf-avtcore-feedback-suppression-rtp-09 section 6.1, 6.1.1, 6.2.

A.14.  draft-ietf-avtcore-feedback-suppression-rtp-04

   The following are the major changes compared to previous version:
   o  Reference Update.

   o  Clarify to suppression interval with regard to how long to receive the

      retransmitted packet.  Treating TPLR in use of the same way as receiving
      NACK.

   o  Replace timer based approach with timeless based approach.

A.10.  draft-ietf-avtcore-feedback-suppression-rtp-10 third-party loss report in section 3 and
      section 6.1.1.

A.15.  draft-ietf-avtcore-feedback-suppression-rtp-03

   The following are the major changes compared to previous version:

   o  Fix the definition of Synchronization source for TPLR in section
      4.2.

   o  Associate SDP parameters tllei and pslei with "nack".  In Appendix A, fix typo: Appendix A.  Appendix A.  -> Appendix A.

   o  Remove the packet loss recovery from TPLR  Update abstract to clarify when third-party loss handling part. reports should be
      sent instead of NACKs.

   o  Other typo fixed.

A.11.  draft-ietf-avtcore-feedback-suppression-rtp-11

   The following are the major changes  Update section 3 Paragraph 2 to differentiate when a third-party
      loss report should be used compared to previous version: a NACK.

   o  Update section 3 Paragraph 3 to explain when media source to send
      a third-party loss.

   o  Additional Editorial changes.

A.12.  draft-ietf-avtcore-feedback-suppression-rtp-12  Move specific rules for section 6.1.1 and section 6.1.2 to section
      6.1 as generic rules and delete section 6.1.1.

A.16.  draft-ietf-avtcore-feedback-suppression-rtp-02

   The following are the major changes compared to previous version:

   o  Additional Editorial changes.

A.13.  draft-ietf-avtcore-feedback-suppression-rtp-13

   The following are the major changes compared  In Section 4.1, fix typo: change Section 4.3.1.1 of section
      [RFC5104] to previous version: section 6.2.1 of [RFC4585].

   o  Additional Editorial changes.

A.14.  draft-ietf-avtcore-feedback-suppression-rtp-14

   The following are the major changes compared  In Section 3: Clarify how to previous version: deal with downstream loss using
      Third-party loss report and upstream loss using NACK.

   o  Two References moving  Update title and abstract to normative refereces. focus on third-party loss report.

   o  Revise IANA  In Section 6.1: Update this section to clarify whether to create new registry or
      add new value explain how third party
      loss report is used to the existing registry. deal with downstream loss.

   o  Revise Security  In section 6.1.2: Update this section to clarify ill effect of accepting
      unauthenticated messages.

   o  Add a glossary explain how third party
      loss report is used to fix acronym issue. deal with downstream loss.

   o  Other Editorial changes.

A.15.  draft-ietf-avtcore-feedback-suppression-rtp-15  In section 6.2: Rephrase the text to discuss how BRS deal with the
      third-party loss report.

A.17.  draft-ietf-avtcore-feedback-suppression-rtp-01

   The following are the major changes compared to previous version:

   o  Some Editorial changes.

A.16.  draft-ietf-avtcore-feedback-suppression-rtp-16

   The following are  Remove the major changes compared merge report from SSM use case and additional text to previous version:
      address report merging issue.

   o  Some  Revise section 3 and section 6 to address FEC packet dealing issue
      and Leave how to repair packet loss beyond the scope.

   o  Modify the SSM use case and RAMS use case to focus on uses.

   o  Other Editorial changes.

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

   Roni Even
   Huawei
   14 David Hamelech
   Tel Aviv 64953
   Israel

   Email: even.roni@huawei.com