Network Working Group Q. Wu
Internet-Draft F. Xia
Intended status: Standards Track R. Even
Expires: August 26, 2010 Huawei
February 22, 2010
Proposal for an extension to RTCP for Retransmission Storm Suppression
of RTP Stream
draft-wu-avt-retransmission-supression-rtp-00
Abstract
This document extends Receiver Summary Information (RSI) report block
to define a new sub-report block for retransmission suppression
within the framework of RTP retransmission. One of initial
retransmission requests for the missing packets is RTCP NACK. This
feedback message conveys packet loss events. Unlike NACK, this new
sub-report block, which is referred to as the Retransmission Storm
Suppression Report, also carries the information regarding
retransmission 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 Retransmission
Suppression together with NACK, 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 avoided. This document also
registers a new sub-report block type for Retransmission Storm
Suppression within RTP retransmission framework.
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.
The list of Internet-Draft Shadow Directories can be accessed at
Wu, et al. Expires August 26, 2010 [Page 1]
Internet-Draft Retransmission Suppression February 2010
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 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 August 26, 2010 [Page 2]
Internet-Draft Retransmission Suppression February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . 5
4. Sub-Report Block for Retransmission Suppression Early
Indication . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Example scenarios for Retransmission Storm
Suppression . . . . . . . . . . . . . . . . . . . . . 8
A.1. Scenario 1: One media Sender, one Distribution Source . . 8
A.2. Scenario 2: One Media Sender, more distribution sources . 8
Appendix B. Applicability of Retransmission Suppression Early
Indication . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Wu, et al. Expires August 26, 2010 [Page 3]
Internet-Draft Retransmission Suppression February 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 that
indicates the sequence number of the lost RTP packets can be used to
request the retransmission of the missing packets [RFC4585].
This RTCP NACK message conveys the RTP sequence number of the lost
packets and request the sender to compensate the missing RTP packets
based on the RTP sequence number of these packets. However, in lots
of multicast environments, packet loss occurs between the media
sender and the intermediate network element (e.g., Distribution
Source) due to oversaturated network link, faulty networking hardware
or corrupted packets rejected in-transit. It may result in
retransmission storm targeting at the same sender, i.e., massive
retransmission request for the same RTP packets through RTCP NACK to
the same multicast sender. 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. As the retransmission storm
progresses, the network is overwhelmed with constant retransmission
traffic, in the worsening case, RTP retransmission 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 the retransmission packets proliferate, the
network may become unusable.
In order to solve this, the current text in RTCP-SSM allows the
distribution source to filter out the NACK messages while this
document propose an option to let the receivers know that NACK is not
needed in the specified cases. i.e., generating a new RSI sub-report
block, which reflects the packet receipt/loss events before the
receiver detects an original packet loss and retransmission
suppression early indication events before all the packet loss repair
methods are applied.
This new RSI sub-report block, which we refer to as Retransmission
Suppression Early Indication, indicates suppressing requests for
transmission of lost packets before the receiver sends a NACK for
those packets. In order to detect the original packet loss in the
upstream direction before the receiver perceives it, the distribution
source located between the sender and receiver may reserve space to
replicate one copy of multicast data and check the sequence number
consistency of the original multicast packets. Also the distribution
source should take into account such factors as the tolerable
application delay, the network environment, and the media type. When
the packet loss is detected immediately and initial latency is
tolerable, in the upstream direction towards the sender, the
Wu, et al. Expires August 26, 2010 [Page 4]
Internet-Draft Retransmission Suppression February 2010
distribution source may ask for retransmission of the lost packet
from the sender using RTCP NACK, in the meanwhile, in the downstream
direction from the sender, the distribution source may convey
Retransmission Suppression Indication to all the receivers concerned
to indicate the receiver not to request packet retransmission. When
the sender receives the packet retransmission request from the
distribution source, the sender resends the missing packet to the
receiver via RTP using retransmission payload format [RFC4588].
Similar to RTCP NACK, the Retransmission Suppression Early Indication
also conveys the packet receipt/loss events at the packet level and
considers missing packets as unrepaired. But different from RTCP
NACK, the retransmission Suppression Early Indication is used by the
intermediate network element to suppress retransmission from the
receiver and can not be taken as feedback-based error repair
mechanism but network based packet loss repair method.
Note that the retransmission suppression Early Indication should
collectively work together with RTCP NACK 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 avoided. The receive may send a NACK message before
receiving the indication but will not need to resend the NACK message
after receiving the indication. Also the idea of retransmission
Suppression Early Indication can be further extended when the
distributed content distribution network are considered. That is to
say several distribution sources and media senders may constitute one
hierarchical model. In this distributed hierarchical content
distribution environment, the Retransmission Suppression Early
Indication not only can be used to suppress all the receivers behind
itself not to send NACK but also suppress the neighboring nodes not
to send NACK for the missing packets via unicast. How the
neighboring node is discovered is beyond scope of this document.
This document registers a new sub-report block type for
Retransmission Storm Suppression within RTP retransmission framework.
Applications that are employing one or more loss-repair methods MAY
use retransmission Suppression Early Indication approach together
with these loss-repair methods for every packet they receive or for a
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].
Wu, et al. Expires August 26, 2010 [Page 5]
Internet-Draft Retransmission Suppression February 2010
3. Basic Operation
The new sub-report block of the retransmission suppression Early
Indication (RSEI) will work in Simple Feedback and in Distribution
Source Feedback Summary Models defined in [I-D.ietf-avt-rtcpssm].
The distribution source will include the support for retransmission
as part of the offered SDP and will expect such support from the
Media Sender.
The distribution source may send this new sub-report block RSEI to
the receivers when detecting a loss on its incoming link while send a
NACK to the media sender. The distribution source may receive NACK
messages from the receivers and may filter them out if it already
sent a NACK for the requested packet to the media source.
If the receiver understands this message it will not send NACKs for
the missing packets reported in the message and will accept a
retransmission stream. The receiver may send NACK messages if it did
not understand this new message.
4. Sub-Report Block for Retransmission Suppression Early Indication
The Retransmission suppression Early Indication (RSEI) sub-report
block uses the similar format of sub-report block specific to the RSI
packet defined in the section 7.1.2 of [I-D.ietf-avt-rtcpssm]. The
report format is shown in Figure 1. Using this RSEI sub-report block
with RTCP NACK can efficiently prevent Retransmission Storm to
happen. The format of this sub-report block is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT(RSEI) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLSN | LLSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the RSEI sub-report block
SRBT:8bits
Report block type for retransmission Suppression Early Indication.
Wu, et al. Expires August 26, 2010 [Page 6]
Internet-Draft Retransmission Suppression February 2010
Length:8bits
The length of the sub-report in 32-bit words.
Reserved:16bits
Starting Loss Sequence Number (SLSN):16bits
The SSN field is used to specify the contiguous packet lost. The
SSN field refers to the RTP sequence number of the first lost
packet.
Last Loss Sequence Number (LLSN): 16 bits
The LSN field is used to specify the contiguous packet loss. The
LSN refers to the RTP sequence number of the last lost packet.
5. SDP Signaling
No new parameter needs to be defined for the Retransmission Storm
Suppression Indication message to be used with Session Description
Protocol (SDP) [RFC4566]using the Augmented Backus-Naur Form (ABNF)
[RFC5234]. It uses the same syntax within the "rtcp-unicast"
attribute [I-D.ietf-avt-rtcpssm].
Refer to Section 10.1 of [I-D.ietf-avt-rtcpssm] for a detailed
description and the full syntax of the "rtcp-unicast" attribute.
6. IANA Consideration
New sub-report block types for RTCP RSI block are subject to IANA
registration. For general guidelines on IANA considerations for RTCP
RSI, refer to [I-D.ietf-avt-rtcpssm].
This document assigns the sub-report block type (SRBT) value x in the
RTCP RSI sub-report Block Type Registry to "Retransmission Storm
Suppression Indication Report Block", with the following
registrations format:
Name: RSEI
Long name: Retransmission Suppression Early Indication
Value: TBD
Reference: This Document.
The contact information for the registrations is:
Wu, et al. Expires August 26, 2010 [Page 7]
Internet-Draft Retransmission Suppression February 2010
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.
7.2. Informative References
[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".
Wu, et al. Expires August 26, 2010 [Page 8]
Internet-Draft Retransmission Suppression February 2010
Appendix A. Example scenarios for Retransmission Storm Suppression
A.1. Scenario 1: One media Sender, one Distribution Source
The general architecture is displayed below in Figure 2. 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 2: One media Sender, one Distribution Source
A.2. Scenario 2: One Media Sender, more distribution sources
The hierarchical model is displayed below in Figure 3. 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
Wu, et al. Expires August 26, 2010 [Page 9]
Internet-Draft Retransmission Suppression February 2010
to it as Retransmission Storm.
+--------+
|---->|RTP_Rx11|
| +--------+
+--------------+ |
| | | +--------+
|--->| Distribution |----|---->|RTP_Rx12|
| | Source1 | | +--------+
| | | | .
+--------+ | +--------------+ | .
| | | | .
| | | | +--------+
| Media | | |---->|RTP_Rx1k|
| |---| +--------+
| Sender | | +--------+
| | | |---->|RTP_Rx21|
| | | | +--------+
+--------+ | +--------------+ |
| | | | +--------+
| | Distribution |----|---->|RTP_Rx22|
|--->| Source2 | | +--------+
| | | .
+--------------+ | .
| .
| +--------+
|---->|RTP_Rx2j|
+--------+
Figure 3: One Media Sender, more distribution sources
Appendix B. Applicability of Retransmission Suppression Early
Indication
This document defines new RTCP RSI sub-report block, which we refer
to as Retransmission Suppression Early Indication to deal with
Retransmission Storm mentioned above. Here we give two examples to
show how this new RTCP sub-report block is applied into two scenarios
described in section A.1 for Retransmission Storm Suppression.
Applicability of Retransmission Storm Suppression in Scenario 1
described in Figure 2 is shown in the Figure 4. In this figure, the
distribution source detect the packet loss before the receiver
perceive it and ask for retransmission of the missing packets from
the media sender, in the meanwhile, the distribution source transmits
the RTCP Retransmission Storm Suppression Indication back to the
receivers using source-specific multicast channel. In this way, the
Wu, et al. Expires August 26, 2010 [Page 10]
Internet-Draft Retransmission Suppression February 2010
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 RSSI-->|
| RTP Retransmission | |
|------------------->| |
| |------RTP Multicast---->|
| | Retransmission |
| | |
| | |
| | |
Figure 4: Applicability of Retransmission Suppression Early
Indication
Applicability of Retransmission Storm Suppression in Scenario 2
described in Figure 3 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 5. The
only difference is distribution source should not only notify all the
receiver behind itself not to send NACK but also propagate the
retransmission suppression indication to the neighboring distribution
sources. In this way, all the receivers behind all the neighboring
distribution source can avoid sending massive retransmission request
to the media sender.
Wu, et al. Expires August 26, 2010 [Page 11]
Internet-Draft Retransmission Suppression February 2010
+------+ +-------+ +--------+ +-------+ +--------+
|Media | | | | RTP_Rx | | | | RTP_Rx |
|Sender| | DS1 | | (DS1) | | DS2 | | (DS2) |
+--+---+ +---+---+ +---+----+ +---+---+ +---+----+
| | | | |
| |RTP Multicast | | |
|----------->|------------->| | |
| | | | |
| | | |RTP Multicast|
|------------------------------------------->|------------>|
| | | | |
| +--------+------------+ | | |
| |Detect Packet Loss | | | |
| |and Identify the SN | | | |
| |of the missing Packets | | |
| +--------+------------+ | | |
| | | | |
|<-RTCP NACK-| Multicast RTCP RSSI | |
| |------------->| | |
| | | | |
| |-----Unicast RTCP RSSI-------->|Multicast RTCP RSSI
| | | |------------>|
|RTP Retransmission | | |
|----------->| | | |
| | | | |
| | RTP Retransmission | |
|------------+--------------+--------------->| |
| | | | |
| | RTP Multicast| | RTP Multicast
| |Retransmission| |Retransmission
| |------------->| |------------>|
| | | | |
DS1: Distribution Source 1
DS2: Distribution Source 2
Figure 5: Applicability of Retransmission Suppression Early
Indication
Wu, et al. Expires August 26, 2010 [Page 12]
Internet-Draft Retransmission Suppression February 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 August 26, 2010 [Page 13]