Internet DRAFT - draft-hua-avt-rtp-svcmvc
draft-hua-avt-rtp-svcmvc
Network Working Group H. Chao, Ed.
Internet-Draft Alcatel-Lucent Shanghai Bell
Intended status: Standards Track Co., Ltd.
Expires: May 9, 2013 November 5, 2012
Extension of RTP for SVC and MVC with usage of ECN
draft-hua-avt-rtp-svcmvc-00
Abstract
This memo specifies how to support RTP packet stream thinning (or
rate adaptation) and Explicit Congestion Notification (ECN) with the
Real-time Transport Protocol (RTP) running over UDP to make effect in
parallel with reliable RTCP report to the RTP sender. It introduces
"dummy RTP packets" into the single-session transmission (SST) mode
for Scalable Video Coding (SVC) and Multiview Video Coding (MVC).
The reactions of RTP receivers upon receiving the "dummy RTP packets"
are defined. The document also recommend to extend the ECN
functionalities based on the scalability feature of SVC and MVC.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 9, 2013.
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
Chao Expires May 9, 2013 [Page 1]
Internet-Draft Extension of RTP for SVC/MVC November 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology and Abbreviations . . . . . . . . . . . . . . . 4
1.2.1. Definitions Specific to This Memo . . . . . . . . . . . 4
2. Discussion and Design Rationale . . . . . . . . . . . . . . . . 4
2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Interoperability . . . . . . . . . . . . . . . . . . . . . 5
3. RTP extension for ECN . . . . . . . . . . . . . . . . . . . . . 5
4. Use of ECN with RTP/UDP/IP for SVC and MVC . . . . . . . . . . 5
4.1. Setting ECN-CE within an RTP Session . . . . . . . . . . . 6
4.2. Reporting ECN Feedback via RTCP . . . . . . . . . . . . . . 6
4.3. Response to Congestion Notifications . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chao Expires May 9, 2013 [Page 2]
Internet-Draft Extension of RTP for SVC/MVC November 2012
1. Introduction
The SVC and MVC bring new challenges for the ECN design. Based on
congestion control principle, media-aware network elements (MANEs)
may perform media-aware stream thinning i.e. selective removing
incoming RTP packets or portions thereof. It implies that MANEs may
need to rewrite the RTP header as defined in RFC 6190 [RFC6190].
During the period of stream thinning making effect, routers in the
video transmission path may apply ECN due to their impending
congestion and indicate to the RTP sender. In this situation, as the
RTP receiver does not aware the removing of RTP packets the MANEs
have done, it will not counter the dropped RTP packets by the MANEs
when calculating parameters of the RTCP signaling (specified as ECN
feedback report and ECN summary report, see [RFC6679] for details)
e.g. "ECT(0) Counter", "ECT(1) Counter", "Lost Packets Counter". As
a result, the RTCP reports from the RTP receiver to the RTP sender
are not accurate and reliable for SVC and MVC streams.
Based on above considerations, mechanisms defined in this document
aim to improve the accuracy of RTCP reports for SVC and MVC streams
over UDP and in return help the RTP sender to achieve a better rate
adaptation or congestion control effect.
The document recommends to improve current stream thinning or rate
adaptation schemes in MANEs for SVC or MVC bitstreams. It introduces
"dummy RTP packets" into the single-session transmission mode. The
reactions of RTP receivers upon receiving the "dummy RTP packets" are
also defined.
The document recommends to extend the ECN functionalities based on
the scalability feature of SVC and MVC. Corresponding behaviours of
routers or other network element with ECN capability are defined.
The behaviours of receivers upon receiving ECN-CE marked packet are
also specified.
1.1. Background
The mechanisms defined for ECN provide in-band ways to indicate
congestion before packet loss occuring. Two bit ECN field was
defined for IP packets to indicate ECN-capable packets as well as
ECN-CE marked packets. In addition to the functionality given by the
ECN field in the IP packet header, ECN requires support from the
transport protocol to inform the sender that ECN-CE marked packets
are being received. As regards to TCP, RFC 3168 [RFC3168] specifies
the incorporation of ECN to TCP and IP. It leaves issues of ECN in
other transport protocols to further research.
UDP-based transports, such as RTP [RFC3550], faces challenges to use
Chao Expires May 9, 2013 [Page 3]
Internet-Draft Extension of RTP for SVC/MVC November 2012
ECN due to lack of feedback mechanisms directly in UDP. Later on,
[RFC6679] defines how ECN can be used with RTP over UDP. By using
RTCP as a feedback mechanism, both periodic ECN feedback and timely
report of congestion events are supported. It defines a new RTCP
Extended Report (XR) block for periodic ECN feedback and a new RTCP
transport feedback message for timely reporting of congestion events.
As defined in RFC 6190 [RFC6190] and [I-D.ietf-payload-rtp-mvc] both
single session transmission (SST) and multi-session transmission
(MST) are defined for SVC and MVC. In the case of SST all SVC or MVC
data are carried in a single RTP session. In the case of MST two or
more RTP sessions are used to carry the SVC or MVC data.
1.2. Terminology and Abbreviations
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].
The abbreviations and definitions "Sender", "Receiver", "ECN Capable
Packets", "ECN-CE" and "not-ECT Packets" in this document are to be
interpreted as described in [RFC6679].
The abbreviations and definitions "Enhancement layer", "Empty NAL
unit", "MANE", "Multi-session transmission", "RTP packet stream" and
"single-session transmission" are to be interpreted as described in
[RFC6190].
The abbreviations and definitions "Base view", "non-base view", are
to be interpreted as described in [I-D.ietf-payload-rtp-mvc].
1.2.1. Definitions Specific to This Memo
Dummy RTP packet: For a given RTP packet, a dummy RTP packet replaces
the payload of one or more NAL units with an empty NAL unit.
2. Discussion and Design Rationale
2.1. Assumptions
Before the descriptions of the solutions defined in this document,
work assumptions of this document are listed as bellow.
o Assumption1: One SVC or MVC bitstream could consist of one or more
RTP sub- streams, i.e. single-session transmission (SST) mode or
multiple-session transmission (MST) mode in other words. In this
document we only consider the SST transmission mode.
Chao Expires May 9, 2013 [Page 4]
Internet-Draft Extension of RTP for SVC/MVC November 2012
o Assumption2: The solutions defined in this document are complied
with the four different pieces (as specified by Section 4 in
[RFC6679]) that together make the solution for using ECN with RTP
over UDP/IP work.
o Assumption3: This document assumes that initiation of ECN usage in
one or more RTP Sessions is finished. Receivers tell the sender
that their paths support ECN. And the RTP sender makes the
decision to use ECN (otherwise the problems proposed to solve in
this document do not exist) by setting ECT(0) or ECT(1) codepoint
in the corresponding IP packet flow.
2.2. Interoperability
For interoperability we mandate both the implementation of RTCP XR
extension for periodic ECN feedback purpose and the ECN feedback
format, which require the RTP/AVPF profile to ensure timely feedback.
3. RTP extension for ECN
The scalability features of SVC and MVC enable the adapation
functionality to be performed at the RTP sender, the RTP receiver or
in MANEs. The MANEs can find that the RTP sender uses ECN when
receiving IP packets marked as ECT(0) and ECT(1). For these IP
packets, when MANEs perform the stream thinning, the basic operation
of adaptation (or stream thinning) is improved to avoid full RTP
packet removing.
When an MANE finds a full RTP packet needs to be removed, it replaces
the RTP packet with a dummy RTP packet instead of removing it at all.
It means that the dummy RTP packet contains the same RTP header as
the original RTP packet and includes a single empty NAL unit. When
MANEs find that part of a RTP packet (i.e. one or more NAL units)
needs to be removed the operation of stream thinning remain the same
as today. As empty NAL unit is only defined for MST mode today
[RFC6190], this document extends the usage of empty NAL units to SST
mode.
4. Use of ECN with RTP/UDP/IP for SVC and MVC
In this section, the solutions of this document are described in
details. Below, behaviour of different network elements are
described in separate subsections.
Chao Expires May 9, 2013 [Page 5]
Internet-Draft Extension of RTP for SVC/MVC November 2012
4.1. Setting ECN-CE within an RTP Session
In this subsection, the behaviour of the routers or other network
elements with ECN functionality in the video stream transmission path
are defined.
A router could decide to select more than one enhancement layers or
non-base views to set the CE codepoint. This method can trigger
multiple different congestion events.
For each selected layer or non-base view, one router could set the CE
codepoint for more than one IP packet. Especially for routers or
network elements within radio network, we recommend setting two or
three packets in the time order for each selected layer or non-base
view to avoid packet loss due to the time-varying of wireless
channel.
4.2. Reporting ECN Feedback via RTCP
In this subsection, the behaviour of the receivers are defined.
When receiving the dummy RTP packets, the receiver records the IP and
RTP header for future ECN usage and does not use them for video
decoding. The receiver should counter the dummy RTP packets when
calculates the parameters of the ECN reports. Especially, the dummy
RTP packets should be countered into the parameter of "ECT(0)
Counter", "ECT(1) Counter", "ECN-CE Counter" and "Lost Packets
Counter".
An immediate or early (depending on the RTP/AVPF mode defined in
[RFC4585]) ECN feedback report should be generated on receipt of the
first ECN-CE marked packet. The early ECN feedback report metioned
in this document complies with the available IETF mechanism.
For each new received ECN-CE marked packet, the receiver shall
determine whether the new arriving packet belongs to an existing
congestion event or is a new congestion event. The receiver only
needs to generate ECN feedback reports for new congestion events to
avoid unnecessary ECN feedback reports. The principles are:
a. The receivers always treat different ECN-CE marked packet of
different layers or non-base view as different congestion events.
b. For the ECN-CE marked packets of the same layer or the same non-
base view, the receiver calculates the reception time of the new
arriving ECN- CE marked packet, i.e. T_new. It compares the
T_new with the reception time of the previous arrived ECN-CE
marked packet i.e. T_old. If the T_new < T_old + RTT, then the
Chao Expires May 9, 2013 [Page 6]
Internet-Draft Extension of RTP for SVC/MVC November 2012
new arriving ECN-CE marked packet is considered to belong to the
same congestion event. Otherwise, it is considered as a new
congestion event. T_odd is the reception time of a previous
ECN-CE marked packet of the same layer or non-base view. RTT is
the Round Trip Time between the RTP sender and the RTP receiver.
4.3. Response to Congestion Notifications
In this subsection, the behaviour of the sender is defined.
Upon receiving ECN feedback reports from the UE, the RTP sender
inputs the ECN feedback reports into its congestion control or rate
adaptation algorithms and acts as if packet loss is detected.
With multiple ECN feedback reports for the same RTP packet stream, we
believe that the RTP sender will get a reference to perform proper
congestion control or rate adaptation. More amount of ECN feedback
reports will contribute to quicker congestion control or rate
adaptation effect but will bring more quality loss. The trade-off
details are algorithm-dependent and are not included in this
document.
5. Acknowledgements
TBD.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
The security considerations of the RTP Payload Format for SVC Video
specification [RFC6190] apply. The security considerations of the
ECN for RTP over UDP draft [RFC6679] apply.
8. References
8.1. Normative References
[I-D.ietf-payload-rtp-mvc]
Wang, Y., Schierl, T., Skupin, R., and P. Yue, "RTP
Payload Format for MVC Video",
draft-ietf-payload-rtp-mvc-02 (work in progress),
Chao Expires May 9, 2013 [Page 7]
Internet-Draft Extension of RTP for SVC/MVC November 2012
June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[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.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012.
8.2. Informative References
[I-D.carlberg-tsvwg-ecn-reactions]
Carlberg, K. and P. O'Hanlon, "Reactions to Signaling from
ECN Support for RTP/RTCP",
draft-carlberg-tsvwg-ecn-reactions-03 (work in progress),
October 2012.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Chao Expires May 9, 2013 [Page 8]
Internet-Draft Extension of RTP for SVC/MVC November 2012
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
Recommendations for Internationalized Domain Names
(IDNs)", RFC 4690, September 2006.
Author's Address
Hua Chao (editor)
Alcatel-Lucent Shanghai Bell Co., Ltd.
Shanghai,
China
Phone: +86 21 38436338
Email: hua.chao@alcatel-sbell.com.cn
Chao Expires May 9, 2013 [Page 9]
