draft-ietf-avt-rtp-format-guidelines-00.txt | draft-ietf-avt-rtp-format-guidelines-01.txt | |||
---|---|---|---|---|
Internet Engineering Task Force AVT Working Group | Internet Engineering Task Force AVT Working Group | |||
Internet Draft Mark Handley | Internet Draft Mark Handley | |||
draft-ietf-avt-rtp-format-guidelines-00.txt ISI | draft-ietf-avt-rtp-format-guidelines-01.txt ISI | |||
December 16, 1997 | November 13, 1998 | |||
Expires: June 1998 | Expires: May 1999 | |||
Guidelines for writers of RTP payload format specifications | Guidelines for Writers of RTP Payload Format Specifications | |||
STATUS OF THIS MEMO | STATUS OF THIS MEMO | |||
This document is an Internet-Draft. Internet-Drafts are working docu- | This document is an Internet-Draft. Internet-Drafts are working docu- | |||
ments of the Internet Engineering Task Force (IETF), its areas, and | ments of the Internet Engineering Task Force (IETF), its areas, and | |||
its working groups. Note that other groups may also distribute work- | its working groups. Note that other groups may also distribute work- | |||
ing documents as Internet-Drafts. | ing documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
skipping to change at page 2, line 28 ¶ | skipping to change at page 2, line 28 ¶ | |||
video data in an ADU must be capable of being decompressed regardless | video data in an ADU must be capable of being decompressed regardless | |||
of whether previous ADUs have been received. Additionally the ADU | of whether previous ADUs have been received. Additionally the ADU | |||
must contain "header" information detailing its position in the video | must contain "header" information detailing its position in the video | |||
image and the frame from which it came. | image and the frame from which it came. | |||
Although an ADU need not be a packet, there are many applications for | Although an ADU need not be a packet, there are many applications for | |||
which a packet is a natural ADU. Such ALF applications have the great | which a packet is a natural ADU. Such ALF applications have the great | |||
advantage that all packets that are received can be processed by the | advantage that all packets that are received can be processed by the | |||
application immediately. | application immediately. | |||
RTP was designed around an ALF philosphy. In the context of a stream | RTP was designed around an ALF philosophy. In the context of a stream | |||
of RTP data, an RTP packet header provides sufficient information to | of RTP data, an RTP packet header provides sufficient information to | |||
be able to identify and decode the packet irrespective of whether it | be able to identify and decode the packet irrespective of whether it | |||
was received in order, or whether preceding packets have been lost. | was received in order, or whether preceding packets have been lost. | |||
However, these arguments only hold good if the RTP payload formats | However, these arguments only hold good if the RTP payload formats | |||
are also designed using an ALF philosophy. | are also designed using an ALF philosophy. | |||
3 Guidelines | Note that this also implies smart, network aware, end-points. An | |||
application using RTP should be aware of the limitations of the | ||||
underlying network, and should adapt its transmission to match those | ||||
limitations. Our experience is that a smart end-point implementation | ||||
can achieve significantly better performance on real IP-based net- | ||||
works than a naive implementation. | ||||
3 Channel Characteristics | ||||
We identify the following channel characteristics that influence the | ||||
best-effort transport of RTP over UDP/IP in the Internet: | ||||
o Packets may be lost | ||||
o Packets may be duplicated | ||||
o Packets may be reordered in transit | ||||
o Packets will be fragmented if they exceed the MTU of the | ||||
underlying network | ||||
The loss characteristics of a link may vary widely over short time | ||||
intervals. | ||||
Although fragmentation is not a disastrous phenomena if it is a rare | ||||
occurance, relying on IP fragmentation is a bad design strategy as it | ||||
significantly increases the effective loss rate of a network and | ||||
decreases goodput. This is because if one fragment is lost, the | ||||
remaining fragments (which have used up bottleneck bandwidth) will | ||||
then need to be discarded by the receiver. It also puts additional | ||||
load on the routers performing fragmentation and on the end-systems | ||||
re-assembling the fragments. | ||||
In addition, it is noted that the transit time between two hosts on | ||||
the Internet will not be constant. This is due to two effects - | ||||
jitter caused by being queued behind cross-traffic, and routing | ||||
changes. The former is possible to characterise and compensate for by | ||||
using a playout buffer, but the latter is impossible to predict and | ||||
difficult to accommodate gracefully. | ||||
4 Guidelines | ||||
We identify the following requirements of RTP payload format specifi- | We identify the following requirements of RTP payload format specifi- | |||
cations: | cations: | |||
o A payload format should be devised so that in the presence of | o A payload format should be devised so that in the presence of | |||
loss, the payload can still be decoded. | loss, the payload can still be decoded. | |||
o Ideally all the contents of every packet should be possible to | o Ideally all the contents of every packet should be possible to | |||
be decoded and played out irrespective of whether preceding | be decoded and played out irrespective of whether preceding | |||
packets have been lost or arrive late. | packets have been lost or arrive late. | |||
The first of these requirements is based on the nature of the inter- | The first of these requirements is based on the nature of the inter- | |||
net. Although it may be possible to engineer parts of the internet to | net. Although it may be possible to engineer parts of the internet to | |||
produce low loss rates through careful provisioning or the use of | produce low loss rates through careful provisioning or the use of | |||
non-best-effort services, as a rule payload formats should not be | non-best-effort services, as a rule payload formats should not be | |||
designed for these special purpose environments. Payload formats | designed for these special purpose environments. Payload formats | |||
should be designed to be used in the public internet with best effort | should be designed to be used in the public internet with best effort | |||
service, and thus should expect to see moderate loss rates (for exam- | service, and thus should expect to see moderate loss rates. For exam- | |||
ple, a 5% loss rate is not uncommon). Where payload formats do not | ple, a 5% loss rate is not uncommon. We note that TCP steady state | |||
make these assumptions, they should state this explicitly up front, | models[4][5][6] indicate that a 5% loss rate with a 1KByte packet | |||
and they will be considered special purpose payload formats, unsuit- | size and 200ms round-trip time will result in TCP achieving a | |||
able for use on the public internet without special support from the | throughput of around 180Mb/s. Higher loss rates, smaller packet | |||
network infrastructure. | sizes, or a larger RTT are required to constrain TCP to lower data | |||
rates. For the most part, it is such TCP traffic that is producing | ||||
the background loss that many RTP flows must co-exist with. Without | ||||
explicit congestion notification (ECN)[7], loss must be considered an | ||||
intrinsic property of best-effort parts of the Internet. | ||||
Where payload formats do not assume packet loss will occur, they | ||||
should state this explicitly up front, and they will be considered | ||||
special purpose payload formats, unsuitable for use on the public | ||||
internet without special support from the network infrastructure. | ||||
The second of these requirements is more explicit about how RTP | The second of these requirements is more explicit about how RTP | |||
should cope with loss. If an RTP payload format is properly designed, | should cope with loss. If an RTP payload format is properly designed, | |||
every packet that is actually received should be useful. Typically | every packet that is actually received should be useful. Typically | |||
this implies the following guidelines are adhered to: | this implies the following guidelines are adhered to: | |||
o Packet boundaries should coincide with codec frame boundaries. | o Packet boundaries should coincide with codec frame boundaries. | |||
Thus a packet should normally consist of one or more complete | Thus a packet should normally consist of one or more complete | |||
codec frames. | codec frames. | |||
skipping to change at page 3, line 41 ¶ | skipping to change at page 4, line 41 ¶ | |||
cannot be used with IP-level fragmentation. | cannot be used with IP-level fragmentation. | |||
In the abstract, a codec frame (i.e., the ADU or the minimum size | In the abstract, a codec frame (i.e., the ADU or the minimum size | |||
unit that has semantic meaning when handed to the codec) can be of | unit that has semantic meaning when handed to the codec) can be of | |||
arbitrary size. For PCM audio, it is one byte. For GSM audio, a frame | arbitrary size. For PCM audio, it is one byte. For GSM audio, a frame | |||
corresponds to 20ms of audio. For H.261 video, it is a Group of | corresponds to 20ms of audio. For H.261 video, it is a Group of | |||
Blocks (GOB), or one twelfth of a CIF video frame. | Blocks (GOB), or one twelfth of a CIF video frame. | |||
For PCM, it does not matter how audio is packetised, as the ADU size | For PCM, it does not matter how audio is packetised, as the ADU size | |||
is one byte. For GSM audio, arbitrary packetisation would split a | is one byte. For GSM audio, arbitrary packetisation would split a | |||
20ms frame over two packets, which would mean that is one packet were | 20ms frame over two packets, which would mean that if one packet were | |||
lost, partial frames in packets before and after the loss are mean- | lost, partial frames in packets before and after the loss are mean- | |||
ingless. This means that not only were the bits in the missing packet | ingless. This means that not only were the bits in the missing packet | |||
lost, effectively additional bits in packets that used bottleneck | lost, effectively additional bits in packets that used bottleneck | |||
bandwidth were also lost because the receiver must throw them away. | bandwidth were also lost because the receiver must throw them away. | |||
Instead, we would packetise GSM by including several complete GSM | Instead, we would packetise GSM by including several complete GSM | |||
frames in a packet; typically four GSM frames are included in current | frames in a packet; typically four GSM frames are included in current | |||
implementations. Thus every packet received can be decoded because | implementations. Thus every packet received can be decoded because | |||
even in the presence of loss, no incomplete frames are received. | even in the presence of loss, no incomplete frames are received. | |||
The H.261 specification allows GOBs to be up to 3KBytes long, | The H.261 specification allows GOBs to be up to 3KBytes long, | |||
skipping to change at page 5, line 5 ¶ | skipping to change at page 6, line 5 ¶ | |||
does reduce the magnitude and duration of the distortion produced | does reduce the magnitude and duration of the distortion produced | |||
when the previous packet is lost. Such compressed state is by defini- | when the previous packet is lost. Such compressed state is by defini- | |||
tion, very dependent on the codec in question. Thus we recommend: | tion, very dependent on the codec in question. Thus we recommend: | |||
o Payload formats for encodings where the decoder contains | o Payload formats for encodings where the decoder contains | |||
internal data-driven state that attempts to track encoder state | internal data-driven state that attempts to track encoder state | |||
should normally consider including a small additional header | should normally consider including a small additional header | |||
that conveys the most critical elements of this state to reduce | that conveys the most critical elements of this state to reduce | |||
distortion after packet loss. | distortion after packet loss. | |||
4 Summary | 5 Summary | |||
Designing packet formats for RTP is not a trivial task. Typically a | Designing packet formats for RTP is not a trivial task. Typically a | |||
detailed knowledge of the codec involved is required to be able to | detailed knowledge of the codec involved is required to be able to | |||
design a format that is resilient to loss, does not introduce loss | design a format that is resilient to loss, does not introduce loss | |||
magnification effects due to inappropriate packetisation, and does | magnification effects due to inappropriate packetisation, and does | |||
not introduce unnecessary distortion after a packet loss. We believe | not introduce unnecessary distortion after a packet loss. We believe | |||
that considerable effort should be put into designing packet formats | that considerable effort should be put into designing packet formats | |||
that are well tailored to the codec in question. Typically this | that are well tailored to the codec in question. Typically this | |||
requires a very small amount of processing at the sender and | requires a very small amount of processing at the sender and | |||
receiver, but the result can be greatly improved quality when operat- | receiver, but the result can be greatly improved quality when operat- | |||
ing in typical internet environments. | ing in typical internet environments. | |||
Designers of new codecs for use with RTP should consider making the | ||||
output of the codec "naturally packetizable". This implies that the | ||||
codec should be designed to produce a packet stream, rather than a | ||||
bit-stream; and that that packet stream contains the minimal amount | ||||
of redundancy necessary to ensure that each packet is independently | ||||
decodable with minimal loss of decoder predictor tracking. It is | ||||
recognised that sacrificing some small amount of bandwidth to ensure | ||||
greater robustness to packet loss is often a worthwhile tradeoff. | ||||
It is hoped that, in the long run, new codecs should be produced | ||||
which can be directly packetised, without the trouble of designing a | ||||
codec-specific payload format. | ||||
It is possible to design generic packetisation formats that do not | It is possible to design generic packetisation formats that do not | |||
pay attention to the issues described in this document, but such for- | pay attention to the issues described in this document, but such for- | |||
mats are only suitable for special purpose networks where packet loss | mats are only suitable for special purpose networks where packet loss | |||
can be avoided by careful engineering at the network layer, and are | can be avoided by careful engineering at the network layer, and are | |||
not suited to current best-effort networks. | not suited to current best-effort networks. | |||
5 Bibliography | Acknowledgments | |||
This document is based on experience gained over several years by | ||||
many people, including Van Jacobson, Steve McCanne, Steve Casner, | ||||
Henning Schulzrinne, Thierry Turletti, and Christian Huitema amongst | ||||
others. Colin Perkins contributed to the text. | ||||
6 Bibliography | ||||
[1] H.Schulzrinne, S.Casner, R.Frederick, V. Jacobson, "Real-Time | [1] H.Schulzrinne, S.Casner, R.Frederick, V. Jacobson, "Real-Time | |||
Transport Protocol", RFC1899. [2] D. Clark, D. Tennenhouse, "Archi- | Transport Protocol", RFC1899. [2] D. Clark, D. Tennenhouse, "Archi- | |||
tectural Considerations for a New Generation of Network Protocols" | tectural Considerations for a New Generation of Network Protocols" | |||
Proc ACM Sigcomm 90. [3] J. Nonnenmacher, E. Biersack, Don Towsley, | Proc ACM Sigcomm 90. [3] J. Nonnenmacher, E. Biersack, Don Towsley, | |||
"Parity-Based Loss Recovery for Reliable Multicast Transmission", | "Parity-Based Loss Recovery for Reliable Multicast Transmission", | |||
Proc ACM Sigcomm '97, Canne, France, 1997. | Proc ACM Sigcomm '97, Cannes, France, 1997. [4] J. Mahdavi and S. | |||
Floyd. "TCP-friendly unicast rate-based flow control". Note sent to | ||||
end2end-interest mailing list, Jan 1997. [5] M. Mathis, J. Semske, | ||||
J. Mahdavi, and T. Ott. "The macro-scopic behavior of the TCP conges- | ||||
tion avoidance algorithm". Computer Communication Review, 27(3), July | ||||
1997. [6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling TCP | ||||
Throughput: A Simple Model and its Empirical Validation", Proc. ACM | ||||
Sigcomm 1998. | ||||
[7] K. K. Ramakrishnan, Sally Floyd, "A Proposal to add Explicit | ||||
Congestion Notification (ECN) to IP" INTERNET DRAFT, Work in Pro- | ||||
gress. | ||||
End of changes. 10 change blocks. | ||||
15 lines changed or deleted | 83 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |