Subject: RE: [rohc] Lessons learned from 5 years of 3095 experience

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 9 Jun 2005 08:16:04 +0200

I've continued with the work of collecting the various issues that,
during the years since RCF 3095 was published in 2000, have been
identified as not-how-we-would-had-done-it-if-we-had-known-what-we-
know-today items. These are being collected in appendix B of the implementer's guide, and here is another chunk of item proposals,
all originating from various implementers and/or conclusions drawn
during the work with ROHC TCP. Also this time, I have expressed the
issues as text proposed to be incorporated in this appendix B
(previous version of appendix B can be found below, with updated
section numbering).

Feedback appreciated!
/L-E

---------------------------------------------------------------------

Appendix B - Improvements for updated profiles

B.1. General improvements

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. Implementers
  have noticed that using these three extra 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.2. Size of list compression table for RTP CSRC

  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.

---------------------------------------------------------------------

References (from the implementer's guide):

  [1]  C. Bormann, et al., "RObust Header Compression (ROHC) Framework
       and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
       July 2001.

  [3]  L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC):
       A Compression Profile for IP", RFC 3843, June 2004.

  [6]  G. Pelletier, L-E. Jonsson, and K. Sandlund, "ROHC over Channels
       that can Reorder Packets", internet-draft (work in progress),
       May 2005. <draft-ietf-rohc-over-reordering-03.txt>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 20 april 2005 10:30
