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

From: "West, Mark" <[email-masked]>
Date: Sun, 31 Aug 2003 23:00:30 +0100 (GMT Daylight Time)

Hi all,

Gosh... guess what..?  It seems that the IPR situation hasn't been
resolved yet...

Ok, well, here's one suggestion: let's ignore context repair (which, it
has to be said, probably counts as novel) and just use the CRC to verify
correct decompression in its most basic form...

You want a reason?  Oh, ok!  Here are some 'quotes' from 'zlib' (you'll
note that this was written in '95/'96 and, who'd've thunk it, contains a
CRC over the uncompressed data...):

	/* gzio.c -- IO on .gz files
	 * Copyright (C) 1995-1996 Jean-loup Gailly.
	 * For conditions of distribution and use, see copyright notice in zlib.h
	 */

<snip>

	typedef struct gz_stream {
	    z_stream stream;
	    int      z_err;   /* error code for last stream operation */
	    int      z_eof;   /* set if end of input file */
	    FILE     *file;   /* .gz file */
	    Byte     *inbuf;  /* input buffer */
	    Byte     *outbuf; /* output buffer */
	    uLong    crc;     /* crc32 of uncompressed data */
	    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	          This might be relevant...

	    char     *msg;    /* error message */
	    char     *path;   /* path name for debugging only */
	    int      transparent; /* 1 if input file is not a .gz
					file */
	    char     mode;    /* 'w' or 'r' */
	} gz_stream;

<snip>

        if (s->z_err == Z_STREAM_END) {
            /* Check CRC and original size */
            s->crc = crc32(s->crc, start, (uInt)(s->stream.next_out - start));
            start = s->stream.next_out;

            if (getLong(s) != s->crc || getLong(s) != s->stream.total_out)
            {
                s->z_err = Z_DATA_ERROR;
            } else {
                /* Check for concatenated .gz files: */
                check_header(s);
                if (s->z_err == Z_OK) {
                    inflateReset(&(s->stream));
                    s->crc = crc32(0L, Z_NULL, 0);
                }
            }
        }

Now, I know I'm *really* slow on the uptake, but isn't this a CRC over the
uncompressed data to verify decompression..?!

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

Comments..?!

;-/

Mark.

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

---

From: Alan Kennington <[email-masked]>
Date: Tue, 2 Sep 2003 23:52:54 +0930

On Sun, Aug 31, 2003 at 11:00:30PM +0100, West, Mark wrote:
[....]
> 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.