Re: Submitted new I-D: Cache Digests for HTTP/2

[Martin Thomson <[e-mail]>]

On 8 January 2016 at 18:17, Kazuho Oku <[e-mail]> wrote:
> Please let us know how you think about the proposal.  Thank you in advance.


This is good stuff, I'd like to see it validated, but it could be the
thing that makes server push viable for a lot of servers.

Like Alex, I'm interested in other applications than the primary one
you describe.  I don't think that you need to remove text about server
push, but you should avoid making statements that restrict its use.  I
recommend that you define the basic mechanism and then describe its
application to your primary use case.

I think that the draft is lacking a description of how to consume the
value.  That's particularly relevant as you get to the tail of the
value.

I wonder if we might be able to pack N and P a little more tightly by
constraining their range just a little.  And not only because it saves
a byte: you also want to limit the damage someone can do with the
header field and small P would bound the size of the data.  Similarly,
it will simplify implementations considerably if they can store
integers in uint64_t, which is possible if log2(N) + log2(P) doesn't
exceed 64.  I don't see any case for probabilities of 1/2^255 or 1/1;
likewise sets of 1 resource aren't interesting, and sets of 2^255
resources is a shade on the massive size.  2^32 is probably fine for
both.

"key" modulo ( "N" * "P" ) should instead be constructed by truncating
the hash to log2(N) + log2(P) bits and converting to an integer.