Re: [Webtransport] Measuring the friction of Http3Transport

We're on the same page that there's code in HTTP/3 that could be leveraged
for QuicTransport in the form of the header parsing. I think there's a path
to merge QuicTransport and Http3Transport by leveraging HTTP/3 for the
handshake and QUIC for stream delivery.

My primary concern is that Http3Transport requires non-generic
modifications to the HTTP/3 layer mostly to support connection pooling. I'm
worried that this will limit support for Http3Transport and complicates any
HTTP/3 implementation that does support it.

On Mon, Nov 16, 2020 at 4:49 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> 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
>>>
>>