Re: Fwd: Question related to ROHC-TCP Profile

Hi Raffles,

Thanks for your clarification, things are more clear now.  I'd only
like to make the "It is up to the implementer to produce an
implementation which ensures they (expressions) are always true"
premise more precisely. The ensuring that those expressions are always
true depends not only on the right implementation but also (and
mainly, I think) on contents of the packets being processed, doesn't
it?

Thanks,
Igor.

On Tue, Mar 17, 2009 at 3:28 PM, Raffles <[email protected]> wrote:
> Hi Igor,
>
> This is an excellent question, I hope you don't mind me copying the reply to the list.
>
> RoHC-FN does not define any order of computation. It is "atemporal".  Unlike most programming languages where you specify "do this, then do this etc.", RoHC-FN is much more mathematical in nature (more like a functional programming language). We tried very hard to produce a notation which specifies WHAT must be acheived, not HOW. Any implementation order is acceptable as long as it maps between compressed format packets and uncompressed format packets in the way which the notation defines.
>
> The expressions defined which bind together seq_number_scaled, seq_number, seq_number_residue etc. are mathematical facts. It is up to the implementer to produce an implementation which ensures they are always true. It is the end results that matter, not how you get there.
>
> Does that help?
>
> Raffles
>
>>Hi Raffles,
>>
>>Thank you very much for your answer, I’d like to avail myself of your
>>obliging offer of asking you further questions.  Seems I really need
>>it.
>>
>>Probably I didn’t fully understand a binding concept, so could you
>>please explain it by giving an example of  processing
>>“seq_number_scaled” field of the “tcp” encoding method.  Let’s suppose
>>we have a Compressor which has gotten its very first TCP/IP packet but
>>hasn't yet processed it.  FN says: “During compression, the
>>uncompressed attributes of the field are already defined”.
>>Concentrating on the “seq_number” TCP field only (because
>>“seq_number_scaled” control field is only needed to more efficiently
>>compress the “seq_number”, right?), Compressor first go to store
>>incoming “seq_number” value in its context, and this value is what we
>>call “seq_number.UVALUE”.  After this (if we omit other fields of TCP
>>header) Compressor starts to process fields defined in the CONTROL
>>format.  At this moment, is “seq_number_scaled.UVALUE” already
>>defined? If yes then is it equal to “seq_number_scaled.UVALUE” divided
>>by the “payload_size”?
>>
>>Or “seq_number_scaled.UVALUE” is calculated during the mapping of the
>>“seq_number_residue” field, and, in turn, the equivalence between
>>“seq_number_scaled.UVALUE” and “seq_number_scaled.UVALUE /
>>payload_size” is defined in the “ENFORCE(unscaled_value ==
>>scaled_value * stride_value + residue_field.UVALUE);” statement?
>>
>>Great thanks for your help,
>>Igor.
>
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc