Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)

Spinning off a thread of discussion focused toward implementation
complexity.

Thanks, for sharing your implementation insight Bence.

On Tue, Jun 9, 2020 at 1:11 PM Bence Béky <bnc@chromium.org> wrote:

> Hi all,
>
> I find the statement that the client often learns information that
> influences priority after the request is sent conceivable.  To me this
> implies that the additional benefit of reprioritization is comparable to
> the benefit of prioritization in the first place.  Unfortunately, however,
> I do not have any data on the effect of reprioritization on the users' page
> load experience, neither for HTTP/2 or HTTP/3.
>
> However, I can speak to the complexity part.  I have implemented the
> PRIORITY_UPDATE frame for HTTP/3 both in the client and in the server
> network stack.  I consider the complexity of server-side buffering and
> resource usage limiting minimal.  Because of this, I oppose removing
> reprioritization from the Extensible Prioritization Scheme for HTTP draft.
>

Speaking as an individual:

HTTP/3 offers a pretty rational base profile of functionality,it provides
multiplexed request/response without HoL blocking. Much of the
implementation complexity needed for this is now handled by the QUIC layer.

QUIC handles a lot of complex bits now. The remaining mandatory complexity
in HTTP/3 comes from QPACK static table and huffman coding. Victor recently
asked the QUIC WG about the possibility of further simplifying things by
allowing these opt-in [1]. Negotiating these features has some gnarly race
conditions that could be hard to fix with the protocol toolkit we have
today. Group consensus was that the design strikes a fair balance between
broad optimization and complexity; future work might let us fix the
gnarlies, so the issue was punted to a future version.

Endpoints can opt-in to two additional, more-specialized, performance
optimization features, at the cost of additional complexity: QPACK dynamic
compression and server push. The spec spells out some of the constraints
and trade offs an implementation needs to think about but the instantiation
of these features is specific to an endpoint applying some decisions to the
connection properties. Importantly, these two features can interact with
the progressively-stateful QPACK compression context and getting that wrong
(desync) can lead to security problems. So it is important to know that the
receiving peer is happy to receive QPACK or server push signals before you
send them. The spec spends quite a few words to describe these features,
even though endpoints are under no obligation to implement them or use them
on any connection where they are enabled.

I can hypothesize that an implementation with QPACK dynamic support has
already crossed the threshold of complexity that means implementing
reprioritization is not burdensome. I'd like to hear from other
implementers if they agree or disagree with this.

I tend to think of reprioritization as a more-specialized optimization of
priorities. In this sense, it is similar to QPACK and server push. The
important difference though is that extensible priorities purposefully
minimizes the need for progressive state. Ignoring a priority signal is
going to be safe. It may have a non-neglibile effect on performance, but it
is time bound and recoverable within a connection. In contrast, desync of
the old tree-based priorities could lead to strange state with no way to
recover, which means there was a stronger mandate to either a) process
PRIORITY frames even if the endpoint just wanted to implement something
minimally complex, or b) just ignore most things to be safe.

For the above reasons, IMO extensible priorities on the whole is pretty
lightweight and dispensable. I think there is a valid argument to document
reprioritization alongside the core scheme, this is in-keeping with QPACK
and server push.

Cheers,
Lucas

[1] - https://github.com/quicwg/base-drafts/issues/3622