WebTransport (webtrans) Working Group

CHAIRS: Bernard Aboba
David Schinazi

IETF 120 Agenda
Date: Thursday, July 25, 2024
Session: III
Time: 15:00 - 16:30 Pacific Time
Room: Georgia B
Note Takers: Dustin Mitchell

Meeting link: https://meetecho-or.ietf.org/client/?session=33018
Notes: https://notes.ietf.org/notes-ietf-120-webtrans
Slides:
https://docs.google.com/presentation/d/1vvn7mIz_y2SkxL8eH2-VlhaAnzAlGvRNSVbYStuco5A/

---

1. Preliminaries (Chairs, 15 min)
   Note Well, Note Takers, Agenda Bashing, Draft status

No takers on bashing the agenda.

1. W3C WebTransport Update, Will Law (15 minutes)
   https://w3c.github.io/webtransport/

Jan-Ivar Bruaroey gave the update.

Jan-Ivar: WebTransport API has 7 Open Issues (5 "Ready for PR") that
need to be resolved prior to Candidate Recommendation (CR). Goal is to
be ready for CR by October 2024.

Jan-Ivar: Major decisions since IETF 119:

• Retransmissions. Ordering is implementation-defined, but UAs are
  strongly encouraged to prioritize retransmissions with higher
  SendOrder values.
• Support for relative URLs.
• Give datagrams priority over streams, but don't starve them (e.g.
  don't block stream flow completely).

regarding priority:

Alan Frindell (moq): MOQ has a priority design in draft 05 that is not
compatible with always giving datagrams priority; recommends
collaboration. There is no brief summary, but Ian Swett's slide deck has
slide with a summary, but in terms of moq objects. Alan will open an
issue.

Jan-Ivar: WebTransport API supported in Chrome, Edge, Firefox and Opera.
Safari support is coming along.
Jan-Ivar: W3C has dependencies on several IETF WEBTRANS Issues:

• Issue 167: Do we need DRAIN_WEBTRANSPORT_SESSION? – needs debate
  and resolution.
• Issue 15: Subprotocol negotiation — has been assigned to Eric
  Kinnear, has a PR.
• PR 14: Data Recvd -> all data committed — needs to be merged.

Jan-Ivar: W3C added stats.estimatedSendRate, are now adding some new
qualifying Booleans to help applications in interpreting this value:
stats.isSendingDataLimited; // is sending application limited?
stats.isSendingServerLimited; // the server is overloaded with data
stats.inSendingSlowStart; // the client CC is in slow start

regarding booleans isSending*Limited:

Magnus Westerlund: How would you derive isSendingDataLimited? Will
this actually help? Similarly for isSendingServerLimited?
Jan-Ivar: isSendingDataLimited would be based on send queue trend.
isEndingServerLimited is based on flow-control data from the server.

Eric Kinnear: booleans provide context for estimatedSendRate, and are
intended to help applications know if they can/should send more or less
data. Is it possible to get correct answers to these questions?

