Network Working Group                                              Q. Wu
Internet-Draft                                                    F. Xia
Intended status: Standards Track                                 R. Even
Expires: September 9, 2010                                        Huawei
                                                           March 8, 2010


  Proposal for an extension to RTCP Receiver Report for Feedback Storm
                              Suppression
             draft-wu-avt-retransmission-supression-rtp-01

Abstract

   This document specifies an extension to the messages defined in the
   Audio-Visual Profile with Feedback (AVPF) designed to allow
   intermediate node to suppress the feedback implosion from the
   receivers.  One of examples for feedback implosion is utilizing RTCP
   NACK to request retransmission of the missing packets which may
   result in NACK storm targeting to the same media sender.  This issue
   can be addressed to define one new RTCP message, which is referred to
   as the Feedback Storm Suppression receiver report and carries the
   information regarding feedback suppression early indication events to
   the receiver before the receiver detects an original packet loss and
   all the packet loss repair methods are applied.  By using feedback
   Suppression message together with RTCP based feedback message, the
   delay for the receiver to recover from the packet loss can be reduced
   and the risk of increasing network congestion can be mitigated or
   diminished.  This document also registers a new RTCP receiver report
   for Feedback Storm Suppression.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.




Wu, et al.              Expires September 9, 2010               [Page 1]


Internet-Draft         Feedback Storm Suppression             March 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 9, 2010.

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
   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 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 September 9, 2010               [Page 2]


Internet-Draft         Feedback Storm Suppression             March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Basic Operation  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Message Format . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . .  5
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  6
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  7
   Appendix A.  Example scenarios for Feedback Storm Suppression  . .  7
     A.1.  Scenario 1: One media Sender, one Distribution Source  . .  7
     A.2.  Scenario 2: One Media Sender, more distribution sources  .  8
   Appendix B.  Applicability of Feedback Storm Suppression . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11



































Wu, et al.              Expires September 9, 2010               [Page 3]


Internet-Draft         Feedback Storm Suppression             March 2010


1.  Introduction

   RTP retransmission is an effective packet loss recovery technique for
   real-time applications with relaxed delay bounds [RFC4588],e.g.,
   streaming media.  The conventional RTCP feedback (NACK) message which
   conveys the RTP sequence number of the lost packets can be used to
   request the sender to compensate the missing RTP packets based on the
   RTP sequence number of these packets[RFC4585].

   However, in lots of multicast environments, packet loss occurs in the
   upstream link or downstream aggregate link of the intermediate
   network element (e.g., Retransmission server, Distribution Source)
   due to oversaturated network link, faulty networking hardware or
   corrupted packets rejected in-transit.  It may result in NACK
   implosion targeting at the same sender, i.e., massive NACK request to
   the same multicast sender for retransmission of the same RTP packets
   which is also known as "NACK storm" described in [DVB-IPTV].  To
   increase the robustness to the loss of a NACK or of a retransmission
   packet, a receiver may also send multiple NACKs for the same packet.
   Another use case is Fast Update request storm occurs in the
   conversational multimedia scenarios.  In this case, packet loss may
   happen in the upstream link or downstream aggregate link of
   intermediate network element like Multipoint Control Unit(MCU) which
   results in massive fast update request(i.e., Full Intra Request(FIR)
   described in [RFC5104]) from receivers to the same media sender.

   As these feedback storms progress (e.g., NACK implosion or Fast
   update implosion), the network is overwhelmed with constant feedback
   traffic, in the worsening case, RTCP feedback storm poses a risk of
   increasing network congestion, with excessive traffic and degrading
   network performance, this can eventually lead to a complete loss of
   network connectivity as such feedback packets proliferate, the
   network may become unusable.

   In order to solve this, the current text in [I-D.ietf-avt-rtcpssm]
   allows the distribution source to filter out the NACK messages while
   this document propose an option to let the receivers know that
   Feedback for packet loss is not needed in the specified cases. i.e.,
   generating one new generic RTCP receiver report message, which
   reflects the packet receipt/loss events and feedback suppression
   early indication events before the receiver detects an original
   packet loss and all the packet loss repair methods are applied.

   This new RTCP receiver report, which we refer to as Feedback Storm
   Suppression, indicates suppressing feedback request for the packet
   loss(e.g., request retransmission of lost packets or request decoder
   refresh point) before the receiver sends a request to the media
   sender for the missing packet.  In order to detect the original



