Subject: RE: [rohc] Mode transitions (was: (no subject))

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 17 Jun 2003 14:51:48 +0200

Tommy, Ghyslain, and others,

> > Would it be useful to introduce means for the compressor to
> > reject a mode change?
> 
> That's an interesting question. I am also of the opinion that
> it would be useful to allow a compressor to decline a
> decompressor request for a mode transition. Right now the way
> RFC-3095 is written, mode changes are entirely a decompressor
> decision (why so?).

I think this was just something we did not think of at that
point in time, we just agreed that the decompressor should be
the one initiating mode transitions, and we never even talked
about any other options than confirmations from the compressor.
However, as negotiations usually allow both sides to express
their opinion, I agree with you that it seems reasonable to 
have such an alternative. 

The question is how to address this standardization-wise. We do
not want to upgrade the existing profiles just to add this, I 
think, but let's keep it in our minds if we make new revision of
profiles 1-3. Maybe it would make sense to add it to the IP
profile, i.e. define the "reserved" value for the mode response
in that profile.

> > It seems like all the mode changes that requires the compressor to
> > send an IR/IR-DYN/UOR-2 packet could have used use the reserved bit
> > pattern for mode, to reject a mode change.
> 
> This seems to be a potential approach. Some minor additional logic
> would also have to be introduced with respect to the parameters
> C_MODE, C_TRANS, D_MODE and D_TRANS of section 5.6.1 for the
> relevant transitions. 

Well, not very much, basically just state how a rejected mode
transition should be terminated. 

> > Is there any specific reason why the compressor is not allowed
> > to have an opinion in the mode changing procedure?

Standardization that has progressed too quickly...

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

---

From: Ghyslain Pelletier <[email-masked]>
Date: Wed, 18 Jun 2003 16:36:05 +0200

> profile, i.e. define the "reserved" value for the mode response

I also think it is a good idea to add this in the IP profile. What is
needed is to specify the bit and, as I mentionned earlier, add some
minor logic with respect to the parameters C_MODE, C_TRANS, D_MODE and
D_TRANS of rfc-3095 section 5.6.1 for the relevant transitions - to
ensure that a decompressor request for a mode transition being declined
by the compressor does complete with respect to these parameters. I
think it should be possible to generalize the change in logic with
respect to any transitions.
 
> transition should be terminated.

The compressor will still need to receive feedback with the unchanged
mode to stop sending IR/IR-DYN/UOR-2 with the bit set to '0' (declining
the mode transition) and to ensure that PT-0 and PT-1 formats will not
be misinterpreted by the decompressor. This additional logic still seems
to be also necessary, based on how mode transitions are currently
performed in 3095.