[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.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: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 1 april 2005 09:49
> To: rohc at ietf.org
> 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
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc