draft-ietf-rohc-rtp-requirements-02.txt   draft-ietf-rohc-rtp-requirements-03.txt 
Network Working Group Mikael Degermark (editor) /University of Arizona Network Working Group Mikael Degermark (editor) /University of Arizona
INTERNET-DRAFT USA INTERNET-DRAFT USA
Expires: December 7, 2000 June 7, 2000 Expires: May 17, 2001 Nov 17, 2000
Requirements for robust IP/UDP/RTP header compression Requirements for robust IP/UDP/RTP header compression
<draft-ietf-rohc-rtp-requirements-02.txt> <draft-ietf-rohc-rtp-requirements-03.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 37 skipping to change at page 1, line 38
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 contains 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 ROHC compression to be developed by the ROHC WG. It is based on the ROHC
charter, discussion in the WG, the 3GPP document "3GPP TR 23.922", charter, discussions in the WG, the 3GPP document "3GPP TR 23.922",
version 1.0.0 of october 1999 [TR], as well as contributions from version 1.0.0 of october 1999 [TR], as well as contributions from
3G.IP. 3G.IP.
0. History and Change Log 0. History and Change Log
Nov 1, 2000 - draft-ietf-rohc-rtp-requirements-03.txt
Changed "packet" to "header" on several places.
June 7, 2000- draft-ietf-rohc-rtp-requirements-02.txt June 7, 2000- draft-ietf-rohc-rtp-requirements-02.txt
Transparency: Added note saying that the ROHC WG has not found an Transparency: Added note saying that the ROHC WG has not found an
instance where semantically identical is not the same as bitwise instance where semantically identical is not the same as bitwise
identical. identical.
Ubiquity: Added note saying that ROHC may recommend changes that Ubiquity: Added note saying that ROHC may recommend changes that
will improve compression efficiency. will improve compression efficiency.
2.2.4 IPSEC: new requirement 2.2.4 IPSEC: new requirement
skipping to change at page 6, line 13 skipping to change at page 6, line 13
overhead under 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 or damage of packets subsequent to packets lost or as the loss or damage of headers subsequent to headers lost or
damaged by the link, even if those subsequent packets are not lost or damaged by the link, even if those subsequent headers are not lost or
damaged. damaged.
Justification: Error propagation reduces spectral efficiency and Justification: Error propagation reduces spectral efficiency and
reduces quality. CRTP suffers severely from error propagation. reduces quality. CRTP suffers severely from error propagation.
Note: There are at least two kinds of error propagation; loss Note: There are at least two kinds of error propagation; loss
propagation, where a lost packet causes subsequent packets to be propagation, where a lost header causes subsequent headers to be lost
lost, and damage propagation, where a damaged packet causes or damaged, and damage propagation, where a damaged header causes
subsequent packets to be damaged. subsequent headers to be lost or damaged.
3a. Handover loss events: Loss events of lenght 150 ms should be 3a. Handover loss events: Loss events of lenght 150 ms should be
handled efficiently and without additional packet loss being handled efficiently and without additional packet loss being
introduced by ROHC. introduced by ROHC.
Justification: Such loss events can be introduced by handover Justification: Such loss events can be introduced by handover
operations in the (radio) network between compressor and operations in the (radio) network between compressor and
decompressor. Handover operations can be frequent in cellular decompressor. Handover operations can be frequent in cellular
systems. Failure to handle handover well can adversely impact systems. Failure to handle handover well can adversely impact
spectrum efficiency and quality. spectrum efficiency and quality.
3b. Handover context recreation: There must be a way to run ROHC 3b. Handover context recreation: There must be a way to run ROHC
that deals well with events where the route of an RTP conversation that deals well with events where the route of an RTP conversation
changes such that either the compressor or the decompressor of the changes such that either the compressor or the decompressor of the
conversation is relocated to another node, where the context needs to conversation is relocated to another node, where the context needs to
be recreated. ROHC must not create erroneous packets during such be recreated. ROHC must not create erroneous headers during such
events. events.
Justification: Such events can be frequent in cellular systems where Justification: Such events can be frequent in cellular systems where
the compressor/decompressor on the network side is close to the radio the compressor/decompressor on the network side is close to the radio
base stations. base stations.
Note: In order to aid developers of context recreation schemes where Note: In order to aid developers of context recreation schemes where
context is transfered to the new node, the specification shall context is transfered to the new node, the specification shall
outline what parts of the context is to be transfered, as well as outline what parts of the context is to be transfered, as well as
conditions for its use. Procedures for context recreation (and conditions for its use. Procedures for context recreation (and
skipping to change at page 8, line 8 skipping to change at page 8, line 8
available and that ROHC may pick a suitable header format to utilize available and that ROHC may pick a suitable header format to utilize
available space as well as possible. available space as well as possible.
10. Delay: ROHC should not noticeably add to the end-to-end delay. 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. video have a limited end-to-end delay budget.
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 header i+x, x>0, is received before header 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.
skipping to change at page 9, line 11 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 December 7, 2000. This draft expires May 17, 2001.
 End of changes. 

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