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

From: "Kavitha KR" <[email-masked]>
Date: Wed, 7 Apr 2004 18:36:27 +0530

Hi all,

>Some examples of _possible_ ways to use this (the 3095-authors might have
more
>realistic examples to give):
>One possible usage is to actually construct IR-no-dyn-no-payload packets
even
>when no data is received (either as a "keep-alive" or as initialization if
the
>flow's static info is somehow known a priori).
>Another possible use is to discard the data of the first few packets and
only
>send the static chain to initialize the context (to save bandwidth/delay
at
>initialization).
>The most likely use case for this should be links with a limited maximum
packet
>size.

===>  One another possible reason to send IR-no-dyn-no-payload packets
could
      be something like this.The dynamic fields contain additional fields
      and flags like TIME_STRIDE, RND etc.The values of these fields &
flags
      cannot be determined by the compressor until it has checked
      2-3 packets from the IP layer. The compressor has to conduct some
heuristical
      analysis on the packets to observe these values. In the
meanwhile,compressor
      would like to initialize the static context at the decompressor,
      using IR-no-dyn-no-payload packets.

      Again,as Kristofer said, the authors should confirm what they really
had in mind
      while designing such packets.

> 1. The state is left unchanged - but when the decompressor was in
NO_CONTEXT
> state. Since the decompressor know knowns the static chain it should
rather
> advance the state to the STATIC_CONTEXT state.

> 3. If the decompressor is in NO_CONTEXT state, the new state is set to
> STATIC_CONTEXT. Otherwise, the state is left unchanged.

====> Are not options 1 & 3 same?

>But isn't the option 3 against the RFC 3095, as the decompressor state
>transition diagram (section 5.3.2, page 57] does not show transition from
>NO_CONTEXT to STATIC_CONTEXT ?

===>  Yes!! There is no transition from NC to SC according to section
5.3.2. Also,
      everywhere in the RFC, SC state is portrayed only as a state to come
back
      from FC due to failures. But the diagram, showing decompressor states
      in section 4.3.2, shows double-headed arrow between NC & SC states.
Isn't
      it contradicting?

Regards,
Kavitha

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 16 Apr 2004 08:50:20 +0200

> > But isn't the option 3 against the RFC 3095, as the 
> > decompressor state transition diagram (section 5.3.2,
> > page 57] does not show transition from NO_CONTEXT
> > to STATIC_CONTEXT ?
> 
> ===>  Yes!! There is no transition from NC to SC 
>       according to section 5.3.2. Also, everywhere
>       in the RFC, SC state is portrayed only as a 
>       state to come back from FC due to failures.
>       But the diagram, showing decompressor states
>       Isn't it contradicting?

Yes, I agree this can be seen as a contradiction, and
as I wrote both sections I am for sure one to blame
for it. The reason for this difference is that 4.3
was supposed to provide an informative overview without
specifying the details, while the actual specification
is in chapter 5. The double-headed arrows was supposed
to show state relations on a general level, but I 
understand it might be confusing and we'll have to
consider this when we progress the standard.

Cheers,
/L-E