Minutes IETF113: webtrans
minutes-113-webtrans-00

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!