Re: Fwd: Question related to ROHC-TCP Profile

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 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

--
Raffles (Robert Finking)
m: 0789 463 9887
e: [email protected]
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.
-----------------------------------------------------------------

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