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

[Ian Swett <[e-mail]>]

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
>