[Webtransport] Minutes of the IETF 113 WEBTRANS Meeting

[Bernard Aboba <[e-mail]>]

Here are the minutes from the IETF 113 WEBTRANS WG Meeting. Kudos to Marten
for the notes.

IETF 113 WEBTRANS WG Agenda
Thursday, March 24, 2002
Session II, Grand Klimt Hall 2
13:30 - 15:30 UTC
09:30 - 11:30 US/Eastern Time

Chairs: Bernard Aboba and David Schinazi
------

IETF 113 info: https://www.ietf.org/how/meetings/113/
Meeting URL: https://wws.conf.meetecho.com/conference/?group=webtrans
Notes: https://notes.ietf.org/notes-ietf113-webtrans
Slides:
https://docs.google.com/presentation/d/1ZnQJSJEwCtqg6JP-Rdd31BF06YbWpS-g9yQFzHgMPBI/

1. Preliminaries, Chairs (10 minutes)
Note Well, Jabber Scribe, Note Takers (Marten & Bernard)
Speaking Queue Manager
Agenda Bash

2. W3C WebTransport Update, Will Law (5 minutes)
Will: Good morning from California!
Progress since Nov. 9: Now a Working Draft (latest is March 11, 2022)
Main blocker: Need two independent implementations. Chrome has been in
production since M97, but Firefox not ready yet. So July 31, 2022 seems
optimistic for PR.
Martin Thomson said in chat:
“you aren’t going to get anything better from us on dates, sorry
I think that we just got writable streams finalized, so we’re in
a reasonable shape, but a small team with shifting priorities
makes it hard to commit to a date”
Progress on stats.
Work in progress on fallback, datagram priority, CSP.
In debate: stream stats, connection pooling, priority between streams
Marten: Do you need two implementations of every feature?
Will: No. Basic functionality is sufficient. Chrome has already shipped
without full feature set support.
Alan: With respect to priority, like HTTP scheme. Finding a way to adapt
that would be good. Would we add signaling to the wire protocol, so browser
could set priority on streams server is sending? Or only allow browser to
set priority on streams it is sending?
Victor: ?
Martin: Agree with Victor. Application can do signaling over Webtransport.
Extensible prioritization scheme scares me. ??

3. WebTransport over HTTP/3, Victor Vasiliev (45 minutes)
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3
Victor: I am editor of overview and HTTP/3 draft (implemented in Chromium,
interops with non-Google servers). Still lots of unresolved issue, esp. in
overview draft.
Wrote up a PR to add discussion of HTTP/3 and HTTP/2 in the overview draft.
Encourage everyone to take a look at the PR.

Some unresolved issues: do we need a draining mechanism for sessions?
Reason why this is needed in protocol vs. application: the GOAWAY can be
sent by endpoints *and* by intermediates / proxies. Proposal: add Capsule
that can be inserted by everyone.

Action item: Alan to do a PR.

Issue 67: in HTTP GOAWAY means that old requests can finish, but no new
requests. For WebTransport currently not defined. Does this only mean that
no new WebTransport sessions should be created, or should new streams be
forbidden as well.

Alan: in HTTP/2 streams are not visible to the transport layer, so a GOAWAY
would have no semantics. Therefore: no new sessions, but new streams on
existing sessions are fine.

Victor: Agreed.

Issue 33: Current behavior: when CONNECT stream closes, everything in the
session is closed, datagrams rejected etc. Alan suggested that we might
want to keep internal streams open. With more impl. experience: closing
everything is easier with respect to resource management / lifecycle. Also
this mirrors more closely what would happen on HTTP/2.

Eric: Agrees. This is kind of an implicit GOAWAY. Better to keep the
control stream around, because how else would you send control messages.

Magnus: ?

Victor: Closing in any direction kills the session. Similar to
CONNECTION_CLOSE in QUIC.

Magnus: This depends on what the application protocol needs.

Victor: Higher level application doesn't need to necessarily care if it's a
pooled connection. Just one session disappeared.

mt: In HTTP/2 closing the request stream prevents you from sending (and
receiving (?)) any data. So everything is effectively orphaned at that
point.

David: speaks as MASQUE enthusiast. When the CONNECT stream is closed, you
can't send any more datagrams. So closing should mean that you're done.

Victor: We all agree that closing the request stream closes the session.

Magnus: If you send all the data and then you hit close, is there the risk
that the close arrives before the data.

David: CLOSE_SESSION capsule is what you'd do. ?

Victor: 3 ways: sending CLOSE_SESSION Capsule with status code. You can
close the stream, and you can reset the stream.

In QUIC, when you close the data, you don't care about the connection any
more (other than retransmitting the CONNECTION_CLOSE).

