[Webtransport] Measuring the friction of Http3Transport

[Lucas Pardue <[e-mail]>]

Hi folks,

To follow up on one thread of discussion during IETF 109. To over simplify
what we've heard a few folks say, they prefer QuicTransport because it
simpler and they don't need pooling.

I'd like to push more on this, what is the measurable complexity of HTTP/3
over QUIC plus a new application mapping that needs to be defined? Let's
isolate pooling as a variable and ignore it.

Victor mentioned his proposal for a unified header semantic across all
transports, this is
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/pull/4/files.
Taking a closer look at it, I have some concerns that I added as comments.
HTTP has semantics for a reason. If QuicTransport is going to start
borrowing HTTP piecemeal, I really wonder how simple people might feel it
is. I think it's important to avoid something that looks like HTTP but
behaves differently. Is it really much of a stretch to just do HTTP/3 but
give it a different ALPN so that we avoid problems related to
cross-protocol pooling?

Cheers,
Lucas