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

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 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
>
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc