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

[Kazuho Oku <[e-mail]>]

2016-01-12 18:46 GMT+09:00 Stefan Eissing <[e-mail]>:
> Kazuho,
>
> thanks for the draft and your work in this. I am currently implementing
> a "push diary" for connections in mod_http2. This updates itself while
> handling the connection, but ideally is initialized by a CACHE_DIGEST
> frame.

My pleasure.  It's great to hear that you are also looking into optimizing push.

>> Am 12.01.2016 um 02:04 schrieb Kazuho Oku <[e-mail]>:
>> [...]
>> There are three options here (the draft adopts option C):
>>
>> a) send CACHE_DIGEST frame right before HEADERS
>> b) send CACHE_DIGEST frame at stream_id=zero, with the value of the
>> authority that should be associated to the digest included within the
>> frame
>> c) send CACHE_DIGEST frame right after HEADERS
>>
>> B is clearly the easiest but would have a small impact on the consumed
>> bandwidth, since the authority needs to be sent separately.
>>
>> In A, the server does not need to delay the processing of the request,
>> but needs to cache the value of the digest.
>>
>> It would be great to discuss which of the three approach will be the
>> best solution in general (or if there could be other approaches).
>
> There seems to be an underlying assumption here that CACHE_DIGEST is
> connected to a specific authority which was not immediately obvious
> to me when reading the draft.
>
> With that in mind, I would prefer the CACHE_DIGEST frame to
> carry the authority scope. That makes it self descriptive and
> it can be sent on stream 0, which solves the before/after problem.
>
> Also, I think the authority in that frame should be allowed to carry
> the value '*' to allow endpoint implementations that keep one set
> for all authorities on a connection.

Thank you for expressing your preference.

Number of additional octets needed for embedding the authority name
will typically far less than INITCWND (in many cases around 15KB);
hopefully we can all agree to accept the overhead.

> Additionally:
>
> 1. Just for clarification: the digest values are calculated on
> the absolute URL, :scheme+'://'+:authority+:path? Because h2o
> currently uses only :path, if I read it right.

Correct.

> 2. Would it make sense to limit N and P, so that (N*P) which is
> used for modulo calculation stays in unsigned 32 bit? Even with
> N==P it would work up to 65K, if I am not mistaken...

That is possible, but I am not sure if we should optimize that much.

The computational cost of restricting N*P to 32bit (as opposed to
64bit proposed by Martin) should be negligible; the dominant factor
for encoding / using the digest will be calculating the SHA256 of the
URLs.

Regarding the cost of space, it is possible to truncate the values
obtained from GCS after decoding them.

> -Stefan
>
>> --
>> Kazuho Oku
>



-- 
Kazuho Oku