Re: [Webtransport] Measuring the friction of Http3Transport

On Mon, Nov 16, 2020 at 11:34 AM Luke Curley <kixelated@gmail.com> wrote:

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

Hi Luke,

I'm curious, could you elaborate on what these "non-generic modifications
to the HTTP/3 layer" are please?

Thanks,
David

> 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
>>>>
>>> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>