Re: Updated QCRAM Draft

["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.   I think that is tricky because one does not
naturally know "depends" yet while emitting indexed entries.    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. 🤔






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