Re: Compression of AH/NULL-ESP headers in ROHCv1

At Tue, 23 Feb 2010 22:55:12 +0800,
Jer-ming Lin wrote:
> 
> 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
> 

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

> 2010/2/23 Klaus Warnke <[email protected]>:
> > At Mon, 22 Feb 2010 20:17:47 -0800,
> > [email protected] 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
> > _______________________________________________
> > Rohc mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rohc
> >