Re: Question related to ROHC-TCP Profile

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.

On Thu, Mar 12, 2009 at 2:56 PM, Finking, Robert
<[email protected]> wrote:
> Hi Igor,
>
> Thanks for the post and apologies for any lack of clarity in the RFCs.
> A key concept to understand when reading ROHC-FN is the idea of binding.
> You are right that the line you have quoted below only specifies the
> ULENGTH (32 bits).  However, if you look at the next line, you will find
> that the UVALUE is also bound by means of the field_scaling encoding
> method:
>
>     seq_number_scaled                    [ 32 ];
>     seq_number_residue =:=
>         field_scaling(payload_size, seq_number_scaled.UVALUE,
>                       seq_number.UVALUE) [ 32 ];
>
> The field_scaling encoding method is defined as follows:
>
>  field_scaling(stride_value, scaled_value, unscaled_value)
>  {
>   UNCOMPRESSED {
>     residue_field [ 32 ];
>   }
>
>   COMPRESSED no_scaling {
>     ENFORCE(stride_value == 0);
>     ENFORCE(residue_field.UVALUE == unscaled_value);
>     ENFORCE(scaled_value == 0);
>   }
>
>   COMPRESSED scaling_used {
>     ENFORCE(stride_value != 0);
>     ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value));
>     ENFORCE(unscaled_value ==
>             scaled_value * stride_value + residue_field.UVALUE);
>   }
>  }
>
> So, the seq_number_scaled.UVALUE is bound to scaled_value within the
> field_scaling encoding method.  Assuming the stride_value (i.e. the
> payload_size) is non-zero, this binds the scaled_value (i.e. the
> seq_number_scaled.UVALUE) in an expression with stride_value,
> residue_field.UVALUE and unscaled_value (i.e. seq_number.UVALUE). This
> is done in such a way the scaled value is the unscaled_value divided by
> the stride_value. In short, the UVALUE of seq_number_scaled is set by
> the field_scaling encoding method (which also calculates the
> modulus/residue from the scaling and encodes it in 32 bits).
>
> I am not sure if that has helped, it is often hard to put these things
> in words. Feel free to ask further questions if this does not answer
> your question.
>
> Thanks for using ROHC-FN
>
> Regards
>
> Raffles
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of eggor
>> Sent: 11 March 2009 12:41
>> To: [email protected]
>> Subject: [rohc] Question related to ROHC-TCP Profile
>>
>> Hi,
>>
>> I've just started working on implementation of the ROHC-TCP
>> profile, and I needed some clarifications.
>>
>> Question about "seq_number_scaled" field defined in the
>> CONTROL format of the tcp(payload_size, ack_stride_value,
>> ip_inner_ecn) encoding method.  It is defined as:
>>
>> CONTROL {
>>      seq_number_scaled                    [ 32 ];
>>      ...
>>    }
>>
>> and isn't appeared in other formats.  If I truly understood
>> ROCH-FN, this definition specifies only ULENGTH attribute of
>> this field, so the question is: where compressor can get its
>> UVALUE?  And the second question is how decompressor can restore it?
>>
>> Thanks in advance,
>> Igor.
>> _______________________________________________
>> Rohc mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/rohc
>>
>
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc