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

From: Ian Swett <[email-masked]>
Date: Thu, 3 Jun 2021 09:57:00 -0400

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=
[email-masked]> 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" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     On Sat, May 22, 2021, at 02:06, Victor Vasiliev wrote:
>     > On Thu, May 20, 2021 at 9:37 PM Martin Thomson <[email-masked]>
> 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
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/webtransport
>
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 3 Jun 2021 08:38:37 -0700

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=
[email-masked]> wrote:

> 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
>> 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.
>>
>>     > > 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.
>>     > >
>>     > aware of is unidirectional versus bidirectional reset, and last
>> time we
>>     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.
>>

---

From: Ian Swett <[email-masked]>
Date: Thu, 3 Jun 2021 11:56:14 -0400

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

> - We know there are networks that block QUIC and/or UDP, those will be
> well served by HTTP/2.

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.

>> 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.
>>
>>> 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.
>>>
>>>     > stream state machines that you are concerned about?  The only one
>>> I am
>>>     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.
>>>
>>>     --

---

From: David Schinazi <[email-masked]>
Date: Thu, 3 Jun 2021 09:28:24 -0700

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 <[email-masked]> wrote:

>> - 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 definitely agree with 1a, with the caveat that the TCP version is
>>> lower priority than the HTTP/3 version.
>>>
>>>> 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
>>>> 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
>>>>
>>>>     > Could you elaborate on the specific differences between HTTP/2
>>>> and QUIC
>>>>     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.
>>>>
>>>>     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.)
>>>>

---

From: Ian Swett <[email-masked]>
Date: Thu, 3 Jun 2021 12:40:32 -0400

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 <[email-masked]>
wrote:

>>> Can you elaborate on what use-case would be solved by having
>>> WebTransport support HTTP/1 ?
>>>>>     > On Thu, May 20, 2021 at 9:37 PM Martin Thomson <
>>>>> [email-masked]> 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.
>>>>>     > >
>>>>>     > stream state machines that you are concerned about?  The only
>>>>> one I am
>>>>>     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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 04 Jun 2021 08:25:16 +1000

One advantage of not using HTTP/2 streams directly is that you can ship something on top of HTTP/1.1.  And that might make deployment easier, not so much because implementing HTTP/1.1 is easier (that's what people believe, but there are enough traps for the unwary that it might not be a true win), but more because it makes the resource allocation story simpler if your WebTransport session takes up the entire connection.

I know that this is probably a little too flippant, but I don't see why we can't "just" drop the necessary QUIC frames into the request body.  STREAM, DATAGRAM, MAX_STREAM_DATA, MAX_DATA, and MAX_STREAMS might be sufficient.  Maybe PADDING and even PING.  It is not quite THAT trivial, as you need to engage with prioritization and some other nasty things, but it would still create a more portable and overall simpler design.

On Fri, Jun 4, 2021, at 02:40, Ian Swett 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.
> 
> 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 <[email-masked]> 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 11:38 AM David Schinazi <[email-masked]> 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=[email-masked]> 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=[email-masked]> 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" <[email-masked] on behalf of [email-masked]> wrote:
> >>>>> 
> >>>>>     > On Thu, May 20, 2021 at 9:37 PM Martin Thomson <[email-masked]> 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 
> >>>>>     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.
> >>>>> 
> >>>>>     --

---

From: Alan Frindell <[email-masked]>
Date: Fri, 4 Jun 2021 00:19:53 +0000

>    I know that this is probably a little too flippant, but I don't see why we can't "just" drop the necessary QUIC frames into the request body.  STREAM, DATAGRAM, MAX_STREAM_DATA, MAX_DATA, and MA…

+ RST_STREAM and STOP_SENDING.  

I don't disagree that's a workable design that doesn't need a lot of litigation, but I don't see how this won't result duplicating a lot of code to actually implement that design.  I think comparing prototype implementations of both designs could help illuminate the tradeoffs.

> One advantage of not using HTTP/2 streams directly is that you can ship something on top of HTTP/1.1.

This is definitely true, but we should understand if this is a real requirement that's going to get used before we factor it into our decision making.

-Alan