Re: 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 ]. 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]
https://www.ietf.org/mailman/listinfo/rohc

--

Raffles (Robert Finking)
m: 0789 463 9887
e: [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.
-----------------------------------------------------------------

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