draft-ietf-rohc-rfc3095bis-improvements-00.txt   draft-ietf-rohc-rfc3095bis-improvements-01.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: February 2006 August 9, 2005 Expires: February 2006 August 26, 2005
Improvements for the ROHC Profile Set Update Improvements for the ROHC Profile Set Update
<draft-ietf-rohc-rfc3095bis-improvements-00.txt> <draft-ietf-rohc-rfc3095bis-improvements-01.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 2, line 16 skipping to change at page 2, line 16
1. Introduction.....................................................2 1. Introduction.....................................................2
2. General improvements.............................................3 2. General improvements.............................................3
2.1. Editorial restructuring.....................................3 2.1. Editorial restructuring.....................................3
2.2. List compression should not be used for IP extension headers3 2.2. List compression should not be used for IP extension headers3
2.3. List compression should only use the generic scheme.........3 2.3. List compression should only use the generic scheme.........3
2.4. Multiple operating modes should be avoided, as in ROHC-TCP..3 2.4. Multiple operating modes should be avoided, as in ROHC-TCP..3
2.5. UO-1-ID should not be allowed to carry extension 3..........4 2.5. UO-1-ID should not be allowed to carry extension 3..........4
2.6. No sequential compression for outer IP-ID...................4 2.6. No sequential compression for outer IP-ID...................4
2.7. ESP NULL-encryption compression should not compress trailer.4 2.7. ESP NULL-encryption compression should not compress trailer.4
2.8. CRC calculation should not use STATIC/DYNAMIC separation....4
3. Minor improvements...............................................5 3. Minor improvements...............................................5
3.1. Meaning of CC=0 for CSRC list presence......................5 3.1. Meaning of CC=0 for CSRC list presence......................5
3.2. Size of list compression table for RTP CSRC.................5 3.2. Size of list compression table for RTP CSRC.................5
3.3. The p-value for 5-bit SN....................................5 3.3. The p-value for 5-bit SN....................................5
3.4. The UDP profile should have same p-value as other profiles..6 3.4. The UDP profile should have same p-value as other profiles..6
3.5. Local repair should be completely optional..................6 3.5. Local repair should be completely optional..................6
4. Improvements already applied to the IP-only and UDP-Lite profiles6 4. Improvements already applied to the IP-only and UDP-Lite profiles6
4.1. Handling Multiple Levels of IP Headers......................6 4.1. Handling Multiple Levels of IP Headers......................6
4.2. The CONTEXT_MEMORY Feedback Option..........................7 4.2. The CONTEXT_MEMORY Feedback Option..........................7
4.3. Compression of constant IP-ID (IPv4 only)...................7 4.3. Compression of constant IP-ID (IPv4 only)...................7
skipping to change at page 3, line 36 skipping to change at page 3, line 36
list compression for IP extension headers is really hard to justify, list compression for IP extension headers is really hard to justify,
and makes ROHC unnecessary complex. Instead, extension headers should and makes ROHC unnecessary complex. Instead, extension headers should
be treated like all other headers, with static and dynamic chains. be treated like all other headers, with static and dynamic chains.
This is the approach taken for ROHC-TCP, and should be applied also This is the approach taken for ROHC-TCP, and should be applied also
to an updated RFC 3095. to an updated RFC 3095.
2.3. List compression should only use the generic scheme 2.3. List compression should only use the generic scheme
List compression ([1], section 5.8) defines four different encoding List compression ([1], section 5.8) defines four different encoding
schemes to be used for compressed lists. There is one generic schemes to be used for compressed lists. There is one generic
encoding scheme, and then three additional optimization schemes based encoding scheme, and three additional optimization schemes based on
on reference-based list compression. Implementers have noticed that reference-based list compression. Implementers have found that using
using reference-based schemes implies unreasonable decompressor reference-based schemes implies unreasonable decompressor memory
memory demands and implementation complexity, while the potential demands and implementation complexity, while the potential gain is
gain is realistically none. The use of the type field in compressed realistically none. The use of the type field in compressed lists
lists should thus be deprecated and only type 0 encoding should be should thus be deprecated and only type 0 encoding should be allowed.
allowed.
2.4. Multiple operating modes should be avoided, as in ROHC-TCP 2.4. Multiple operating modes should be avoided, as in ROHC-TCP
RFC 3095 uses several operating modes with complicated transition RFC 3095 uses several operating modes with complicated transition
procedures to safeguard against incorrect packet interpretation, as procedures to safeguard against incorrect packet interpretation, as
packet formats differ between modes. The multi-mode approach of RFC packet formats differ between modes. The multi-mode approach of RFC
3095 has made the specification unnecessary complex, and experience 3095 has made the specification unnecessary complex, and experience
has shown that this was not a preferable approach. By streamlining has shown that this was not a preferable approach. By streamlining
the protocol to one single mode, the number of different packet the protocol to one single mode, the number of different packet
formats will be reduced, the compression and decompression control formats will be reduced, the compression and decompression control
skipping to change at page 5, line 5 skipping to change at page 4, line 49
compresses not just the header, but also the trailer of the packet. 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 Apart from being a conceptual exception in the sense that it does not
only compress the header but also tampers with the payload, the only compress the header but also tampers with the payload, the
scheme makes assumptions that reduces its applicability, which is scheme makes assumptions that reduces its applicability, which is
already very limited, to a single corner case. Considering the already very limited, to a single corner case. Considering the
relative complexity of implementing it along with the small gain and relative complexity of implementing it along with the small gain and
limited applicability, this mechanism should be significantly limited applicability, this mechanism should be significantly
simplified. The ESP NULL-encryption compression mechanism is defined simplified. The ESP NULL-encryption compression mechanism is defined
in section 5.8.4.3 of [1]. in section 5.8.4.3 of [1].
2.8. CRC calculation should not use STATIC/DYNAMIC separation
The CRC_STATIC and CRC_DYNAMIC separation was intended to reduce the
computational complexity of CRC calculation. However, the separation
has proven to make implementation painful, and it actually also adds
complexity both in terms of data structures and computation. The
STATIC/DYNAMIC CRC separation should therefore be deprecated.
3. Minor improvements 3. Minor improvements
3.1. Meaning of CC=0 for CSRC list presence 3.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
skipping to change at page 6, line 22 skipping to change at page 6, line 22
channels that can not guarantee in-order delivery has gained channels that can not guarantee in-order delivery has gained
momentum, this design choice becomes less appropriate, as described momentum, this design choice becomes less appropriate, as described
in [3]. In an updated version of the UDP profile, it should thus be in [3]. 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 given the same p-vales as for RTP and ESP, i.e. as outlined in
section 3.3 of this document, potentially with an increased section 3.3 of this document, potentially with an increased
reordering-tolerance, see further section 5 of this document. reordering-tolerance, see further section 5 of this document.
3.5. Local repair should be completely optional 3.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 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 decompressor repair attempts upon decompression failures are looked
discussed, and example procedures are described. Section 5.3.2.2.3 at, and example procedures are described. Section 5.3.2.2.3 says:
says:
A. "First, attempt to determine whether SN LSB wraparound (case 3) A. "First, attempt to determine whether SN LSB wraparound (case 3)
is likely, and if so, attempt a correction. For this, the is likely, and if so, attempt a correction. For this, the
algorithm of section 5.3.2.2.4 MAY be used." algorithm of section 5.3.2.2.4 MAY be used."
and it continues: and it continues:
B. "Second, if the previous step did not attempt a correction, a B. "Second, if the previous step did not attempt a correction, a
repair should be attempted under the assumption that the repair should be attempted under the assumption that the
reference SN has been incorrectly updated. For this, the reference SN has been incorrectly updated. For this, the
skipping to change at page 10, line 45 skipping to change at page 10, 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 February 9, 2006. This Internet-Draft expires February 26, 2006.
 End of changes. 

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