- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 9 Jun 2020 15:15:44 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Bence Béky <bnc@chromium.org>, Kazuho Oku <kazuhooku@gmail.com>
- Message-ID: <CALGR9oZgE7ZfXdoYdUh9LUYC1fi8fMUyyTpvmV3GF7Z6Oxgg1g@mail.gmail.com>
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
Received on Tuesday, 9 June 2020 14:16:10 UTC