draft-ietf-avt-rtp-retransmission-11.txt   draft-ietf-avt-rtp-retransmission-12.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission- J. Rey/Panasonic draft-ietf-avt-rtp-retransmission- J. Rey/Panasonic
11.txt D. Leon/Nokia 12.txt D. Leon/Nokia
A. Miyazaki/Panasonic A. Miyazaki/Panasonic
V. Varsa/Nokia V. Varsa/Nokia
R. Hakenberg/Panasonic R. Hakenberg/Panasonic
Expires: September 7, 2005 March 7, 2005 Expires: March 15, 2006 September 15, 2005
RTP Retransmission Payload Format RTP Retransmission Payload Format
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt http://www.ietf.org/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice [Note to RFC Editor: This paragraph shall be deleted upon
publication as an RFC. References in this draft to RFC XXXX
Copyright (C) The Internet Society (2005). All Rights Reserved. should be replaced with the RFC number assigned to this document.]
[Note to RFC Editor: This paragraph is to be deleted when this
draft is published as an RFC. References in this draft to RFC
XXXX should be replaced with the RFC number assigned to this
document.]
Abstract Abstract
RTP retransmission is an effective packet loss recovery technique RTP retransmission is an effective packet loss recovery technique
for real-time applications with relaxed delay bounds. This for real-time applications with relaxed delay bounds. This
document describes an RTP payload format for performing document describes an RTP payload format for performing
retransmissions. Retransmitted RTP packets are sent in a separate retransmissions. Retransmitted RTP packets are sent in a separate
stream from the original RTP stream. It is assumed that feedback stream from the original RTP stream. It is assumed that feedback
from receivers to senders is available. In particular, it is from receivers to senders is available. In particular, it is
assumed that RTCP feedback as defined in the extended RTP profile assumed that RTCP feedback as defined in the extended RTP profile
for RTCP-based feedback (denoted RTP/AVPF), is available in this for RTCP-based feedback (denoted RTP/AVPF), is available in this
memo. memo.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................3
2. Terminology...................................................3 2. Terminology...................................................3
3. Requirements and design rationale for a retransmission scheme.4 3. Requirements and design rationale for a retransmission scheme.4
4. Retransmission payload format.................................6 3.1 Multiplexing scheme choice..................................6
5. Asocciation of a retransmission stream to its original stream.8 4. Retransmission payload format.................................7
5. Association of retransmission and original streams............9
5.1 Retransmission session sharing..............................9
5.2 CNAME use...................................................9
5.3 Association at the receiver.................................9
6. Use with the extended RTP profile for RTCP-based feedback....10 6. Use with the extended RTP profile for RTCP-based feedback....10
7. Congestion control...........................................12 6.1 RTCP at the sender.........................................11
8. Retransmission Payload Format MIME type registration.........13 6.2 RTCP Receiver Reports......................................11
9. RTSP considerations..........................................19 6.3 Retransmission requests....................................11
10. Implementation examples.....................................21 6.4 Timing rules...............................................12
11. IANA considerations.........................................23 7. Congestion control...........................................13
12. Security considerations.....................................23 8. Retransmission Payload Format MIME type registration.........14
13. Acknowledgements............................................24 8.1 Introduction...............................................14
14. References..................................................24 8.2 Registration of audio/rtx..................................15
15. Author's Addresses..........................................25 8.3 Registration of video/rtx..................................16
IPR Notices.....................................................26 8.4 Registration of text/rtx...................................17
Full Copyright Statement........................................26 8.5 Registration of application/rtx............................17
8.6 Mapping to SDP.............................................18
8.7 SDP description with session-multiplexing..................19
8.8 SDP description with SSRC-multiplexing.....................20
9. RTSP considerations..........................................20
9.1 RTSP control with SSRC-multiplexing........................21
9.2 RTSP control with session-multiplexing.....................21
9.3 RTSP control of the retransmission stream..................22
9.4 Cache control..............................................22
10. Implementation examples.....................................22
10.1 A minimal receiver implementation example.................22
10.2 Retransmission of Layered Encoded Media in Multicast......23
11. IANA considerations.........................................24
12. Security considerations.....................................24
13. Acknowledgements............................................25
14. References..................................................25
14.1 Normative References......................................25
14.2 Informative References....................................26
15. Author's Addresses..........................................26
Appendix A. How to control the number of rtxs. per packet.......27
IPR Notices.....................................................31
Full Copyright Statement........................................32
1. Introduction 1. Introduction
Packet losses between an RTP sender and receiver may significantly Packet losses between an RTP sender and receiver may significantly
degrade the quality of the received media. Several techniques, degrade the quality of the received media. Several techniques,
such as forward error correction (FEC), retransmissions or such as forward error correction (FEC), retransmissions or
interleaving may be considered to increase packet loss resiliency. interleaving may be considered to increase packet loss resiliency.
RFC 2354 [8] discusses the different options. RFC 2354 [8] discusses the different options.
When choosing a repair technique for a particular application, the When choosing a repair technique for a particular application, the
skipping to change at page 3, line 11 skipping to change at page 3, line 30
be increased. The sender may use the receiver feedback in be increased. The sender may use the receiver feedback in
order to react to losses before their playout time at the order to react to losses before their playout time at the
receiver. receiver.
In the case of multimedia streaming, the user can tolerate an In the case of multimedia streaming, the user can tolerate an
initial latency as part of the session set-up and thus an end-to- initial latency as part of the session set-up and thus an end-to-
end delay of several seconds may be acceptable. RTP end delay of several seconds may be acceptable. RTP
retransmission as defined in this document is targeted at such retransmission as defined in this document is targeted at such
applications. applications.
At this point, the attention of the reader is called to the fact
that the retransmission mechanism for RTP described in this
document may be encumbered by patent applications filed from
Panasonic. Please refer to the IPR Notices section for details.
Furthermore, the RTP retransmission method defined herein is Furthermore, the RTP retransmission method defined herein is
applicable to unicast and (small) multicast groups. The present applicable to unicast and (small) multicast groups. The present
document defines a payload format for retransmitted RTP packets document defines a payload format for retransmitted RTP packets
and provides protocol rules for the sender and the receiver and provides protocol rules for the sender and the receiver
involved in retransmissions. involved in retransmissions.
This retransmission payload format was designed for use with the This retransmission payload format was designed for use with the
extended RTP profile for RTCP-based feedback, AVPF [1]. It may extended RTP profile for RTCP-based feedback, AVPF [1]. It may
also be used with other RTP profiles defined in the future. also be used with other RTP profiles defined in the future.
skipping to change at page 8, line 44 skipping to change at page 9, line 16
If the original RTP packet contained RTP padding, that padding If the original RTP packet contained RTP padding, that padding
MUST be removed before constructing the retransmission packet. If MUST be removed before constructing the retransmission packet. If
padding of the retransmission packet is needed, padding MUST be padding of the retransmission packet is needed, padding MUST be
performed as with any RTP packets and the padding bit MUST be set. performed as with any RTP packets and the padding bit MUST be set.
The marker bit (M), the CSRC count (CC) and the CSRC list of the The marker bit (M), the CSRC count (CC) and the CSRC list of the
original RTP header MUST be copied "as is" into the RTP header of original RTP header MUST be copied "as is" into the RTP header of
the retransmission packet. the retransmission packet.
5. Association of a retransmission stream to its original stream 5. Association of retransmission and original streams
5.1 Retransmission session sharing 5.1 Retransmission session sharing
In the case of session-multiplexing, a retransmission session MUST In the case of session-multiplexing, a retransmission session MUST
map to exactly one original session, i.e. the same retransmission map to exactly one original session, i.e. the same retransmission
session cannot be used for different original sessions. session cannot be used for different original sessions.
If retransmission session sharing were allowed, it would be a If retransmission session sharing were allowed, it would be a
problem for receivers, since they would receive retransmissions problem for receivers, since they would receive retransmissions
for original sessions they might not have joined. For example, a for original sessions they might not have joined. For example, a
receiver wishing to receive only audio would receive also receiver wishing to receive only audio would receive also
retransmitted video packets if an audio and video session shared retransmitted video packets if an audio and video session shared
the same retransmission session. the same retransmission session.
5.2 CNAME use 5.2 CNAME use
In both the session-multiplexing and the SSRC-multiplexing cases, In both the session-multiplexing and the SSRC-multiplexing cases,
a sender MUST use the same CNAME for an original stream and its a sender MUST use the same CNAME [3] for an original stream and
associated retransmission stream. its associated retransmission stream.
5.3 Association at the receiver 5.3 Association at the receiver
A receiver receiving multiple original and retransmission streams A receiver receiving multiple original and retransmission streams
needs to associate each retransmission stream with its original needs to associate each retransmission stream with its original
stream. The association is done differently depending on whether stream. The association is done differently depending on whether
session-multiplexing or SSRC-multiplexing is used. session-multiplexing or SSRC-multiplexing is used.
If session-multiplexing is used, the receiver associates the two If session-multiplexing is used, the receiver associates the two
streams having the same SSRC in the two sessions. Note that the streams having the same SSRC in the two sessions. Note that the
skipping to change at page 11, line 39 skipping to change at page 12, line 15
packet after a NACK has been sent for that packet. This estimate packet after a NACK has been sent for that packet. This estimate
may also be obtained from past observations, RTCP report round- may also be obtained from past observations, RTCP report round-
trip time if available or any other means. A standard mechanism trip time if available or any other means. A standard mechanism
for the receiver to estimate the RTT is specified in RTP Extended for the receiver to estimate the RTT is specified in RTP Extended
Reports [11]. Reports [11].
The receiver should not send a retransmission request as soon as The receiver should not send a retransmission request as soon as
it detects a missing sequence number but should add some extra it detects a missing sequence number but should add some extra
delay to compensate for packet reordering. This extra delay may, delay to compensate for packet reordering. This extra delay may,
for example, be based on past observations of the experienced for example, be based on past observations of the experienced
packet reordering. packet reordering. It should be noted that, in environments where
packet reordering is rare or does not take place, e.g., if the
underlying datalink layer affords ordered delivery, the delay may
be extremely low or even take the value zero. In such cases, an
appropriate "reorder delay" algorithm may not actually be timer-
based, but packet-based. E.g., if n number of packets are
received after a gap is detected, then it may be assumed that the
packet was truly lost rather than out of order. This may turn out
to be far easier to code on some platforms as a very short fixed
FIFO packet buffer as opposed to the timer-based mechanism.
To increase the robustness to the loss of a NACK or of a To increase the robustness to the loss of a NACK or of a
retransmission packet, a receiver may send a new NACK for the same retransmission packet, a receiver may send a new NACK for the same
packet. This is referred to as multiple retransmissions. Before packet. This is referred to as multiple retransmissions. Before
sending a new NACK for a missing packet, the receiver should rely sending a new NACK for a missing packet, the receiver should rely
on a timer to be reasonably sure that the previous retransmission on a timer to be reasonably sure that the previous retransmission
attempt has failed in order to avoid unnecessary retransmissions. attempt has failed and so avoid unnecessary retransmissions. The
timer value shall be based on the observed round-trip time. Both,
a static or an adaptive value MAY be used. E.g.: an adaptive timer
could be one that changes its value with every new request for the
same packet. This document does not provide any guidelines as to
how this adaptive value should be calculated because no
experiments have been done to find this out.
NACKs MUST be sent only for the original RTP stream. Otherwise, NACKs MUST be sent only for the original RTP stream. Otherwise,
if a receiver wanted to perform multiple retransmissions by if a receiver wanted to perform multiple retransmissions by
sending a NACK in the retransmission stream, it would not be able sending a NACK in the retransmission stream, it would not be able
to know the original sequence number and a timestamp estimation of to know the original sequence number and a timestamp estimation of
the packet it requests. the packet it requests.
Appendix A gives some guidelines as to how to control the number
of retransmissions.
6.4 Timing rules 6.4 Timing rules
The NACK feedback message may be sent in a regular full compound The NACK feedback message may be sent in a regular full compound
RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending
a NACK in an early packet allows to react more quickly to a given a NACK in an early packet allows to react more quickly to a given
packet loss. However, in that case if a new packet loss occurs packet loss. However, in that case if a new packet loss occurs
right after the early RTCP packet was sent, the receiver will then right after the early RTCP packet was sent, the receiver will then
have to wait for the next regular RTCP compound packet after the have to wait for the next regular RTCP compound packet after the
early packet. Sending NACKs only in regular RTCP compound early packet. Sending NACKs only in regular RTCP compound
decreases the maximum delay between detecting an original packet decreases the maximum delay between detecting an original packet
loss and being able to send a NACK for that packet. Implementers loss and being able to send a NACK for that packet. Implementers
should consider the possible implications of this fact for the should consider the possible implications of this fact for the
skipping to change at page 13, line 10 skipping to change at page 13, line 53
services are actually delivered. In a best-effort environment, services are actually delivered. In a best-effort environment,
the sender SHOULD NOT send retransmission packets without reducing the sender SHOULD NOT send retransmission packets without reducing
the packet rate and bitrate of the original stream (for example by the packet rate and bitrate of the original stream (for example by
encoding the data at a lower rate). encoding the data at a lower rate).
In addition, the sender MAY selectively retransmit only the In addition, the sender MAY selectively retransmit only the
packets that it deems important and ignore NACK messages for other packets that it deems important and ignore NACK messages for other
packets in order to limit the bitrate. packets in order to limit the bitrate.
These congestion control mechanisms should keep the packet loss These congestion control mechanisms should keep the packet loss
rate within acceptable parameters. Packet loss is considered rate within acceptable parameters. In the context of congestion
acceptable if a TCP flow across the same network path and control, packet loss is considered acceptable if a TCP flow across
experiencing the same network conditions would achieve, on a the same network path and experiencing the same network conditions
reasonable timescale, an average throughput, that is not less than would achieve, on a reasonable timescale, an average throughput,
the one the RTP flow achieves. If the packet loss rate exceeds an that is not less than the one the RTP flow achieves. If congestion
acceptable level, it SHOULD be concluded that congestion is not is not kept under control, then retransmission SHOULD NOT be used.
kept under control and retransmission SHOULD NOT then be used. It
may further be necessary to adapt the transmission rate (or the Retransmissions MAY still be sent in some cases, e. g., in
number of layers subscribed for a layered multicast session), or wireless links where packet losses are not caused by congestion,
to arrange for the receiver to leave the session. if the server (or the client that makes the retransmission
request) estimates that a particular packet or frame is important
to continue play out, or if an RTSP PAUSE has been issued to allow
the buffer to fill up (RTSP PAUSE does not affect the sending of
retransmissions.)
Finally, it may further be necessary to adapt the transmission
rate (or the number of layers subscribed for a layered multicast
session), or to arrange for the receiver to leave the session.
8. Retransmission Payload Format MIME type registration 8. Retransmission Payload Format MIME type registration
8.1 Introduction 8.1 Introduction
The following MIME subtype name and parameters are introduced in The following MIME subtype name and parameters are introduced in
this document: "rtx", "rtx-time" and "apt". this document: "rtx", "rtx-time" and "apt".
The binding used for the retransmission stream to the payload type The binding used for the retransmission stream to the payload type
number is indicated by an rtpmap attribute. The MIME subtype name number is indicated by an rtpmap attribute. The MIME subtype name
skipping to change at page 14, line 43 skipping to change at page 15, line 43
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de jose.rey@eu.panasonic.com
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG IETF AVT WG delegated from the IESG
8.3 Registration of video/rtx 8.3 Registration of video/rtx
MIME type: video MIME type: video
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP rate: the RTP timestamp clockrate is equal to the RTP
skipping to change at page 15, line 42 skipping to change at page 16, line 42
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de jose.rey@eu.panasonic.com
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG IETF AVT WG delegated from the IESG
8.4 Registration of text/rtx 8.4 Registration of text/rtx
MIME type: text MIME type: text
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP rate: the RTP timestamp clockrate is equal to the RTP
skipping to change at page 16, line 40 skipping to change at page 17, line 40
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de jose.rey@eu.panasonic.com
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG IETF AVT WG delegated from the IESG
8.5 Registration of application/rtx 8.5 Registration of application/rtx
MIME type: application MIME type: application
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP rate: the RTP timestamp clockrate is equal to the RTP
timestamp clockrate of the media that is retransmitted. timestamp clockrate of the media that is retransmitted.
skipping to change at page 17, line 35 skipping to change at page 18, line 35
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de jose.rey@eu.panasonic.com
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG IETF AVT WG delegated from the IESG
8.6 Mapping to SDP 8.6 Mapping to SDP
The information carried in the MIME media type specification has a The information carried in the MIME media type specification has a
specific mapping to fields in SDP [5], which is commonly used to specific mapping to fields in SDP [5], which is commonly used to
describe RTP sessions. When SDP is used to specify describe RTP sessions. When SDP is used to specify
retransmissions for an RTP stream, the mapping is done as retransmissions for an RTP stream, the mapping is done as
follows: follows:
- The MIME types ("video"), ("audio"), ("text") and - The MIME types ("video"), ("audio"), ("text") and
skipping to change at page 23, line 32 skipping to change at page 24, line 32
11. IANA considerations 11. IANA considerations
A new MIME subtype name, "rtx", has been registered for four A new MIME subtype name, "rtx", has been registered for four
different media types, as follows: "video", "audio", "text" and different media types, as follows: "video", "audio", "text" and
"application". An additional REQUIRED parameter, "apt", and an "application". An additional REQUIRED parameter, "apt", and an
OPTIONAL parameter, "rtx-time", are defined. See Section 8 for OPTIONAL parameter, "rtx-time", are defined. See Section 8 for
details. details.
12. Security considerations 12. Security considerations
If cryptography is used to provide security services on the RTP packets using the payload format defined in this specification
original stream, then the same services, with equivalent are subject to the general security considerations discussed in
cryptographic strength, MUST be provided on the retransmission RTP, Section 9.
stream. Old keys will likely need to be cached so that when the
keys change for the original stream, the old key is used until it
is determined that the key has changed on the retransmission
packets as well.
The use of the same key for the retransmitted stream and the In common streaming scenarios message authentication, data
original stream may lead to security problems, e.g. two-time pads. integrity, replay protection and confidentiality are desired.
This sharing has to be evaluated towards the chosen security
protocol and security algorithms. The absence of authentication may enable man-in-the-middle and
replay attacks, which can be very harmful for RTP retransmission.
For example: tampered RTCP packets may trigger inappropriate
retransmissions that effectively reduce the actual bitrate share
allocated to the original data stream, tampered RTP retransmission
packets could cause the client's decoder to crash, tampered
retransmission requests may invalidate the SSRC association
mechanism described in Section 5 of this document. On the other
hand, replayed packets could lead to false re-ordering and RTT
measurements (required for the retransmission request strategy)
and may cause the receiver buffer to overflow.
Further, in order to ensure confidentiality of the data, the
original payload data needs to be encrypted. There is actually no
need to encrypt the 2-byte retransmission payload header since it
does not provide any hints about the data content.
Furthermore, it is RECOMMENDED that the cryptography mechanisms Furthermore, it is RECOMMENDED that the cryptography mechanisms
used for this payload format provide protection against known used for this payload format provide protection against known
plaintext attacks. RTP recommends that the initial RTP timestamp plaintext attacks. RTP recommends that the initial RTP timestamp
SHOULD be random to secure the stream against known plaintext SHOULD be random to secure the stream against known plaintext
attacks. This payload format does not follow this recommendation attacks. This payload format does not follow this recommendation
as the initial timestamp will be the media timestamp of the first as the initial timestamp will be the media timestamp of the first
retransmitted packet. However, since the initial timestamp of the retransmitted packet. However, since the initial timestamp of the
original stream is itself random, if the original stream is original stream is itself random, if the original stream is
encrypted, the first retransmitted packet timestamp would also be encrypted, the first retransmitted packet timestamp would also be
random to an attacker. Therefore, confidentiality would not be random to an attacker. Therefore, confidentiality would not be
compromised. compromised.
If cryptography is used to provide security services on the
original stream, then the same services, with equivalent
cryptographic strength, MUST be provided on the retransmission
stream. The use of the same key for the retransmitted stream and
the original stream may lead to security problems, e. g., two-time
pads. Refer to Section 9.1 of the Secure Real-Time Transport
Protocol (SRTP)[12] for a discussion the implications of two-time
pads and how to avoid them.
At the time of writing this document, SRTP does not provide all
the security services mentioned. There are, at least, two reasons
for this: 1) the occurrence of two-time pads and 2) the fact that
this payload format typically works under the RTP/AVPF profile
while SRTP only supports RTP/AVP. An adapted variant of SRTP
shall solve these shortcomings in the future.
Congestion control considerations with the use of retransmission Congestion control considerations with the use of retransmission
are dealt with in Section 7 of this document. are dealt with in Section 7 of this document.
Any other security considerations of the profile under which the
retransmission scheme is used should be applied. The
retransmission payload format MUST NOT be used under the SAVP
profile defined by the Secure Real-Time Transport Protocol
(SRTP)[12] but instead an extension of SRTP should be defined to
secure the AVPF profile. The definition of such a profile is out
of the scope of this document.
13. Acknowledgements 13. Acknowledgements
We would like to express our gratitude to Carsten Burmeister for We would like to express our gratitude to Carsten Burmeister for
his participation in the development of this document. Our thanks his participation in the development of this document. Our thanks
also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus
Westerlund, Go Hori and Rahul Agarwal for their helpful comments. Westerlund, Go Hori and Rahul Agarwal for their helpful comments.
14. References 14. References
14.1 Normative References 14.1 Normative References
1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP
profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback-
04.txt, September 2002. 11.txt, August 2004.
2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", draft-ietf-avt- Transport Protocol for Real-Time Applications", RFC 3550, July
rtp-new-12.txt, March 2003. 2003.
4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC
ietf-avt-rtcp-bw-05.txt, May 2002. 3556, July 2003.
5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. RFC 2327, April 1998.
6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media
lines in the Session Description Protocol (SDP)", RFC 3388, lines in the Session Description Protocol (SDP)", RFC 3388,
December 2002. December 2002.
7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
skipping to change at page 25, line 14 skipping to change at page 26, line 32
9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000
10 M. Handley, et al., "The Reliable Multicast Design Space for 10 M. Handley, et al., "The Reliable Multicast Design Space for
Bulk Data Transfer", RFC 2887, August 2000. Bulk Data Transfer", RFC 2887, August 2000.
11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 11 Friedman, et. al., "RTP Extended Reports", Work in Progress.
12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M.
Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", Naslund, K. Norrman, "The Secure Real-Time Transport Protocol",
draft-ietf-avt-srtp-05.txt, June 2002. RFC 3711, March 2004.
13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," BCP 11, RFC 2028, IETF, October 1996. Standards Process," BCP 11, RFC 2028, IETF, October 1996.
15. Author's Addresses 15. Author's Addresses
Jose Rey rey@panasonic.de Jose Rey jose.rey@eu.panasonic.com
Panasonic R&D Center Germany GmbH Panasonic R&D Center Germany GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-134 Phone: +49-6103-766-134
Fax: +49-6103-766-166 Fax: +49-6103-766-166
David Leon david.leon@nokia.com David Leon david.leon@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX. USA Irving, TX. USA
skipping to change at page 25, line 47 skipping to change at page 27, line 13
1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan
Phone: +81-6-6900-9172 Phone: +81-6-6900-9172
Fax: +81-6-6900-9173 Fax: +81-6-6900-9173
Viktor Varsa viktor.varsa@nokia.com Viktor Varsa viktor.varsa@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX. USA Irving, TX. USA
Phone: 1-972-374-1861 Phone: 1-972-374-1861
Rolf Hakenberg hakenberg@panasonic.de Rolf Hakenberg rolf.hakenberg@eu.panasonic.com
Panasonic R&D Center Germany GmbH Panasonic R&D Center Germany GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-162 Phone: +49-6103-766-162
Fax: +49-6103-766-166 Fax: +49-6103-766-166
Appendix A. How to control the number of rtxs. per packet
Finding out the number of retransmissions (rtxs.) per packet for
achieving the best possible transmission is a difficult task. Of
course, the absolute minimum should be one (1) - otherwise, do not
use this payload format. Moreover, as of date of publication, the
authors were not aware of any studies on the number of
retransmissions per packet that should be used for best
performance. To help implementers and researchers on this item,
this section describes an estimate of the buffering time required
for achieving a given number of retransmissions. Once this time
has been calculated, it can be communicated to the client via SDP
parameter "rtx-time", as defined in this document.
Scenario and Assumptions
========================
* Streaming scenario with relaxed delay bounds. Client and server
are provided with buffering space as indicated by the parameter
"rtx-time" in SDP.
* RTP AVPF profile used with SSRC-multiplexing retransmission
scheme: 1 SSRC for original packets, 1 for retransmission packets.
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR=0.05.
We have senders (2) and receivers (1). Receivers and senders get
equally 1/3 of the RTCP bandwidth share because the proportion of
senders is greater than 1/4 of session members.
* avg-rtcp-size is approximated by 120 bytes. This is a rounded-
up average of 2 SRs, one for each SSRC, containing 40/8/28/32
bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each;
and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157
bytes. Since senders and receivers share the RTCP bandwidth
equally, then avg-rtcp-size=(157+105+105)/3=117,3~=120 bytes. The
important characteristic of this value is that it is something
over 100 bytes, which seems to be a representative figure for
typical configurations.
* The profile used is AVPF [1] and Generic NACKs are used for
requesting retransmissions. This adds 16 bytes of overhead for 1
NACK and 4 bytes more for every additional NACK FCI field.
* We assume a worst-case scenario in which each packet exhausts
its corresponding number of available retransmissions, N, before
it is received. This means that if a packet may be requested for
retransmission a maximum of 2 times, the corresponding generic
NACK report block requesting that particular packet is sent in two
consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the generic NACK is sent 10 times.
This assumption makes the RTCP packet size approx. constant after
N*RTCP intervals (seconds), namely to avg-rtcp-size= 120 +
(receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver
RTCP bandwidth share is 1/3, thus avg-rtcp-size = 124 + 4*N/3.
* Two delay parameters are difficult to approximate and may be
implementation-dependent. Therefore, we list them here explicitly
without assigning them a particular value: one is the packet loss
detection time (T2) and the other feedback processing and queuing
time for retransmissions (T5). Implementers shall assign
appropriate values to these two parameters .
Graphically, we have:
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
Legend:
=======
DL : downlink (client->server)
UL : uplink (server->client)
Time unit is seconds, s.
Bitrate unit is bit per second, bps.
DL transmission time : T1= physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
Time to detect packet loss : T2= pkt-loss-detect-time
Time to report packet loss : T3= time-to-next-rtcp-report
UL transmission time : T4= physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
Retransmissions processing time : T5= feedback-processing-time +
rtx-queuing-time
Goal
====
To find an estimate of the buffering time, T(), that a streaming
server shall use in order to enable a given number of
retransmissions for each packet, N. This time is approximately
equal at the server and at the client, if one considers that the
client starts buffering T1 seconds later.
Solution
========
First we find the value of the estimate for 1 retransmission,
T(1)=T:
T = T1 + T2 + T3 + T4 + T5
Since T1 + T4 ~= RTT,
T = RTT + T2 + T3 + T5
The worst case for T3 would be that we assume that reporting has
to wait a whole RTCP interval and that the maximum randomization
factor of 1.5 is applied. Therefore, after applying the
subsequent compensation to avoid traffic bursts (see RTP Section
A.7 [3]), we have that T3 = 1.5/1.21828*RTCP-Interval. Thus,
T = RTT + 1.2312*RTCP-Interval + T2 + T5
On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders +
receivers)/(RR+RS). In this scenario: sender + receivers = 3;
RR+RS is the receiver report plus sender report bandwidth share,
in this case, equal to the default 5% of session bandwidth, bw.
We assume an average RTCP packet size, avg-rtcp-size=120 bytes.
This includes Thus:
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
for 1 retransmission.
For enabling N retransmissions, the available buffering time in a
streaming server or client is
approximately:
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
where, as per above,
avg-rtcp-size = 120 + (receiver-RTCP-bw-share=1/3)*(12 + 4*N) =
= 124 + 4*N/3.
Numbers
========
If we ignore the effect of T2 and T5, i.e., assume all losses are
detected immediately and that there is no additional delay due to
feedback processing or retransmission queuing, we have the
following buffering times for different values of N:
RTCP w/ several Generic NACKs; variable packet size= 124 + 4*N/3
bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====|======================================|
1,00 2,00 5,00 7,00 10,00
64000 0,05 1,21 2,44 6,28 8,97 13,18
128000 0,05 0,63 1,27 3,27 4,66 6,84
256000 0,05 0,34 0,68 1,76 2,50 3,67
512000 0,05 0,19 0,39 1,00 1,43 2,09
1024000 0,05 0,12 0,25 0,63 0,89 1,29
5000000 0,05 0,06 0,13 0,33 0,46 0,66
10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,2 1,36 2,74 7,03 10,02 14,68
128000 0,2 0,78 1,57 4,02 5,71 8,34
256000 0,2 0,49 0,98 2,51 3,55 5,17
512000 0,2 0,34 0,69 1,75 2,48 3,59
1024000 0,2 0,27 0,55 1,38 1,94 2,79
5000000 0,2 0,21 0,43 1,08 1,51 2,16
10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 1 2,16 4,34 11,03 15,62 22,68
128000 1 1,58 3,17 8,02 11,31 16,34
256000 1 1,29 2,58 6,51 9,15 13,17
512000 1 1,14 2,29 5,75 8,08 11,59
1024000 1 1,07 2,15 5,38 7,54 10,79
5000000 1 1,01 2,03 5,08 7,11 10,16
10000000 1 1,01 2,01 5,04 7,06 10,08
To quantify the error of not taking the Generic NACKS into
account, we can do the same numbers, but ignoring the Generic NACK
contribution, avg-rtcp-size ~= 120 bytes. As we see from below,
this may result in a buffer estimation error of 1-1.5 seconds (5-
10%) for lower bandwidth values and higher number of
retransmissions. This effect is low in this case. Nevertheless,
it should be carefully evaluated for the particular scenario; that
is why the formula includes it.
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====|======================================|
1,00 2,00 5,00 7,00 10,00
64000 0,05 1,16 2,32 5,79 8,11 11,58
128000 0,05 0,60 1,21 3,02 4,23 6,04
256000 0,05 0,33 0,65 1,64 2,29 3,27
512000 0,05 0,19 0,38 0,94 1,32 1,89
1024000 0,05 0,12 0,24 0,60 0,83 1,19
5000000 0,05 0,06 0,13 0,32 0,45 0,64
10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,2 1,31 2,62 6,54 9,16 13,08
128000 0,2 0,75 1,51 3,77 5,28 7,54
256000 0,2 0,48 0,95 2,39 3,34 4,77
512000 0,2 0,34 0,68 1,69 2,37 3,39
1024000 0,2 0,27 0,54 1,35 1,88 2,69
5000000 0,2 0,21 0,43 1,07 1,50 2,14
10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 1 2,11 4,22 10,54 14,76 21,08
128000 1 1,55 3,11 7,77 10,88 15,54
256000 1 1,28 2,55 6,39 8,94 12,77
512000 1 1,14 2,28 5,69 7,97 11,39
1024000 1 1,07 2,14 5,35 7,48 10,69
5000000 1 1,01 2,03 5,07 7,10 10,14
10000000 1 1,01 2,01 5,04 7,05 10,07
IPR Notices IPR Notices
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/