Skip to main content

Minutes IETF108: webtrans
minutes-108-webtrans-00

Meeting Minutes WebTransport (webtrans) WG
Title Minutes IETF108: webtrans
State Active
Other versions plain text
Last updated 2020-07-27

minutes-108-webtrans-00
# IETF 108 WEBTRANS WG Meeting
*Monday, July 27, 2020*
*14:10 - 15:50 UTC*

Virtual Room 1
Chairs: Bernard Aboba and David Schinazi
Agenda: https://datatracker.ietf.org/doc/agenda-108-webtrans/
MeetEcho: http://www.meetecho.com/ietf108/webtrans/
Jabber Room: webtrans@jabber.ietf.org
Slides:
https://docs.google.com/presentation/d/1cr_4jtUCYTkoJQl4jEWT9LKJfZkkYM1W3MW8s2bz47Y/

## Preliminaries, Chairs
14:10 – 14:20 (10 minutes)

   Note Well
   Virtual Bluesheets
   Jabber Scribe, Etherpad Note Takers
   Speaking Queue Manager (David Schinazi)
   Agenda Bash
   W3C WebTransport Update

Jabber Scribe: Spencer Dawkins
Note Takers: Lucas Pardue, Amelia Andersdotter and Eric Kinnear

## WebTransport Use Cases, Will Law
14:20 - 14:30 (10 minutes)

### Presentation
Update on advancements in W3C, timelines, and use cases.
Have gathered use cases from many different sources and pruned them.
Examples: Machine Learning (translation, security camera analysis), Multiplayer
gaming, low-latency streaming (unidirectional broadcast, bidirectional
WebRTC-like), cloud game streaming, server-based video conferencing, remote
desktop, time synchronized multimedia web comms, IoT sensor and anayltics,
PubSub Models (data tickers, messages) Use cases may be candidates for
QuicTransport or Http3Transport, or both Can use cases be solved sufficiently
well by existing technologies, extending existing technologies? If a new
technology is needed is this best handled by QuicTransport or Http3Transport?
Encourage WebTransport to do a few things well rather than attempt to cover all
possible things. Encourage collaboration between IETF and W3C WG

### Discussion

Lucas: About collaboration between IETF and W3C, some folks are familiar with
both groups but tend to stick to the IETF more than other groups. How would you
recommend people first reach out?

Will: Chairs will coordinate on a more formal update process so that if people
miss meetings they can get updates. We can invite people to the other group's
meetings, hoping for something regular and scheduled, will hammer that out with
Bernard and David

Lucas: It would really help if things come back to the mailing list, even if
there's duplication, better to help people avoid missing things

Will: Certainly, want to avoid email overload, but will also seek help from
folks familiar with the IETF. Also keeping use case document open if folks have
additional use cases they'd like to raise. Will share links and you can file an
issue on GitHub as well.

From jabber:
Mirja
+1 for a joint IETF/W3C meeting for this :-)

wseltzer
And your W3C-IETF liaisons are here to help :)

## WebTransport Overview and Requirements, Victor Vasiliev
14:30 - 14:50 (20 minutes)
https://tools.ietf.org/html/draft-vvv-webtransport-overview

### Presentation

Document goal is to assist coordination between IETF and W3C on design of the
WebTransport API. Draft has been adopted as a WG document, please review
existing issues on [GitHub
repo](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues),
open new ones if anything is not covered.

