Re: Fwd: Question related to ROHC-TCP Profile

Raffles <[email protected]>
Newsgroups gmane.ietf.rohc
Message-ID <29373679.948401237296483525.JavaMail.servlet@kundenserver>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.