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

[David Schinazi <[e-mail]>]

Hello everyone,

This consensus call is now concluded. The results are below:

Question 1: Do you believe that the WebTransport WG should start work
on a version of WebTransport that runs over TCP?
    1A: Yes, we should build this
    1B: No, we should not build this
The consensus was 1A.

Question 2: Do you believe that the version of WebTransport over TCP
should be over HTTP/2?
    2A: Yes, use HTTP/2
    2B: No, build a custom protocol over TLS/TCP
The consensus was 2A. The chairs note that this working group could
potentially also build a different version of WebTransport over TCP at
a later date if the need arises, but that would become the topic of a
separate discussion and consensus call.

Question 3: Do you believe that the WebTransport WG should adopt
draft-kinnear-webtransport-http2?
    3A: Yes, adopt
    3B: No, do not adopt
The consensus was 3A. The chairs note that there are some concerns
about how best to handle the differences between the HTTP/2 and
HTTP/3 stream state machines, however participants confirmed that
they were confident we could address those as a working group. The
document is adopted with the understanding that this topic will be
discussed very early on.

The chairs will work with the editors of that document to migrate it
to the working group GitHub organization, and will send details to
the list once that transition is complete.

Thanks,
David, for the chairs

On Fri, Jun 4, 2021 at 6:54 AM Ian Swett <[e-mail]> wrote:

> I've always thought QUIC over HTTP(or TCP) would be cool, but this is the
> first time I've heard a compelling use case.  Definitely worth considering.
>
> On Thu, Jun 3, 2021 at 2:17 PM Eric Kinnear <ekinnear=
> [e-mail]> wrote:
>
>> I think the question of HTTP/1.1 is an interesting one: we’ve so far
>> been operating with the view that falling back from QUIC to TLS/TCP might
>> enable significantly more folks to participate, but that the delta between
>> HTTP/1.1 and HTTP/2 would not be as significant.
>>
>> I don’t have massively strong opinions in terms of how we go about
>> addressing that, beyond the earlier concerns about additional effort
>> required to cover HTTP/1.1 vs. expected gain, but if the expected gain goes
>> up, then perhaps that changes things sufficiently.
>>
>> It seems that some of that thinking has come from the observations made
>> about _who_ is in control of the versioning; if your network operator does
>> not allow QUIC then that’s less under your control than whether HTTP/2 is
>> supported (although, as Ian mentioned, there’s a population with
>> middleboxes that force you down to HTTP/1.1, which might or might not
>> support CONNECT anyways).
>>
>> Would it be possible to gather some data about the relative size of these
>> different populations? I’m not sure there’s anyone in a great position to
>> do that, at least for CONNECT specifically if it’s not already
>> possible/in-use, but perhaps data about other H1 vs. H2 vs. H3 usage would
>> be interesting.
>>
>
> Google has server-side data of "For people in an HTTP/3 enabled group,
> what fraction of people end up using HTTP/3, HTTP/2, and HTTP/1" and we can
> breakdown by OS/etc.  I'm happy to share but I'd need approvals, so if I
> know exactly what data people would like to see, I can ensure it's all
> approved at once(ie: a single slide deck).
>
> This seems like a fun topic for maprg, but I'm not sure it's worth waiting
> that long?
>
> It would be ideal if different people could share their data, since any
> single set of users may not be completely representative(ie: one could
> block a set of domains entirely, so none of the protocols worked).
>
>
>>
>> We know that, at least on iOS, HTTP/2 is in use in a higher percentage
>> for web browsing use cases than for other application use cases.
>>
>> On Jun 3, 2021, at 12:41 PM, Ian Swett <ianswett=
>> [e-mail]> wrote:
>>
>> 
>> 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.
>>>>>>>
>>>>>>
>> This sounds about right to me, if we think that the mapping of H3 onto H2
>> is not how we’d want it to be, we’ve evolved it significantly so far, and I
>> don’t see any reason why we can’t continue to do so.
>>
>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>> I’d agree, I support adoption (as an author), and with that I’d very much
>> like to sit down and make sure we’re covering Martin’s feedback here — I
>> know parts of it were also raised at 110 prior to the interim and we
>> haven’t all synced up to make sure it’s sorted out. That might result in
>> minor changes to the document, it might result in major changes to the
>> document — either is fine from my perspective.
>>
>> Thanks,
>> Eric
>>
>>
>>
>>>>>>> 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
>>>>>>
>>>>> --
>> Webtransport mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
>>