[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] linux constant IP ID field can't be compressed in prof ile 0x0001?
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
> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: den 2 juni 2003 17:04
> To: 'zhigang.c.liu@nokia.com'; micke@cs.arizona.edu; Lars-Erik Jonsson
> (EAB); rohc@ietf.org
> Subject: RE: [rohc] linux constant IP ID field can't be compressed in
> prof ile 0x0001?
>
>
> 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: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > Sent: Friday, May 30, 2003 8:14 PM
> > To: micke@cs.arizona.edu; Lars-Erik.Jonsson@epl.ericsson.se;
> > rohc@ietf.org
> > 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
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> >
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc