Re: Updated QCRAM Draft

[Kazuho Oku <[e-mail]>]

2018-01-24 23:10 GMT+11:00 Jana Iyengar <[e-mail]>:
>
> The draft outlines what I think the room converged on, and it seems fairly straightforward -- thanks for the quick turnaround!
>
> Kazuho: I could be wrong, so Buck or Mike should correct me if so, but I believe the "Base Index" is basically what I think of as the "generation ID" of the table. It reflects the number of table operations that have happened... this is important when you have evictions, since just a reference to the largest index is ambiguous if there have been evictions.

Jana, thank you for the response.

Please correct me if I am wrong, but the below is my understanding.

Modifications to the HPACK state only happens on the Control Stream.
So we do not need to rely on the index to determine how the state
needs to be changed.

For HEADERS frames sent over non-control streams, the only information
that the decoder needs is the absolute indices of the header table,
which can be encoded as largest_index (or whatever you call) plus the
deltas.

>
>
> I don't understand however how the largest index is "Base Index - Depends". I would've thought the largest index would simply be "Depends". What am I missing?
>
> On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku <[e-mail]> wrote:
>>
>> Buck,
>>
>> Thank you for the draft.
>>
>> I like the approach and I think that it is not difficult to implement.
>>
>> Reading the spec, the question I have is why you need the BLOCKING flag and two variables (i.e. base index and depends). Can't each HEADERS frame always hold just one offset (i.e. largest index that the frame refers to)?
>>
>> Maybe I am missing something.
>>
>>
>> 2018-01-24 16:53 GMT+11:00 Mike Bishop <[e-mail]>:
>>>
>>> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please read before tomorrow’s meeting so we can have a useful discussion.  Thanks!
>>
>>
>>
>>
>> --
>> Kazuho Oku
>
>



-- 
Kazuho Oku