Minutes IETF111: webtrans
minutes-111-webtrans-00

# IETF 111 WEBTRANS WG Agenda
Friday, July 30, 2021
12:00 - 14:00 Pacific Time
Session I, Room 1
Chairs: Bernard Aboba and David Schinazi

IETF 111 info: https://www.ietf.org/how/meetings/111/
Meeting URL: https://ws.conf.meetecho.com/conference/?group=webtrans
Etherpad: https://codimd.ietf.org/notes-ietf-111-webtrans
Jabber:  https://jabber.ietf.org/jabber/logs/webtrans/2021-07-30.html
Slides:
https://datatracker.ietf.org/meeting/111/materials/slides-111-webtrans-ietf-111-webtrans-wg-slides

## Preliminaries, Chairs (10 minutes)
Minutes: Mike Bishop

## W3C WebTransport Update, Will Law (10 minutes)

There are media protocols looking at going directly over QUIC.
Why not WebTransport?  Are there API gaps?

Request we resolve:
- Priorities between streams, datagrams, etc.
- Error code spaces that should be surfaced

## WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3

New -01 draft post-110, notably has type-value (no length) frames and no
requirement to wait for handshake to complete (requires buffering).

Martin:  What if people don't want to buffer?
Victor:  Stream gets closed, would have to restart.

Issue discussion:
#10: Need a consistent stream ID across proxies?  Think we decided no, but
can't find that written down.

No objection in room.  Speak up in the next week if you object.

#31: PR#40 should resolve; allocated error code subspace within H2 and H3
space. Error code transport is best effort across intermediaries.

Agreement in room that best effort is sufficient.

#34: MAX_WT_SESSIONS seems to be the conclusion on the issue.

Alan:   This is an option, but it seems like the most complex of our options.
Masque doesn't have this. How critical is it to have a limit? Victor: Not
critical, but some people want only one session per connection. Martin:
Resource management can get tricky with multiple sessions on the same
connection. Should have a limit of some kind. So should Masque. Luke:   Using
connection-level stats to make decisions about session. We currently refuse all
extra sessions; would be nice to tell browser up-front. Alan:   Not necessarily
objecting, but this seems similar to H3 MAX_PUSH_ID. Is this max simultaneously
or max ever? Luke:   For us, simultaneous. A new one later is fine. Alan:   If
it's max concurrent, you run into reordering concerns. Victor: Let's design
that on the issue.

Victor will write PR for MAX_WT_SESSIONS.

#32: When do we close for invalid IDs?

Alan:   Fine, some obvious connection error cases. Be careful of reordering,
though. MT:     Are we requiring or allowing a connection error? #1 we can
require, #2 perhaps we can just allow.

MUST close for #1, MAY close in 2-3.

#39: Setting; has a PR, please review.

#40: Allocated error codes for stream; please review.

#41: Error codes for session. Modeled off QUIC CONNECTION_CLOSE; see PR#60.
Uses Capsules, which will likely wind up inside DATA frames.

Alan:   Do you also need something like GOAWAY's stream IDs to allow for
draining, or will that be a separate capsule? Victor: Probably a separate
capsule; there's an issue for GOAWAY. Lucas:  Is this more like
CONNECTION_CLOSE or a RESET_STREAM -- who's asking for the error message?
Victor: Application might want to reliably communicate error message. David: 
Capsule encoding is changing, but capsules aren't gone. Using capsules is fine.

No objection to general idea in room.

#42: What status code accepts session? PR#58 says 2XX; please review.

#48: Make unidirectional streams use frames; no PR yet.

#50: Connection throttling. Should we have text about this, or leave it to API?

MT:     Everyone should limit connections, but servers are less able to
identify when connections are from the same client.  Needs further study.
Recommend that it happens, but don't build specific mechanism here.

No further comments, so Victor will write proposal.

#54: Datagram context IDs; currently not needed, but potential for extensions.

David:  Clarification that there's always a context, but there can be either a
single context or multiple. MT:     Let's just say we don't currently use
contexts. Why would we? David:  Example for WT is priorities. MT:     No way to
expose in W3C API; let's just leave this alone. Question whether context IDs
are useful. David:  We're skewing into H3-Datagrams -- take that to Masque.

Discuss on issue, refer design of H3 Datagram contexts to Masque.

## WebTransport using HTTP/2, Eric Kinnear (40 minutes)
https://datatracker.ietf.org/doc/html/draft-ietf-webtransport-http2

Integrating into H2 versus riding over H2? H3 has new frames and stream types,
uses H3 datagrams, etc. H2 does multiplexing, forces ordering and reliability,
etc. Leads to introducing new H2 frames.  WT_DATAGRAM frame that looks like an
H3 datagram.  WT_STREAM frame semantically equivalent to HEADERS, but can be
sent by server.  Effectively integrated into H2, meaning this requires changes
to H2 instead of an H2 implementation off-the-shelf.

Four new frames introduced, bringing some H3 semantics to H2. MT adds that this
changes state machine, which gets awkward. Conceptually, this is not QUIC over
TCP.

#25: Follow Masque on how to transport datagrams

Currently, that means CONNECT body is a capsule stream, and there's a DATAGRAM
capsule type.

Should streams be defined inside capsules?  If so, it makes H1 support easier,
and maybe HTTP/2 streams are an optimization.

Is proxying through generic H2 intermediaries a requirement?

### Layered vs. Integrated

MT:     In Masque, we decided to layer on top of HTTP and opportunistically use
native transport features where available. That way, you have a baseline that
works, with some possible upgrades. Don't want to spend effort on HTTP/2
implementation; QUIC flow control is relatively simple, and reimplementing that
might be easier than messing with the HTTP/2 stack. Ian:    Strong support for
running over HTTP/1.  Experience with protocols that over-integrate with H2,
and that makes deployment more difficult in a general-purpose proxy. QUIC over
reliable stream, or QUIC/TCP, has valuable use cases. Eric:   If you were doing
QUIC over TCP, would you also do H3 over TCP? Ian:    Not currently. Victor:
Used to think we should bring H2 state machine to H3 for WT; less enthusiastic
now. Old presentations for WT had four protocols: H3, H2, QUIC, WebSocket. WS
never really advanced; no practical interest. But now that sounds more
appealing. Eric:   Not the same; we chose to build on top of HTTP, not on top
of raw transport protocols. Victor: Don't want to remove HTTP, but pointing out
that this idea didn't have interest before. Luke:   Legacy systems have HOLB;
we want to get rid of that using WT. H3 will cover 95% of our users. What's our
simplest way to serve the remaining 5%? Don't want to rewrite HTTP/2 stack; be
as simple as possible. Eric:   Also points to other QUIC use-cases that would
like a ready-made fallback. Alan:   Is H2's resource management adequate for
WT? Sounds like most people don't want to tinker with their H2 stack. Victor:
We're shipping non-pooled first, and resource management matters more with
pooling. TCP also used intra-datacenter, and other cases UDP is blocked.

Lots of support for on top of HTTP, rather than inside HTTP/2.  Would people be
willing to write up, help implement?

Alan:   First step is producing a document; MT took an early stab.  Would
consider implementing at next Hackathon. Mike B.:Is there much different from
being inside CONNECT body vs. native H2? H3 difference is real. MT:     Slight
difference in encoding efficiency, but it's unclear which way that goes. Alan: 
 High RPC use cases might see a performance impact. It's unclear anyone cares.
Could build extension later if useful. Ian:    If we think 95+% will use H3, do
we really care about H2 perf if it's "acceptable"? If you want perf over TCP,
consider H1.

Strong support for moving to a layered approach.

### CONNECT-*?

WT and Masque are both using some version of CONNECT -- Extended CONNECT,
CONNECT-UDP, CONNECT-IP, etc. How to reconcile?

MT:     CONNECT with :protocol is probably cleaner. Care about being able to
use a URL that indicates the resource rather than the target, but any of these
will work. David:  +1, will discuss on Masque list. Victor: Extended CONNECT is
consistent with WebSockets; represents resources on the wire. WT should not
change; Masque can do what it wants. Lucas:  Having tried both, I call them all
"CONNECT streams"; doesn't matter. MT:     Some people in HTTPbis have an
allergic reaction to extended CONNECT; make sure HTTP list is involved. Mike:  
Is RFC 8441 Standard or Experimental? MT:     Standard; we're fine.

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

David: Consensus in the room to unify on having WebTransport-over-TCP built
atop HTTP semantics, with version-specific optimizations. We'll confirm that on
the list.