draft-ietf-avt-rtp-retransmission-07.txt   draft-ietf-avt-rtp-retransmission-08.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission- J. Rey/Matsushita draft-ietf-avt-rtp-retransmission- J. Rey/Matsushita
07.txt D. Leon/Nokia 08.txt D. Leon/Nokia
A. Miyazaki/Matsushita A. Miyazaki/Matsushita
V. Varsa/Nokia V. Varsa/Nokia
R. Hakenberg/Matsushita R. Hakenberg/Matsushita
Expires: November 2003 April 2003 Expires: June 2003 December 2003
RTP Retransmission Payload Format RTP Retransmission Payload Format
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026. with all provisions of Section 10 of RFC 2026.
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction..................................................3 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 4. Retransmission payload format.................................6
5. Asocciation of a retransmission stream to its original stream.8 5. Asocciation of a retransmission stream to its original stream.8
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 7. Congestion control...........................................12
8. Retransmission Payload Format MIME type registration.........13 8. Retransmission Payload Format MIME type registration.........13
9. RTSP considerations..........................................19 9. RTSP considerations..........................................19
10. Implementation examples.....................................21 10. Implementation examples.....................................21
11. IANA considerations.........................................24 11. IANA considerations.........................................23
12. Security considerations.....................................24 12. Security considerations.....................................24
13. Acknowledgements............................................24 13. Acknowledgements............................................24
14. References..................................................25 14. References..................................................25
15. Author's Addresses..........................................26 15. Author's Addresses..........................................25
IPR Notices.....................................................26 IPR Notices.....................................................26
Full Copyright Statement........................................27 Full Copyright Statement........................................27
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.
skipping to change at page 4, line 30 skipping to change at page 4, line 30
in this document are to be interpreted as described in RFC 2119 in this document are to be interpreted as described in RFC 2119
[2]. [2].
3. Requirements and design rationale for a retransmission scheme 3. Requirements and design rationale for a retransmission scheme
The use of retransmissions in RTP as a repair method for streaming The use of retransmissions in RTP as a repair method for streaming
media is appropriate in those scenarios with relaxed delay bounds media is appropriate in those scenarios with relaxed delay bounds
and where full reliability is not a requirement. More and where full reliability is not a requirement. More
specifically, RTP retransmission allows to trade-off reliability specifically, RTP retransmission allows to trade-off reliability
vs. delay, i.e. the endpoints may give up retransmitting a lost vs. delay, i.e. the endpoints may give up retransmitting a lost
packet after a given buffering time has elapsed. Unlike TCP packet after a given buffering time has elapsed. Unlike TCP there
there is thus no head-of-line blocking caused by RTP is thus no head-of-line blocking caused by RTP retransmissions.
retransmissions. The implementer should be aware that in cases The implementer should be aware that in cases where full
where full reliability is required or higher delay and jitter can reliability is required or higher delay and jitter can be
be tolerated, TCP or other transport options should be considered. tolerated, TCP or other transport options should be considered.
The RTP retransmission scheme defined in this document is designed The RTP retransmission scheme defined in this document is designed
to fulfil the following set of requirements: to fulfil the following set of requirements:
1. It must not break general RTP and RTCP mechanisms. 1. It must not break general RTP and RTCP mechanisms.
2. It must be suitable for unicast and small multicast groups. 2. It must be suitable for unicast and small multicast groups.
3. It must work with mixers and translators. 3. It must work with mixers and translators.
4. It must work with all known payload types. 4. It must work with all known payload types.
5. It must not prevent the use of multiple payload types in a 5. It must not prevent the use of multiple payload types in a
session. session.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
happened. In addition, an RTCP BYE packet MUST also be sent for happened. In addition, an RTCP BYE packet MUST also be sent for
the associated stream in its own session. After a new SSRC the associated stream in its own session. After a new SSRC
identifier is obtained, the SSRC of both streams MUST be set to identifier is obtained, the SSRC of both streams MUST be set to
this value. this value.
In the case of SSRC-multiplexing, two different SSRC values MUST In the case of SSRC-multiplexing, two different SSRC values MUST
be used for the original stream and the retransmission stream as be used for the original stream and the retransmission stream as
required by RTP. If an SSRC collision is detected for either the required by RTP. If an SSRC collision is detected for either the
original stream or the retransmission stream, the RTP original stream or the retransmission stream, the RTP
specification requires that an RTCP BYE packet MUST be sent for specification requires that an RTCP BYE packet MUST be sent for
this stream. No RTCP BYE packet MUST be sent for the associated this stream. An RTCP BYE packet MUST NOT be sent for the
stream. Therefore, only the stream that experienced SSRC associated stream. Therefore, only the stream that experienced
collision will choose a new SSRC value. Refer to Section 5.3 for SSRC collision will choose a new SSRC value. Refer to Section 5.3
the implications on the original and retransmission stream SSRC for the implications on the original and retransmission stream
association at the receiver. SSRC association at the receiver.
For either multiplexing scheme, the sequence number has the For either multiplexing scheme, the sequence number has the
standard definition, i.e. it MUST be one higher than the sequence standard definition, i.e. it MUST be one higher than the sequence
number of the preceding packet sent in the retransmission stream. number of the preceding packet sent in the retransmission stream.
The retransmission packet timestamp is set to the original The retransmission packet timestamp is set to the original
timestamp, i.e. to the timestamp of the original packet. As a timestamp, i.e. to the timestamp of the original packet. As a
consequence, the initial RTP timestamp for the first packet of the consequence, the initial RTP timestamp for the first packet of the
retransmission stream is not random but equal to the original retransmission stream is not random but equal to the original
timestamp of the first packet that is retransmitted. See the timestamp of the first packet that is retransmitted. See the
skipping to change at page 7, line 47 skipping to change at page 7, line 47
stream MUST map to a different payload type value in the stream MUST map to a different payload type value in the
retransmission stream. Therefore, when multiple payload types are retransmission stream. Therefore, when multiple payload types are
used in the original stream, multiple dynamic payload types will used in the original stream, multiple dynamic payload types will
be mapped to the retransmission payload format. See Section 8.1 be mapped to the retransmission payload format. See Section 8.1
for the specification of how the mapping between original and for the specification of how the mapping between original and
retransmission payload types is done with SDP. retransmission payload types is done with SDP.
As the retransmission packet timestamp carries the original media As the retransmission packet timestamp carries the original media
timestamp, the timestamp clockrate used by the retransmission timestamp, the timestamp clockrate used by the retransmission
payload type is the same as the one used by the associated payload type is the same as the one used by the associated
original payload type. It is thus possible to send retransmission original payload type. Therefore, if an RTP stream carries
packets whose original payload types have different timestamp payload types of different clockrates, this will also be the case
clockrates in the same retransmission stream. Note that an RTP for the associated retransmission stream. Note that an RTP stream
stream does not usually carry payload types of different does not usually carry payload types of different clockrates.
clockrates.
The payload of the RTP retransmission packet comprises the The payload of the RTP retransmission packet comprises the
retransmission payload header followed by the payload of the retransmission payload header followed by the payload of the
original RTP packet. The length of the retransmission payload original RTP packet. The length of the retransmission payload
header is 2 octets. This payload header contains only one field, header is 2 octets. This payload header contains only one field,
OSN (original sequence number), which MUST be set to the sequence OSN (original sequence number), which MUST be set to the sequence
number of the associated original RTP packet. The original RTP number of the associated original RTP packet. The original RTP
packet payload, including any possible payload headers specific to packet payload, including any possible payload headers specific to
the original payload type, is placed right after the the original payload type, is placed right after the
retransmission payload header. retransmission payload header.
For payload types that support encoding at multiple rates, instead For payload formats that support encoding at multiple rates,
of retransmitting the same payload as the original RTP packet the instead of retransmitting the same payload as the original RTP
sender MAY retransmit the same data encoded at a lower rate. This packet the sender MAY retransmit the same data encoded at a lower
aims at limiting the bandwidth usage of the retransmission stream. rate. This aims at limiting the bandwidth usage of the
When doing so, the sender MUST ensure that the receiver will still retransmission stream. When doing so, the sender MUST ensure that
be able to decode the payload of the already sent original packets the receiver will still be able to decode the payload of the
that might have been encoded based on the payload of the lost already sent original packets that might have been encoded based
original packet. In addition, if the sender chooses to retransmit on the payload of the lost original packet. In addition, if the
at a lower rate, the values in the payload header of the original sender chooses to retransmit at a lower rate, the values in the
RTP packet may not longer apply to the retransmission packet and payload header of the original RTP packet may not longer apply to
may need to be modified in the retransmission packet to reflect the retransmission packet and may need to be modified in the
the change in rate. The sender should trade-off the decrease in retransmission packet to reflect the change in rate. The sender
bandwidth usage with the decrease in quality caused by resending should trade-off the decrease in bandwidth usage with the decrease
at a lower rate. in quality caused by resending at a lower rate.
If the original RTP header carried any profile-specific If the original RTP header carried any profile-specific
extensions, the retransmission packet SHOULD include the same extensions, the retransmission packet SHOULD include the same
extensions immediately following the fixed RTP header as expected extensions immediately following the fixed RTP header as expected
by applications running under this profile. In this case, the by applications running under this profile. In this case, the
retransmission payload header is thus placed after the profile- retransmission payload header is thus placed after the profile-
specific extensions. specific extensions.
If the original RTP header carried an RTP header extension, the If the original RTP header carried an RTP header extension, the
retransmission packet SHOULD carry the same header extension. retransmission packet SHOULD carry the same header extension.
skipping to change at page 12, line 24 skipping to change at page 12, line 24
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
application being used. application being used.
Furthermore, receivers may make use of the minimum interval Furthermore, receivers may make use of the minimum interval
between regular RTCP compound packets. This interval can be used between regular RTCP compound packets. This interval can be used
to keep regular receiver reporting down to a minimum, while still to keep regular receiver reporting down to a minimum, while still
allowing receivers to send early RTCP packets during periods allowing receivers to send early RTCP packets during periods
requiring more frequent feedback, e.g. times of higher packet loss requiring more frequent feedback, e.g. times of higher packet loss
rate.. Note that although RTCP packets may be suppressed because rate. Note that although RTCP packets may be suppressed because
they do not contain NACKs, the same RTCP bandwidth as if they were they do not contain NACKs, the same RTCP bandwidth as if they were
sent needs to be available. See AVPF [1] for details on the use sent needs to be available. See AVPF [1] for details on the use
of the minimum interval. of the minimum interval.
7. Congestion control 7. Congestion control
RTP retransmission poses a risk of increasing network congestion. RTP retransmission poses a risk of increasing network congestion.
In a best-effort environment, packet loss is caused by congestion. In a best-effort environment, packet loss is caused by congestion.
Reacting to loss by retransmission of older data without Reacting to loss by retransmission of older data without
decreasing the rate of the original stream would thus further decreasing the rate of the original stream would thus further
skipping to change at page 13, line 17 skipping to change at page 13, line 15
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. Packet loss is considered
acceptable if a TCP flow across the same network path and acceptable if a TCP flow across the same network path and
experiencing the same network conditions would achieve, on a experiencing the same network conditions would achieve, on a
reasonable timescale, an average throughput, that is not less than reasonable timescale, an average throughput, that is not less than
the one the RTP flow achieves. If the packet loss rate exceeds an the one the RTP flow achieves. If the packet loss rate exceeds an
acceptable level, it should be concluded that congestion is not acceptable level, it SHOULD be concluded that congestion is not
kept under control and retransmission should then not be used. It kept under control and retransmission SHOULD NOT then be used. It
may further be necessary to adapt the transmission rate (or the may further be necessary to adapt the transmission rate (or the
number of layers subscribed for a layered multicast session), or number of layers subscribed for a layered multicast session), or
to arrange for the receiver to leave the session. 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".
 End of changes. 

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