Re: Question related to ROHC-TCP Profile

Hi Eggor,

I am very glad that Appendix B helped. We were not sure whether to include such a large example in an RFC, so it is good to hear it is useful.

For reference I am leaving Roke, so this e-mail address will cease to work in a few weeks.  For further contact, use [email protected].

Thanks

Raffles

> -----Original Message-----
> From: eggor [mailto:[email protected]] 
> Sent: 12 March 2009 17:50
> To: Carl Knutsson
> Cc: Finking, Robert; [email protected]; [email protected]
> Subject: Re: [rohc] 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
> >
> >
>