draft-ietf-rohc-rtp-requirements-01.txt   draft-ietf-rohc-rtp-requirements-02.txt 
Network Working Group Mikael Degermark (editor) /University of Arizona Network Working Group Mikael Degermark (editor) /University of Arizona
INTERNET-DRAFT Sweden INTERNET-DRAFT USA
Expires: November 20, 2000 May 20, 2000 Expires: December 7, 2000 June 7, 2000
Requirements for IP/UDP/RTP robust header compression Requirements for robust IP/UDP/RTP header compression
<draft-ietf-rohc-rtp-requirements-01.txt> <draft-ietf-rohc-rtp-requirements-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/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.
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@cdt.luth.se. directed to its mailing list, rohc@cdt.luth.se.
Abstract Abstract
This document gives draft requirements for robust IP/UDP/RTP header This document contains requirements for robust IP/UDP/RTP header
compression to be developed by the ROHC WG. It is based on the compression to be developed by the ROHC WG. It is based on the ROHC
charter, the 3GPP document "3GPP TR 23.922", version 1.0.0 of october charter, discussion in the WG, the 3GPP document "3GPP TR 23.922",
1999 [TR], as well as contributions from 3G.IP. version 1.0.0 of october 1999 [TR], as well as contributions from
3G.IP.
0. History and Change Log 0. History and Change Log
June 7, 2000- draft-ietf-rohc-rtp-requirements-02.txt
Transparency: Added note saying that the ROHC WG has not found an
instance where semantically identical is not the same as bitwise
identical.
Ubiquity: Added note saying that ROHC may recommend changes that
will improve compression efficiency.
2.2.4 IPSEC: new requirement
Performance/Spectral Efficiency: changed "error conditions" to
"operating conditions".
Split Cellular Handover requirement in two: one dealing with loss
events caused by handover, and another dealing with context
recreation after switching compressor or decompressor to a new
node.
Added note to Genericity requirement stating that it applies to an
RTP stream before as well as after it has passed through IP-
networks.
Added note to Error Propagation requirement that explains the
terms "loss propagation" and "damage propagation".
2.3.11: Residual bit-error rate: New requirement
May 20, 2000 - draft-ietf-rohc-rtp-requirements-01.txt May 20, 2000 - draft-ietf-rohc-rtp-requirements-01.txt
added "robust" to the title of the document. added "robust" to the title of the document.
2.1.2 Mobile-IP: Added requirement for compression of Home Address 2.1.2 Mobile-IP: Added requirement for compression of Home Address
option. option.
2.3.3 Cellular handover: Added note to requirement stating that 2.3.3 Cellular handover: Added note to requirement stating that
handover procedure will not be prescribed as the procedure will be handover procedure will not be prescribed as the procedure will be
highly system-dependent. However, it must be possible to run ROHC highly system-dependent. However, it must be possible to run ROHC
skipping to change at page 3, line 43 skipping to change at page 4, line 43
1. Transparency: When a header is compressed and then decompressed, 1. Transparency: When a header is compressed and then decompressed,
the resulting header must be semantically identical to the original the resulting header must be semantically identical to the original
header. If this cannot be achieved, the packet containing the header. If this cannot be achieved, the packet containing the
erroneous header must be discarded. erroneous header must be discarded.
Justification: The header compression process must not produce Justification: The header compression process must not produce
headers that might cause problems for any current or future part of headers that might cause problems for any current or future part of
the Internet infrastructure. the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically identical"
is not the same as "bitwise identical".
2. Ubiquity: Must not require modifications to existing IP (v4 or 2. Ubiquity: Must not require modifications to existing IP (v4 or
v6), UDP, or RTP implementations. v6), UDP, or RTP implementations.
Justification: Ease of deployment. Justification: Ease of deployment.
2.1 Supported headers and kinds of RTP streams Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the RTP streams emitted by
implementations. However, ROHC cannot rely on such recommendations
being followed.
2.2 Supported headers and kinds of RTP streams
1. Ipv4 and Ipv6: Must support both IPv4 and IPv6. 1. Ipv4 and Ipv6: Must support both IPv4 and IPv6.
Justification: IPv4 and IPv6 will both be around during the Justification: IPv4 and IPv6 will both be around during the
foreseeable future. foreseeable future.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be 2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be
compressed efficiently. For IPv4 these include headers of tunneled compressed efficiently. For IPv4 these include headers of tunneled
packets. For IPv6 these include headers containing the Routing packets. For IPv6 these include headers containing the Routing
Header, the Binding Update Destination Option, and the Home Address Header, the Binding Update Destination Option, and the Home Address
skipping to change at page 4, line 30 skipping to change at page 5, line 35
3. Genericity: Must support compression of headers of arbitrary RTP 3. Genericity: Must support compression of headers of arbitrary RTP
streams. streams.
Justification: There must be a generic scheme which can compress Justification: There must be a generic scheme which can compress
reasonably well for any payload type and traffic pattern. This does reasonably well for any payload type and traffic pattern. This does
not preclude optimizations for certain media types where the traffic not preclude optimizations for certain media types where the traffic
pattern is known, e.g., for low-bandwidth voice and low-bandwidth pattern is known, e.g., for low-bandwidth voice and low-bandwidth
video. video.
Note: This applies to the RTP stream before as well as after it has
passed through an internet.
4. IPSEC: ROHC should be able to compress headers containing IPSEC
subheaders.
Note: It is of course not possible to compress the encrypted part of
an ESP header, nor the cryptographic data in an AH header.
2.3 Efficiency 2.3 Efficiency
1. Performance/Spectral Efficiency: Must provide low relative 1. Performance/Spectral Efficiency: Must provide low relative
overhead under expected operating conditions; compression efficiency overhead under expected operating conditions; compression efficiency
should be better than for RFC2508 under equivalent error conditions. should be better than for RFC2508 under equivalent operating
The error rate should only marginally increase the overhead under conditions. The error rate should only marginally increase the
expected operating conditions. overhead under expected operating conditions.
Justification: Spectrum efficiency is a primary goal. RFC2508 does Justification: Spectrum efficiency is a primary goal. RFC2508 does
not perform well enough. Notes: the relative overhead is the average not perform well enough. Notes: the relative overhead is the average
header overhead relative to the payload. Any auxiliary (e.g., control header overhead relative to the payload. Any auxiliary (e.g., control
or feedback) channels used by the scheme should be taken into account or feedback) channels used by the scheme should be taken into account
when calculating the header overhead. when calculating the header overhead.
2. Error propagation: Error propagation due to header compression 2. Error propagation: Error propagation due to header compression
should be kept at an absolute minimum. Error propagation is defined should be kept at an absolute minimum. Error propagation is defined
as the loss of packets subsequent to packets damaged by the link, as the loss or damage of packets subsequent to packets lost or
even if those subsequent packets are not damaged. damaged by the link, even if those subsequent packets are not lost or
damaged.
Justification: Error propagation reduces spectral efficiency and Justification: Error propagation reduces spectral efficiency and
reduces voice quality. CRTP suffers severely from error propagation. reduces quality. CRTP suffers severely from error propagation.
3. Cellular handover: Cellular handover must be supported. The header Note: There are at least two kinds of error propagation; loss
compression scheme should not cause packet loss after handover. propagation, where a lost packet causes subsequent packets to be
lost, and damage propagation, where a damaged packet causes
subsequent packets to be damaged.
Justification: Handover can be a frequent operation in cellular 3a. Handover loss events: Loss events of lenght 150 ms should be
systems. Failure to handle it well can adversely impact spectrum handled efficiently and without additional packet loss being
efficiency and voice quality. introduced by ROHC.
Note: "Supported" does not imply that a handover procedure will be Justification: Such loss events can be introduced by handover
prescribed by the ROHC specification. Handover is a highly system- operations in the (radio) network between compressor and
dependent operation as is handover frequency and characteristics of decompressor. Handover operations can be frequent in cellular
loss events related to handover. "Supported" does imply that there systems. Failure to handle handover well can adversely impact
must be a way to run ROHC that deals well with handover in target spectrum efficiency and quality.
systems. The specification shall outline possible handover schemes
and pitfalls. The specification will outline what parts of the 3b. Handover context recreation: There must be a way to run ROHC
context is to be transfered, as well as conditions for using that deals well with events where the route of an RTP conversation
transfered context, to aid developers of handover implementations changes such that either the compressor or the decompressor of the
that transfer context between compressors or decompressors. conversation is relocated to another node, where the context needs to
be recreated. ROHC must not create erroneous packets during such
events.
Justification: Such events can be frequent in cellular systems where
the compressor/decompressor on the network side is close to the radio
base stations.
Note: In order to aid developers of context recreation schemes where
context is transfered to the new node, the specification shall
outline what parts of the context is to be transfered, as well as
conditions for its use. Procedures for context recreation (and
discard) without such context transfer will also be provided.
4. Link delay: Must operate under all expected link delay conditions. 4. Link delay: Must operate under all expected link delay conditions.
5. Processing delay: The scheme must not contribute significantly to 5. Processing delay: The scheme must not contribute significantly to
system delay budget. system delay budget.
6. Multiple links: The scheme must perform well when there are two or 6. Multiple links: The scheme must perform well when there are two or
more cellular links in the end-to-end path. more cellular links in the end-to-end path.
Justification: Such paths will occur. Note: loss on previous links Justification: Such paths will occur.
will cause irregularities in the RTP stream reaching the compressor.
Such irregularities should only marginally affect performance.
7. Packet Misordering: The scheme must tolerate moderate misordering Note: loss on previous links will cause irregularities in the RTP
in the packet stream reaching the compressor. No misordering is stream reaching the compressor. Such irregularities should only
expected on the link between compressor and decompressor. marginally affect performance.
7a. Packet Misordering: The scheme should be able to compress when
there are misordered packets in the RTP stream reaching the
compressor. No misordering is expected on the link between
compressor and decompressor.
Justification: Misordering happens regularly in the Internet. Justification: Misordering happens regularly in the Internet.
However, since the Internet is engineered to run TCP reasonably well,
excessive misordering will not be common and need not be handled with
optimum efficiently.
Note: Since the Internet is engineered to run TCP reasonably well, 7b. Moderate Packet Misordering: The scheme should efficiently handle
excessive misordering will not be common, and need not be handled moderate misordering (2-3 packets) in the packet stream reaching the
efficiently. Moderate misordering (up to 2-3 packets) should be compressor.
handled efficiently.
Note: This kind of reordering is common.
8. Unidirectional links/multicast: Must operate (possibly with less 8. Unidirectional links/multicast: Must operate (possibly with less
efficiency) over links where there is no feedback channel or where efficiency) over links where there is no feedback channel or where
there are several receivers. there are several receivers.
9. Configurable header size fluctuation: It should be possible to 9. Configurable frame size fluctuation: It should be possible to
restrict the number of different header sizes used by the scheme. restrict the number of different frame sizes used by the scheme.
Justification: Some radio technologies support only a limited number Justification: Some radio technologies support only a limited number
of frame sizes efficiently. Note: Somewhat degraded performance is to of frame sizes efficiently.
be expected when such restrictions are applied.
10. Delay: The scheme should not delay packets. Note: Somewhat degraded performance is to be expected when such
restrictions are applied.
Note: This implies that a list of "good" frame sizes must be made
available and that ROHC may pick a suitable header format to utilize
available space as well as possible.
10. Delay: ROHC should not noticeably add to the end-to-end delay.
Justification: RTP packets carrying data for interactive voice or Justification: RTP packets carrying data for interactive voice or
video have a limited end-to-end delay budget. ROHC should not video have a limited end-to-end delay budget.
noticeably add to the end-to-end delay.
Note: This requirement is intended to prevent schemes that achieve Note: This requirement is intended to prevent schemes that achieve
robustness at the expense of delay, for example schemes that require robustness at the expense of delay, for example schemes that require
that packet i+x, x>0, is received before packet i can be that packet i+x, x>0, is received before packet i can be
decompressed. decompressed.
Note: Together with 2.3.5, this requirement implies that ROHC will Note: Together with 2.3.5, this requirement implies that ROHC will
not noticeably add to the jitter of the RTP stream, other than what not noticeably add to the jitter of the RTP stream, other than what
is caused by variations in header size. is caused by variations in header size.
Note: This requirement does not prevent a queue from forming upstream Note: This requirement does not prevent a queue from forming upstream
a bottleneck link. Nor does it prevent a compressor from utilizing a bottleneck link. Nor does it prevent a compressor from utilizing
information from more than one header in such a queue. information from more than one header in such a queue.
11. Residual errors: For a residual bit-error rate of at most 1e-5,
the ROHC scheme must not increase the error rate.
Justification: Some target links have a residual error rate, i.e,
rate of undetected errors, of this magnitude.
Note: In the presence of residual bit-errors, ROHC will need error
detection mechanisms to prevent damage propagation. These mechanisms
will catch some residual errors, but those not caught might cause
damage propagation. This requirement states that the reduction of
the damage rate due to the error detection mechanisms must not be
less than the increase in error rate due to damage propagation.
3. Editor's address 3. Editor's address
Mikael Degermark Tel (May-July): +46 70 833-8933 Mikael Degermark Tel (May-July): +46 70 833-8933
Dept. of Computer Science Tel: +1 520 621-3489 Dept. of Computer Science Tel: +1 520 621-3489
University of Arizona Fax: +1 520 621-4246 University of Arizona Fax: +1 520 621-4246
P.O. Box 210077 P.O. Box 210077
Tucson, AZ 85721-0077 Tucson, AZ 85721-0077
USA EMail: micke@cs.arizona.edu USA EMail: micke@cs.arizona.edu
4. References 4. References
skipping to change at page 7, line 6 skipping to change at page 9, line 11
[RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980. [RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980.
[RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981.
[RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed [RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed
Serial Links, RFC 1144, February 1990. Serial Links, RFC 1144, February 1990.
[CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers [CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links, RFC 2508. for Low-Speed Serial Links, RFC 2508.
This draft expires November 20, 2000. This draft expires December 7, 2000.
 End of changes. 

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