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

From: David Schinazi <[email-masked]>
Date: Thu, 20 May 2021 15:26:43 -0700

Hi everyone,

The chairs have heard interest in building a version of WebTransport
that works on networks that block QUIC. Additionally, the chairs think
the WG can work on such a protocol with lower priority than
WebTransport over HTTP/3 to avoid delaying that deliverable.

Because of this, in today's WebTransport interim meeting, we had
three consensus calls, and the chairs were able to determine
consensus in the room. The chairs would like to confirm the following
consensus on the list:

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.

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.

This consensus call (and adoption call) will run for two weeks until
2021-06-03. If you disagree with any of the consensus points, please
let us know by replying to this email. Please add information to explain
why you disagree.

Thanks,
David for the chairs

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 May 2021 17:06:46 -0700

I am in favor of adoption of draft-kinnear-webtransport-http2 and agree with the meeting consensus on points 1 and 2 as well.

> On May 20, 2021, at 3:27 PM, David Schinazi <[email-masked]> wrote:
> 
> 
> Hi everyone,
> 
> -- 
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 21 May 2021 11:37:19 +1000

As I was happily asleep for this conversation...

> draft-kinnear-webtransport-http2?

I have no qualms with the other items, but I have some questions about this.

Did the discussion address questions of functional difference between this design and the HTTP/3-based design?  The way that this works is subtly different in ways that are not limited to just the unavoidable differences (that is, reliability and ordered delivery).  To a large extent this is grounded in attempting to use HTTP/2 stream creation mechanics.

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.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 21 May 2021 12:06:27 -0400

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.

Thanks,
  Victor.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 24 May 2021 11:47:42 +1000

On Sat, May 22, 2021, at 02:06, Victor Vasiliev wrote:
> 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 
> 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.

---

From: Alan Frindell <[email-masked]>
Date: Tue, 25 May 2021 21:36:38 +0000

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: