Re: [Webtransport] Confirming consensus calls from today's WebTransport interim

[David Schinazi <[e-mail]>]

Hi Ian,

Can you elaborate on what use-case would be solved by having WebTransport
support HTTP/1 ?
- We know there are networks that block QUIC and/or UDP, those will be well
served by HTTP/2.
- We know there are networks that MITM TLS then force a transparent HTTP/1
proxy, those won't allow CONNECT nor any other form of WebTransport anyway.
I'm failing to see a use-case where WebTransport over HTTP/1 would be
useful. Can you provide an example?

Thanks,
David

On Thu, Jun 3, 2021 at 6:57 AM Ian Swett <ianswett=
[e-mail]> wrote:

> I definitely agree with 1a, with the caveat that the TCP version is lower
> priority than the HTTP/3 version.
>
> I'm slightly less concerned about the stream state machine than Martin,
> but I think it's definitely a real concern and I think it makes sense to
> have a solution fairly well fleshed out before adopting the direction and
> document.
>
> I'm slightly more concerned about creating a TCP fallback that doesn't
> work over HTTP/1.  If we're building a fallback, it seems like these people
> shouldn't be excluded, since that means developers will have to build and
> maintain a 3rd fallback that's not WebTransport based.  If the dream is to
> be able to develop apps for WebTransport and not have a non-WebTransport
> fallback, I don't see how we accomplish that without an option over HTTP/1?
>
> Possibly this is a forcing function to convince customers to upgrade their
> middleboxes to ones which support HTTP/2 and HTTP/3, but if so I'd like to
> call that out explicitly.
>
> Or maybe the physical office with its corp middleboxes is dead and my
> concern is an unfounded anachronism?
>
> Ian
>
> On Tue, May 25, 2021 at 5:36 PM Alan Frindell <afrind=
> [e-mail]> wrote:
>
>> I think the fundamental discussion here is about whether we want to
>> modify/extend the HTTP/2 state machine to handle WebTransport streams, or
>> whether we should build an entirely separate stream state machine for them,
>> and leave the H2 machinery untouched.
>>
>> Martin may be right that there be dragons down the path of modifying the
>> H2 state machine.  The alternative strikes me as an awful lot of
>> duplication -- it's close to implementing H2 again over a single HTTP
>> stream, minus header processing.  That said, I think either approach can be
>> made to work, we just need to choose the tradeoffs we want.
>>
>> I am remiss in not addressing the feedback regarding unidirectional
>> stream resets.  I think that it got lost during the bizarre hours of the
>> last IETF.  I filed an issue in the draft repo to track it (
>> https://github.com/ekinnear/draft-webtransport-http2/issues/17).  I
>> think the right solution is to keep the unidirectional reset functionality,
>> and implement it in the H2 draft using either new frames or messages,
>> depending on the direction we take regarding the state machine.
>>
>> During the interim, we expressed our flexibility to adapt the design here
>> as the H3 design evolves (eg: stream limits), new tools become available
>> (eg: CAPSULE) and as we gather implementation experience.
>>
>> While I think it is important we address this design decision as soon as
>> possible, I don't know that it needs to block adoption.
>>
>> Thanks
>>
>> -Alan
>>
>> On 5/23/21, 6:48 PM, "Webtransport on behalf of Martin Thomson" <
>> [e-mail] on behalf of [e-mail]> wrote:
>>
>>     On Sat, May 22, 2021, at 02:06, Victor Vasiliev wrote:
>>     > On Thu, May 20, 2021 at 9:37 PM Martin Thomson <[e-mail]>
>> wrote:
>>     > > I'm opposed to adoption of this document.  I don't believe that
>> it can be made so due to some fundamental differences in how HTTP/2 and
>> QUIC stream states.
>>     > >
>>     > > If this problem was acknowledged, then I have every confidence
>> that the people listed as authors are able to find a solution.  But
>> generally adoption is about the document more than the people.  Adoption
>> means agreeing that the document contains approximately the right shape for
>> a solution.  I can't agree with that in this case.
>>     >
>>     > Hi Martin,
>>     >
>>     > Could you elaborate on the specific differences between HTTP/2 and
>> QUIC
>>     > stream state machines that you are concerned about?  The only one I
>> am
>>     > aware of is unidirectional versus bidirectional reset, and last
>> time we
>>     > discussed this, the easiest solution was to make HTTP/3 behave like
>>     > HTTP/2, which would mean there's nothing HTTP/2 draft would do to
>>     > address that.
>>
>>     That's the one I'm most concerned about, but there is also the whole
>> mess around inventing semantics for unidirectional streams that needs to be
>> worked into the state machines.
>>
>>     For reset, sure, you could make the HTTP/3 draft worse to deal with
>> the problem.  Why would you want that?  QUIC has a much better set of
>> semantics here than HTTP/2.
>>
>>     There is also the stream state management disconnect for
>> server-initiated streams, which currently is only used for server push.
>> The draft currently doesn't say anywhere near as much as it would need to
>> in order to specify that part.
>>
>>     And managing allocation of stream limits is a little scant on detail
>> in the same way.  I thought we wanted independent limits, which means
>> defining new accounting systems.  (Yes, this is a criticism of the HTTP/3
>> draft also, but the additional effort required to use QUIC streams is
>> entirely justified in that case, because you are getting something in
>> exchange.)
>>
>>     Why bother with all of that when you can just import QUIC frame
>> semantics and then serialize them on the same stream?
>>
>>     Yes, this all boils down to a fairly central question: do we build
>> the same thing for HTTP/2 and HTTP/3?  I'm not sure that we want that.  We
>> need to do a whole bunch of stuff to use QUIC (BTW, Roberto gets to say
>> "told you so" again here), but doing that same work for HTTP/2 doesn't make
>> sense unless the changes are minimal.  I'm suggesting that the changes
>> aren't as minimal as the rough sketches of protocols we have might imply.
>>
>>     If you conclude that there are more functions needed, as I have done,
>> then you might also conclude that building those same functions into two
>> different protocols is not desirable, especially when there are no benefits
>> to doing so for one of those protocols.
>>
>>     --
>>     Webtransport mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/webtransport
>>
>> --
>> Webtransport mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>