Subject: Re: [rohc] ROHC context reuse & mode

From: Kristofer Sandlund <[email-masked]>
Date: Tue, 16 Mar 2004 16:09:16 +0100

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

[email-masked] 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:[email-masked]]
>>Sent: 18 February, 2004 07:32 AM
>>To: [email-masked]
>>Cc: [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Feb 2004 09:56:06 +0100

On Feb 11 2004, at 08:35 Uhr, Kristofer Sandlund wrote:

> Hi Carsten,
>
> Are you saying that every IR packet (regardless of it being for a new 
> flow or not) should flush the ENTIRE decompressor context?

Not quite (but see below).
What I was trying to say is that a compressor must be prepared to deal 
with a decompressor that does exactly this.

> One case where some state probably should be kept is for the list 
> compression. Just because an extension header (or CSRC identifier) is 
> not present in the current IR packet does not mean that it's not 
> present in the context and could reappear in a later packet. If I 
> flush the list compression tables every time I get an IR packet, I 
> will have to re-establish every item once again. This does not seem to 
> be very efficient, especially in U-mode where I should periodically 
> refresh the context with IRs.

Well, U-mode is the simple example: We are sending IR-packets because 
we don't know whether the decompressor got enough of the previous 
packets to have set up state yet.  So the compressor must be prepared 
to deal with a decompressor that has a clean slate immediately after 
the IR.

> Also, if every IR would mean the same as establishing a new context, 
> wouldn't that mean that all IR:s would need to carry U-mode? (since 
> all compression should start in U-mode). Why then a mode parameter in 
> the profile 1 IR packet?

That is the interesting part.  Given that the compressor knows (R-mode) 
or is likely to be correct (O-mode) about the state at the 
decompressor, the U-mode argument above does not apply.  But then, we 
are sending an IR packet because something isn't right, so the 
assumptions that can be made about the state are probably limited.  It 
seems to me some serious analysis is required, which I can't do at the 
moment.

The questions I have in my mind:

1) Can it be dangerous for a decompressor to retain state beyond an IR?

2) Do we have an interoperability problem?
2a) Would your compressor have problems with a decompressor that starts 
with a clean slate after each IR packet?
2b) Would your decompressor have problems with a compressor that 
assumes this?  (Related to 1 above.)

Gruesse, Carsten