Re: Question related to ROHC-TCP Profile

Hi Carl,

Thank you for your advise.  I understand this, and I have already
studied RFC4997.  And I need to say that RFC4997 per se didn't seemed
to me too difficult.  Especially thanks to authors for intelligible
example in Appendix B, it is very helpful to understanding of FN.  But
I ran into some difficulties with the applying of that information to
the RFC4996.  For example, mentioned sample didn't consider a case
when the control fields aren't appeared in any compressed format, like
control fields of the "tcp" encoding method in RFC4996...

But I hope that I'll be able to overcome all difficulties with your help guys.

Thanks again,
Igor.

On Thu, Mar 12, 2009 at 3:32 PM, Carl Knutsson <[email protected]> wrote:
> Igor, Raffles,
>
> First, thank you Raffles for answering Igor's question and explaining
> ROHC-FN. It is a tough subject, but think you guys did a great job on
> RFC4997.
>
> Igor, the binding between attributes that Robert explained below is
> called two-way matching. It is one of the key concepts of ROHC-FN. I
> advise you to study the RFC4997(ROHC-FN) before you start implementing
> RFC4996. Implementing RFC4996 without understanding RFC4997 will be very
> difficult.
>
>
> Best Regards
>
> /Carl Knutsson
>
>
> Finking, Robert 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
>
>
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc