Minutes IETF112: webtrans
minutes-112-webtrans-00

# IETF 112 WEBTRANS WG Agenda
Tuesday, November 9, 2021
12:00 - 14:00 UTC
04:00 - 06:00 Pacific Time
Session I, Room 2
Chairs: Bernard Aboba and David Schinazi
------

IETF 112 info: https://www.ietf.org/how/meetings/112/
Meeting URL: https://wws.conf.meetecho.com/conference/?group=webtrans
Etherpad: https://notes.ietf.org/s/notes-ietf-112-webtrans
Slides:
https://docs.google.com/presentation/d/1BfAUQui73mFhKqXY5Awv4rjBe_eLPmfgx_8zjQnPN1M/

## Preliminaries, Chairs (10 minutes)
Note Well, Jabber Scribe, Etherpad Note Takers (James Gruessing, Spencer
Dawkins) Speaking Queue Manager (David Schinazi) Agenda Bash

No bashing occurred. The agenda was unscathed.

## W3C WebTransport Update, Jan-Ivar Bruaroey (10 minutes)

Jan-Ivar: Have published an updated working draft.
* New `WebTransportError` DOMException with source and error code
* Minimal prioritisation
* Chrome shipping webtransport in M97
* Still needs prioritisation and stats
* Multicast-for-the-web presentation, requesting multicast for consideration in
WebTrans working group * Issue identified in bi-direction video conferencing,
encoder and cc algorithm need to work together * Probing of network to
determine bandwidth to be requested * Mirja (from Jabber): rmcat wg for
real-time media congestion avoidance had draft-singh-rmcat-adaptive-fec to add
fec to fill the cwnd for probing. that draft never made it to RFC because there
was not enough interest but I always thought it interesting work

## WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-02.html

Victor: New draft version, 6 months of changes, including:
* Clean close connection
* Version negotiation
Chrome 97 ships, but negotiates separate version but will be removed later

### Issue #27 - Do we need something like a GOAWAY frame to drain sessions?
Alan: Value in having a GOAWAY, seems lightweight, and cheaper
Martin: I'm not sure what semantics would be?
Alan: A signal as intention
Martin: If there's a generic signal, no need to attach
Alan: Not sure if we've defined if it's okay to have unknown capsules, or do
they have to go over application stream? Victor: We should not add new concepts
trivial to add to the APIs we provide Alan: There may be applications that
don't use a control stream Lucas: The value on GOAWAY depends on what the
receiver would act upon - how is this more than HTTP/3 GOAWAY? Erik: Benefit at
this layer is intermediate to send it, alternatively API exposed H2/H3 GOAWAY
Alan: The intermediator use case is useful, if the intermediator wants to go
away and needs to tell both endpoints Victor: Sounds like we need specific
proposal with use cases, Alan would you volunteer for handling this?
**Action**: Alan to write a PR, and everyone else to argue about this in the PR
### Issue #22/#36 - Pool resources

Victor: Pooling resources is useful, but how do we limit resources, in an ideal
scenario we would isolate connections and prevent starvation Currently no
proposals, so can we start a discussion about this? Martin: We give sites
`fetch` almost without constraint, but that might be the best solution for the
time being and do nothing Victor: That's possible, but I'm afraid of logical
indirections such as opening so many streams you can't fetch at all Martin:
That's possible Spencer: Do you think laissez-faire, would be easier to add or
take away later? Martin: I'd have to think about that - easy to add
*something*, but not sure it could easily be made reliable if something bad
DOES happen. Lucas: This seems similar to a discussion about H3 priorities,
where endpoints detect the number of streams, to think about bidirection
streams that all information is available to clients, and this is an API
problem not protocol. I don't think there's much to do here. Yutaka: Ideally
memory consumed should be a function of bandwidth, more streams shouldn't
result in more memory only bytes transmitted, correct? Victor: Some extent,
QUIC has a limit is shared between all Dragana: I'm afraid of different
implementations having different limits, and timing dependency Victor: We
should give developers some idea on what limits the browser supports - 4
streams versus 100 would make a difference on how you design the application
protocol. Dragana: I wondering of different pooling behaviours, but this is a
different problem Martin: Imagine the ease of exhaustion, but no guarantee of
number of concurrent streams for QUIC (unlike H2). There should be a cap or
minimum guarantee. Victor: We have some ideas, this should be taken to the list

