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

["Kapoor, Rohit" <[e-mail]>]

Lars-Erik,

I agree that the improvements you have outlined will help to clean up
the RFC. I have a few comments/questions regarding your suggested
improvements:

1) I am not completely sure how interoperability issues with existing
RoHC implementations will be addressed by RoHC bis? Will RoHC bis
propose new profile numbers for the "improved" profiles?
   As an example, say an older RoHC implementation using RTP profile
uses p = 1 for k <= 4 (for RTP SN). A newer RTP profile may be able to
set a different p value, in which case inter-op can be an issue. If
these have different profile numbers, then maybe inter-op is not an
issue.


2) It would help to make the 'p' value configurable, so RoHC can choose
optimal values of p depending upon link characteristics. In this regard,
would it also make sense to make the 'p' value negotiable (as opposed to
configurable), i.e., let both the compressor and the decompressor have a
say in selection of 'p'?


Thanks,
Rohit


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Aniruddha Kulkarni
> Sent: Friday, June 17, 2005 6:07 AM
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: [e-mail]
> Subject: Re: [rohc] Lessons learned from 5 years of 3095 experience
> 
> 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.
> 
> Lars-Erik Jonsson (LU/EAB) wrote:
> 
> >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).
> >
> >
> 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".
> 
> >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.
> >
> >
> 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?
> 
> >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.
> >
> >
> Agreed.
> 
> >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.
> >
> >
> Agreed.
> I think rather than saying "three additional optimization schemes" if
> you say "reference based list
> compression", it will be clearer.
> 
> >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.
> >
> >
> Agreed.
> 
> >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.
> >
> >
> Agreed.
> 
> >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]).
> >
> >
> Agreed.
> 
> >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].
> >
> >
> Agreed.
> 
> >
> >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.
> >
> >
> Agreed.
> 
> >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.
> >
> >
> 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.
> 
> >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.
> >
> >
> Agreed.
> 
> >---------------------------------------------------------------------
> >
> >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: [e-mail] [mailto:[e-mail]]On Behalf
Of
> >>Lars-Erik Jonsson (LU/EAB)
> >>Sent: den 20 april 2005 10:30
> >>To: [e-mail]
> >>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: [e-mail]
> >>>
> >>>
> >[mailto:[e-mail]]On Behalf Of
> >
> >
> >>Lars-Erik Jonsson (LU/EAB)
> >>Sent: den 1 april 2005 09:49
> >>To: [e-mail]
> >>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
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/rohc
> >
> >
> 
> 
> 
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc

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