Re: Updated QCRAM Draft

[Kazuho Oku <[e-mail]>]

Hi,

Thank you for the response.

2018-01-25 3:44 GMT+11:00 Charles 'Buck' Krasic <[e-mail]>:

>
>
> On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku <[e-mail]> wrote:
>
>> 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.
>>
>
> Great point.  The prefix is not needed for the modifications to HPACK
> state, i.e. for the blocks delivered on the Control Stream.
>
>
>>
>> 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?
>>
>
> Alan F.  also made a similar point.
>
> Base index is for interpreting indexed representations correctly
> regardless of re-ordering.  It is basically the total number of insertions
> that happened before the current block has processed.
>
> Depends is for ensuring that the decoder blocks if necessary to wait for
> table updates the current block depends on.
>
> The 'Base Index - Depends' is poorly written and needs an example, sorry
> about that.   The point I was trying (badly) to make was that depends is
> encoded relative to Base Index so that it's size stays bounded, it's just
> an optimization to save bytes for the case of very long lived connections.
> Note that Base Index does not have such bound right now.  Maybe a change to
> specify wrap-around  might be a reasonable way to also bound Base Index.
>
> Alternatively, and maybe this is what you just said (?), the two could be
> combined into one number.
>

Yes. That is what I have been thinking of.


> I think that is tricky because one does not naturally know "depends" yet
> while emitting indexed entries.
>

I think that the encoder needs to do a two-pass operation regardless of if
we encode two numbers (i.e. base_index, depends) or just one. This is
because since base_index and depends cannot be determined until the encoder
iterate through all the headers.

So to me it seems that it is not tricker for an encoder to use an unified
value; in the first pass the encoder determines the absolute index, and
then in the second pass emit the unified "base index" plus the deltas.


>     It could be in practice that either the depends flag is false, or it
> is true and the Depends value is the same as Base Index.   This was
> definitely not true with QCRAM-03, but it might well be with QCRAM-04.
> That's what I hope to sort out ASAP with updates to the simulator. 🤔
>

I understand that it's hard to update all the related code as we adjust the
approach. Thank you for your efforts!


>
>
>
>
>
>> >
>> > 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
>>
>
>
>
> --
> Charles 'Buck' Krasic | Software Engineer | [e-mail] | +1 (408)
> 412-1141 <(408)%20412-1141>
>
>


-- 
Kazuho Oku