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

[Ian Swett <[e-mail]>]

On Thu, Jun 3, 2021 at 11:38 AM David Schinazi <[e-mail]>
wrote:

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

I think there's evidence that those two sets of networks are very similar
today, and over time I expect the set of networks that block QUIC but don't
block HTTP/2 to be tiny(ie: <1%).

But I could be wrong.

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