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

From: "West, Mark" <[email-masked]>
Date: Tue, 2 Sep 2003 18:23:41 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Alan Kennington <[email-masked]>
Date: Wed, 3 Sep 2003 04:15:37 +0930

Mark,

There are two separate issues here:

1.	Choice of header field ordering for CRC calculation.

2.	Caching the CRC when the static fields don't change.

Clearly (2) is the motivation for the ordering in (1).  However, anyone who
specifies the scope and algorithm for a CRC can arbitrarily decide ordering and
various other factors, such as interleaving, convolution, "salt", bit order,
byte order, etc.  So I don't see that any possible patent on the concept of a
CRC cache for partial CRC calculations (which have been around for over a
decade anyway) can somehow imply a patent on a particular field order.  

In other words, I don't see that an IPR issue on (2) implies an IPR issue on
(1).  If someone "owns" the method of incremental CRC calculation, that doesn't
imply that they "own" a particular order of header fields in a CRC calculation.

Once again, it's very difficult to see how anyone can patent everyday,
bog-standard engineering practices. 

> if you want to know more..!)

I must say that I am shocked by this. This is clearly in the intersection
of the categories "prior art", "obvious to those skilled in the art", and
"not very useful". I pity the poor company that has to prove these things
in court. The patent office shouldn't accept these shallow concepts.

> http://l2.espacenet.com/espacenet/viewer?PN=CA2375830&CY=gb&LG=en&DB=EPD

Once again, I am shocked. What does the Patent Office do apart from
clicking the "OK" button? By the way, did you know that about 12 months
ago, some guy in Australia patented the lever? Then a couple of weeks later,
someone patented the wheel! 

One effect of this sort of attempt to patent ROHC will be to prevent any open
source, free implementations from being published. Even a frivolous patent can
bankrupt a poor programmer. The IETF is not supposed to be a publishing house
for proprietary standards. IETF standards are supposedly open and free for
anyone to implement. If ROHC is the private property of a few big companies,
then this should be clarified so that other people can avoid it - and maybe
create a free and open robust header compression standard. If it becomes known
that ROHC is private intellectual property, then I think the general, wider
interest in it will decrease. When GIF file users were sued by Unisys, the open
source community created the PNG format. There are many cases where proprietary
protocols and formats have been substituted by the open source world. 

> (in fact) exactly what 'deflate', 'zlib', 'pkzip', ... do.

These CRC-equipped compression formats were published after a long history of
routine use of CRCs to check received files, I believe.  There have been many
programs like cksum, crc32, md5 etc. which have been used routinely in the unix
world for verifying correct receipt of uncompressed files. 

Software like "ssh" has always used compression, and has used very strong
checksums on the decompressed result. The same is true, I believe, of
bog-standard telephone modems, which do compression and checksumming to
verify correct reception. This is at least a decade old.

CRCs have been in the signal processing texts for many decades, as have also
compression algorithms. It's seems strange to me that anyone would
think of trying to patent such an obvious combination: compression + CRC.

> about RFC 3095, which is probably no bad thing...)

If the IPR issues are not satisfactorily clarified, only companies with
big legal departments will publish ROHC implementations.
In my opinion, there needs to be a process whereby the "little fish" can
get a solid assurance from the "big fish" that they will not be sued
for implementing and releasing RoHC implementations. Patents really
poison the whole market place so that little fish cannot breathe.
An invalid patent is as harmful as a valid patent to the little fish.

Cheers,
Alan.