Minutes interim-2021-webtrans-02: Thu 09:30
minutes-interim-2021-webtrans-02-202105200930-03

WEBTRANS WG
Virtual Interim Meeting Agenda

Thursday, May 20, 2021
09:30 - 11:00 AM Pacific Time

Google Meet URL: https://meet.google.com/eur-udvp-bsn
Sides:
https://docs.google.com/presentation/d/1FtDsHKC5gCZPUjDbLX2dDsj5syGwlVu5zW_u1jsLbFk/
CodiMD (Meeting Minutes & Virtual Bluesheets):
https://codimd.ietf.org/notes-ietf-interim-2021-webtrans-02-webtrans

Chairs: Bernard Aboba and David Schinazi

9:30 AM Preliminaries, Chairs (15 minutes)
Note Well
Virtual Bluesheets
Jabber Scribe, Etherpad Note Takers
Speaking Queue Manager (David Schinazi)
Agenda Bash

W3C WebTransport Update, Will Law

Will: We’ve now progressed our public draft as of May 4 to be the first
official WG draft status. This kicks off an IPR process on the W3C side, moving
down the road to a published spec, likely within the time window we anticipated.

Some questions on the W3C side, issues listed on the slide.

Connection throttling to avoid DDoS. Should there be language that we mandate
some mechanism to introduce limits?

Some clarification on stats. Some language that all protocols should provide
client with available bandwidth estimates. Does this apply to pooled clients?
Will RTT be available?

Issue raised by Lucas around WebTransport and Alt-Svc. W3C issue and was
requested to return to IETF, opened #47 on IETF GitHub.

Google is signalling intent to ship WebTransport in Chrome, very exciting.

9:45 AM WebTransport over HTTP/3, Victor Vasiliev (30 minutes)

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3

Victor: We just published -01 for WebTransport over HTTP/3 this week, reflects
consensus at the March IETF 110.

Two biggest changes, whenever we receive a WebTransport data stream before we
get a connect stream, we are allowed and recommended to buffer it for some
period of time. This allows both client and server to send those streams in
parallel to the connect stream.

Second, we defined server-initiated bidi streams to match the ones from the
client side, so the design is the same in both directions now.

Had some other editorial fixes too.

This draft is exciting because I’ve implemented it, shipping Chrome Origin
Trial in the next few weeks, currently in beta. Mostly ships draft-01, some
things are somewhat undefined like error codes and other details around error
handling. Ships dedicated HTTP/3 connections, no pooling support, every
WebTransport object results in a connection. Datagrams are specifically
implemented with the H3 datagrams as they were in January, those are the ones
with the idea of an associated stream but without any context. Flow ID combined
with Datagram Flow ID header where that is an integer. We are waiting for H3
datagram draft to stabilize so we can upgrade to a new version, expecting that
to happen mid-trial, we will ship the new version and un-ship the old before
the trial is over.

If the trial is successful, we expect to actually ship this as API pending
discussion in W3C, this doesn’t mean all that much within the IETF because we
shipped QUIC 6 or more years before it was done, we can upgrade protocols.
Notably, this will still commit us to some level of semantics, for example it
will have to have bidirectional streams. If we ship them, we can’t really
unship them.

This means that we’ll need to do more work on the overview draft, but I don’t
have slides for it and I don’t think there’s anything interesting to discuss,
just needs to reflect reality.

Issues

Issue 39

Victor: If we want to use settings for versioning, then we need to wait so we
know what version to use. Proposing that we should wait for settings, I don’t
see how we can get out of it.

Alan Frindell: It’s annoying to wait for settings and have to buffer things. I
guess we already have to buffer things for streams, it’s annoying, but I agree
we’ll lose the ability to version if we don’t.

Victor: Fwiw, I just buffer all streams and don’t read anything until we get
settings in the implementation. I know Ian was really unhappy about that.

Alan: You can also cheat until Version 2 comes out.

Victor: Good point.

Jonathan Lennox: Do you anticipate having some limits on buffering to avoid
DDos?

Victor: We will need some text, we don’t have any right now, we picked some
values in the implementation because you definitely need something.

Lucas Pardue: I may be missing something, what the server receives should be
compliant with what it sent. If it sent something declaring what it needed, why
would it wait to process the request.

