Re: Question related to ROHC-TCP Profile

Hi All, 

Could you please tell me , is there any other implementation way to use the scaling factor for the scaled Acknowledgment number apart what is mentioned in the RFC(4996) section 6.4.8.2. Since we find it may not be possible always to use the sequence number from the co-located Decompresor.
Kindly suggest

Thanks 
Gurushant

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
eggor
Sent: Thursday, March 12, 2009 11:16 PM
To: Finking, Robert
Cc: [email protected]; [email protected]
Subject: Re: [rohc] 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


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc