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

[Kazuho Oku <[e-mail]>]

2016-01-09 4:57 GMT+09:00 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.

Thank you for the positive response.

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

That approach sounds very reasonable.

Considering the fact that there are specific requirements to cache
digests for optimizing HTTP/2 push (i.e. the digest should be small /
the digest may be sent before the first HTTP/2 frame arrives from the
server), I think it would be appropriate to keep the description of
the 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.

Agreed.

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

Thank you for the thoughtful suggestion.  Limiting the value of N and
P to be below 2^32 sounds like a very good idea.

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

Agreed.  Defining the operation as truncation and conversion to an
integer will be more precise.

Thank you for the advices.

-- 
Kazuho Oku