Victor: There are two aspects, imagine I support two versions, v1, v2, I only
advertise both but the client only supports v1, then my processing might differ
based on which version we use.

Lucas: Could we just put the version in the protocol string so that we don’t
have to deal with it.

Victor: In theory, yes, but I already have one issue which would require a
breaking change.

Lucas: I think I need to think some more, how would a client know what version
to send stuff with.

Victor: You have versions supported and you take the max of both.

David: So from the client perspective, I think the client can’t send the
connect request until it has received and parsed the server settings, you just
wait and don’t need to buffer. On the server side it’s harder to handle because
you have to buffer. Lucas’s proposal, which Marten Seemann is supporting in the
chat, would solve that right?

Victor: Yes, but you need to put the version of HTTP/3 datagram in there as
well.

David: Oh, I see, yeah we really didn’t get that part of HTTP/3 right.

Victor: If you think ALPS is real and will happen, then ALPS guarantees you’ll
have it up front and it’s all good. I’m not sure how much buffering is a
problem in practice. I know Ian said he had concerns, not only from a
performance perspective, but also from the perspective to get this wrong. I
don’t believe it is likely, because eventually flow control will kick in, and
if you’re not reading from the streams before you get settings there’s not much
you can do. It sounds like we’re in agreement that we have to buffer it for
now. Any objections?

Issue 40

Victor: This is for resetting data streams, not connect streams. We discussed
this at the last interim, then at W3C, where we agreed that 256 error codes
should be roughly enough. There should be a more detailed description of what
was agreed in the minutes. We changed the API to accept UInt8 as a reason code.
We wanted it to be as widely compatible as possible and HTTP/2 reason code
error space is fairly small, we cannot take the entire space because then
untrusted JS can send semantically meaningful reset stream codes. We can
reserve some small sub-space and say those are all WebTransport reset stream
codes. There is a small problem with HTTP/3 in which it does not have any
contiguous error code spaces since we reserved all 0x1f codepoints for grease,
we’ll have to un-grease and re-grease unless someone has a better proposal.

Mike Bishop: Just pointing out that there’s a draft to grease in HTTP/2 as
well, so you’re likely to hit the same issue there. I don’t have a great answer
than working around it or pre-reserving the ones that overlap your code space.

David: Just reiterating something I said at W3C, having an encoding that maps
around them, if you have some grease points in the middle, just having the
range not be contiguous isn’t super elegant but it’s an easy way to work around
this, I’d suggest doing that and moving on.

Victor: It sounds like we have agreement to just do that and move on, unless
anyone objects I will reflect that in the draft.

Issue 41

Victor: Previously we were looking at individual stream error codes, this is
for sessions. The goal is to provide a mechanism that is similar in utility to
what Connection Close does in QUIC. Code and string both, string has been super
useful for debugging production issues. Multiple ideas for how to implement
this, option 1 is to just use RST_STREAM. This has a problem where you can’t
embed the code numbers, and those are not end-to-end and there is nothing in
HTTP/3 that guarantees propagation across intermediaries. There is no error
message and no error code, so RST_STREAM doesn’t really work.

Alternatives, HTTP trailers, would need a field for code and string, works
across intermediaries. Issues there, one of which is that trailers aren’t
defined in CONNECT and we’d need to define for Extended CONNECT.

Third alternative, not in the slides, current version of H3 datagram draft
defines a “capsule” and we might want to do that. The reason I’d lean towards
something like that as a more flexible option is that we already need some form
of control metadata for something like session go away. That would be the
option that I would be leaning most towards right now.

Lucas: I think the capsule option sounds okay, I appreciate it’s fresh and I’d
like to see some proposal there, but I can imagine it in my head. That seems
better than defining yet another extension frame specific for this purpose.

Alan: Follow up to Lucas - assuming that capsule is going to be a thing, how
does one decide when to add an extension frame versus using something inside a
capsule. What’s the guidance there?

Victor: Capsule is end-to-end and extension frames are default hop-by-hop
unless defined otherwise.

David: Exactly that, whole reason for existing is that intermediaries forward
them end to end along the same path, HTTP/3 extension frames are always
hop-by-hop unless you want to specifically add semantics. Seems like capsules
are extensible enough to just use them for everything.

Alan: I think that works better for this use case of an error code and a
reason. But the stream IDs are hop-by-hop, so something like GOAWAY can’t be in
a capsule because intermediaries might need to rewrite stream IDs.

