Subject: [Webtransport] IETF 111 Draft minutes

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Jul 2021 14:28:17 -0700

Here are the draft minutes.  Corrections/additions/deletions to the Chairs.

# 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.