- From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
- Date: Tue, 9 Jun 2020 15:41:46 -0400
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Bence Béky <bnc@chromium.org>, Kazuho Oku <kazuhooku@gmail.com>
On Tue, Jun 09, 2020 at 08:22:10PM +0100, Lucas Pardue wrote: > On Tue, Jun 9, 2020 at 3:44 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com> > wrote: > > > > I don't think we can judge either way. If Alice implements QPACK and > > Bob implement reprioritization, results will vary based on their level > > of competence. The degree of burden will also vary for each > > particular implementation. > > I agree that, all things considered, QPACK and prioritization are > dissimilar. However, this thread is specifically exploring the mechanics of > the reprioritization mechanism, which requires a signal received on one > stream (the control stream) to affect the send behaviour on another. There > is always a possibility of a race here. My conjecture is that the > priorities race ends up being is similar to QPACK'S (i.e. handling blocked > streams). And therefore if Alice implements QPACK dynamic support > competently, then implementing reprioritization is no more difficult. My point was that Alice may have no problem implementing repriotization, but Bob very well might! That is to say, there may be more than one person working on an HTTP/3 stack. After Bob gives up after three months leaving reprioritization a steaming pile of crap, Alice (who's grown to hate that fool) inherits Bob's code, but may not be able to make a good implementation given tight deadlines. Alice gets blamed; Bob gets promoted. The story gets sadder and sadder in my mind, so I better stop. > > Speaking for lsquic, reprioritization > > had to [1] touch more code and was much more tightly coupled than > > QPACK; on the other had, QPACK encoder logic was a lot more code. > > > > Thanks for sharing your experiences. If we take the scheduling aspects out > of consideration, the old HTTP/3 priority tree (+ placeholders etc) scheme > signals were pretty tough to implement. They were... that made it difficult to part with my implementation > I suspect that extensible > priorities' reprioritization would be relatively more simple. But it would > be interesting to hear from someone that implemented the old scheme > compared with the new one. I think so as well. I will resurrect this thread once we have reprioritization working and share my thoughts. - Dmitri.
Received on Tuesday, 9 June 2020 19:42:10 UTC