Re: [rohc] ROHC context reuse & mode

[Kristofer Sandlund <kristofer.sandlund at effnet.com>]

Hi all,

Myself, Carsten, Ghyslain and L-E continued the "re-use" discussion at the IETF 
meeting. I will summarize that discussion here, so that we can verify these 
conclusions on the list and hopefully make some "final" decisions on this subject.

* Re-use and mode
We all agreed that the solution proposed earlier that mode is inherited when a 
new flow re-uses a context of the same profile seems like the best option. We 
should hopefully be able to verify this at the next interop. When a context is 
re-used for a different profile, the mode will be set to initial mode (e.g. 
U-mode for 3095-profiles). We propose to add some text regarding this to the 
implementer's guide.

* Keeping decompressor context after IR reception
In the earlier discussion, some people felt that all context at the decompressor 
should be discarded every time an IR is received, no matter what the reason is 
for the IR being sent (repetition, initialization, static-nack). See message 
thread below.
The discussion we had in Seoul does not agree with this (but please feel free to 
correct any mistakes in the conclusions below). It _seems_ like there won't be 
any problem for the decompressor to keep the state that is not transmitted in 
the IR packet (second-order values, list compression item confidence etc). Since 
IR stands for Initialization and Refresh, it should be possible to use in a 
simple refresh way and not lose all context.
When the compressor re-uses a context for a new flow, it should try to 
re-establish all second order values etc, but should not need to do this for a 
"normal" refresh.
Therefore, we propose to add a bit more text to the implementer's guide to 
clarify what state can be kept by the decompressor and something about what the 
compressor can assume about decompressor state after IR packets.
Naturally, if the profile is changed, then the decompressor can safely flush out 
all information, since this is the only time that the decompressor can know for 
sure that this is for a new flow.

If we would go with the other suggestion of always assuming all state is 
discarded, then the decompressor will have quite a hard time to establish 
second-order values when running in U-mode (example, expected delta of extension 
header sequence numbers), and so far no problems seen with keeping this kind of 
state.

* IR-no-dynchain packets (see 5.7.7 and 5.7.7.2 in RFC3095)
These packets (which will be transmitted without payload), only update the 
static part of the context and are then to be discarded, and not passed on to 
upper layers. Since we allow context to be kept by the decompressor when IR 
packets are received, we feel that this should not have to invalidate the 
dynamic chain, and we propose adding one sentence (impl. guide again) to 
describe that these packets only update the static chain.

* IR-DYN profile downgrade (see 5.11.1. & 5.12.1. in RFC3095)
According to the decision to go to initial mode when changing profiles with an 
IR packet (see above), it seems like a resonable assumption that these also 
should use "initial mode". It is of course _possible_ to "inherit mode" here, 
but that would require more text to specify that IR-DYN profile changes differ 
from IR profile changes. Do we really want more special cases?

Best regards,
     Kristofer Sandlund, Effnet AB


zhigang.c.liu@nokia.com wrote:
> To be accurate, we should say context ID is reused, not the context
> (e.g. header field values, parameters, etc).
>
> In addition, we can also make a clarification related to this: an IR 
> packet will flush out the decompressor context that exists before 
> receipt of the IR packet. (Note: mode is treated differently than
> the "normal" context which can be in different states.)
>
> BR,
> Zhigang
>
>
> > -----Original Message-----
> > From: ext Lars-Erik Jonsson [mailto:larsman@home.se]
> > Sent: 18 February, 2004 07:32 AM
> > To: kristofer.sandlund@effnet.com
> > Cc: rohc@ietf.org; Liu Zhigang.C (Nokia-NRC/Dallas)
> > Subject: Re: Re: [rohc] ROHC context reuse & mode
> >
> >
> >
> > OK,
> >
> > I can buy that argumentation. So, what we should clarify then is that:
> > 1) This is what happens when a context is re-used 
> >   for a new flow, compressed with the same profile.
> > 2) If a context is re-used for compression of a new
> >   flow using a different profile, compression is
> >   obviously restarted in U-mode, independent of 
> >   previous mode
> >
> > Would that be it?
> > /L-E
> >
> >
> >
> > Zhigang/L-E,
> >
> > I think that Zhigang's scheme of letting mode be inherited 
> > when we have the same 
> > profile seems like the best choice to me. I think this 
> > approach will be more 
> > consistent with the mode transition logic.
> > If we choose the "always U-mode when new flow" approach, and 
> > a new flow appears 
> > in the middle of a pending mode transition, we would probably 
> > have to specify 
> > that the decompressor must detect that it is a new flow (for example 
> > static-def-diffing as I suggested earlier) and also it should 
> > set D_TRANS=done & 
> > D_MODE=U-mode when we have a new flow (i.e. mode trans must 
> > be restarted). The 
> > inheritance scheme will just complete the mode transition 
> > without having to 
> > understand that it is a new flow.
> >
> > I can agree that this is slightly inconsistent with the spec, 
> > but I don't think 
> > it "clearly says new contexts must start in U-mode". All it 
> > says is "Compression 
> > with ROHC MUST start in the Unidirectional mode" (sec. 
> > 4.4.1), which _could_ be 
> > interpreted as being on a per-channel basis. If so, mode 
> > inheritance is 
> > completely ok.
> >
> > Rgds,
> > 	Kristofer Sandlund, Effnet AB

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc