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

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