draft-ietf-rohc-rtp-impl-guide-12.txt   draft-ietf-rohc-rtp-impl-guide-13.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT P. Kremer INTERNET-DRAFT P. Kremer
Expires: November 2005 Ericsson Expires: January 2006 Ericsson
May 23, 2005 July 18, 2005
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-12.txt> <draft-ietf-rohc-rtp-impl-guide-13.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78. of Section 3 of BCP 78.
skipping to change at page 14, line 13 skipping to change at page 14, line 13
sequence number fields of extension headers are also updated." sequence number fields of extension headers are also updated."
7. Context management and CID/context re-use 7. Context management and CID/context re-use
7.1. Compressor and decompressor MUST keep MAX_CID contexts 7.1. Compressor and decompressor MUST keep MAX_CID contexts
As part of the negotiated channel parameters, compressor and As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on context identification (CID) number to be used. By agreeing on
MAX_CID, both compressor and decompressor also agrees to provide MAX_CID, both compressor and decompressor also agrees to provide
memory resources to host at lest MAX_CID+1 contexts, and an memory resources to host at least MAX_CID+1 contexts, and an
established context with CID within this negotiated space MUST be established context with CID within this negotiated space MUST be
kept by both compressor and decompressor until either the CID gets kept by both compressor and decompressor until either the CID gets
re-used, or the channel is taken down or re-negotiated. re-used, or the channel is taken down or re-negotiated.
7.2. CID/context re-use 7.2. CID/context re-use
As part of the channel negotiation, the maximal number of active As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can decompressor through the MAX_CID parameter. The value of MAX_CID can
of course vary enormously between different link scenarios, as well of course vary enormously between different link scenarios, as well
skipping to change at page 25, line 7 skipping to change at page 25, line 7
#--------------------------------- #---------------------------------
# #
# 3-bit FO/SO CRC # 3-bit FO/SO CRC
# #
# C(x) = x^0 + x^1 + x^3 # C(x) = x^0 + x^1 + x^3
# #
do_crc(3, 0x6, $string); do_crc(3, 0x6, $string);
Appendix B - Potential improvements in updated profiles Appendix B - Potential improvements in updated profiles
B.1. Minor improvements B.1. General improvements
B.1.1. Meaning of CC=0 for CSRC list presence B.1.1. Editorial restructuring
Experience has shown that the structure of RFC3095 could had been
much better, and normative specifications could have been less
fragmented. One goal should thus be to do proper restructuring to
make the documentation easier to take in. One fundamental editorial
restructuring is to explicitly define and specify the ROHC framework
in a separate document. The profiles will then be specified in their
own document(s), and will most probably incorporate the updated
profiles from both RFC3095 and the "add-on" specifications ROHC IP-
only and ROHC UDP-Lite into one profile set documentation.
B.1.2. List compression should not be used for IP extension headers
RFC 3095 defines list compression as a generic mechanism ([1],
section 5.8) that is used for both RTP CSRC lists ([1], section
5.8.6) and IP extension headers ([1], section 5.8.4-5.8.5). In the
former case, list compression is indeed very suitable, as the scheme
maps very well to the expected behavior of CSRC items. However, using
list compression for IP extension headers is really hard to justify,
and makes ROHC unnecessary complex. Instead, extension headers should
be treated like all other headers, with static and dynamic chains.
This is the approach taken for ROHC-TCP, and should be applied also
to an updated RFC 3095.
B.1.3. List compression should only use the generic scheme
List compression ([1], section 5.8) defines four different encoding
schemes to be used for compressed lists. There is one generic
encoding scheme, and then three additional optimization schemes based
on reference-based list compression. Implementers have noticed that
using reference-based schemes implies unreasonable decompressor
memory demands and implementation complexity, while the potential
gain is realistically none. The use of the type field in compressed
lists should thus be deprecated and only type 0 encoding should be
allowed.
B.1.4. Multiple operating modes should be avoided, as in ROHC-TCP
RFC 3095 uses several operating modes with complicated transition
procedures to safeguard against incorrect packet interpretation, as
packet formats differ between modes. The multi-mode approach of RFC
3095 has made the specification unnecessary complex, and experience
has shown that this was not a preferable approach. By streamlining
the protocol to one single mode, the number of different packet
formats will be reduced, the compression and decompression control
logic needed will be significantly simplified, mode transition
procedures can be eliminated, non-updating packets can be avoided,
etc. When developing the ROHC TCP profile, the ROHC WG has already
concluded that the RFC 3095 mode concept is not to be used again.
Consequently, there are no explicit modes in ROHC-TCP, but only one
consistent logic is used exclusively, both for unidirectional and
bidirectional operation. An updated version of the RFC 3095 profiles
should follow that approach.
B.1.5. UO-1-ID should not be allowed to carry extension 3
UO-1-ID is the only UO-1 format that can carry an extension (see
section 5.7.3 and 5.7.5 of [1]). The updating properties of UO-1 is
also so that when carrying an extension 3, all fields except SN, TS,
and IP-ID are non-updating, which is a fundamental exception to
normal UO operation. The usefulness of partially updating UO packets
is really questionable. This "feature" is also only available for
contexts with a non-random IP-ID, and is thus mainly a useless
inconsistency. In an updated RTP profile, which is the only profile
using this packet type, UO-1-ID should thus not be allowed to carry
extension 3.
B.1.6. No sequential compression for outer IP-ID
The ROHC 3095 profiles define a mechanism for compression of the IP-
ID, not just for the innermost IP header, but also for a potential
outer (second innermost) IP header (see section 5.7 of [1]). It is
however really unrealistic to expect the outer header IP-ID to be
compressible from the sequence number of the RTP header or a
compressor-generated sequence number, while a ROHC-RTP decompressor
must still be implemented to handle such a case if it indeed happens.
This is extremely far-fetched, and the compressor should instead
simply have to identify an outer IP-ID as either random or constant
(for constant IP-ID handling, see section 3.3 of [3]).
B.1.7. ESP NULL-encryption compression should not compress trailer
The ESP NULL-encryption compression mechanism defined for ROHC
compresses not just the header, but also the trailer of the packet.
Apart from being a conceptual exception in the sense that it does not
only compress the header but also tampers with the payload, the
scheme makes assumptions that reduces its applicability, which is
already very limited, to a single corner case. Considering the
relative complexity of implementing it along with the small gain and
limited applicability, this mechanism should be significantly
simplified. The ESP NULL-encryption compression mechanism is defined
in section 5.8.4.3 of [1].
B.2. Minor improvements
B.2.1. Meaning of CC=0 for CSRC list presence
Regarding the CC field and CSRC list, the following interpretation Regarding the CC field and CSRC list, the following interpretation
has been proposed as an improvement: has been proposed as an improvement:
"It should be noted that when the value of this CC field is equal to "It should be noted that when the value of this CC field is equal to
zero, there is no Generic CSRC list present in the dynamic chain, zero, there is no Generic CSRC list present in the dynamic chain,
i.e. the field comment should have said "variable length, present if i.e. the field comment should have said "variable length, present if
CC > 0". " CC > 0". "
B.2. Improvements already applied to the IP-only and UPL-Lite profiles B.2.2. Size of list compression table for RTP CSRC
B.2.1. Handling Multiple Levels of IP Headers List compression formats are defined with 3 or 7 bit list item index
identifiers (see section 5.8.6.1 of [1]). As there is no additional
explicit restriction on the maximal number of list items, up to 128
items must be supported, which implies a significant memory demand
for an extreme corner-case. One RTP packet can have up to 15 CSRC
items, and that is probably a well over-provisioned number. Since
items can always be re-assigned, it is therefore suggested to have an
upper limit on the number of CSRC list item index identifiers, with a
max value of either 16 or 32.
B.2.3. The p-value for 5-bit SN
For the RFC 3095 RTP profile, p-values for SN fields are defined in
the beginning of section 5.7 of [3], as follows:
p = 1 if bits(SN) <= 4
p = 2^(bits(SN)-5) - 1 if bits(SN) > 4
This would mean p=1 for bits(SN)=4, p=1 for bits(SN)=6, p>1 for bits
(SN)>6, but for bits(SN)=5, p would then be 0. This is illogical, and
obviously a mistake. One reason it was not noticed might be that the
RTP profile does not have any packet format with 5 bits of SN.
However, the ESP profile refer to the RTP profile for p values
(section 5.12 of [1]), and in the ESP profile there are packet
formats with 5 bits of SN. The p-values should thus be redefined as
follows:
p = 1 if bits(SN) <= 5
p = 2^(bits(SN)-5) - 1 if bits(SN) > 5
It should be noted that the UDP profile has a fixed p-value of -1,
motivated by the use of a compressor-generated SN (section 5.11 of
[1]), and is thus not affected by the incorrectly specified p-value,
although the USP profile has packet formats with 5 bits of SN. Note
however the recommendation in section B.2.4.
B.2.4. The UDP profile should have same p-value as other profiles
Since the UDP profile makes use of a compressor-generated SN instead
of an SN taken from an uncompressed header field, it has in section
5.11 of [1] been given a fixed p-value of -1. This made sense, as one
design assumption was in-order delivery from compressor to
decompressor. However, as the interest in using ROHC also over
channels that can not guarantee in-order delivery has gained
momentum, this design choice becomes less appropriate, as described
in [6]. In an updated version of the UDP profile, it should thus be
given the same p-vales as for RTP and ESP, i.e. as outlined in B.2.3,
potentially with an increased' reordering-tolerance, see further
section B.4.
B.2.5. Local repair should be completely optional
In section 5.3.2.2.3-5.3.2.2.5 of [1], possibilities to do local
decompressor repair attempts upon decompression failures are
discussed, and example procedures are described. Section 5.3.2.2.3
says:
A. "First, attempt to determine whether SN LSB wraparound (case 3)
is likely, and if so, attempt a correction. For this, the
algorithm of section 5.3.2.2.4 MAY be used."
and it continues:
B. "Second, if the previous step did not attempt a correction, a
repair should be attempted under the assumption that the
reference SN has been incorrectly updated. For this, the
algorithm of section 5.3.2.2.5 MAY be used."
These are good examples of potential implementation improvements, and
the procedures are described as optional, i.e. with the use of "MAY".
However, both these paragraphs then take one step further and
actually mandates local repair procedures by saying:
C. "If another algorithm is used, it MUST have at least as high a
rate of correct repairs as the one in 5.3.2.2.4 (or 5.3.2.2.5,
respectively).
This should be a local decompressor implementation option, and it is
therefore suggested to exclude the mandating text C.
B.3. Improvements already applied to the IP-only and UPL-Lite profiles
B.3.1. Handling Multiple Levels of IP Headers
The profiles in RFC 3095 can only handle compression of packet The profiles in RFC 3095 can only handle compression of packet
streams with at most two IP headers. The IP-only profile defines a streams with at most two IP headers. The IP-only profile defines a
generic way of handling multiple IP headers (see section 3.2 of [3]). generic way of handling multiple IP headers (see section 3.2 of [3]).
B.2.2. The CONTEXT_MEMORY Feedback Option B.3.2. The CONTEXT_MEMORY Feedback Option
To provide means for a decompressor implementation to have an upper To provide means for a decompressor implementation to have an upper
limit on its available context memory size, the IP-only profile limit on its available context memory size, the IP-only profile
defines an additional feedback option to use (see section 3.7 of defines an additional feedback option to use (see section 3.7 of
[3]). The CONTEXT_MEMORY option informs the compressor that the [3]). The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the decompressor does not have sufficient memory resources to handle the
context of the packet stream, as the stream is currently compressed. context of the packet stream, as the stream is currently compressed.
B.2.3. Compression of constant IP-ID (IPv4 only) B.3.3. Compression of constant IP-ID (IPv4 only)
Most IPv4 stacks assign an IP-ID according to the value of a counter, Most IPv4 stacks assign an IP-ID according to the value of a counter,
increasing by one for each outgoing packet. ROHC-RTP therefore increasing by one for each outgoing packet. ROHC-RTP therefore
compresses the IP-ID field using offset IP-ID encoding based on the compresses the IP-ID field using offset IP-ID encoding based on the
RTP SN. For stacks generating IP-ID values using a pseudo-random RTP SN. For stacks generating IP-ID values using a pseudo-random
number generator, the field is not compressed and is sent as-is in number generator, the field is not compressed and is sent as-is in
its entirety as additional octets after the compressed header. its entirety as additional octets after the compressed header.
Cases have also been found where an IPv4 stack uses a constant value Cases have also been found where an IPv4 stack uses a constant value
for the IP Identifier. When the IP-ID field is constant, it cannot for the IP Identifier. When the IP-ID field is constant, it cannot
be compressed using offset IP-ID encoding and the field must be sent be compressed using offset IP-ID encoding and the field must be sent
in its entirety, although it is completely static and could had been in its entirety, although it is completely static and could had been
completely omitted in compressed headers. The IP-only profile completely omitted in compressed headers. The IP-only profile
addresses this problem and defines an additional mechanism to cope addresses this problem and defines an additional mechanism to cope
efficiently with constant IP-ID (see section 3.3 of [3]). efficiently with constant IP-ID (see section 3.3 of [3]).
B.3. Adding tolerance to reordering between compressor and decompressor B.4. Adding tolerance to reordering between compressor and decompressor
RFC 3095 was written based on the assumption of in-order packet RFC 3095 was written based on the assumption of in-order packet
delivery between compressor and decompressor. Since the publication delivery between compressor and decompressor. Since the publication
of RFC 3095, is has been clear that using ROHC would be desirable of RFC 3095, is has been clear that using ROHC would be desirable
also in environments where in-order delivery can not be guaranteed. also in environments where in-order delivery can not be guaranteed.
The challenges associated with such usage have been analyzed in an The challenges associated with such usage have been analyzed in an
informational ROHC WG document "ROHC over channels that can reorder informational ROHC WG document "ROHC over channels that can reorder
packets" [6], and the finding of that document should be used as a packets" [6], and the finding of that document should be used as a
basis when developing an enhanced ROHC that can tolerate a certain basis when developing an enhanced ROHC that can tolerate a certain
amount of reordering, possibly a configurable reordering tolerance. amount of reordering, possibly a configurable reordering tolerance.
B.5. Implementation stuff that should go out of the spec.
There is a significant amount of implementation ideas given in
chapter 6 of, both potential implementation enhancement,
implementation API parameters, as well as data structures. It is
sometimes useful to have such material being provided in an appendix,
as it can help implementers. However, in this case it has been clear
that in the way these things were included in RFC 3095, more concerns
than benefits were created. There are several reasons for this, one
is that these parts were not included as an appendix, but actually
part of the specification itself. Also, the size and overall
structure of the whole RFC can easily make an implementer confused
about what is actually part of the standard.
In general, it is thus suggested that an update of RFC 3095 should
have larger implementation example material, if any, in an appendix
to make it clearer that it is not part of the actual standard.
Further, reducing the amount of material would be desirable, to make
the whole documentation more concise.
What to do with the various subsections of chapter 6 is discussed
below, along with other informational parts or concepts that can be
questioned.
B.5.1. Reverse decompression
Reverse decompression is described in section 6.1. This is a very
questionable implementation enhancement, and should preferably be
removed, or at least be put in an appendix.
B.5.2. Implementation parameters and signals
In section 6.3, various potential API parameters are defined,
although only informatively, as they are not at all necessary from a
ROHC protocol point of view. Unfortunately, the way this section is
written might make implementer's believe this is actually part of the
standard, as it even makes use of RFC 2119 keywords.
This section should thus be revised, simplified, and it should be
made clear that it is an API parameter proposal, nothing more,
nothing less. The result could potentially be put in an appendix of
the profiles specification.
B.5.3. Decompressor resource limitations
Section 6.4 of discusses how to handle resource limitations at the
decompressor. This is typical implementation guidelines that fits
very well in an "implementation issues" section, and should thus be
kept. Note that the addition of the CONTEXT_MEMORY feedback option
(see B.3.2) affects this discussion, which would have to be updated
accordingly.
B.5.4. Implementation structures
Section 6.5 provides some explanatory material on data structures
that a ROHC implementation will have to maintain in one form or
another. The section explicitly states the explanatory nature of it,
and points out that it is not intended to constrain implementations.
However, it is far from clear whether this material is actually
useful. It should therefore be revised, potentially removed, or at
least put in an appendix.
B.5.5. The state concept
The concept of states (FO/SO), as used in a normative manner
throughout RFC 3095, should be removed from the spec or at least
rewritten so that it becomes clear that this is a descriptive concept
and not at all normative. Mentioning of implementation parameters,
such as k_2/n_2 and k_3/n_3 should be dropped, or it should at least
be made clear that these are just example parameters in example
algorithms. Probably the entire state concept can be dropped, since
it really describes implementation choices. It can be used
informatively, but that should then be made clear.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 27, line 45 skipping to change at page 32, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires November 23, 2005. This Internet-Draft expires January 18, 2006.
 End of changes. 

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