One document matched: draft-yang-avt-selective-transmission-01.txt
Differences from draft-yang-avt-selective-transmission-00.txt
Audio/Video Transport P. Yang
Internet-Draft Y. Hu
Intended status: Standards Track Huawei Technologies Co., Ltd.
Expires: January 10, 2011 July 9, 2010
RTP Extension Header for Selective Transmission
draft-yang-avt-selective-transmission-01.txt
Abstract
When network congestion occurs or dynamic transient burst stream
transfers on a bandwidth constrained network, it is easy to cause
bursts of consecutive packet loss. Video streams are very vulnerable
to packet loss because of motion compensation predictive coding at
the decoder. In this document, we describe a method of using
selective transmission to decrease the effect of random drop to video
stream when necessary. At the same time, this document describes a
method to avoid retransmission request due to selective transmission.
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 January 10, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Yang & Hu Expires January 10, 2011 [Page 1]
Internet-Draft Selective transmission July 2010
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
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Selective transmission Mechanism Description . . . . . . . . . 4
5. The use case of network congestion . . . . . . . . . . . . . . 5
6. RTP Packet Format . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Selective Transmission Notification Indication . . . . . . 6
7. Signaling Information . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Yang & Hu Expires January 10, 2011 [Page 2]
Internet-Draft Selective transmission July 2010
1. Introduction
When a congestion event in the network occurs, it tends to result in
a burst of successive packet loss. Real-time video services is very
vulnerable to packet loss of reference frame even if a single packet
loss of reference frame occurs, because video compression coding
makes use of Motion-Compensated Predictive Coding at the decoder. A
burst of consecutive packet loss is more likely to cause the loss of
reference frame which makes it difficult for the decoder to construct
a picture. Though RTP retransmission [RFC4588] can partly solve this
issue, the retransmission may cause more serious congestion if
network congestion still exists. Therefore, it is necessary to
utilize a new method to avoid the loss of the reference frame packets
when a congestion event occurs. Packets of reference frame are
normally important because they are used as a reference for
predicting other pictures, while packets of predictive non-reference
frame or reference frame which is used as references for only one or
a few frames are less decoding-sensitive. For reference frame, intra
frame is the best decoding-sensitive, predictive frames in turn
reduce their sensitivity from the beginning to the end of GOP. Take
an example, packets of I-frame is the best significant and decoding-
sensitive; packets of P-frames in one GOP are also decoding-
sensitive, decoding-sensitivity of P-frames in turn decrease from the
beginning to the end of GOP; packets of non-reference B-frame are
least decoding-sensitive; packets of reference B-frame is more
decoding-sensitive than non-reference B-frame; We use these inherent
characteristic of video codec to selectively transmit video packets
when a network congestion occurs. Based on the difference of network
congestion levels, intermediary network element drops video packets
according to the order from less decoding-sensitive packets to
significant and decoding-sensitive packets during selective
transmission.
If an intermediary network element selectively transmits significant,
decoding-sensitive packets and drops less decoding-sensitive packets
of video stream, it will result in non-consecutive RTP sequence
number of media stream packets. When RTP receivers have received
these non-consecutive RTP packets, they may request the
retransmission of these RTP packets which have been dropped by
intermediary network element. However, those RTP packets have been
dropped selectively by the intermediary network element due to
network congestion, and the intermediary network element do would
like the RTP receivers not to request retransmission for them.
Therefore, in order to suppress these retransmission requests, it is
necessary to notify RTP receivers not to request retransmission for
those RTP packets which have been dropped by the intermediary network
element.
Yang & Hu Expires January 10, 2011 [Page 3]
Internet-Draft Selective transmission July 2010
2. Conventions
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].
3. Definitions
This document uses the following acronyms and definitions frequently:
Decoding-sensitivity: The degree of influence of a video packet to
decode. The more a video packet which has been directly or
indirectly used as a reference to predict other pictures is, the more
decoding-sensitive it is, otherwise, the less decoding-sensitive it
is.
Selective transmission: An intermediary network element transmits the
remainder of the packets after dropping video packets according to
the order from less sensitive packets to sensitive and significant
packets during selective transmission.
4. Selective transmission Mechanism Description
A General Mechanism for RTP Header Extensions [RFC 5285] provides a
general mechanism to use the header extension feature of RTP
Protocol. It provides the option to use a small number of small
extensions in each RTP packet, where the universe of possible
extensions is large and registration is de-centralized.
This document uses the header extension mechanism to build a new RTP
extension header to avoid retransmission request from RTP receivers.
When selective transmission is required (e.g. network congestion
occurs), the intermediary network element drops video packets based
on the order from less decoding-sensitive to decoding-sensitive and
significant according to present network situation, and sends RTP
receivers a notification indication to indicate some dropped video
packets that have been taken the initiative to discard.
This document defines the expected behaviors of the intermediary
network element when selective transmission happens. It is
instructive to have independently operating implementations on the
intermediary network element that inspect decoding-sensitivity of
video packets, discard less decoding-sensitivity of video packets,
and send notification indication.
The following steps describe selective transmission in detail:
Yang & Hu Expires January 10, 2011 [Page 4]
Internet-Draft Selective transmission July 2010
1. When selective transmission is required, the intermediary network
element has acquired the decoding-sensitivity of video packets in the
active queue.
2. The intermediary network drops some less decoding-sensitive video
packets according to the level of network condition. The worse
network condition is, the more video packets according to the order
from less decoding-sensitive to decoding-sensitive and significant
are dropped, the less video packets of selective transmission are.
3. The intermediary network element sends Selective Transmission
Notification Indication to RTP receivers not to request
retransmission for those packets which the intermediary network
element has taken the initiative to drop.
5. The use case of network congestion
Though the algorithm of Queue Management and Congestion Avoidance in
the internet [RFC2309](e.g. Tail Drop or Random Early Drop) do not
cause as much harm to the throughput and latency of other
connections, it inevitably causes packet loss and may seriously
degrade video quality. Selective transmission will be an effective
way to improve video quality which is caused by other congestion
avoidance algorithms (e.g. Tail Drop or Random Early Drop[RFC2309]).
The degree of dropping packets depends on network congestion level.
For the case of network congestion, more severe network congestion
is, more video packets will be dropped. The dropping policy is based
on the order from less decoding-sensitive to decoding-sensitive and
significant. That is to say, packets of non-reference frames are the
least sensitive; packets of reference frames are more sensitive than
non-reference frames; packets of intra frame are the best sensitive.
In the packets of reference frames, the more a reference frame is
cited, the more sensitive it is. Take an example of the following
video frame sequence(In order to conveniently calculate, it assumes
that I-frame consists of 80 RTP packets, B-frame consists of 25 RTP
packets, P-frame consists of 55 RTP packets), in the following GOP
from I1 to P13, I1 (intra frame) is the best sensitive; non-reference
B-frames (B2, B3, B5, B6, B8, B9, B11 and B12) are the least
sensitive, reference P-frames (P4, P7, P10 and P13) are more
sensitive than non-reference B-frames. The sensitivity of P4, P7,
P10 and P13 decreases in turn
...I1(1000-1079)B2(1080-1104)B3(1105-1129)P4(1130-1184)B5(1185-1209)
B6(1210-1234)P7(1235-1289)B8(1290-1314)B9(1315-1339)P10(1340-1394)
B11(1395-1419)B12(1420-1444)P13(1445-1499)I14(1500-1579)...
Yang & Hu Expires January 10, 2011 [Page 5]
Internet-Draft Selective transmission July 2010
If transient congestion will occur at the I1 frame of this video
frame sequence, and about ten packets will be dropped, intermediary
network element may drop B2 and/or B3 and/or other B-frames in terms
of the congestion level.
After intermediary network element decides to drop these video
packets, it immediately needs to send Selective Transmission
Notification Indication to RTP receivers to suppress the
retransmission request for these video packets.
If the last RTP packet having been dropped is still unknown before
intermediary network element sends Selective Transmission
Notification Indication, intermediary network element may send a
Selective Transmission Notification Indication without the last RTP
sequence number. Intermediary network element sends a Selective
Transmission Notification Indication again with the last RTP sequence
number when it gets the last RTP sequence number
6. RTP Packet Format
This section defines the Header Extension for RTP Selective
Transmission Notification Indication (STNI) by intermediary network
element which notifies RTP receivers not to send the retransmission
request for those packets which have been discarded actively when
selective transmission occurs.
6.1. Selective Transmission Notification Indication
The Selective Transmission Notification Indication is delivered to
the RTP Receivers in-band using the "General Mechanism for RTP Header
Extensions" [RFC5285]. The format of the Selective Transmission
Notification Indication is shown in Figure 1. The Selective
Transmission Notification Indication consists of Network Reason of
selective transmission, Notification Information Mode (NIM) of
selective transmission and Notification Information of selective
transmission.
Yang & Hu Expires January 10, 2011 [Page 6]
Internet-Draft Selective transmission July 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. RTP Header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | Network Reason| ID | L=0 | NIM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (pad) | ID | L= |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Information Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Information Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 The format of Selective Transmission Notification Indication
Network Reason of selective transmission: Network Reason field is one
octet and its length field is equal to zero; Network Reason indicates
the reason why selective transmission happens. Network Reason field
set to one means network congestion happening. Other Values are
Unassigned.
0: Unassigned
1: Network Congestion
2-255: Unassigned
Notification Information Mode (NIM) of selective transmission:
Notification Information Mode field is one octet and its length field
is equal to zero; The Notification Information Mode indicates the
structure of notification information field. When Notification
Information Mode field is set to one, Notification information field
uses sequence pairs of Start Sequence Number and Stop Sequence Number
shown in Figure 2 to indicate discarding RTP packets. When
Notification Information Mode field is set to two, Notification
information field uses Packet Identifier consisting of Start Sequence
Number and Bitmask of Following Packets shown in Figure 3 to indicate
discarding RTP packets. Other Values are Unassigned.
0: Unassigned
1: Sequence Pairs
2: Packet Identifier
3-255: unassigned
Yang & Hu Expires January 10, 2011 [Page 7]
Internet-Draft Selective transmission July 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | Network Reason| ID | L=0 | NIM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (pad) | ID | L= |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Sequence Number | Stop Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Sequence Number | Stop Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Notification Information based on Sequence pairs
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | Network Reason| ID | L=0 | NIM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (pad) | ID | L= |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Sequence Number | Bitmask of Following Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Sequence Number | Bitmask of Following Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Notification Information based on Packet Identifier
Notification Information of selective transmission: The structure of
Notification Information field depends on the Notification
Information Mode. The length of Notification Information field is
variable, and consists of Notification Information Units. Each
Notification Information Unit is four octets.
7. Signaling Information
The URI for declaring the selective transmission header extension in
an SDP extmap attribute and mapping it to local extension header
Yang & Hu Expires January 10, 2011 [Page 8]
Internet-Draft Selective transmission July 2010
identifiers are "urn:ietf:params:rtp-hdrext: sel-trans-net-
reason,sel-trans-noti-info-mode and sel-trans-noti-inf ". There is
no additional setup information needed for this extension (i.e. no
extensionattributes).
An example attribute line in the SDP might be:
a=extmap:4/sendonly urn:ietf:params:rtp-hdrext: sel-trans-netreason
a=extmap:5/sendonly urn:ietf:params:rtp-hdrext: sel-trans-notinfmode
a=extmap:6/sendonly urn:ietf:params:rtp-hdrext: sel-trans-notinf
8. Security Considerations
TBD.
9. IANA Considerations
IANA should register three new extension URIs to the RTP Compact
Header Extensions subregistry of the Real-Time Transport Protocol
(RTP) Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext: sel-trans-netreason
Description: Network Reason of selective transmission
Contact: Peilin Yang <yangpeilin@huawei.com>
Reference: RFC xxxx
Extension URI: urn:ietf:params:rtp-hdrext: sel-trans-notinfmode
Description: Notification Information Mode of selective transmission
Contact: Peilin Yang <yangpeilin@huawei.com>
Reference: RFC xxxx
Extension URI: urn:ietf:params:rtp-hdrext: sel-trans-notinf
Description: Notification Information of selective transmission
Contact: Peilin Yang <yangpeilin@huawei.com>
Reference: RFC xxxx
10. Acknowledgements
TBD.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Yang & Hu Expires January 10, 2011 [Page 9]
Internet-Draft Selective transmission July 2010
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
Authors' Addresses
Peilin Yang
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District, Nanjing 210012
P.R.China
Phone: +86-25-56622638
Email: yangpeilin@huawei.com
Yinliang Hu
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District, Nanjing 210012
P.R.China
Phone: +86-25-56622642
Email: huyingliang@huawei.com
Yang & Hu Expires January 10, 2011 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:35 |