Re: [Moq] Warp

[Lucas Pardue <[e-mail]>]

Hey,

Thanks for publishing Luke, it's been a good conversation catalyst.

On Tue, 15 Feb 2022, 06:23 Luke Curley, <[e-mail]> wrote:

> Hey Mo,
>
> Absolutely!
>
> Twitch is using QUIC (actually WebTransport) instead of HTTP/3 just to
> avoid some extra headaches caused by HTTP semantics. I'm not sure which
> approach is easier to standardize, but we should take it!
>
> At one point I started a draft called DASH-WARP but I'll be honest, I
> didn't want to learn the DASH terminology. I'm also not a fan of how
> divergent contribution and distribution protocols have become. This is a
> good opportunity to reevaluate why we currently need a separate protocol
> for both use cases. I like your idea of flipping the HTTP verb while
> keeping everything else the same. You'll notice that I used the terms
> "sender" and "receiver" instead of "server" and "client" in the Warp draft
> for the very same reason.
>
> As for why this hasn't been done before; no clue, and maybe it has. I
> really only stumbled upon the idea thanks to the recent efforts to actually
> eliminate head-of-line blocking in HTTP.
>

I could speculate that part of the reason such an approach wasn't done
before was the absence of conmon APIs and/or absence of standard
intermediary-to-origin and origin-to-intermediary signalling.

For APIs, I mean, an ability for clients to control the value of a priority
signal; an ability for server applications to control how servers actually
schedule.

For signalling, I mean a way to talk about the priority of the
client-to-intermediary connection properties outside of the actual
connection.

RFC 7540 priority signals (the first incarnation of HTTP/2 signals) support
the notion of signalling strict priority order where newer streams are more
important. As suggested in Warp. It just wasn't really exposed very well to
let people use it.  For example, trying to do so using Fetch. So even if
there was a full end-to-end H2 chain across intermediaries (e.g. low
latency HLS) it would be difficult to have explicit control over the
sending of response data to clients.

As Mo suggested, Extensible Priorities [1] addresses some of these
challenges, especially where there are multiple hops that might support
different HTTP versions or where APIs are version agnostic (Fetch).
However, out of the box Extensible Prioirites suggests serving data of the
same importance in the order it was requested. There's ways to do the
reverse; Luke and I have talked previously about different possible
methods. I'm confident that we could find an answer with enough discussion,
design and implementation experience.

All that said, I'm not overwhelmingly convinced that HTTP has to be used.
It introduces the potential for problems where an intermediary shards or
coalesces requests over different connections and ordering is affected. In
contrast, WebTransport stands a better chance of keeping streams bound to
the connection, aiding strict ordering. It also has a web-accessible API,
avoiding problems with going native QUIC.

Cheers
Lucas

[1] https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/