Re: [rohc] IPR... again...

[Alan Kennington <[e-mail]>]

On Sun, Aug 31, 2003 at 11:00:30PM +0100, West, Mark wrote:
> 
[....]
> 
> Oh, and before anyone points out the fact: yes, I do know that IPR is
> claimed on computing the static / dynamic part of the CRC.  Hmmmm...
> sounds like an implementation issue to me.  Ok -- let's try this:
> everyone raise your right hand & repeat after me: "I do solemnly swear
> that I shall not stoop to any nasty implementation enhancements like
> caching the static part of the CRC computation without first consulting my
> tame patent attorney."  There, that should fix it..?
> 


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?

Today's CPUs are so fast that there is absolutely no reason to cache the CRC
over a few bytes. I don't even bother to use an 8-bit look-up table (which I
usually do with CRCs) to accelerate CRC calculation because CPUs are so fast
that you can do individual bit-shift CRC calculation. It's also a tiny
proportion of the overall CPU burden. When a 400 MHz CPU is doing GSM voice
encoding and decoding and all of the ROHC encoding/decoding and much more (like
logging 1000 bytes of information to disk for every packet), I find that the
CPU usage is about 6%. 

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.

------------------------------
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?

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.

Cheers,
Alan.


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