Subject: Re: [rohc] Compression of AH/NULL-ESP headers in ROHCv1

From: Klaus Warnke <[email-masked]>
Date: Tue, 23 Feb 2010 11:48:56 +0100

At Mon, 22 Feb 2010 20:17:47 -0800,
[email-masked] wrote:
Hello Anil,

> Dear Klaus,
> 
> Thanks for your response.
> Please clarify me the below queries.

I try inline...

> Regards,
> Anil Kumar Maguluri
> 
> Klaus Warnke-2 wrote:
> > 
> > At Mon, 22 Feb 2010 22:23:03 +0800,
> > Jer-ming Lin wrote:
> >> 
> >> Dear ROHCers,
> >> 
> >> "The AH sequence number can be omitted from the compressed header
> >> when the offset from the sequence number (SN) of the compressed
> >> header is constant, ...."
> >> 
> >> When I read the above lines about the AH sequence number in RFC 4815
> >> 5.8, I got the some questions.  Please clarify the following
> >> probelms. Thanks
> >> 
> >> 1) Does the SN mean RTP SN or AH SN in the "offset sequence number
> >>    (SN) of the compressed header"?
> > 
> > It means the master SN, derived from/compressed to the transmitted,
> > compressed SN bits.  And the master SN depends on the profile used. If
> > the used profile is RTP, the master SN is the RTP-SN. In UDP profile
> > it is a counter. The AH is handled as an extension header and can
> > occur in all profiles, I think.
> > 
> >> 2) Does the offset mean the method like "offset IP-ID encoding" or
> >>    just calculating the delta respectively(RTP SN and AH SN) and
> >>    compare?  Since RTP SN is 2 bytes and AH is 4 bytes, the two
> >>    methods will be different at wraparound.
> > 
> > I think, it is "just calculating the delta", because you are not
> > transmitting a (compressed) AH-SN offset itself anywhere. If the AH-SN
> > is in step with the compressed master SN, it can be omitted. If not,
> > you have to transmitt it "compressed" here:
> 
> [ANIL] what is the procedure to calculate the offset? is it the difference
> b/w the RTP SN and AH SN of the received packet (for profile-1) ? And 
> compare with the previous packet difference to decide whether AH SN
> needs to transmit or not. 
> is my understanding is right?

Yes and yes. 
This is my understanding about offset, Example:

SN	AH-SN	offset (SN - AH-SN)
128	42	86
129	43	86
130	44	86
131	45	86
132	46	86
133	256	-123
134	257	-123
135	258	-123
136	259	-123
137	260	-123

On SN 128..132 the offset is constant.
You can calculate the AH-SN from the SN - offset:

SN    offset AH-SN
128 - 86 =   42
129 - 86 =   43

At SN 133 the AH-SN jumps, for what reason ever.
But after that jump, the offset is constant again.

SN    offset             AH-SN
133 - -123 = 133 + 123 = 256
134 - -123 = 134 + 123 = 257

So there is no need to send the AH-SN at all, when the offset between
SN and AH-SN is constant and known by de-compressor. Because the
de-compressor can calculate the AH-SN from the formerly calculated
offset and the transmitted SN.

If the offset between SN and AH-SN changes, you have to sent both SN
and AH-SN x-times in order that the de-compressor updates its offset.

The offset itself will not transmitted. So it is on you, how to
calculate it (if the result is correct). 

Rules: The compressor must be able to detect changes (if the linearity
between SN and AH-SN is broken), and the de-compressor must be able to
calculate the AH-SN from its offset.

Right?

br
Klaus

> > 5.8.5.1.  Format of IP Extension Header(s) field
> > 
> >       +-----+-----+-----+-----+-----+-----+-----+-----+
> >       :    compressed AH Seq Number,  1 or 4 octets   :  if ASeq = 1
> >       +-----+-----+-----+-----+-----+-----+-----+-----+
> > 
> > "Compressed" means, either 7bit or 31 bits LSB. See below.
> > 
> > I think, if you are using a 4 byte variable for the AH and adding the
> > delta (offset) the is no need for a special wraparound handling, from
> > my point of view. If the AH SN wraps over before compression, but the
> > offset is constant and in step with the master SN, it will be wrap
> > over on de-compressor site also when adding the offset.
> > 
> > Gruß, Klaus

---

From: Jer-ming Lin <[email-masked]>
Date: Tue, 23 Feb 2010 22:55:12 +0800

Dear Klaus,

    Your example is like the "offset IP encoding". However, I think
this encoding is not suitable for the numbers of different bytes. That
will be ambiguous at signed calculation and wraparound. Since the AH
SN is 4 bytes, the compressor need to use RTP SN as 4 bytes to
calculate the offset. When decompressor get the compressed header,
decompressor also need to up the RTP SN to 4 bytes and substract the
offset. This is a little weird! @@ Moreover, the offset will be
different at wraparound. Please see the following examples.

1) offset

   SN (2 bytes)      AH-SN (4bytes)      offset (SN - AH-SN)(4 bytes)
 65534                  10                                    65524
 65535                  11                                    65524
        0                  12                           4294967284
        1                  13                           4294967284
        2                  14                           4294967284

    I think calculating delta with previous self SN is better. This
way is like INCORRECT parts in the RFC4815 5.8. It seems the CORRECT
part use the offset method. May you clarify this?

2) delta with previous SN

   SN     delta(SN)   AH-SN    delta(AH SN)
 65534       (no)           10          (no)
 65535         1             11            1
        0         1             12            1
        1         1             13            1
        2         1             14            1

2010/2/23 Klaus Warnke <[email-masked]>:
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>

---

From: Klaus Warnke <[email-masked]>
Date: Tue, 23 Feb 2010 16:55:53 +0100

At Tue, 23 Feb 2010 22:55:12 +0800,
>    SN (2 bytes)      AH-SN (4bytes)      offset (SN - AH-SN)(4 bytes)

Yes, you are right.  

If either SN or AH-SN wrap around (which should occur seldom), my
offset calculation is not optimal. If your are comparing the delta
values, and there are equal, the stride/offset is also equal. This is
a good hint, how to calculate the offset.

(prev-ah-sn + delta(SN) == curr-ah-sn)? -> offset constant

However, did you read in rfc 4815?

4.4.2.  TS Wraparound with Scaled Timestamp Encoding

Maybe it is better to waste some octets on wire for a seldom occuring
szenario than to risk that the de-compressor sends a NACK.

br Klaus