Subject: Re: [rohc] Fwd: Question related to ROHC-TCP Profile

From: Raffles <[email-masked]>
Date: Tue, 17 Mar 2009 14:28:03 +0100

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.

---

From: eggor <[email-masked]>
Date: Wed, 25 Mar 2009 16:06:33 +0200

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.

---

From: Raffles <[email-masked]>
Date: Wed, 25 Mar 2009 20:31:31 +0000

Hi Igor,

Yes, you are really understanding it now. It depends on the packets
being processed. For packets for which it can be true then it can be
used as an encoding. For packets where it cannot be true, this cannot
be used as an encoding method. This is a general statement true for all
encoding methods defined in RoHC-FN, not just this one, and is also
affected by the context, not just the packet itself.

Having said that, I guess you would expect this encoding to work normal
usage.

Regards

Raffles

eggor wrote:

Hi Raffles,

Thanks,
Igor.

Hi Igor,

Does that help?

Raffles

Hi Raffles,

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

--
Raffles (Robert Finking)
m: 0789 463 9887
e: [email-masked]
w: gluft.com

O O
OOOOOO O O O OOOOOO OOOOO
O O O O O OOOOO O
OOOOOO O OOOOOO O O
OOOOOO
we care about software

-----------------------------------------------------------------
Gluft Ltd. Registered No.: 6795336
The information contained in this e-mail and any attachments is
proprietary to Gluft Ltd and must not be passed to any third
party without permission. This communication is for information
only and shall not create or change any contractual relationship.
Please consider the environment before printing this email.
-----------------------------------------------------------------