David: If you have end to end stream ID space then you’re good, but you’re
right that you can’t use the hop by hop stream IDs in a capsule.

Victor: It sounds like we have general agreement to use capsule if it becomes a
real thing, we’ll need to see what will happen at the next masque meeting.

Lucas: New capsule background appears

Issue 42

Victor: Spec requires 200, CONNECT is any 2xx. Proposal is to switch
WebTransport to also do that to be consistent with how CONNECT is defined.

silence

Victor: Sounds like no opinions or objections, sounds like we have consensus
for issue 42.

Issue 47

Victor: How does Alt-Svc interact with WebTransport? Makes sense to assume that
server implements HTTP/3 from scratch so doing TCP and then doing HTTP/3 on the
second attempt doesn’t make sense. Does Alt-Svc have a place, does it affect
pooled vs. dedicated connections. Lucas filed the issue, any comments?

Lucas: As some background, it came into my head during the Singapore (BoF?),
raised in W3C at the time because that was the only place and moved to IETF
since it seems like an IETF thing, but I think some of it has been answered by
our choice to pick HTTP/3 transport. An issue more for pooling and coalescing,
maybe we should keep it around as we get some more deployment experience. The
example for URL in WebTransport to open the thing, that implies that you know
it’ll do HTTP/3 – you don’t need to fall back to Alt-Svc or anything like that.

David: I think this ties into a few other conversations that we need to have,
some of which are on the agenda for later in this meeting. Do we want to run a
version of WebTransport over TCP. Perhaps we keep this open until we have more
clarity on those. In a world where you can do both HTTP/3 and HTTP/2, if the JS
has a way to say “no I want H3” then you can just assume if you haven’t seen
Alt-Svc. Then we can decide if we want to mandate something or give
clients/browsers some more leeway.

Victor: Agree with David, let’s hold for later.

Issue 48

Victor: Alan do you want to explain your proposal?

Alan: Yeah. Current unidirectional streaming works where you send the type that
indicates it will be WT uni stream, that defines the contents of the stream
from then on, there’s a varint session ID and as soon as you parse that it
converts to unframed. I found this cumbersome to implement since it’s different
from other streams since they all have at least one frame on them (except maybe
qpack), you can do something that defines a single frame and then you define it
as a TV frame. Adds one more byte, you have stream type, then frame type, then
maybe converts to unframed.

Victor: Seems clear, no objection but we need to decide what to call that
stream type, do we just call it WT uni stream?

Alan: Yeah I guess it’s redundant, this came out as part of the discussion that
a stream type followed by frames allows us to insert other frames in between
the two at some point in the future.

Victor: Priority could be one of those, I could imagine.

Alan: Could be a sensitive topic for some people but yeah, something like that.

Victor: Any objections? None, okay we have consensus to change it.

Questions

David: Before we move on, I was going to ask if anyone has questions for Victor?

Alan: Looked in the repo, there are a bunch more issues that we didn’t discuss.
What’s the plan?

Victor: The reason I didn’t put most of those is: (1) there were a bunch that
are editorial, (2) some of them looked like we discussed last time but no new
proposals, nothing to do to move forwards, and (3) I forgot

Lucas: As a co-author on H3 datagram, I’m keen to play with prototype of that,
I did some work to see how hard it would be, but I have no interest in
supporting old and new at the same time. It makes some of that a bit tricky,
what’s the timeline on moving to the new H3 datagram. No answer is fine, but
something for the next IETF, I’d like to understand what the roadmap would be.

Victor: Personal intuition, we want to wait for the draft to stabilize a bit, I
don’t want to implement old, new, and the final datagram and ship them all as
an experiemnt. Most likely, I hope we’ll reach some form of consensus in the
upcoming masque meeting, after which we can likely implement and ship in the
Origin trial.

David: I’d say we could move more quickly, latest version of H3 datagram has
capsules and changes settings, those are the main changes, I’d say you could
start relying on that in WebTransport from now on. Something something masque
enthusiasm. Hoping to publish something that we can get more experince with it.
Want to avoid pain.

10:15 AM WebTransport using HTTP/2, Eric Kinnear (20 minutes)

https://datatracker.ietf.org/doc/html/draft-kinnear-webtransport-http2