GH issue
[#1](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1):
stream IDs
  Developers would like to know in what order streams arrived.
  Stream IDs used to be in the draft but were removed due to some hard
  problems: proxying, and information disclosure.

GH issue
[#2](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/2):
stream resets
  No consistent stream reset semantics across HTTP versions. Port H3's
  STOP_SENDING to H2? Or just go with H2 style?

GH issue
[#3](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/3):
streams, messages
  WebTransport offers streams of bytes and messages. No capability for streams
  of messages, do we want to ffer this?

There are TODOs in the draft: state machine description depends on #2, missing
section on priorities

### Discussion

Bernard: it is important to get clarity on the state machine. We used to have a
state machine diagram in the API document, which we had to update as QUIC
evolved. So support updating it. Note that the state machines of QuicTransport
and Http3Transport are different. Victor: two machines, one for transport, one
for stream. Transport machine we might wwant to extend if we get 0-RTT support.

Yutaka: Regarding messages and byte streams, websocket allows infinite size
messages, which prevents us from optimization. I don't want to introduce such a
messaging schema. Victor: I agree, personally for #3, since none of our
protocols support messaging we should just stick with streams. If applications
want message delineation they can do it themselves Yutaka: Thank you

Harald: Do you know what happens if we don't define messages is that we will
use streams as messages. Victor: That's one of the supported ways in which you
can operate QUIC Bernard: That's how WebTransport provides reliable/unordered
transport. David: It's possible for the application layer to do this: question
for WG? Is this a feature to build into WebTransport, or do we provide supports
for streams and leave the rest as an exercise for the application? Harald: The
focus on bytes is harmful because you end up retransmitting stuff as parts of
messages in a way which is not optimal. Would rather have messages in the
protocol itself.

Erik: Having messages has more flexibility for applciations to do things. I
would prefer these not to be sent in the same packet, in order to support FEC.
Victor: Would Datagram satisfy that problem? Erik: I guess so Victor: When
talking messages, we mean ones that are reliable and span multiple packets. If
you're willing to use Datagram we can solve those problems with some text e.g.
anti affinity

Ben Schwartz: I wanted to point out that the WebSocket spec and protocol have
things in them like binary vs text framing. So it is not just enough to create
a messaging stream and call it a drop in replacement for WebSockets. Wants to
remind people that the HTTP/2 WebSocket draft also naturally applies to HTTP/3,
continues to provide the in order behaviour. Let's develop the cleanest
protocol we can think of and rely on W3C to design an API that helps people
migrate. Victor: Thanks for the reminder about text vs binary David: Browsers
aren't going to drop WebSocket support anytime soon. Having people still use
WebSocket is still an option Bernard: What is it important to be compatible
with, the WebSockets API or the Websockets Protocol? Peter Thatcher built a
shim that demonstrated the WebSockets API over WebTransport. Also, there is a
new API (WebSocket Streams) that also uses the Websockets Protocol that is
similar to the WebTransport API (not message based). Important to be clear what
we're trying to do.

Ian: Wanted to say that the idea of messages is interesting but it seems like
there's a few different sets of use cases: ordering vs. head of line blocking
is desired, putting a message substrate on top of a stream does provide head of
line blocking but does not make it that easy to do out of order delivery
because it's hard to find the boundaries of messages. Clear requirements on
what we need here would be helpful.

Jana: Ian said mostly what I wanted to say. Recommend very lightweight streams,
could be messages, can have a "begin" and "end" bit for a stream, if you have
that as part of a message it can all fit in a packet if lightweight enough.
Design WT streams to be lightweight then you get flexibility. ??? will be
difficult.

From jabber:
Magnus Westerlund too: Well SCTP is a transprot protocol that support reliable
messages, both in and out of order. Philipp Tiesel: I definitely second the
preference for message streams over byte streams

## WebTransport using HTTP/2, Eric Kinnear
14:50 - 15:05 (15 minutes)
https://tools.ietf.org/html/draft-kinnear-webtransport-http2
https://github.com/ekinnear/draft-webtransport-http2/

### Presentation

Since IETF 107: great feedback, created some [GitHub
issues](https://github.com/ekinnear/draft-webtransport-http2/issues/), updated
to a 01 draft Concepts:
  Http2Transport provides bidirectional streams that either endpoint can
  initiate. QUIC can do this today. Coexistence with QUIC... H2 is missing some
  things that H3 has: unidirectional streams, Datagrams and especially
  unreliable ones. Clarify how much we care about ordering and HoL, who do we
  expose this to the user i.e. express this via the API
Aside: Eventually need to decide if we want to spec a QUIC equivalent over TCP
without HTTP/2.

GH issue [#3](https://github.com/ekinnear/draft-webtransport-http2/issues/3):
new streams without additional roundtrips
  New streams need a CONNECT, requiring one RTT. Do we need a routing stream
  and then stream. H2 might not be present across every hop, can we provide an
  equivalent for each mapping. The question is we we want to sovle this problem
  to open streams quickly.

GH issue [#5](https://github.com/ekinnear/draft-webtransport-http2/issues/5):
unidirectional streams
  Do we want to use half-closed streams (to align with H2's extant state
  machine)? Or simply prevent endpoints from sending data by layering the
  requirement on top in WebTransport? Establishing different types of streams
  requires metadata - does that impact our choices when mapping HTTP/3 vs QUIC.

GH issue [#6](https://github.com/ekinnear/draft-webtransport-http2/issues/6):
datgrams
  Reliability: Apps need to know what they requested vs what they got. Some
  options for this: dedicated datagram stream, new frame, WTHEADERS per
  datagram. Be good to think and challenge assumptions. Flow control: new frame
  makes it easier to reason about, interesting things can happen when reliable
  links drop data, outcome may lead us to somewhere that we are more
  comfortable making large changes to protcol.

Stream IDs:
  Resonating with Victor's earlier points. Consistency is key. Goals probably
  prevent us from relying on the stream IDs from anything underneath this layer.

### Discussion

Ian Swett: I think a lot of these questions are really good. How many do we
need to answer in order to get a technical direction?

Eric: Good question - the first half of this presentation is much of what
Victor already talked about and we need to collectively decide as a group where
we want to go. Many of the other things are just implementation issues, and we
can only decide on those after we decide on the particular direction. The big
question for today is what the layerings are that we want, and what the
destination is that we're heading towards. I defer to the chairs (David and
Bernard) for their thoughts on this.

Bernard: Victor has a presentation later that might touch on these. Any
thoughts, David?

David: I would not count on the chairs - we lack the authority to decide what
the priorities are, it needs to be decided through consensus. But perhaps we
should focus on the presentations we have, and perhaps the opportunities for
collaboration with W3C.

Bernard: We may need to spend more time. Interim meetings might be needed.

## WebTransport over QUIC, Victor Vasiliev
15:05 - 15:20 (15 minutes)
https://tools.ietf.org/html/draft-vvv-webtransport-quic

### Presentation

QuicTransport has a URI scheme
QuicTransport has an origin trial in Chrome 84-86 -
https://web.dev/quictransport (QUIC draft 27, draft-29 starting Chrome 85)
Great Transport Zoo:
  - QuicTransport
  - Http2Transport
  - Http3Transport
  - FallbackTransport (no draft currently)

Want one QUIC-based transport so we can have unrelaible datagrams, one
TCP-based transport for fallback. Decision to support QuicTransport or
HttpTransport, or both? Slide 44 has Victor's intuition on which would be best
for some use cases. Advantage of HTTP transport comes from multiplexing, e.g.
in a browser when a connection exists in a pool reuse it rather than spin up a
new independent QUIC or TCP connection. However, a dedicated connection can be
beneficial so this could be controlled at the API layer.

### Discussion

Ben: slide 44 shows an implication that a dedicated transport is more
appropriate for use cases with tight performance requirements, at least that is
my read, this is a speed thing Victor: not necessarily speed, better access to
transport properties such as congestion control Bernard: some use cases are
p2p, so don't apply to HTTP Ben: if performance of multiplexing is a problem,
you can chose not to multiplex. But if you do multiplex, then a single
congestion control algorithm can be used to manage both WebTransport and HTTP.
Victor: interesting point. There is an argument that on the same connection
that you can do meaningful prioritization

Jonathan Lennox: for HttpTransport is it anticipated that at least the client
would have to support the HTTP state machine e.g. follow a 300 redirect Victor:
I'll talk about that on the next slide

Ted: going back to what Ben said. I agree with him but have the opposite
reaction to slide 44. When I look at HTTP and load balancing, I might have use
cases where I don't want that, because the application has its own means for
things such as caching. For a use case that doesn't need properties provided by
the web (such as a datagram request/response protocol like what is used in
games or DNS), there is a good argument for providing QuicTransport that
doesn't require them to use the web.

### Presentation resumes

Advantages of HTTP transports
  - Shared metadata, can reuse HTTP headers and status codes e.g. origin,
  location + 3xx status, forwarded (useful for load balancing),
  :path/:authority/:scheme - Counterpoint: similarity of HTTP can lead to wrong
  expectations.

Disadvantages of HTTP transports
  - Requirements for HPACK and QPACK
  - Multiplexing and socket pools makes things hard in browsers
  - Need to define interaction with existing HTTP mechanisms, especially
  something like Alt-Svc - how to decide when to switch between HTTP transports
  and QuicTransports - Pooling and flow control can lead to DoS, example given
  related to stream concurrency - Stats are easier to define with dedicated
  connections

Implementation experience
  - QuicTransport
    - Implemented in Chrome, various server implementations, easy to implement
    on an existing python library
  - HttpTransport
    - Implementations at Apple and Facebook, no in-browser clients yet

Use cases
  - Both options satisfy WebTransport requirements: datagrams and streams
  - Other aspects make each individual transport a better fit
    - HTTP-based options help operators of large server setups
    - Implementers work on niche platforms where it is useful to minimise
    complexity and implementation requirements, so preference for QUIC-based
    option

Beyond wire protocol
  - What URL scheme? Determines whether WebTransport and HTTP are same-origin
  - High level concerns: cookies, HTTP auth, TLS client certs, Alt-svc and
  socket pools

Next steps
  - Current discussion is between two options "only QUIC", "only HTTP"
  - Need more input, continue discussion on list, potential focus of an interim?

### Further discussion

Yutaka: I didn't mention on mailing list, I am not opposed to having both
QuicTranport and HttpTransport

David: interested in folks that have opinions on which protocols they want to
build, so we can start making progress

Phillip Tiesel: question whether the transports are end-to-end or if proxies
can convert protocols Victor: possibly. Converting between H2 and H3 is
straightforward. Converting H3 and QUIC is harder because we'd need to describe
how to map things like metadata. If metadata is available to both, we'd need to
understand why there is an advantage to defining both.

Erik: it would seem preferable to avoid having all four and avoid the pressure
to implement all 4. It would be easier/more flexible to use reuse headers etc
so the H2/H3 model seems better. Ben's mention of a profiled HTTP seems like a
option. Ben: I wonder how hard it would be to expose the WebTransport semantics
in ??? raw framing Victor: it would not be that hard Ben: we should make it
possible to implement as either endpoint without having to implement a full
HTTP stack. For example, I could write a simple Http3Transport client that
could even speak to a full HTTP server that is also an Http3Tranport. Ted: I
tend to think it is entirely possible to define such a profile for a client.
But I don't think there a good chance that it will *only* go into an
environment that would treat it special/ any different to any other HTTP
client. Build on a bare transport would avoid this. ??? middleboxes

From jabber:
  Ben: can we profile down Http3Transport for Webtransport-only use cases e.g.
  minimise required methods i.e. make it possible to implement a
  WebTransport-only server Eik: Upside to muxing: lots of those apps
  (IoT/streaming/etc) also make HTTP API calls today and may continue to do so.
  Downside to muxing with H2/H3: some non-spec-compliant clients/servers will
  (continue to) make bad assumptions about multiple requests sharing a
  connection and having connection-associated state.

## WebTransport over HTTP/3, Victor Vasiliev
15:20 - 15:35 (15 minutes)
https://tools.ietf.org/html/draft-vvv-webtransport-http3

### Presentation
Rolled into previous segment
### Discussion
Rolled into previous segment

## Wrap up and Summary, Chairs & ADs
15:35 - 15:50 (15 minutes)

Bernard: Please help in answering these questions by continuing discussion on
the list. An interim meeting may be in order. David: Will take a lot of these
questions to the list. Interim will also be discussed on the list.

Thank you everyone!