Subject: RE: [rohc] linux constant IP ID field can't be compressed in prof ile 0x0001?

From: "Price, Richard" <[email-masked]>
Date: Mon, 2 Jun 2003 16:04:28 +0100

Hi,

I'm confused - is this a part of the final standard?

My interpretation of RFC 3095 is that the compressor subtracts the
sequence number from the IP-ID, and then sends the resulting offset
using W-LSB encoding. The decompressor reconstructs the original
IP-ID by decoding the offset and then adding the sequence number. In
particular, if the decompressor receives 0 LSBs of offset, it will
always assume that the offset is the same as the value stored in the
context - i.e. that the IP-ID is going up by 1 in every successive
packet.

Regards,

Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 30, 2003 8:14 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [rohc] linux constant IP ID field can't be compressed in
> profile 0x0001?
> 
> 
> > Since the IP ID field being constant is clearly a pattern, it seems
> > reasonable to demand that this pattern should be detected in the normal 
> > way patterns are detected. Thus, even if the existing WLSB encoding doesn't 
> > compress the constantly zero field very well, the compressor would still 
> > be able to send type 0 headers and the decompressor should be able do 
> > decompress them. Also for profile 0x0001.
> > 
> > I believe Zhigang said this about a year ago, and I don't recall any
> > protests at that time. Have we since decided to not recognize this pattern?
> 
> Thanks for pointing this out, Micke. I cannot remember when I said that
> (probably 2 years ago?) but you're certainly right. 
> 
> In this case, the pattern of (IP-ID - SN) is slope = -1. So, it only takes
> two headers (successfully decompressed) for the decompressor to detect the
> pattern. Considering possible packet loss, the compressor only need to send
> a few (>2) non-type-0 headers. The overhead due to inefficient IP-ID offset 
> encoding only occurs in those headers. In fact, since a few IR packets
> (carrying the full value of IP-ID) have to be sent at the beginning of a 
> packet flow anyway, there is no additional cost to handle this particular
> case.
> 
> BR,
> Zhigang
> 
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 3 Jun 2003 09:59:29 +0200

Richard, Zhigang, and others,

I agree with Richard that this is indeed confusing. What has been
outlined as a potential solution by Micke and Zhigang might be a
good way to handle this, and something we can define for new
profiles. However, the profiles in 3095 do not specify this
behavior, and a compressor can thus not assume that the decompressor
will detect the pattern. The compressor must rather assume the
opposite, and send IP-ID.

We are working with standards here, solutions are important, but we
must also introduce them in our standards in a proper way.

Rgds,
/L-E

> From: Price, Richard [mailto:[email-masked]]
> Sent: den 2 juni 2003 17:04
> To: [email-masked]'; [email-masked]; Lars-Erik Jonsson
> (EAB); [email-masked]
> prof ile 0x0001?