Re: HTTP/3 Prioritization: kickstarting the discussion (again)

[Dmitri Tikhonov <[e-mail]>]

On Wed, Jul 03, 2019 at 04:26:02PM +0200, Robin MARX wrote:
> We have been recently running some prioritization experiments for a variety
> of schemes and proposals using our own HTTP/3 implementation in the Quicker
> project.
> We have discussed our findings in a paper, which you can find in attachment
> and also on https://h3.edm.uhasselt.be.

Last paragraph of Section 5 states:

  " Note finally that our H3 implementation does employ
  " dynamic header compression using the QPACK specification.
  " While QPACK can in itself lead to HOL-blocking between
  " streams, even in the normal modus operandi (as decoding some
  " compressed headers can depend on the receipt of previously
  " encoded headers), we believe this effect is negligible in
  " our reported results.

I take this to mean that, in your experiment setup, the QPACK encoders
on both client and server use the dynamic table, that blocked streams
are allowed, and that the encoders do, in fact, risk blocked stream to
maximize compression performance.  Is that correct?

If so, did you observe HOL-blocking between encoder and request
streams?

It would be interesting to tease out the magnitude of this impact
by running experiments with QPACK_BLOCKED_STREAMS=0 vs
QPACK_BLOCKED_STREAMS=100 (since you already have a setup ready).
My own (purely theoretical) musings about this can be found here:

    https://blog.litespeedtech.com/2018/01/29/qcram-04-does-not-solve-head-of-line-blocking/

(QCRAM-04 became QPACK.)

I still posit that

  " the single control stream introduces ordering to otherwise
  " independent operations, making it unable to minimize HoLB
  " for a class of applications.

And that upgrading to HTTP/3 (from HTTP/1.x or HTTP/2) will make
some applications perform worse -- if blocked streams are allowed.

  - Dmitri.