Re: Results from adopting HTTP/3 priority

Hello Alan and Yang,

Thank you for the very interesting insights.

I had a few more detail questions that I hope you can answer:

1) Can you detail how often you use *the "incremental" flag* and for which
types of resources (and in which urgency "buckets")? And why?
    If not using much incremental, that might explain in part why the
metrics don't change when prioritizing retransmits.
    a) I also wonder if you have more data/insight on how much QUIC's HOL
blocking removal has helped in practice and how that interacts with the
incremental logic. Matt has mentioned this before, but didn't share details
as of yet.
    b) If you do incremental, do you still Round-Robin streams on a
per-packet basis or have you switched to larger bursts per stream? Have you
experimented with other approaches?
    c) How exactly do you deal with mixed incremental/non-incremental
resources in the same urgency bucket?
        Say a and b are not incremental, then c and d are, then e again is
not. Do you do a, b, mixed cd, e? or for example: a, b, e, mixed cd (i.e.,
non-incremental is a bigger indicator of priority than stream ID/request
order)
        The spec currently does not detail how best to handle this case
(and to be honest, I'm not sure what the best default approach would
be...), but I assume the second option is easier to implement (use 2 queues
per priority bucket, 1 sequential, 1 RR).

2) You mention "implementing priorities directly in the QUIC layer": do you
have insight in the *design of the API* between the H3 and the QUIC layer
for this?
     d) Does the QUIC part internally implement this as a direct analogue
to the H3 priorities (say a list of urgency buckets, with some more
complexity for incremental vs non-incremental subslices, see c)) or does
QUIC offer a simpler/more complex setup onto which you map the H3 signals?
     e) Is there a coupling between stream-level flow control and stream
priority? (e.g., high priority streams get higher allowances from the
client than low-priority streams, to make sure they're not FC-blocked?). I
assume client-side FC allowance is always high enough, but still :)
     You mention TCP_NOTSENT_LOWAT, but the concept of deep vs shallow
buffers still stands in QUIC as well:
     f) Do you prepare buffers with data to be sent or do you (only)
generate QUIC packets/DATA frames on the fly?
     g) In the first case, how large are the buffers? Do you flush them if
a new, higher priority request arrives?

3) With regards to *prioritizing retransmits*:
   Is this deployed on a CDN-style setup, where e.g., the edge has
low-priority (static) resources cached and starts sending them before
receiving higher priority responses from the "origin"?
   I would assume that in this setup, you'd have cases where sending
high-priority fresh data before low-priority retransmits does matter a lot,
especially for non-incremental resources (though it depends on many
factors). Do you have any insight on this scenario?
   h) if deployed in a CDN-style setup, do you use (persistent) H3/QUIC to
the origin as well? I mainly wonder about if (and how) you tweak priority
across requests from multiple clients coalesced onto a single "backend
connection" (as that's one of the use cases we "lose" by dropping the
dependency tree).

If you can even answer a few of these, I'll be a happy camper ;)

With best regards,
Robin





On Tue, 27 Apr 2021 at 18:56, Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
> On Tue, Apr 27, 2021 at 4:30 PM Yang Chi <yangchi@fb.com> wrote:
>
>> I should also note that part of the experiment result (the critical API
>> experiment mentioned in Alan’s email) was done without scheduling fresh
>> data and loss data together. Back then, loss data were scheduled
>> separately, before fresh data, but still respect to priority. In other
>> words, we used to send high pri loss data, then low pri loss data, then
>> high pri fresh data, then low pri fresh data. Then we switched to this new
>> scheduler, where it first sends high pri loss data, then high pri fresh
>> data, then low pri loss data followed by low pri fresh data. I didn’t see
>> any interesting metrics move since this change though.
>>
>
> Thank you Yang, very interesting. There's a lot of potential factors, so
> even if metrics are neutral that is a useful observation.
>
>

-- 

dr. Robin Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media

*Cellphone *+32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05