> To: [email-masked]
> Subject: RE: [rohc] Lessons learned from 5 years of 3095 experience
> 
> 
> Instead of waiting for others to contribute to this, I guess I better
> start off with the obvious things that have already been discussed by
> Rohit and others. We have talked about reordering support and constant
> IP-ID, and while looking at constant IP-ID I think it is worth noting
> also the other two fixes we did for the IP profile, 
> multiple-IP support
> and the CONTEXT_MEMORY feedback option. Adding these to the "Meaning
> of CC=0" already present would give an appendix B of the implementer's
> guide with the following content.
> 
> ---------------------------------------------------------------------
> Appendix B - Potential improvements in updated profiles
> 
> 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
>   has been proposed as an improvement:
> 
>   "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,
>   i.e. the field comment should have said "variable length, present if
>   CC > 0". "
> 
> 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
>   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]).
> 
> B.3.2. The CONTEXT_MEMORY Feedback Option
> 
>   To provide means for a decompressor implementation to have an upper
>   limit on its available context memory size, the IP-only profile
>   defines an additional feedback option to use (see section 3.7 of
>   [3]). The CONTEXT_MEMORY option informs the compressor that the
>   decompressor does not have sufficient memory resources to handle the
>   context of the packet stream, as the stream is currently compressed. 
> 
> B.3.3. Compression of constant IP-ID (IPv4 only)
> 
>   Most IPv4 stacks assign an IP-ID according to the value of a counter,
>   increasing by one for each outgoing packet.  ROHC-RTP therefore
>   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
>   number generator, the field is not compressed and is sent as-is in
>   its entirety as additional octets after the compressed header.
> 
>   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
>   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
>   completely omitted in compressed headers. The IP-only profile
>   addresses this problem and defines an additional mechanism to cope
>   efficiently with constant IP-ID (see section 3.3 of [3]).
> 
> B.4. Adding tolerance to reordering between compressor and 
> decompressor
> 
>   RFC 3095 was written based on the assumption of in-order packet
>   delivery between compressor and decompressor. Since the publication
>   of RFC 3095, is has been clear that using ROHC would be desirable
>   also in environments where in-order delivery can not be guaranteed.
>   The challenges associated with such usage have been analysed in an
>   informational ROHC WG document "ROHC over channels that can reorder
>   packets" [6], and the finding of that document should be used as a
>   basis when developing an enhanced ROHC that can tolerate a certain
>   amount of reordering, possibly a configurable reordering tolerance.
> ---------------------------------------------------------------------
> 
> I guess it could make sense to make appendix B a separate document at
> some point, but for now let's keep it in the implementer's guide.
> 
> Comments?
> /L-E
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
[mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 1 april 2005 09:49
> To: [email-masked]
> Subject: [rohc] Lessons learned from 5 years of 3095 experience
> 
> 
> ROHCers,
> 
> In the ROHC implementer's guide, we have collected clarifications
> to ambiguities, inconsistencies, and other specification flaws of
> RFC 3095. The purpose of this has been to guide implementer's towards
> interoperability and functional operation, but not to introduce 
> changes to any well specified mechanisms, even if we have seen
> potential for improvements. The implementer's guide therefore got
> an appendix B where additional ideas for improvements, based on
> experience, could be collected. However, there is currently not much
> in this appendix.
> 
> Now with 5 years of RFC 3095 experience, I think it would be a proper
> time to start collecting additional experience-based ideas also for
> appendix B. We should do this while we have implementer's actively
> involved in the working group, and before we all start forgetting
> what we have disliked in 3095. When doing ROHC TCP, we have already
> taken our 3095 experiences into account, so we can probably identify
> the most important ideas by looking into what we have done different
> with ROHC TCP. However, there are probably additional RTP-specific 
> issues that are also worth paying attention to and document.
> 
> So, please contribute with your reflections and ideas!
> 
> BR
> /L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Aniruddha Kulkarni <[email-masked]>
Date: Fri, 17 Jun 2005 15:07:16 +0200

Hi Lars-Erik,

    I think you have captured most of the changes I also would like to
have in ROHC
standard. I agree with you that ROHC standard requires simplification,
clarity and in
some cases better mechanisms.
    I would like to add some more points to the list and I have inlined
some questions/
comments.

Aniruddha Kulkarni
Effnet AB

I have not divided the list into major/minor changes.
1. Reverse decompression mechanism should be removed from ROHC standard even
though it is optional. It can be specified in separate document as
additional feature.
2. The packet size restriction parameters as specified in section 6.3.1
should be
simplified. There are too many of them and not well defined.
3. All the implementation specific details should be removed from
standard. The
description of states and their loose association with packet types has
been most
confusing part of the RFC. I think it will be much better if whole state
machine thing
is dropped and packet type selection process is clearly explained.
4. The split of CRC into static and dynamic has been difficult to
implement. It may
have saved some cpu cycles but I am not sure if it has been worth the
complexity.
A simple implementation can be optimized and cpu cycles saved.

>(previous version of appendix B can be found below, with updated
The implementor's guide is supposed to be "normative" as it clears
doubts and fixes bugs
in standard to make it interoperable. The appendix B is not "normative".
At some point, I guess
the list will be moved to rohc-bis-draft and then to rohc-bis standard
only then it becomes
"normative".

>/L-E
Can you clarify for every ones benefit, how transition from rohc to
rohc-bis will affect other
standards which recommend using rohc? how it will affect standards like
rohc over ppp and
other link layers?

>  taken for ROHC-TCP, and should be applied also to an updated RFC 3095.
Agreed.

>  compressed lists should thus be deprecated and only type 0 encoding
Agreed.
I think rather than saying "three additional optimization schemes" if
you say "reference based list
compression", it will be clearer.

>  updated version of the RFC 3095 profiles should follow that approach.
Agreed.

>  UO-1-ID should thus not be allowed to carry extension 3.
Agreed.

>  ID handling, see section 3.3 of [3]).
Agreed.

>  encryption compression mechanism is defined in section 5.8.4.3 of [1].
Agreed.

>  on the number of CSRC list item index identifiers, with a max value of
Agreed.

>  reordering-tolerance, see further section B.4.
Agreed for both B.2.3 and B.2.4. But I think we should also consider "p
value negotiation" as
suggested in draft-kapoor-rohc-rtp-new-requirements-00.txt.

>  therefore suggested to exclude the mandating text C.
Agreed.