Subject: [rohc] Clarification regarding the ESP SN Encoding

From: Anil Maguluri <[email-masked]>
Date: Wed, 16 Jun 2010 12:32:18 +0530

Hi All,

Currently I am working on ROHCv1 Profile-3 (ESP/IP).

Please let me know whether my understanding is right or not regarding the ESP SN Encoding.

As per RFC 3095, 4.5.1, " The parameter p is introduced so that the interpretation interval can be shifted with respect to v_ref.
Choosing a good value for p will yield a more efficient encoding for fields with certain characteristics. Below are some examples:

-          P = -1 if the field value is expected to increase always

-          p = 0 if the field value is constant or increase

-          p = 2^(k-1) - 1, if the field value is expected to deviate slightly from a constant

-          p = 2^(k-2) - 1, if the field value is expected to undergo small negative changes or larger positive changes "

Also RFC 3095, 5.7, " SN: The compressed RTP Sequence Number.
Compressed with W-LSB. The interpretation intervals, see section 4.5.1, are defined as follows:
p = 1 if bits(SN) <= 4
p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 "

As per my understanding,  we should use the below 'p' values at compressor [for SN Encoding]

-          p=-1, if packets are received in-order

-          p=2^(k-2)-1, if packets are received out-of-order
at decompressor

-          p = 1 if bits(SN) <= 4

-          p = 2^(bits(SN)-5) - 1 if bits(SN) > 4

Queries

1.       Is my understanding is right?

2.       What is the value of 'p' for Profile-3 at compressor and decompressor?  Is it same as above?

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.

______________________________________________________________________

---

From: Klaus Warnke <[email-masked]>
Date: Wed, 16 Jun 2010 13:03:38 +0200

Hello Anil,

if I remember correct, RoHCv1 requires, that the link layer delivers
all packets in order (RoHCv2 not).

For p see 5.12.:

  The interpretation interval (value of p) for the ESP-based SN is as
  with ROHC RTP (profile 0x0001).

Therefore p is as 5.7.:

  p = 1                   if bits(SN) <= 4
  p = 2^(bits(SN)-5) - 1  if bits(SN) >  4

Regards, Klaus

At Wed, 16 Jun 2010 12:32:18 +0530,
Anil Maguluri wrote:
> As per RFC 3095, 4.5.1, " The parameter p is introduced so that the
> interpretation interval can be shifted with respect to v_ref.
> Choosing a good value for p will yield a more efficient encoding for
> fields with certain characteristics. Below are some examples:
> 
> - p = 2^(k-2) - 1, if the field value is expected to undergo small
>                    negative changes or larger positive changes "
> 
> - p = -1,                if packets are received in-order
> 
> - p = 2^(k-2)-1,         if packets are received out-of-order at 
>                          decompressor
> 
> - p = 1                  if bits(SN) <= 4
>

---

From: Anil Maguluri <[email-masked]>
Date: Wed, 16 Jun 2010 16:51:30 +0530

Dear Klaus,

Thanks for your response.
Please clarify me whether my understanding is right or wrong.

As per the RFC 3095, ROHCv1 won't support reordering between compressor
and decompressor. Right?
But, the compressor can receive packets in out-of-order from the upper
layers. Right?

As per the RFC 5225, ROHCv2 supports the reordering between the compressor
and decompressor. This is one of the advantage for ROHCv2.

Regards,
Anil Kumar Maguluri

-----Original Message-----
From: Klaus Warnke [mailto:[email-masked]]
Sent: Wednesday, June 16, 2010 4:34 PM
To: Anil Maguluri
Cc: [email-masked]; 'Anil Kumar Maguluri'
Subject: Re: [rohc] Clarification regarding the ESP SN Encoding

Hello Anil,

For p see 5.12.:

Therefore p is as 5.7.:

  p = 1                   if bits(SN) <= 4

Regards, Klaus

---

From: Klaus Warnke <[email-masked]>
Date: Thu, 17 Jun 2010 11:12:22 +0200

At Wed, 16 Jun 2010 16:51:30 +0530,
> As per the RFC 3095, ROHCv1 won't support reordering between compressor
Yes. See 

4.1.  Operating assumptions

   Reordering

      The channel between compressor and decompressor is required to
      maintain packet ordering, i.e., the decompressor must receive
      packets in the same order as the compressor sent them.

> But, the compressor can receive packets in out-of-order from the
> upper layers. Right?
Yes. If I remeber correct, the "-1" in the formular of p takes this
into account. Then the sliding window contains SN values that are
"-1" from v_ref. See 4.5.1. "v_ref - p". For UDP profile, where the SN
is generated by compressor, there is reorder possible, sure, the
interpretation interval contains no "-1" SN value.

> As per the RFC 5225, ROHCv2 supports the reordering between the
> compressor and decompressor. This is one of the advantage for
> ROHCv2.
Yes. There is a "reorder_ratio_value" defined.

> Anil Kumar Maguluri
br, Klaus

---

From: Anil Maguluri <[email-masked]>
Date: Fri, 18 Jun 2010 09:40:37 +0530

Dear Klaus,

Thanks for your response.
Comments/queries are inline.

Regards,
Anil Kumar Maguluri

-----Original Message-----
From: Klaus Warnke [mailto:[email-masked]]
Sent: Thursday, June 17, 2010 2:42 PM
To: Anil Maguluri
Cc: Klaus Warnke; [email-masked]; 'Anil Kumar Maguluri'
Subject: Re: [rohc] Clarification regarding the ESP SN Encoding

Yes. See

   Reordering

[ANIL] Ok.

[ANIL]
As per RFC 3095, 4.5.1

The parameter p is introduced so that the interpretation interval can
be shifted with respect to v_ref. Choosing a good value for p will
yield a more efficient encoding for fields with certain
characteristics. Below are some examples:
a) For field values that are expected always to increase, p can be
set to -1. The interpretation interval becomes
[v_ref + 1, v_ref + 2^k].
b) For field values that stay the same or increase, p can be set to
0. The interpretation interval becomes [v_ref, v_ref + 2^k - 1].
c) For field values that are expected to deviate only slightly from a
constant value, p can be set to 2^(k-1) - 1. The interpretation
interval becomes [v_ref - 2^(k-1) + 1, v_ref + 2^(k-1)].
d) For field values that are expected to undergo small negative
changes and larger positive changes, such as the RTP TS for video,
or RTP SN when there is misordering, p can be set to 2^(k-2) - 1.
The interval becomes [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)],
i.e., 3/4 of the interval is used for positive changes.

As per my understanding, we have to use "a" in case if the compressor
received packets in-order [RTP SN/ESP SN] (sequential) and "d" in case
if the compressor received packets in out-of-order. Is it right?

Also RFC 3095, 5.7,

"SN: The compressed RTP Sequence Number.
Compressed with W-LSB. The interpretation intervals, see section
4.5.1, are defined as follows:

p = 1                  if bits(SN) <= 4

The above "p" values should use at the decompressor for RTP SN/ESP SN.
Is it right?

[ANIL] Ok.

br, Klaus

---

From: Klaus Warnke <[email-masked]>
Date: Fri, 18 Jun 2010 11:28:16 +0200

At Fri, 18 Jun 2010 09:40:37 +0530,
Anil Maguluri wrote:
> The parameter p is introduced so that the interpretation interval
> can be shifted with respect to v_ref. Choosing a good value for p
> will yield a more efficient encoding for fields with certain
>    set to -1. The interpretation interval becomes [v_ref + 1, v_ref
>    + 2^k].
>
> c) For field values that are expected to deviate only slightly from
>    a constant value, p can be set to 2^(k-1) - 1. The interpretation
>    changes and larger positive changes, such as the RTP TS for
>    video, or RTP SN when there is misordering, p can be set to
>    2^(k-2) - 1.  The interval becomes [v_ref - 2^(k-2) + 1, v_ref +
>    3 * 2^(k-2)], i.e., 3/4 of the interval is used for positive
>    changes.
> 
> As per my understanding, we have to use "a" in case if the
> compressor received packets in-order [RTP SN/ESP SN] (sequential)
> and "d" in case if the compressor received packets in
> out-of-order. Is it right?

No.  There is no need to analyse the the RTP SN behavior.  The RTP-SN
always increases, never stay the same. If a reorder before compressor
occurs, a small negative change takes place. The formular of "p" below
takes this into account. In the udp profile the sn is generated by the
compressor, so negativ changes could not occur. So the "p" is
different from the "p" for the RTP "SN". It is important that the
compressor and decompressor using the same v_ref and the same "p" to
minimize the transmitted SN bits count and to avoid decompression
errors.

> The above "p" values should use at the decompressor for RTP SN/ESP SN.

Yes, and for compression too.

The 4.5.1 tries to explain how the stuff works and which values for p
are may usefull in which situations. And 5.7 says, which values you
have to use to make sure that interoperability is ensured.

br, Klaus