Re: QPACK proposal: wrap absolute index values

[Martin Thomson <[e-mail]>]

So this is a really interesting idea, but I did a triage yesterday and
missed it.  Dmitri, would you mind creating an issue for this?
On Mon, Aug 6, 2018 at 10:19 PM Dmitri Tikhonov
<[e-mail]> wrote:
>
> On Mon, Aug 06, 2018 at 04:52:34PM +1000, Martin Thomson wrote:
> > 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.
>
> Well, that's just pseudo-code, you know.  I'd never CamelCase real
> code!
>
> > 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.
>
> Yes, all the arithmetic for the absolute index is modulo MaxEntries * 2.
>
> > 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.
>
> This is true -- my assertion about the future horizon is incorrect.
> Somehow I assumed that the mirror argument about the encoder worked,
> but it does not.  For example, nothing prevents the encoder from
> pumping the table full of speculative updates, maybe even a few times
> over, before ever using it.
>
> > 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).
>
> Yes, for the proposed mechanism to work, we'd have to mandate that the
> encoder not create new entries past some limit, which is a function of
> the known decoder state (based on TSS or Header Acks) and MaxEntries.
>
> Thanks for identifying this flaw.  The change is larger than I was
> hoping it would be.  It's still worth it.
>
>   - Dmitri.