On Mon, Jun 15, 2020 at 9:55 AM Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > > Am 11.06.2020 um 10:41 schrieb Kazuho Oku <kazuhooku@gmail.com>: > > > > That depends on how much clients would rely on reprioritization. Unlike > H2 priorities, Extensible Priority does not have inter-stream dependencies. > Therefore, losing *some* prioritization signals is less of an issue > compared to H2 priorities. > > > > Assuming that reprioritization is used mostly for refining the initial > priorities of a fraction of all the requests, I think there'd be benefit in > defining reprioritization as an optional feature. Though I can see some > might argue for not having reprioritization even as an optional feature > unless there is proof that it would be useful. > > > > We should decide if reprioritization is good or bad, based on as much > data as we can pull, and make sure it's implemented only if we see benefits > for it in some cases, and then make sure it's only used in those cases. > > When thinking about priority implementations, I recommend thinking about a > H3 reverse proxy in front of a legacy H1 server. Assume limited memory, > disk space and backend connections. > > (Re-)prioritization in H2 works well for flow control, among the streams > that have response data to send. Priorities can play a part in server > scheduling, but > it's more tricky. By "scheduling" I mean that the server has to pick one > among the opened streams for which it wants to compute a response for. This > is often impossible to re-prioritize afterwards (e.g. suicidal for a server > implementation). > Can you expand on why it is "suicidal"? > > If we would do H2 a second time, my idea would be to signal priorities in > the HTTP request in a connection header and use this in the H2 frame layer > to allocate DATA space on the downlink. Leave out changing priorities on a > request already started. Let the client use its window sizes if it feels > the need. > > Cheers, Stefan (lurking)
Received on Monday, 15 June 2020 08:29:07 UTC