RE: [rohc] IPR... again...

["West, Mark" <[e-mail]>]

Hi Alan,

Thanks for your response!  (I was a bit worried that messages were in a
random 1 - 2 day time-warp, but the bottleneck seems to have cleared now!)

A couple of comments, in-line...

> 
> Mark,
> 
> Personally I think it's bad engineering to cache the static CRC.
> In my implementation, I didn't even think of doing this.
> It's asking for trouble because you have to keep track of
> whether it might change and make sure that the CRC is always 
> synched with
> the static header fields. It's very much simpler and more reliable to
> CRC everything every time it's needed.
> After all, you do a CRC to ensure robustness. So why would you 
> introduce the danger of software error in CRC calculation?
> 

Good question... ;-)

<snip>

> 
> Conclusion: the static/dynamic CRC calculation split is 
> really perplexing.
> When I first saw that, I couldn't work out why someone would bother
> which such a minor optimisation when there are so many other things
> that could have been optimized.
> 
> Theoretically, implementation issues that have no influence on the
> coding "on the wire" have no place in comms standards. So the
> static CRC caching is in the category of "implementation hints".
> This should really be in an appendix.
> However, RFC 3095 contains numerous "implementation hints" of 
> this sort.
> For example the "compression state" variable is in this category.
> It does not appear on the wire, and can be dispensed with completely.
> 

The thing that pains me about this is that it does affect the bits on the
wire, as you have to re-order all the bytes in the header to be able to
compute the CRC in two stages.  Hence my slightly facetious remark that we
should just 'promise not to do it...'  By the standard you are obliged to
re-order the fields as if you were going to do this but if, as in your
implementation, you don't actually *do* the caching, I assume that this
avoids the IPR..?

(See patent WO0207323 or 
http://l2.espacenet.com/espacenet/viewer?PN=WO0207323&CY=gb&LG=en&DB=EPD 
if you want to know more..!)

> ------------------------------
> Concerning the idea of using a CRC to detect errors in 
> decompressed data,
> surely this is as old as the history of CRCs and compression.
> Isn't this just ordinary communications engineering?
> 

Well, I'd have thought so.  Again, for the curious, see patent WO0079763, or
http://l2.espacenet.com/espacenet/viewer?PN=CA2375830&CY=gb&LG=en&DB=EPD
for the gory details.

My contention (hence my previous e-mail) is that a CRC over the compressed
data, that is only used to verify that decompression of same succeeded, is
(in fact) exactly what 'deflate', 'zlib', 'pkzip', ... do.

And, now I come to think of it, it is also as described in section 2.2 of
RFC 1950 (I'm sure I don't need to give a URL for that ;-)

Let me be clear that I am only talking about using a CRC to verify
decompression -- not any of the other tricks (e.g. context repair) that
might also be tried.  In fact, come to think of it, things like this should
really be decompressor-local optimisations anyway...

> Question:
> Could someone please explain what _serious_ IPR issues there might be
> in RFC 3095? Standard everyday communications engineering surely
> cannot be patented. 
> Does someone have a patent on the idea of using X module N to 
> communicate
> X when X is slowly varying? That's as old as using 03 to mean 2003.
> 

It's extremely tempting (albeit facetious, again) to comment that there is
quite a lot of frivolous IPR...
... but I think that there are some more-or-less valid concerns.

In order to move forward, though, we really need to determine what we can
and what we cannot use for TCP compression.  (Which is my main motivation
for pushing this thread -- although it will clearly tell us some things
about RFC 3095, which is probably no bad thing...)

Cheers,

Mark.


_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc