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/