Wu, et al.              Expires September 9, 2010               [Page 4]


Internet-Draft         Feedback Storm Suppression             March 2010


   packet loss in the upstream direction before the receivers perceive
   it, the intermediate node located between the media sender and
   receiver may monitor a certain packet loss by reserving space to
   replicate one copy of multicast data and checking the sequence number
   consistency of the original multicast packets or configuring upstream
   RTP client or a small subset of RTP receivers to act as immediate
   reporters described in [DVB-IPTV].  Also this intermediate node
   should take into account such factors as the tolerable application
   delay, the network environment, and the media type.  Upon the packet
   loss is detected and initial latency is tolerable, in the upstream
   direction towards the sender, the intermediate node may ask for
   retransmission of the lost packet from the sender or re-asking for
   the correct decoder refresh point, in the meanwhile, in the
   downstream direction from the sender, the intermediate node may
   convey Feedback Suppression Indication to all the receivers concerned
   to indicate the receiver not to transmit feedback message.  When the
   sender receives the request from the intermediate node, the sender
   resends the missing packet to the receiver via RTP using
   retransmission payload format[RFC4588].

   Similar to RTCP NACK, the Feedback Storm Suppression also conveys the
   packet receipt/loss events at the packet level and considers missing
   packets as unrepaired.  But different from RTCP NACK, the Feedback
   Storm Suppression is used by the intermediate node to multicast back
   to the receivers in response to the RTCP feedback issued by the
   receivers.

   Note that the feedback storm suppression should collectively work
   together with feedback to repair the lost source packets.  Thus, the
   delay for the receiver to recover from the packet loss can be reduced
   and the risk of increasing network congestion can be mitigated or
   diminished.  The receiver may send a Feedback message before
   receiving the indication but will not need to resend the Feedback
   message after receiving the indication.  Also the idea of Feedback
   Storm Suppression can be further extended when the distributed
   content distribution network are considered.  That is to say several
   intermediate node and media senders may constitute hierarchical
   model.  In this distributed content distribution environment, the
   Feedback Storm Suppression not only can be used to suppress all the
   receivers behind itself not to send packet loss request but also
   suppress the neighboring node not to send packet loss request for the
   missing packets via unicast.  How the neighboring node is discovered
   is beyond scope of this document.

   This document registers a new RTCP receiver report message for
   Feedback Storm Suppression.  Applications that are employing one or
   more loss-repair methods MAY use feedback Storm Suppression together
   with these loss-repair methods for every packet they receive or for a



Wu, et al.              Expires September 9, 2010               [Page 5]


Internet-Draft         Feedback Storm Suppression             March 2010


   set of specific packets they have received.


2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Basic Operation

   The new RTCP receiver report, i.e., the Feedback Storm suppression
   will work in Simple Feedback and in Distribution Source Feedback
   Summary Models defined in [I-D.ietf-avt-rtcpssm].  The intermediate
   node between media sender and receivers will include the support for
   retransmission as part of the offered SDP and will expect such
   support from the Media Sender.

   The intermediate node may send this new RTCP receiver report FSEI
   when detecting a loss on its incoming link while sending a packet
   loss request to the media sender.  The intermdidate node may receive
   packet loss request messages(e.g., RTCP NACK) from the receivers and
   may filter them out if it already sent a packet loss request for the
   missing packet to the media source.

   If the receiver understands this message it will not send packet loss
   request(e.g., NACK) for the missing packets reported in the message
   and will accept a retransmission stream.  The receiver may send
   packet loss request(e.g., NACK messages) if it did not understand
   this new message.


4.  Message Format

   The Feedback Storm Suppression message is an extension to the RTCP
   receiver report.  [[The message format is to be decided based on the
   AVT discussion.]]


5.  SDP Signaling

   TBD.


6.  IANA Consideration

   New message type and New parameters for RTCP receiver report are



Wu, et al.              Expires September 9, 2010               [Page 6]


Internet-Draft         Feedback Storm Suppression             March 2010


   subject to IANA registration.  For general guidelines on IANA
   considerations for RTCP feedback, refer to [RFC4585]

   The contact information for the registrations is:

     Qin Wu
     sunseawq@huawei.com
     Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd.
     Nanjing, JiangSu 210001 China


7.  References

7.1.  Normative References

   [I-D.ietf-avt-rtcpssm]
              Ott, J., Chesterfield , J., and E. Schooler, "RTCP
              Extensions for Single- Source Multicast Sessions with
              Unicast Feedback", September 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, February 2008.






Wu, et al.              Expires September 9, 2010               [Page 7]


Internet-Draft         Feedback Storm Suppression             March 2010


7.2.  Informative References

   [DVB-IPTV]
              ETSI Standard, "Digital Video Broadcasting(DVB); Transport
              of MPEG-2 TS Based DVB Services over IP Based Networks",
              ETSI TS 102 034, V1.4.1 , August 2009.

   [I-D.hunt-avt-monarch-01]
              Hunt, G. and P. Arden, "Monitoring Architectures for RTP",
              August 2008.

   [I-D.ietf-pmol-metrics-framework-02]
              Clark, A., "Framework for Performance Metric Development".


Appendix A.  Example scenarios for Feedback Storm Suppression

A.1.  Scenario 1: One media Sender, one Distribution Source

   The general architecture is displayed below in Figure 1.  In this
   figure, one or more Media Senders send RTP packets to the
   Distribution Source.  The Distribution Source relays the RTP packets
   to the receivers using a source-specific multicast channel.  In the
   reverse direction, the receivers transmit RTCP packets via unicast to
   the distribution source.  The Distribution Source in turn relays RTCP
   packets to the media sender and then transmits the RTCP packets back
   to the receivers, using source-specific multicast.  When packet loss
   happens between Media sender and distribution source, it may result
   in massive retransmission request for the same RTP packets from all
   the receivers using RTCP NACK to the same multicast sender.  We refer
   to it as Retransmission Storm.

                                                 +-------+
                                           |---->|RTP_Rx1|
   +--------+                              |     +-------+
   |        |       +--------------+       |
   |        |       |              |       |     +-------+
   | Media  |-------| Distribution |-------|---->|RTP_Rx2|
   |        |       |   Source     |       |     +-------+
   | Sender |       |              |       |         .
   |        |       +--------------+       |         .
   |        |                              |         .
   +--------+                              |     +-------+
                                           |---->|RTP_Rxn|
                                                 +-------+

            Figure 1: One media Sender, one Distribution Source




Wu, et al.              Expires September 9, 2010               [Page 8]


Internet-Draft         Feedback Storm Suppression             March 2010


A.2.  Scenario 2: One Media Sender, more distribution sources

   The hierarchical model is displayed below in Figure 2.  In this
   figure, one media sender and two Distribution source constitute one
   hierarchical model.  In this model, one Media Senders send RTP
   packets to two Distribution Sources respectively.  These Distribution
   Sources relay the RTP packets respectively to the receivers behind
   itself using a source-specific multicast channel.  In the reverse
   direction, the receivers transmit RTCP packets via unicast to the
   distribution source.  The Distribution Source in turn relays RTCP
   packets to the media sender and then transmits the RTCP packets back
   to the receivers, using source-specific multicast.  When packet loss
   happens between Media sender and distribution source, it may result
   in massive retransmission request for the same RTP packets from all
   the receivers using RTCP NACK to the same multicast sender.  We refer
   to it as Retransmission Storm.

                                                +--------+
                                          |---->|RTP_Rx11|
                                          |     +--------+
                      +--------------+    |
                      |              |    |     +--------+
                 |--->| Distribution |----|---->|RTP_Rx12|
                 |    |   Source1    |    |     +--------+
                 |    |              |    |         .
    +--------+   |    +--------------+    |         .
    |        |   |                        |         .
    |        |   |                        |     +--------+
    | Media  |   |                        |---->|RTP_Rx1k|
    |        |---|                              +--------+
    | Sender |   |                              +--------+
    |        |   |                        |---->|RTP_Rx21|
    |        |   |                        |     +--------+
    +--------+   |    +--------------+    |
                 |    |              |    |     +--------+
                 |    | Distribution |----|---->|RTP_Rx22|
                 |--->|   Source2    |    |     +--------+
                      |              |    |         .
                      +--------------+    |         .
                                          |         .
                                          |     +--------+
                                          |---->|RTP_Rx2j|
                                                +--------+

           Figure 2: One Media Sender, more distribution sources






Wu, et al.              Expires September 9, 2010               [Page 9]


Internet-Draft         Feedback Storm Suppression             March 2010


