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

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 1 Apr 2005 09:49:26 +0200

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

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 8 404 29 61

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.  

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 10:30:20 +0200

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.1. Minor improvements

B.1.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.2. Improvements already applied to the IP-only and UPL-Lite profiles

B.2.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.2.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.2.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.3. 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,
>