Subject: [rohc] Question related to ROHC-TCP Profile

From: eggor <[email-masked]>
Date: Wed, 11 Mar 2009 14:41:03 +0200

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.

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 12 Mar 2009 12:56:34 -0000

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-masked] [mailto:[email-masked]] On 
> Behalf Of eggor
> Sent: 11 March 2009 12:41
> To: [email-masked]
> 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 {
> 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-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 12 Mar 2009 14:32:48 +0100

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

---

From: eggor <[email-masked]>
Date: Thu, 12 Mar 2009 19:45:55 +0200

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.

---

From: eggor <[email-masked]>
Date: Thu, 12 Mar 2009 19:50:01 +0200

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.

---

From: "Gurushant" <[email-masked]>
Date: Fri, 13 Mar 2009 12:41:00 +0530

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-masked] [mailto:[email-masked]]On Behalf Of
eggor
Sent: Thursday, March 12, 2009 11:16 PM
To: Finking, Robert
Cc: [email-masked]; [email-masked]
Subject: Re: [rohc] Question related to ROHC-TCP Profile

Hi Raffles,

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.

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 13 Mar 2009 08:27:57 -0000

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-masked].

Thanks

Raffles

> From: eggor [mailto:[email-masked]] 
> Sent: 12 March 2009 17:50
> To: Carl Knutsson
> Cc: Finking, Robert; [email-masked]; [email-masked]
> 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...
> 
> > RFC4996. Implementing RFC4996 without understanding RFC4997 will be 
> > very difficult.
> >
> >
> > Best Regards
> >
> > /Carl Knutsson
> >
> >
> > Finking, Robert wrote:
> >> Hi Igor,
> >>
> >> 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:
> >>
> >> 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
> >>
> >>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> >>> Of eggor
> >>> Question about "seq_number_scaled" field defined in the CONTROL 
> >>> format of the tcp(payload_size, ack_stride_value,
> >>> 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.

---

From: eggor <[email-masked]>
Date: Mon, 16 Mar 2009 19:38:24 +0200

Hi Raffles,

Thanks for the information, I'm switching on the new address.  BTW,
have you received my mail sent on Mar 12 to the old one?

Thanks,
Igor.