Appendix B.  Applicability of Feedback Storm Suppression

   This document defines new RTCP receiver report which we refer to as
   Feedback Storm Suppression to deal with Retransmission Storm
   mentioned above.  Here we give two examples to show how this new RTCP
   receiver report is applied into two scenarios described in section
   A.1 for Retransmission Storm Suppression.

   Applicability of Feedback Storm Suppression in Scenario 1 described
   in Figure 1 is shown in the Figure 3.  In this figure, the
   distribution source detect the packet loss before the receiver
   perceive it and ask for retransmission of the missing packets from
   the media sender, in the meanwhile, the distribution source transmits
   the RTCP Feedback Storm Suppression Indication back to the receivers
   using source-specific multicast channel.  In this way, the delay for
   the receiver to recover from the packet loss can be reduced and the
   risk of increasing network congestion can be mitigated.

   +------+         +--------------+            +--------+
   |Media |         | Distribution |            |        |
   |Sender|         |   Source     |            | RTP_Rx |
   +--+---+         +------+-------+            +---+----+
      |                    |                        |
      |                    |                        |
      |------------------->|------RTP Multicast---->|
      |                    |                        |
      |                    |                        |
      |           +--------+----------+             |
      |           |Detect Packet Loss |             |
      |           |and Identify the SN|             |
      |           |of missing Packets |             |
      |           +--------+----------+             |
      |<-----RTCP NACK-----|                        |
      |                    |                        |
      |                    +--Multicast RTCP FSEI-->|
      | RTP Retransmission |                        |
      |------------------->|                        |
      |                    |------RTP Multicast---->|
      |                    |     Retransmission     |
      |                    |                        |
      |                    |                        |
      |                    |                        |

     Figure 3: Applicability of Feedback Suppression Early Indication

   Applicability of Feedback Storm Suppression in Scenario 2 described
   in Figure 2 is shown in the figure A.2.2.  The procedure in the
   figure A.2.2 is similar to the one in the figure Figure 4.  The only



Wu, et al.              Expires September 9, 2010              [Page 10]


Internet-Draft         Feedback Storm Suppression             March 2010


   difference is distribution source should not only notify all the
   receiver behind itself not to send NACK but also propagate the
   retransmission suppression indication to the neighboring distribution
   sources.  In this way, all the receivers behind all the neighboring
   distribution source can avoid sending massive retransmission request
   to the media sender.

   +------+    +-------+      +--------+       +-------+     +--------+
   |Media |    |       |      | RTP_Rx |       |       |     | RTP_Rx |
   |Sender|    |  DS1  |      | (DS1)  |       |  DS2  |     | (DS2)  |
   +--+---+    +---+---+      +---+----+       +---+---+     +---+----+
      |            |              |                |             |
      |            |RTP Multicast |                |             |
      |----------->|------------->|                |             |
      |            |              |                |             |
      |            |              |                |RTP Multicast|
      |------------------------------------------->|------------>|
      |            |              |                |             |
      |   +--------+------------+ |                |             |
      |   |Detect Packet Loss   | |                |             |
      |   |and Identify the SN  | |                |             |
      |   |of the missing Packets |                |             |
      |   +--------+------------+ |                |             |
      |            |              |                |             |
      |<-RTCP NACK-| Multicast RTCP RSSI           |             |
      |            |------------->|                |             |
      |            |              |                |             |
      |            |-----Unicast RTCP RSSI-------->|Multicast RTCP FSEI
      |            |              |                |------------>|
      |RTP Retransmission         |                |             |
      |----------->|              |                |             |
      |            |              |                |             |
      |            |  RTP Retransmission           |             |
      |------------+--------------+--------------->|             |
      |            |              |                |             |
      |            | RTP Multicast|                | RTP Multicast
      |            |Retransmission|                |Retransmission
      |            |------------->|                |------------>|
      |            |              |                |             |
   DS1: Distribution Source 1
   DS2: Distribution Source 2

        Figure 4: Applicability of Retransmission Suppression Early
                                Indication







Wu, et al.              Expires September 9, 2010              [Page 11]


Internet-Draft         Feedback Storm Suppression             March 2010


Authors' Addresses

   Qin Wu
   Huawei
   Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565892
   Email: sunseawq@huawei.com


   Frank Xia
   Huawei
   1700 Alma Dr. Suite 500
   Plano, TX 75075
   USA

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Roni Even
   Huawei
   14 David Hamelech
   Tel Aviv 64953
   Israel

   Email: even.roni@huawei.com






















Wu, et al.              Expires September 9, 2010              [Page 12]