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

[Ian Swett <[e-mail]>]

Thanks David,

I was thinking of corporate networks with MITMs that inspect HTTP 1.1 in a
limited way, but it sounds like those may not be very common, so there's no
way to make WebTransport work anyway.

If so, making WebTransport HTTP/2 specific is fine with me.

I still think apps that want to work close to 100% of the time won't be
able to depend upon WebTransport always working, but maybe that's just the
state of the internet.

Ian

On Thu, Jun 3, 2021 at 12:28 PM David Schinazi <[e-mail]>
wrote:

> Can you provide an example of a network that would benefit from this scope
> increase? I've yet to see a network that MITMs TLS but allows all HTTP/1.1
> through unmodified. The ones that MITM and downgrade to h1 generally do it
> because they then inspect and/or modify the request and response, so
> getting something with WebTransport semantics to work there at all isn't
> guaranteed to be possible. Perhaps a good step forward is for us to build a
> version of WebTransport over h2 and then look at deployment data and
> feedback to decide if another version is needed.
>
> David
>
> On Thu, Jun 3, 2021 at 8:56 AM Ian Swett <[e-mail]> wrote:
>
>>
>>
>> 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
>>>>
>>>