[Http-crcsync] General comments on crcsync document

[Alex Wulms]

Op zondag 12 juli 2009, schreef Rusty Russell:
> On Fri, 10 Jul 2009 11:06:12 am Patrick McManus wrote:
> > > more related comments on the spec.. it took me a few minutes to figure
> > Is there a strong basis for 60, or is it just "more than 32". and was 32
> > shown to have problems significant enough to warrant the change? (the
> > strong sha is wrapped around the whole thing should it collide,
> > afterall.)
>
> It's a 64 bit hash with 4 bits thrown away.
>
> Unf. 32 bits is probably not enough given the birthday problem (but has the
> advantage that it will test those code paths).  We started with 32 bits;
> ISTR there was pressure for change, don't know if that was from actual
> testing results?
>
> (FWIW I like 32 bit myself: easy and well understood).

It was based on a discussion but not on actual testing results. The discussion 
can be found back here: 
http://lists.laptop.org/pipermail/server-devel/2009-April/003143.html


> > in a somewhat related thought:
> >
> > "In case of a mismatch, the crcsync cache client should return an error
> > condition to the classical cache client and discard the original
> > instance from it's local store, to prevent the same error from
> > re-occurring when the user retries the request. "
> >
> > I'm not sure this specification has any business telling the a cache
> > that it should discard legitimate instances from its local store. There
> > might very well be administrative policy in place pinning them there! A
> > more appropriate remedy would be prohibiting said client from sending
> > the same if-block sequence for a subsequent request to the same resource
> > without getting a successful transaction in between. Even changing the
> > block size on the next request would cure a crc conflict.
>
> Yes, I suggest rewording.  Of course, in practice deleting is probably
> simplest for a stateless implementation.
The idea to throw away the cached page was also based on that same discussion. 
Though, indeed, the spec should not force the crcsync cache client to 
completely discard the cached page. How to recover from a collission is 
indeed an implementation detail.

Cheers,
Alex