Christian Huitema: What signals are these giving and why? Congestion
control algorithms do not necessarily implement "slow start" as defined
in TCP (e.g. QUBIC, see:
https://huitema.wordpress.com/2019/11/11/implementing-cubic-congestion-control-in-quic/)
So are your booleans based on an internal model of congestion control
that may not apply? API should be customer-centric, instead of
congestion-centric. It should answer application questions: should / can
it send more or less?

Matt Mathis: 1st author of the TCP extended statistics MIB
(https://datatracker.ietf.org/doc/html/rfc4898), which included metrics
relating to congestion control, flow control, etc. [but not booleans].
That made the specifications general and the RFC 4898 said applications
must understand the implementation to understand them. Sender-limited
was complicated and we never got it right. Don't be surprised if that
doesn't work.

Eric Kinnear: agree with Matt. If we can find something that is both
possible/real and useful to someone, that's great. Trying to find the
smallest set of useful information that meets both of those.

Jan-Ivar: If we didn't provide any of these, would anyone be upset?
Eric Kinnear: Echoes questions to MOQ folks.

David Schinazi: Are there requests for this information in the W3C?

Jan-Ivar: The issue was opened by Victor Vasiliev. Presumably someone
asked for it.

Eric Kinnear: Media people have expressed concern about
QUIC/WebTransport datagrams. They are like UDP datagrams (application
handles retransmission), but congestion control is provided by QUIC. A
WebTransport application using datagrams won't have the same
information/control as with UDP datagrams.

Matt Mathis: need a diagnostic facility, but only useful in some
situations. Only says who was idle.

Christian Huitsma: Network works to have a general notion of how fast
the network can go. Only valuable information is what you get when you
try. Lots of variables including stream priority affect that. Multi-path
makes this more complicated since each path has its own congestion
control state. This makes a tension between having precise information
that depends on the implementation and having useful infomration.
Recommend providing information tied to the API: how long would a write
take, etc. -- something that provides some information about the
underlying network.

Eric Kinnear: Goal isn't "how fast can you send", it's "how fast things
are going out right now". For a limited set of use cases, we know this
is a floor or a ceiling. "This is how fast you are currently going, and
either you might consider trying OR if you put more data in it's not
going to go faster". So if we can scope this differently that might be
tractable.

Jonathan Lennox: Ask is actually "is estimatedSendRate a ceiling or
are we still in some exploratory phase". This is actionable, usable
information but involves a timescale over which it is measured and other
hand-wavy things.

Harald Alvestrand: The TCP model was designed for file transfer - amount
of data is fixed, delay is acceptable. We are trying to use WebTransport
in cases where delay is important and we can adapt the amount of data.
Exposing even imperfect measurements allows learning and iteration and
producing better systems for users.

Christian Huitema: One thing that might be missing is an event from
congestion controller to application saying "things have changed" e.g.,
lost a link or throughput was reduced. Application would need to respond
to this. Probably a useful event to understand.

regarding {sub,}protocol:

Jan-Ivar: WebSockets
(https://websockets.spec.whatwg.org//#the-websocket-interface) uses
"protocol".

Nidhi Jaju: From an editorial perspective, "subprotocol" suggests an
underlying protocol. "protocol" is very overloaded. How about
"application protocol"?

Eric Kinnear: That ship has already sunk. Being consistent with the IANA
registry is not consistent with the WebSocket spec. W3C and IETF specs
should match. Application protocol sounds fine. "Sub" is weird if it's
closer to the application. "Application" avoids notions of up or down.

Christian Huitema: "application level protocol" is already used in TLS.
Things that are designed to run either on QUIC or WebTransport (e.g.,
moq). On QUIC, those are identified by an ALPN and that terminology
would overlap. Don't mind "application level protocol" only if has
exactly the same name on top of QUIC. E.g., moq would use the same
string in ALPN or WebTransport.

Harald Alvestrand: Those who think "application" is well-defined are
incorrect. Please pick a short name in the interest of ergonomics.

Summary: be consistent. reuse IETF one or open an issue to change that.
flip a coin.

Poll results:

• 19 protocol
• 3 subprotocol
• 9 applicationProtocol

Jan-Ivar: will rename.

1. WebTransport over HTTP/2, Eric Kinnear (25 minutes)
   https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2
   Open PRs:
   https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http2/pulls

   Open Issues:
   https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http2/issues

regarding key exporters:

https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http2/issues/113

Eric Kinnear: For HTTP/2, is there a reason to do anything different
than HTTP/3?
[See:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/116

https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/148
]

David Schinazi: HTTP/2 can use TLS 1.2. For TLS 1.2, key exporters are
considered unsafe unless you have the extended master secret. Draft said
can't use unless TLS 1.3 or TLS 1.2 with that enabled. Could say that
WebTransport over HTTP/2 requires the same, and that wouldn't be
ridiculous.

Yaroslav Romomakho: This is the first time key exporters would be
available to Javascript in a browser. Things might break if there is a
proxy in between that is performing TLS decryption. Perhaps that needs
to be noted in the [W3C] spec. Yaroslav will file an issue to track.
[See: https://github.com/w3c/webtransport/issues/]

regarding new settings:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http2/issues/105

General thumbs-up to new SETTINGS proposal.

regarding WT over HTTP/2 interop:

Randall Jessup - Moz will implement WebTransport over HTTP/2 in ~6mo
timeframe

Next HTTP/2 draft will be the interop target, will be on hold until
interops are done.

1. WebTransport over HTTP/3, Eric Kinnear presenting for Victor (25
   minutes)
   https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3
   Open PRs:
   https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pulls

   Open Issues:
   https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues

Eric gave the update for Victor.

regarding DATA RECVD:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/13

https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/pull/14

Mike Bishop: Have questions regarding meaning in QUIC. Will read the PR.
Suggests DATA_SENT then later transitioning to DATA_RECVD. Mike will
leave comment on PR.

Matt Mathis: Senses danger. Ambiguities between abort and EOF
connections. "Received" will lead to incorrect assumptions that will
cause bugs. Maybe DATA_COMMITTED? Will comment on the PR.

regarding subprotocol:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/15

David Schinazi (as chair): Checking that all documents will update
subprotocol -> protocol. No objections.

** regarding capabilities **
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/12

A tracking Issue (largely editorial).

regarding auth:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/10

Mike Bishop: Unclear why we would prohibit HTTP auth with WebTransport.
Maybe we forgot. Review history.
Jonathan Lennox: WebTransport originally supported QuicTransport, wasn't
always over HTTP [HTTP auth prohibition was introduced along with
HTTP/3 transport]

Eric Kinnear: When using HTTP, WG was careful not to bring in extra bits
of HTTP. But weird to prohibit it.

No objections to removing the prohibition.

regarding DRAIN:
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/167

Bernard Aboba: There are two orthogonal questions:

1. Should the IETF protocol specification include support for
   DRAIN_WEBTRANSPORT_SESSION from server-> client, client->server or
   both?
2. Should the W3C provide an API supporting
   DRAIN_WEBTRANSPORT_SESSION from server-> client, client->server or
   both?

Alan has a use case for client -> server DRAIN_WEBTRANSPORT_SESSION
that involves the backend (e.g. DRAIN_WEBTRANSPORT_SESSION would not
be sent by a browser). Alan's use case requires support in the IETF
protocol specifications, but not necessarily in the browser API.

Alan Frindell: Similar to WRAP_UP in the MASQUE WG. Intermediaries may
want to send this in one direction or the other so that an endpoint
finds out that intermediary would like things wrapped up. Maybe this
should be joined to WRAP_UP.

Victor's not here so we can make him say whatever we want.

Bernard Aboba: Is it useful for an application to be able to ask the
browser to send DRAIN_WEBTRANSPORT_SESSION? If the browser imposes no
restrictions on the JS application, same effect could be achieved by
having the application send its own application-specific message.

Alan Frindell: Imagine you're viewing a livestream and the client is
going away and wants to get to the end of it. The Javascript application
can do that on its own. But an intermediary cannot. Note that GOAWAY was
removed from QUIC, but it is still in HTTP/3.

Nidhi Jaju: GOAWAY is for all WebTransport sessions, whereas
DRAIN_WEBTRANSPORT_SESSION is for one session. But text just says "may
continue" and "may open new streams". Especially with client-initiated
drain, nothing is enforced so what does the browser do with it?

David Schinazi (chair): Neither the IETF nor W3C issue is about removing
DRAIN_WEBTRANSPORT_SESSION entirely, just about sending it from
client-to-server.

Mike Bishop: Server-to-client is fine.

David Schinazi (chair): Could people live with allowing
DRAIN_WEBTRANSPORT_SESSION to be sent in either direction in the IETF
protocol, and the W3C API only supporting server->client?

Eric Kinnear: That is not a practical outcome. Part of Issue 167 is an
ambiguity in the meaning of "application" in WebTransport over HTTP/3
Section 4.6:

["After sending or receiving either a DRAIN_WEBTRANSPORT_SESSION
capsule or a HTTP/3 GOAWAY frame, an endpoint MAY continue using the
session and MAY open new streams. The signal is intended for the
application using WebTransport, which is expected to attempt to
gracefully terminate the session as soon as possible."]

What does "application" mean here? Does it mean the user agent or the
Javascript application? [Also, what does "endpoint" mean?]

Mike Bishop: Push a little more on Alan's suggestion to merge with
WRAP-UP. This is useful for WebTransport, and silly to make two things
that mean the same thing. Maybe merge with WRAP-UP and not include in
WebTransport protocol at all?

David Schinazi (chair): WRAP-UP isn't adopted yet and adding a
dependency would add delay.

Eric Kinnear: Requests that WebTransport chairs check in with MASQUE
chairs to see if the dependency can be resolved in time.

Matt Mathis: Think about making the protocol layer functionally
complete, even if the API layer is not complete. A problem with
WebSockets is there's a lot of nonuniformity in cancelling
non-transmitted data. If the protocol isn't functionally complete, this
limits what you can add to the API.

Lucas Pardue: The protocol specification shouldn't arbitrarily restrict
the direction of DRAIN_WEBTRANSPORT_SESSION, but could do so at the
API or application level. To whether this could be WRAP-UP capsule,
would still need text about what draining/wrapping-up a WebTransport
would mean. Proposal to make an update when WRAP-UP arrives.

Alan Frindell: What can you do after you've sent or received
DRAIN_WEBTRANSPORT_SESSION. Hard to specify, because application knows
what it means to wrap up -- may need to open a new stream in that
process. Intermediary can't insert an application-level message. Maybe
MASQUE and WEBTRANS WGs should have worked more closely as there are
lots of parallels, but that's the past.

Eric Gorbaty: If we were considering a W3C API, this would make sense.
If this capability would be useful at the API surface, would make sense
to have the state be expressed in HTTP as well for consistency.

David Schinazi (individual): It's OK to have two capsules meaning
similar things. If the timing works out then WebTransport's
DRAIN_WEBTRANSPORT_SESSION can just switch to WRAP-UP, but that isn't
certain. Have 4,611,686,018,427,387,904 capsule types available.

Will go around a few more times.

1. Wrap up and Summary, Chairs & ADs (10 minutes)

David thanks the academy, his family, and all the friends he made along
the way. In lieu of flowers he requests PRs and comments.