Re: QPACK proposal: wrap absolute index values

[Martin Thomson <[e-mail]>]

On Mon, Aug 6, 2018 at 2:46 PM Dmitri Tikhonov
<[e-mail]> wrote:
>       bool
>       isHeaderBlocked (unsigned LargestRef)

Thanks for sharing code.  Note that I'm not just interested in whether
I'm blocked, but for how many table updates I should block for, but I
can use this function (repeatedly if necessary) to make that
determination, I guess.

It took me ages to understand this code.  Are you expecting all the
arithmetic for CurMax to be modulo MaxEntries*2 ?  Because if that is
the case, then this makes sense.  Without that stipulation, I really
struggled.

We should examine the assertion here then.  That is, you make two
claims: one true, and one maybe-true:

1. You can't receive a header block with a largest reference that is
more than MaxEntries old from the current state.  This holds trivially
because that would mean that the entire header table was evicted.  We
don't allow entries to be referenced after eviction and there is no
way to reach this state without evicting the largest reference.

2. You can't receive a header block with a largest reference that is
more than MaxEntries new.  This doesn't hold because we don't cap the
amount that a header block can be blocked by.  Now, it's arguably a
reasonable restriction, because it takes multiple round trips to reach
a state where that header block can be used, but we don't currently
prevent someone from doing something like that.

Now, it's reasonable to assume that you can't have more than
MaxEntries worth of updates in flight, which means that in one round
trip, this will never happen.  But we don't say that you can't
reference dynamic table entries that are far in the future.  For this
to work, we would have to prohibit that.  Maybe we should, because
referencing entries that can't be sent is a footgun, just as
referencing entries that have not yet been sent is a footgun (it can
deadlock flow control if you do that).