Eric: Continuation of conversation at IETF 110. WebTransport over HTTP/2 is a
protcol for times when HTTP/3 is not available; as mentioned at 110, Chrome
sees QUIC unavailable in over 5% of cases. Agreed at the last meeting that we
should have a fallback.

Our choices: failure, bring-your-own-fallback, WebTransport over HTTP/2. HTTP/2
does not preclude you from bringing your own fallback.

Overview draft has a list of things that you are required to have, as well as
allowing you to require or prohibit specific features. We looked through the
draft, and we can provide all of the mandatory requirements over HTTP/2. We may
not always provide all optional features; e.g. datagrams are provided, but are
not always unreliable. Works fine by default, but in latency-sensitive or
bring-your-own-fallback cases, user can fail instead of getting HTTP/2.

[three principles from the slides explained here]

Questions

Lucas: not a question, observation. Someone who supports both HTTP/3 and
HTTP/2, extending HTTP/2 is harder than HTTP/3 because of technical assumptions
and it would take a lot of effort to fit it into existing ecosystem.

Eric: this makes a lot of sense. We tried to put in new frames that are as
self-contained as possible.

Dragana: how do you define fallback in terms of the API, and how do you define
datagrams?

Eric: we’re still figuring this out. One of the options is to let application
wait until ready state and then check a property on the object.

Jonathan: looking at the layering, in HTTP/3, we have datagram draft, and then
there’s WebTransport. Is this an issue for consumers who don’t support QUIC?

Eric: one of the issues we discussed before in httpbis, what do we do when
datagrams or other HTTP/3-only features? We don’t intend to answer that in
general.

David: as a co-author of HTTP datagram draft, we intend to extend it from
HTTP/3 to other HTTP versions.

Bernard: as a follow-up, the API issue here is secondary to decision to ship
HTTP/2 or not.

Victor: the amount of cases where QUIC is blocked is very context-specific, for
example in enterprise it is much higher

Eric: this means that for a given user, they might be always blocked as opposed
to everyone blocked some of the time

Bernard: if you have the wrong firewall you can't use QUIC

Lucas: in response to my earlier point, using capsule will make WebTransport
over h2 easier to implement. Also, firewalls are hard to deal with so when they
are present a fallback is necessary.

Alan: two parts. One, David says capsule is coming to H2 as an extension frame.

David: yes, I’ve not written this up or discussed in MASQUE, but it’s the
easiest approach. Another aspect is that there’s a datagram capsule to send
datagrams on stream data, which would allow you to send datagrams over H2.

Alan: WebTransport over HTTP/2 is very flexible in terms of specific details,
we just want it to exist. Another point is that there are non-Web use cases
(like DC) where TCP is used over QUIC.

Eric: to that point, if capsule is coming to HTTP/2, using it as a point for
WebTransport makes sense.

Jan-Ivar: as a clarification, at W3C we were discussing an attribute, we
weren’t contemplating constructor arguments. Is the assumption that server
always speaks H3, and only middleboxes block it?

Eric: I think we don’t want to preclude H2-only connections.

Victor: We were able to update some HTTP/2 implementation with some extensions
as long as it uses SETTINGS, wasn’t that big of a deal.

Lucas: I hit a separate issue with a broken HTTP/2 implementation the other day
and it was a pain there, especially because I don’t own that stack.

10:35 AM Hums, Wrap up and Summary, Chairs & ADs (25 minutes)

David: Based on this great discussion, there is interest in WebTransport over
TCP so we're going to ask some hums to get a sense of the room. We'll confirm
consensus on list.

Question 0: Which of these two flavors of ice cream do you prefer?

0A: Vanilla - 7

0B: Chocolate - 7

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 - 10

1B: No, we should not build this - 0

Question 2: Do you believe that the version of WebTransport over TCP should be
over HTTP/2?

2A: Yes, use HTTP/2 - 9

2B: No, build a custom protocol over TLS/TCP - 2

Chairs asked people who responded 2B to discuss why they preferred this option
and no one said anything.

Question 3: Do you believe that the WebTransport WG should adopt
draft-kinnear-webtransport-http2?

3A: Yes, adopt - 8

3B: No, do not adopt - 0

Closing comments

David, Bernard: Will follow up on the list to confirm consensus. Encourage
folks to go to GitHub and comment on the issues.