Re: Query regarding the LSB encoding in TCP Profile

Hi Raffles,

Thanks for your response. My queries are explained very clearly.
If the authors mention these points in the RFC (may be at the end), it will
be helpful for the new people who are working on ROHCv2.

Regards,
Anil Kumar Maguluri

From: Raffles [mailto:[email protected]]
Sent: Saturday, March 27, 2010 5:16 AM
To: Anil Maguluri
Cc: [email protected]; Anil Kumar Maguluri; Kristofer Sandlund; [email protected]
Subject: Re: [rohc] Query regarding the LSB encoding in TCP Profile

Hi Anil,

Thanks for the mail. With respect to the 4997 queries, I think the key issue is with understanding LSB encoding so I'll start with your final question and work backwards.

The example given in RFC 4997 section 4.11.5 uses 14 bits which covers 2^14 = 16384 possibilities. Without any offset, this would give a range of 0 to 16383. We wish to allow for an equal amount of deviation each side so we set the offset in the middle, 8192. This gives us a range of (0 - 8192) to (16383 - 8192) i.e. a range of -8192 to 8191 (i.e. by setting the offset to be half the range we have effectively turned this into two's complement).

Going back one question, the use of "p=2^(k-1)-1"* is to calculate offsets such as 8191 in rnd_5. The authors are simply explaining where they got the number 8191 from. Because the range of an lsb encoding is a power of 2 in size it is always an even number. Therefore there is no integer midpoint; you can't split the range exactly into two. You can either pick the integer immediately above the midpoint, or the one just below. With the example in RFC 4996, I chose the conventional two's complement midpoint (p=2^(k-1)), which slightly favours the negative. The RFC 4997 authors chose the other option (p=2^(k-1)-1), which slightly favours the positive. With 8191 as the offset, the range is (0 - 8191) to (16383 - 8191) i.e. a range of -8191 to 8192. It really is arbitrary which you pick.

Going back now to what I think is your very first question (i.e. why 65535 in rnd_1), I must confess I don't understand why this value was selected. It is certainly at odds with the stated design you quoted, since it doesn't satisfy p=2^(k-1) - 1: 65535 != 2^(18-1) -1, 65535 != 2^17 - 1, 65535 != 131071. However, I am not an expert on RFC 4996. I know the authors spent years agonising over the profile so I suspect they just ran out of words to explain this value. The main point is,  the offset specified is the one that should be used.

So, finally, to answer your overall question. My understanding is that you can safely ignore the "p=2^(k-1)-1" when producing an implementation. Despite the fact that it is contained in a normative section, it is only there for explanatory purposes. The important thing in producing an implementation is to get it right, for which section 8.1 can be ignored, but section 8.2 must definitely be adhered to.

I suspect that you already understood a lot of this, but other readers may not, I hope you didn't mind the extra explanations. If on the other hand I have failed to explain clearly, I do apologise. Please feel free to ask further questions.

Regards

Raffles (Robert Finking)

* for the meaning of p and k, see also text on page 42 of RFC 4996:



   When discussing LSB-encoded fields below, "p" equals the

   "offset_param" and "k" equals the "num_lsbs_param" in [RFC4997<rfc4997>].  The

   encoding methods used in the compressed base headers are based on the

   following design criteria:



Anil Maguluri wrote:
HI All,

Please clarify me the below queries regarding the LSB encoding in TCP Profile.

The below statements in RFC 4996 are confusing, please clarify me.

Statement-1
In RFC 4996, Page 43, under TCP Sequence Number:
" Also, for ROHC-TCP to be robust to losses, two additional bits are added to the LSB encoding of the sequence number. This
means that the base headers should contain at least 14 bits of LSB-encoded sequence number when present. According to the
logic above, the LSB offset value is set to be as large as the positive offset, i.e., p = 2^(k-1)-1. "

Statement-2
In RFC 4996, Page 81, in the compressed packet formats are represented as below:
// Send LSBs of sequence number
COMPRESSED rnd_1 {
Discriminator    =:= '101110' [ 6 ];
seq_number      =:= lsb(18, 65535) [ 18 ];
msn                       =:= lsb(4, 4) [ 4 ];
psh_flag               =:= irregular(1) [ 1 ];
header_crc         =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}

As per my understanding, we have to use offset param value (RFC 4997, page 27) as 65535 to compress the seq_number to select
The rnd_1 packet. Is it right? If my understanding is right, then what is the use of p=2^(k-1)-1?

Also please explain me the below statement which is present in RFC 4997, page 27.
For example, the TCP sequence number:
tcp_sequence_number =:= lsb(14, 8192);
This takes up 14 bits, and can communicate any value that is between 8192 lower than the value of the field stored in context and 8191
above it.

Thanks for your support.

Regards,
Anil Kumar Maguluri

________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________







________________________________






_______________________________________________

Rohc mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/rohc



--

Raffles (Robert Finking)

m: 0789 463 9887

e: [email protected]<mailto:[email protected]>

w: gluft.com



         O                  O

 OOOOOO  O  O    O OOOOOO OOOOO

 O    O  O  O    O OOOOO    O

 OOOOOO  O  OOOOOO O        O

 OOOOOO

      we  care  about  software



-----------------------------------------------------------------

Gluft Ltd. Registered No.: 6795336      VAT No.: 974 2755 83

The information contained in this e-mail and any attachments is

proprietary to Gluft Ltd and must not be passed to any third

party without permission. This communication is for information

only and shall not create or change any contractual relationship.

Please consider the environment before printing. Thank you.

-----------------------------------------------------------------

______________________________________________________________________

________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________

_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc