Re: [quicwg/base-drafts] Unidirectional stream (some or) all the control things in HTTP/3 (#2678)

[Dmitri Tikhonov <[e-mail]>]

Stopping processing _PRIORITY_ frames has the effect of -- well, **stopping** processing _PRIORITY_ frames.  In other words, in addition to the presumed packet loss (discussed in #2502 as part of @rmarx original scenario), this approach effectively simulates even more packet loss.

Consider what happens when there are many existing streams that need to be reprioritized.  A loss of a possibly unrelated (different subtree) _STREAM_ packet would now cause delay in applying priorities of one or more RTTs.

Then there are the corner cases.  For example, what happens when the client decides to cancel the stream whose lost _STREAM_ packet caused the priority stream blockage?  Do we need a special _CANCELLED_STREAM_ instruction on the control stream that would allow the server to resume processing the priority stream?  If so, this would introduce even more dependencies between streams.

Similar to QPACK design, stream prioritization mechanism should minimize the number of stream interdependencies and potential for priority inversion.  The current (http-20) spec is not perfect, but it has the profitable feature of stream independence.  Combined with the guarantee of eventual consistency, it strikes a good balance between complexity and performance.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2678#issuecomment-490917885