### Issue #61 - Redirects
Victor: Two options: either follow or not follow redirects, in W3C we agreed
not to follow the redirect (to give the redirect to the application) David: I'm
okay with that, no strong opinion but we should be clear Martin: I think if
we're playing HTTP, we have to play by the BCP56bis rules, there are 3xxs that
don't make sense for webtrans, but some that do. We shouldn't ignore all of
them Mark Nottingham (in Jabber): HTTP doesn't require clients to follow
redirects. It's up to them whether they do (and they often do, if they want to
complete their task). Jonathan Lennox (in jabber): Returning the 3xx to the JS
API and letting the JS handle it doesn't seem terrible, so long as the JS to
implement standard redirect handling is simple. Victor: Redirects are something
they don't build initially, and later regret Victor: We should figure out what
to do based on the BCP, and if not revisit this

### Issue #63 - Request Forgery
Victor: In Websocket we use masking to avoid confusion attacks on the
intermediaries, do we need something similar? Martin: The impersonation is not
only HTTP but any protocol, e.g. STUN, SIP. Because you have full control over
the packets, you can do a lot. Harald (in Jabber): it was STUN + UDP message
fragmentation Victor: Is this specific to webtrans? Why is this not a problem
with `fetch`? Martin: It is a problem. Harald: The problem with masking is you
can count on a middlebox doing something inappropriate if the attack can
control the first bytes in a packet. If content is encrypted, or header
controlled by the protocol the attack can't control it and you're safe against
forgery. David: Encryption helps but not here, because it's predictable.
Because we use stream-ciphers, you can influence the cipher text. How do we
solve this? Maybe add a few port blocklists, punting the problem to the W3C.
Victor: Port blocking will protect against NAT slip-streaming attacks and
others, but not all attacks we might not be aware of. Yutaka: In seems both
directions of client to server need masking? Victor: It doesn't help requiring
masking on server to client, and client to server is more important Yutaka:
Masking is relying on server to client is safe Victor: There's nothing we can
do about it, because it can send whatever it wants David (in Jabber):
Slipstream attack relies on middlebox treating client-originated traffic as
trusted Harald: A server leaking keys will work against any QUIC-based
protocol, and that's not this WG's problem to solve Harald (in Jabber): webrtc
is using the tcp blocklist for udp as a stopgap. Victor: This is something we
should punt to quic WG. Does anyone disagree? Martin: I can live with us having
the discussion elsewhere Harald Alvestrand (in jabber): webrtc is using the tcp
blocklist for udp as a stopgap. And webrtc (the implementation) is arbitrarily
blocking all ports < 1024. Erik Nygren (in jabber): see
https://github.com/whatwg/fetch/issues/1268 for a udp blocklist in Fetch. @mt
raises the good point of it's unclear where the best place is to own this
between ietf and w3c.

## WebTransport using HTTP/2, Eric Kinnear (40 minutes)
https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-02.html

Eric: New layered design, as it'll be easier to implement
Instead of adding new frames to H2, we use extended connect
Inside the connect we have webtrans streams and datagrams
### Issue #29 - Frame Formats
Eric: Some fields are not necessary, for example in a `WT_RESET_STREAM` Final
Size is not required Eric: Currently we've put length after type, but if we
swap them it could be parsed by a QUIC parser after removing the length Martin:
Even more clever and use the same length field for multiple frames, but this is
the fallback protocol, so we shouldn't be TOO clever. Removing final size
doesn't make me uncomfortable Lucas: I would go for the simple thing and not be
overly clever Alan: Put the length first, but QUIC doesn't have the lengths so
maybe we drop it Eric: We're headed toward a binary choice - do we make this
look like QUIC, or do we care if it doesn't look like QUIC? Ian: Do we really
think we need a length here? Victor: Length is fine where we're not concerned
about size David: This is a fallback transport, length sounds like fewer
headaches, and this is starting to look like a capsule. Why don't we just
register 8 frame types as WT capsules and move on? Martin (in Jabber): "once
you have a length, these are capsules" Eric: You're saying make it a capsule,
register it, and keep going? David: That's what I'm saying. Alan: All capsules
buy you is a parser that knows how to parse the length and hand you a blob. If
we're going to do this, I'd also like a type. Martin (in Jabber): I don't think
that we get any benefit from sharing code for capsule parsing. Frame decoding
is not a whole lot of code. David: Given there's 6 frame types with 2-3 fields,
reusing QUIC frame parser doesn't fit. When it comes to processing, it's stream
and flow control. Drop trying to re-use the parser. Eric: Hearing an overall
lack of concern, and it's okay if it's a little bit different.

### Issue #25 - Capsule

Eric: Do we make webtrans datagram its own thing?
Alan: I'm not sure of the capsule value, given the capsules are kept in a
global register. If it's no big deal to copy+paste QUIC parser, then it's
really no big deal to copy+paste a capsule parser David: Depends on the plan
for getting across intermediates Eric: We're not talking about H1 here Eric: We
have this sit until MASQUE design team on capsules concludes Alan:
Intermediates are not participating, and if they are they have to parse it all
anyway.

### What about streams?

Eric: We try to use the existing features. HTTP/2 has native streams. Should we
have HTTP/2 streams in WebTrans? We haven't seen a strong case for this. Does
anyone else see one? Everybody: (crickets), so, no strong case suggested in the
meeting session

### Issue #27 - Flow Control

Eric: We have an issue to write up flow control behaviour, which we have 4
layers: * H2 * CONNECT * WebTransport Session * WebTransport Stream

That's a lot of flow control.

Eric: We're going to write up some text for visibility and avoid common
pitfalls. Does anyone think this isn't workable? Everybody: (crickets), so no
objections in the meeting session.

### Issue #44 - Error Handling
Eric: We didn't import all of QUIC's error handling, which needs to be brought
in Eric: We could bring a GOAWAY, the webtrans close capsule Eric: Do we want
this to look like H3? Or H2? Alan: This may depend on capsule's direction Ian:
Shouldn't we make sure they are similar? Martin: H3 webtrans has means to
signal before close, let's see what Alan comes up with the GOAWAY requirements
Eric: So we'll end up with whatever we do in H3 Victor: What does "WT over H3
shares error space with H3"? Eric: The error codes shared by the same registry
Victor: This is for resetting the streams, the close webtrans is for the
session. Does this issue cover both streams and sessions? Eric: short answer is
"yes", but we haven't been super clear about that. The intent of the issue was
to tear down the session, but we need the ability to tear down individual
streams. Victor: I need to take a closer look at this ### Other Discussion? None

### WebTransport for HTTP/2 over HTTP/3

Eric: Using additional frames over WebTrans, not in WebTrans (please verify!)
Should all the mappings of webtrans be doing the same thing?
Two points of conflicts: if you have an intermediate, do we have neogitation in
speaking transport protocol? Do we need to support both? **Eric hands off mike
control to the chairs for this generic discussion**

Martin: I think it should support operation over H3, but you must use datagrams
and streams - just describe the way that streams and datagrams are lifted off
to the native capabilities Victor: We should not require servers to support
operation over H2 if they're only interested in H3. That's just requiring them
to deploy twice the code. Alan: If they're the same protocol, but there's only
a few shared things between them - you can't use H2 frames over H3 CONNECT
stream, and we should make it not possible Eric: Martin's proposal is
attractive, Alan says there's not 100% overlap because H2 adopts native H3
things Victor: The overview draft provides a model of interaction based on
QUIC, and webtrans over h2/h3 are an implementation of that model. The
fundamental abstraction is streams and datagrams. Alan: If you couldn't speak
WebTrans H2 over H3, this is interacting with an intermediate that can't
translate, Victor: (???) Alan (in Jabber): +1 - make the proxies do this. They
already advertised the H2 SETTING. Alan: The stream limits can be different,
this isn't only a HTTP version problem, which might be more hairy

## Hums, Wrap up and Summary, Chairs & ADs (20 minutes)

Bernard: WebTransport is now available in Chrome, with the APIs available so
it's no longer an academic exercise David: see you on the mailing list, and in
March, if we don't have an interim before then!