Next Issue: Issue 47 Alt-Svc. Currently WebTransport doesn't do anything
with alt-svc header. There are 2 modes in which WebTransport can operate.
It can operate in pooled mode or with a dedicated connection. We have to do
it (?) for both. Does this even belong in the IETF draft, or W3C?

mt: Easy part is alt-svc in your response. ???? There's something going on
in the HTTP WG, let them sort it out.

Victor: So let's just close this issue.

mt: Agreed.

Eric: Pooling: More than one WebTransport Session per HTTP/3 connection.
Not an issue in H2, as each session is fully encapsulated in one connect
stream. In H3, WebTransport should also coexist with regular H3 requests.
There are different native H3 streams serving different purposes for this
WebTransport session. Multiple sessions will use multiple streams.
Proposal to provide resource limits, and don't do anything else. Proposal:
we need to keep any WebTransport session to starve others from resources.
Be careful not to preclude any future improvements to this.
Resource limits: flow control inherited from QUIC. Remaining: maximum
number of sessions, number of streams per session.
Currently: we don't provide any limit on the number of WebTransport
sessions. 2 ways to do this: HTTP_REQUEST_REJECTED or 429. We could say
that this is sufficient, or we could take it further with little added
complexity.
Proposal: replace SETTINGS_ENABLE_WEBTRANSPORT with
SETTINGS_WEBTRANSPORT_MAX_SESSIONS. 1 = no pooling, >1 = more sessions
allowed
Flow control details: limit total session count (as talked about), limit
number of streams within the session, session-level flow control,
stream-level flow control
In QUIC we have MAX_* frames for that. WebTransport uses native QUIC
streams, so we don't need to do anything for stream flow control. Total
session count is solved with SETTINGS_WEBTRANSPORT_MAX_SESSIONS.
So we only need to deal with streams within a session, and session flow
control.
WT_MAX_STREAMS and WT_MAX_DATA capsules could solve this.
In H2 there's a proposal to do the same.
Marten: Having connection level control on the WebTransport level seems
like a layer violation. But maybe QUIC is all about layer violations...
Eric: Have an aversion to keeping track of data you're allowed to send
within a WebTransport session.
David: Can you clarify? This can be done all at the WebTransport layer
without reaching down into QUIC, right?
Marten: You can read the data out of the stream and have all buffers at the
WebTransport layer. But what if there are missing packets on the stream?
David: my undersrtanding was that this was a completely separate flow
control.
Martin: Marten is right. Difficult to do this without major architectural
contorsions. QUIC level flow control acting on the bytes, having a limit on
the number of streams for WebTransport is useful. Would be useful to stop
WebTransport from starving out all the other things.
Eric: On slide 30, first two items make sense (limit session count, limit
streams within a session), can punt the last one (limit session data, just
use QUIC flow control). The one above it (limit total data) is very painful.
Marten: MAX_STREAMS might also be difficult.
mt: We can just provide the total number of streams. But we have to be
careful with the accounting.
Alan: let's separate out MAX_DATA. Cannibalizing by one session would be
bad. But maybe it's too complicated and not worth implementing. Let's looks
at streams for now.
David as chair: limiting the total session count. There is consensus for
that.
Limiting MAX_STREAMS might be hard, but let's write a PR and see how it
goes.
Limiting MAX_DATA is probably too hard. Let's close the issue, and if
someone has a design implemented, we can reopen the issue.
Alan: not sure that it's possible to solve, but the group should spend more
time exploring. Let's keep issues open till they're resolved.

4. WebTransport using HTTP/2, Eric Kinnear (45 minutes)
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2

Need to decide what to do with capsules.

Need to discuss Martin's issue first (#38). It would be bad to send ???
frames, as it would cost one round-trip. Proposal: Allow sending any frames
allowed by flow control.

Datagram design time is complete. Previously we defined TLVs for every WT
frame. Now with capsule we can register them in a different registry where
we register capsules.
What do we get from capsules. > bunch of capsules <
There's a DATAGRAM capsule, so we don't need a WT_DATAGRAM.
HTTP/3 can reuse the WT_MAX_STREAMS (+ BLOCKED). Reuse is good, shared
registry, all good.
Is the end-to-end-ianness a problem?
Intermediary might allow WebTransport/H2 for clients in UDP-blackholed
networks, but might want to speak WebTransport/H3 all the time. What is the
expectation if the Capsules don't have large overlap? Does *every* endpoint
now need to support the H2 capsules?

Alan: Datagram capsules is end-to-end as a concept, but not on the wire.
Will be converted by intermediaries to DATAGRAM frames. WT_RESET_STREAM and
WT_STOP_SENDING can be translated to QUIC frames. Flow control is
hop-by-hop.

mt: ???
Right answer might be to not do any of that because it's too hard.

Eric: As Alan pointed out, there is a way. Each capsule type can define the
translation. But not sure if that gets us where we want.

