Subject: [rohc] ROHC IP profile comments

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 27 Jun 2003 11:44:15 +0200

Hi!

Here are some (late) comments on the IP-only profile.

The draft is a bit vague about the presense of compressed lists and
extension headers. It only says:
    the static chain is terminated if the "Next Header / Protocol" field
of a
    static IP header part indicates anything but IP (IPinIP or IPv6).

Which of course is correct, but would be more clear if it ALSO said that
"each additional IP header can contain one extension header chain" or
something along those lines.

Problem:
----------------------

When adding support for compressing an arbitrary number of IP headers
(which leads to an arbitrary number of extension header lists), I feel
that there will likely be memory issues for many implementations. This
is because there is no way for the decompressor to tell the compressor
that this specific context has grown too large and the decompressor
cannot handle this.
The likely situations where the decompressor context size grows are:
I) A CID is re-used for a completely new flow. With an arbitrarily long
header chain, there _could_ be bizarrely long, even if those won't occur
very often in reality.
II) When changing profile. This case is indirectly handled by the
negotiation, as a decompressor should not negotiate a profile that it
does not have enough space to decompress. So we don't really have to
worry about this one.
III) When there are frequent changes in the list compression (the
translation tables for extension headers uses many indexes).

Solutions with the current spec:

If implementing a decompressor where I want to limit the per-context
memory usage, I can only do the following with the current spec:
a) Send a REJECT option in the feedback. This says that the decompressor
is out of memory for ALL contexts, and the compressor should stop
compressing this flow altogether. This has a side-effect that the
compressor should not be initiating any new contexts for an unspecified
amount of time. _Can_ solve both I) and III) but we stop compressing
this flow altogether and can have side-effects on other flows.
b) Send a NACK (or STATIC-NACK) so the compressor flushes the entire
list compressor translation table(s) and has to re-establish everything.
For case I), this does not automatically solve anything, since we do not
know the reason for the NACK.
For case III), if the flow changes a lot, then this will only solve the
situation temporarily and the compressor can again compress out of the
decompressor's table range causing a 'thrashing' situation. With an
arbitrary number of IP headers, we will also have to re-establish all
the extension header lists if one of them is out of range.

Note: This is an issue that (to a lesser extent, though) also applies to
the RFC3095 profiles.

I suggest two different solutions for this issue, where one of them does
not rule out the use of the other, so either one or both can be used.

Proposed 'solution' 1:

Add a new feedback option, LIMIT-CONTEXT, where the decompressor can
send back information about how much context that it can safely handle.
Upon reception of this, the compressor can decide to not use more
context than the decompressor should handle.
So what limit should LIMIT-CONTEXT convey, then?
a) Size in bytes of base header chain (all IP headers in this profile)
plus the sum of all extension header sizes in all the translation
tables?
b) The maximum number of IP headers that the compressor should compress
in a flow? 
c) A limit in number of indexes in each translation table? 
d) A limit in total number of indexes in all translation tables?

There are a number of other limits that could be used, so is there
anything else that would fit even better?

Some of these only partially help, but a) seems to be able to work for
both I) and III).

Proposed 'solution' 2:

Start using the MAX_HEADER parameter of RFC3241 (ROHC-over-PPP) to
negotiate a limit on copmressible header chain. This seems a bit
inadequate, since I can still be forced to store 128 extension headers
per extension header list. If the parameter could be interpreted as the
sum of all base header sizes plus the sum of all extension header sizes
in all translation tables then we're a bit closer.
This would of course impact on all profiles.
This solves case I) and depending on interpretation can help III) as
well.

Regards,
	Kristofer Sandlund, Effnet AB

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