Re: [Webtransport] Measuring the friction of Http3Transport

Hi Luke,

On Mon, 16 Nov 2020, 12:26 Luke Curley, <kixelated@gmail.com> wrote:

> Just to clarify, when I say "QuicTransport is simpler" I really mean
> "QuicTransport has greater interoperability". You can take any QUIC
> implementation (+ datagram extension) and add a thin layer to support
> QuicTransport. It's a nice layering of protocols and it's something that I
> want to see in general as QUIC replaces TCP.
>

Thanks for the clarification. I appreciate the sentiment. But given the
development of QUIC its kind of surprising that people would find it easier
to identify an implementation that supports QUIC and datagram but does not
support HTTP/3.

Thr situation for a more clean-room implementation is different, I agree.
However, by the time you've done all the hard stuff with QUIC, a very
focused HTTP/3 layer ends up quite thin too. You can ignore dynamic
compression, server push and extensibility points.

I also see the current design being the thin end of the wedge. The proposal
I linked talks about HTTP-like header parsing. So its "just" a thin layer
to do some parsing. Then folks will probably want some want to tweak
parameter, acontrol channel, a way to do graceful close, a sprinkle of
GREASE. To extrapolate forward, what would be the delta be between some
final product QuicTransport and HTTP/3. Too small a delta and we've wasted
years of effort.

Cheers
Lucas

> On Mon, Nov 16, 2020 at 3:16 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> 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
>> --
>> Webtransport mailing list
>> Webtransport@ietf.org
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
>