David: Agree with mt. Depending how you look at it everything looks
different. Is WebTransport/H3 the same protocol as WebTransport/H2. By
protocol I mean upgrade token. Let's say scneario with 2 H2 hops and an
intermediary in the middle. All that the intermediary does is shove bytes
between streams. But with H2 and H3 conceptually you don't have an
intermediary any more. You have a server that terminates the one connection
and establishes a new connection.
This feels consistent. Should they have different upgrade tokens? Maybe yes.

mt: What happens if the intermediary accepts a stream, but can't open the
stream on the other end? What is it supposed to do now? I don't know.

David: 50 shades of backpressure. If you have an intermediary, you have
that problem, no matter what.

mt: If it stays in the stream then no problem. If not, then yes. If it's
just tunneling the byte stream back and forth everything is end-to-end.
Protocol translation is where things get funny.

David: use case for capsules

mt: but they don't buy us any thing except for a lot of redundant length
fields.

Alan: Looks similar to the PUSH problem. Intermediary might also not any
stream credit. Going between protocols is where problems occur.

Lucas: Stream impedance already exists today. We could solve this with
contexts (?). We could solve this with capsules. I don't see any problem
that's bigger than what we have today.

Eric: do we define things on the CONNECT stream. We could do this with a
WebTransport capsule. There's ???

David: Agree with Eric. Reply to mt, what does it buy us? We might want to
add a future frame later. Is it one or two IANA registries. We're defining
one WebTransport over HTTP, and when you run it on H3 it's on steroids.

mt: There's maybe a simpler way to build this, might not be so pleasant. If
it can't guarantee end-to-end, then it doesn't offer it. The way we get
things lifted up requires ???

Eric: Wondering if the effort is worth it.
Using the Capsule is a way to get a different IANA registry. What's the
Litmus test to determine if it should be a Capsule or not.

David: We will be forming a design team.


## Priorities

Luke:

Alan: The easiest thing to go from FIFO to LIFO might be to just tell your
scheduler (???).
In MoQ we can get value by breaking them up and push them over QUIC
streams. If you want to go as fast as possible, you need interaction you
need closer ties with cc, loss recovery, latencies and feed this stuff into
the application.
Maybe WebTransport stats are enough for that? Are we going to think about a
v2 version of the API?

David: Scope this to the implications of WebTransport.

Luke: In our server you can prioritize streams. Want to fully utilize conn
and degrade cleanly. Kind of like LIFO but it's more complicated. There's
control messages and stuff. We need a way to communicate priorities. That
can be solved with an HTTP header.

Victor: Comment on the w3c issue. 62.

mt: That's something the application can do for itself. Signalling can be
worked out on your own terms.

Lucas: Extensible Priorities draft is just one signal. In practicality it
should be combined with all the other information. Some might ignore it,
some might combine it with other pieces of information.
The browser world has a lot of constraints that other don't. QUIC doesn't
specify how it's done, some people love it and some people hate it. We can
still define this later.

Cullen: LIFO doesn't necessarily work. In the video case this makes it
better on semi-congested networks, but makes things works on really
congested networks. We need something more flexible.

Bernard (no hat): w3c now has a functioning version of WebTransport API and
WebCodecs, so you can build this kind of stuff. Video upload scenario can
be implemented right now. Downstream is more complicated. Server can do
things like priority, without the WebTransport client needing to support
that. So we can accomodate both scenarios, people should try it out. We
didn't go down to the lowest level, and we decided that people don't need
it. Only for RTP directly over QUIC. Stats are not intended to implement
cc, just to see how the app is performing.

Magnus: is it dynamic?

Luke: Twitch is using Webtransport, but not WebCodecs. Prioritiation on the
server side. When we create a stream, we know the priority. It's nice to
have that functionality but not required. Re Bernard: if you want to create
media in the browser, you can't control the priority then. We're thinking
about this, send new media before old media.

Bernard: would be interesting to see result.

Alan: some people have really low latency video and might not be happy with
the default cc that the browser is providing.

Bernard: interested to see if you have any issues with BBRv1 in your
implementation.

Alan: I personally don't have any code, just based on discussion that
happened on Wednesday.

Luke: BBRv1, but there are some bugs in BBRv2 not fixed yet. Reno and Cubic
don't have the same latency requirements. Asking browser to allow control
over congestion controller might be too much to ask from a browser API, let
w3c decide.

Cullen: Information about congestion controller could be passed down. We're
not at that point yet.

Bernard: That's what's been proposed, an enum provided to the WebTransport
constructor.

Cullen: That seems adequate.

Victor: enum to let you switch between different ccs. There's a proposal
(where ???) to move cc out of the Linux kernel to user space. Question: is
this really worth the engineering investment?

Bernard: how do you configure that? let people see what works and what
doesn't work. Somethink like SCReaM or Google CC might be interesting.
Problem with pooling!