Skip to main content

Minutes interim-2021-webtrans-01: Tue 08:00
minutes-interim-2021-webtrans-01-202101120800-00

Meeting Minutes WebTransport (webtrans) WG
Date and time 2021-01-12 16:00
Title Minutes interim-2021-webtrans-01: Tue 08:00
State Active
Other versions plain text
Last updated 2021-01-12

minutes-interim-2021-webtrans-01-202101120800-00
**WEBTRANS WG Virtual Interim Minutes**

January 12, 2021
8:00 AM - 9:30 AM Pacific Time
Meeting URL: https://meet.google.com/yux-tvmm-jpj
Slides:
https://docs.google.com/presentation/d/1KT4zaQuNbKwXDbc3q6Ph4uFJtOPzL6MBKi74hUXUVz8/

Scribes: Robin Marx, Spencer Dawkins

# Preliminaries
10 minutes - Chairs

Note Well
Jabber Scribe, Note Takers
Speaking Queue Manager (David Schinazi)
Agenda Bash

W3C Update
- Summary of meeting provided, see slides

# The WebTransport Protocol Zoo
65 minutes - Victor Vasiliev

[draft-ietf-webtransport-overview](https://tools.ietf.org/html/draft-ietf-webtransport-overview)
[draft-vvv-webtransport-quic](https://tools.ietf.org/html/draft-vvv-webtransport-quic)
[draft-vvv-webtransport-http3](https://tools.ietf.org/html/draft-vvv-webtransport-http3)

[slides](https://docs.google.com/presentation/d/1KT4zaQuNbKwXDbc3q6Ph4uFJtOPzL6MBKi74hUXUVz8/)

## Presentation

**Victor**: 4 different proposals for protocols. Question is which we do, if
any?

**Victor**: Make things easier for now by considering only UDP-based options:
QuicTransport (QUICT) and H3Transport (H3T). Unable to choose any at this time.
Mainly because they're very similar, not clear which to pick. Both have
fundamentally same principles because both run on QUIC. QuicTransport got more
like H3Transport with every iteration. So do we do both or just one? If both:
double code, double maintenance, etc.

**Victor**:  Why two options in the first place? Initially they were very
different, but now they're so similar it would be redundant to do both. Main
difference at this point is pooling: default by design in H3Transport, not in
QuicTransport (though nothing prevents QuicTransport from having pooling and
would likely grow into it over time. H3Trans has it but no requirements to use
it).

**Ben Schwartz**: clarification: are you implying QuicTransport could be pooled
with H3?

**Victor**: No: QuicTransport could be pooled with QuicTransport. May or may
not be sufficient: e.g., traffic concealment probably not, but for operational
reasons to reduce #connections: yes

**Victor**: (next slide) Comparison of handshakes of two options. Roughtly the
same thing, only some details different. a) QuicTransport has bespoke H3-alike
things in the handshake (no SETTINGS, no header compression, but does
effectively has headers) b) H3T has additional complexity which would have to
be dealt with (mainly header compression QPACK). There is a proposed extension
however to turn this off.

## Discussion

Note: Martin Thomson couldn't join, but posted some thoughts on the mailing
list ahead of time, [see
here](https://mailarchive.ietf.org/arch/msg/webtransport/do6GKRKxGb0fYMRVIMAo0bhtU6g/)

**Jeff Morrison**: can someone list complexities in H3 that QuicTransport
avoids?

**Victor**: additional framing + pooling. H3 by design can be pooled. I assert
we don't always need pooling, and pooling has some inherent complexity.

**EKR**: a) I thought ... in Q got missed b) channeling Martin Thomson: he
feels H3 complexity is not worth it. c) I'd be interested in understanding
interaction between QuicTransport, H3T and DATAGRAM work in MASQUE WG. Defining
a number of similarly looking DATAGRAM things; seems not-awesome. Sad to have
two separate things if we can prevent it.

**David Schinazi**: replying to point c as MASQUE enthusiast. Agree: we
shouldn't define same thing in multiple places. Right now we split out some
things from CONNECT-UDP into its own H3-DATAGRAM in masque and hope we can
reach consensus on this on both wgs, so it can act as shared layer. Will see
how things go in MASQUE WG.

**EKR**: does that imply H3T is more attractive because of that?

**David**: that just gives you multiplexing over H3 datagrams. It enables H3T
and connect-udp to co-exist on the same connection if someone wanted to do
that. It makes H3T feasible

**EKR**: is that duplicative of work in WEBTRANS WG?

**David**: H3 has a lot of features that QuicTransport would have to rebuild
and this is one of them: de-multiplexing datagrams is something H3 will have,
but not QuicTransport.

**Ben Schwartz**: even if drafts can share H3 DATAGRAMS, still lots of
duplicate discussion here and in masque. e.g., connect-udp defines its own
DGRAM-to-TCP fallback syntax that's providing same syntax as what we'd have
here as fallback transport. So repeating invention of core concepts here.

**Luke Curley**: replying to Ben: purpose of fallback is compatability; people
using websockets to use the new API. I prefer QuicTransport because how many
connection-oriented things are in QUIC. Just a few things at Connection level;
simplicity is that it's its own QUIC connection: don't need to figure out
shared/pooled de-multiplexing, flow control, etc. I vote QuicTransport because
it owns the connection and doesn't have to share.

**Victor**: I do believe WebTransport has to provide a mode in which we would
use only one transport per connection (many reasons for this). Not that much of
a problem afaict: just open H3 connection and send only 1 request; looks
exactly like QuicTransport, just don't send other requests. In browser it might
look different due to fancy logic, but that's implementtion detail in browser.
Agree there are lots of conn-level options and we should provide flag to
indicate to WebTransport APIs that this should not be pooled or make it
un-pooled by default.

**Luke Curley**: In TCP there's a clear benefit to pooling, but not really in
QUIC? Maybe just shared congestion control state? But under the hood only the
conn-id changes. Are we just doing pooling because we've always done it?

**Victor**: one of the big reasons for pooling is that people want to save on
memory consumption and open sockets.

**Eric Kinnear**: wrt masque + WebTrans: we discussed this. We feel WebT could
do fallback to MASQUE using just H3 DGRAMS. Or you could make an argument that
there is a better argument ... Not as worried about duplication if it actually
buys us something, but wouldn't want to do double work to get same outcome.

**Alan Frindell**: a) Luke mentioned fallback was only for people currently
using websockets: disagree. API in the browser will be available when QUIC is
there but not always there... networks block it. Having JS working even if QUIC
isn't there is important. But shouldn't spend too much time on that here. b)
wrt pooling: Martin Thomson mentioned a number of complexities in H3T. Huge
amount comes from pooling; so if we remove that for now and focus on
QuicTransport vs H3 we can revisit that later. prefer H3 because allows some
things that are not possible with QUIC.

**Ben Schwartz**: Favor H3T because ossification and privacy concerns. Lot of
networks that for whatever reason permit things that look like web traffic but
make it difficult to establish other types of connections. So if WebT doesn't
look like H3T there might be (more) networks where it doesn't work.

**Lucas Pardue**: Complexity of H3T is really reduced if we get rid of pooling.
Diff then is mainly how much we want to re-invent in QuicTransport (e.g., HTTP
headers). I'd prefer to keep H3 headers for example and lean towards H3T
without pooling and some other things

**Eric Kinnear**: Would agree with Lucas. One of the main things we discovered
is that we kept adding pieces (e.g., we need some key-value pairs to negotiate
some things). So we now have a minimal version of some H3 concepts. But very
limited delta between minimal and full H3.

**EKR**: repeating what Eric and Ben and Lucas just said. Sad as it is that we
have ALPN for H3 ... There's complexity cost of our design work +
implementation work, but history of H3 shows people are more comfortable
profiling down HTTP than building new protocols. Given that we'd be better off
doing H3 rather than doing something new in QuicTransport that's 73 percent of
H3. But no strong pref.

# Hums, Wrap up and Summary
15 minutes - Chairs & ADs

## Hums
(using Google Meet poll feature, need test poll to see if it works as expected)
18 votes in the test hum, 9/9 split, no consensus

25 total participants at the time of the first Hum (David cannot vote himself)

for hum text details, see the
[slides](https://docs.google.com/presentation/d/1KT4zaQuNbKwXDbc3q6Ph4uFJtOPzL6MBKi74hUXUVz8/)

1. Hum 1: Should we build one or both?
**David**: note: not necessarily tied to Victor's current drafts, voting on
main concepts here

**David**: 22 people voted. 17 say build one, 5 say build both. Can folks who
want both state why?

**Yutaka Hirano**: Still think having both would be beneficial for server
implementers who want just simpler protocol.

**Luke Curley**: I voted only one, but Yutaka has a point: very easy to get
something going on top of QuicTransport with a QUIC library. Nice to have that
ease of development. Eventually however there will also be libraries on top of
H3T, but having multiple protocols still allows easier implementation.

**David**: Def standardization cost and as developer of course also big cost if
you want both...

**Eric Kinnear**: If we think that 1 is more complicated than the other ,doing
both is the worst of both worlds. In this case I'd even more strongly want to
just do 1. Most QUIC libraries currently also provide H3, so that wouldn't be
too much extra effort. IF we would ask people to do QUIC and add "baby version
of H3" for QuicTransport is more difficult than adding H3T to an H3 library.

**Ben Schwartz**: For Luke: does your application need QuicTransport as a layer
or would it be reasonable to build it on top of plain QUIC on both ends? And if
you do need QuicTransport: is it valuable to have that as a standard or just an
element of the proprietary system?

**Luke**: need browser support, that's the main reason for QuicTransport
instead of QUIC. Could def have an in between where browser supports something
intermediate. Happy to move to single finalized transport later on.

**Victor**: having both transports is not just difficult for browser vendors,
but also more chance people will write more libraries for servers. Would also
make life more difficult for those people to support both.

**David**: What I'm hearing is that majority prefer to only build one. Some
folks think it might be worth doing both. But not hearing an absolute
requirement for both. Good path forward is continue with just one. Doesn't
preclude us from later down the road add a second one if needed. If anyone
doesn't like this, get in the queue.

**Spencer**: Pleased that the discussion has morphed into what got standardized
vs what got adopted for now. Even beyond that if you adopt both and publish one
as experimental: signals that people may want do to this, but that's not the
way going forward. Chairs can also prioritize work on one proposal in the same
way MASQUE is doing now between CONNECT-UDP and IP-CONNECT. Think David's
proposal is a good way forward.

2. Hum 2: Directly over QUIC (similar to QUICT) or over HTTP/3 (similar to H3T)

**David**: note again: not necessarily tied to Victor's current drafts, voting
on main concepts here. Not tied to exact QuicTransport/H3T that we have at the
moment.

**David**: (still 25 participants) 19 responses: 13 for H3, 6 for QUIC.
Definitely seem to have a preference in the room. Seems like we have some
consensus emerging. Folks that voted QUIC, can you state why and how strongly
you feel about this?

**Mirja**: (via chat): I am undecided and won't vote at this time.

**Ian Swett**: No super-strong feeling; voted for QUIC directly because don't
understand benefits of H3 over QUIC. If someone can explain this beyond "I'm in
a browser, so why wouldn't I used H3". If does turn out we really do have to
implement many things similar to HTTP headers, I can live with it

**David**: Main benefit is we get several features for free that we would have
to rebuild otherwise (e.g., headers). Other benefit: could later be multiplexed
with H3 requests on the same connection (pooling?) would be easier to do over
H3 but not possible for QuicTransport, so better for extensibility later.

**Ian**: That statement scares me, but willing to ignore that for now

**Victor**: Not just have to rebuild but already have rebuilt quite a bit of
it, so that's why we moved more towards H3 over time

**Luke**: main thing with H3: as long as there is no pooling QuicTransport
makes some sense, but when adding pooling it's yeah, we should do H3 ... so my
vote was more for pooling vs non-pooling instead of QUIC vs H3. So without
pooling, I'm on board with H3. Do think that the downgrade is more complex, but
nothing too bad.

**Bernard Aboba**: question: QuicTransport has been very convenient for API
testing. Would it be possible to replace with H3 in a short amount of time? Not
having tests for a year or two would be real problem.

**Victor**: Hopefully, but right now QuicTransport is the only protocol that
has been implemented, so that is the only protocol we can test. At some point
we should translate the tests to H3, and the tests we do run should translate
semi-transparently.

**David**: getting a sense that we have some pretty good consensus to do
something over H3. Again: doesn't preclude doing something over QUIC later, but
seems like the room has consensus for now.

**Ian**: clarification question: intent to do H3 and then use some sort of
downgrade mechanism to eliminate pooling with other requests or other
WebTransport sessions or...?

**David**: two separate things there: a) will have a way over H3 to say you
want to do WebTransport (e.g., in Victor's proposal it's using the CONNECT
method). Way to say we want to do WebTrans on multidir stream b) (missed this,
was about pooling). Can indicate that client SHOULD NOT pool this. If we later
do want to add pooling, can add something to the W3C API allowing clients to
opt-in to pooling then. For now to disable pooling, browser just does this by
default; just opens a new connection every time.

**Ian**: That's fine

**Alan Frindell**: H3T draft as written now has bunch of machinery to enable
pooling (e.g., stream that enables CONNECT stays open etc.) How we move forward
on pooling does strongly impact shape of H3T draft. IF we decide pooling is
never needed, we can remove all that.

**David**: Once we have a document adopted, that will indeed be an important
question.

**Ben Schwartz**: responding to David as pooling exposed by JS API. Another way
we could do this is by having an option in the HTTP/3 settings where the server
opts in to this kind of connection pooling. Server would have a way to indicate
this and it's transparently handled between server and browser client. If
either doesn't want to do pooling, it doesn't happen.

**David**: Note: server controls the JS, so multiple ways to solve this problem.

**Luke**: Don't understand the statement it could be optional. That implies we
have it, but just don't enable it in the browser. That seems like the worst
option: do all the work and not use it!

**Victor**: Well, there is framing/multiplexing support for pooling, but that's
not the difficult part of pooling. Difficult areas is about prioritization and
sharing limited resources (also a really difficult problem for normal H3). If
you have dedicated connection you could get rid of those pooling framing
amenities for less overhead and we've already considered having that in the
draft

**Luke**: makes sense. Still vote strongly for no-pooling

**EKR**: Range of options here a) make it impossible to pool b) just not do it
and do it later c) do it d) mandate it. Feel like nobody wants to do d) and
major cost of c) should be bypassed. a) would also not be advisable, so I'm in
favor of b) (having trivial options to add it later). There's also value in
having mechanisms to determine if pooling is enabled/possible or not. Re david:
server doesn't always have full control over JS doing this, so seperate
settings needed. But think it's a solvable problem, so it's viable to say
"let's figure it out later".

**David**: Victor made important point: 2 parts to pooling: wire format vs
prioritization/flow control etc. For first, we can add this in a simple way:
something like CONNECT is easy + demultiplexing DATAGRAMS is what we're doing
in MASQUE. So having wire format to enable pooling later, but by default now
just don't and add later, we can get best of both worlds: leave options open
but don't handle complexity now.

**Will Law**: re David's comment on the server controlling JS. This is not
always true: server serving JS is not always the one to terminate H3T
connection. Application dictates JS: needs to be able to request pooled
connection and needs some feedback whether this is possible or not.

**Victor**: I believe that correct design for pooling is having opt-in from
both JS and the server.

**David**: Agree; addresses Will's concerns.

**Will**: I concur

**Alan**: a) pooling is an optimization and have a hard time imagining
applications requiring pooling to function properly. b) prioritization is
indeed hard, but if you really have two different WebTrans sessions that are
going to the same place and putting them on two separate connections, going to
be sharing the same resource either way. So end up with the same end result.

**Ben Schwartz**: Draw parallel to WebSocket over H2: doesn't provide explicit
way to provide pooling, but it is done automatically while H1.1 WebSockets are
not pooled. Essentially right design decision is to leave it do the application
transport layer to figure out how those connections are made. For applications
that want to opt-out of pooling we already have a specific way to do this:
specify different origins or domain names for these destinations.

## Wrap-up

**David**: made lots of progress today. Had consensus in the room. Starting
with only building one protocol based on HTTP/3. Will send email to confirm
consensus on the list, probably for 2 weeks. If that is confirmed, we'll see
which documents we want to adopt as working group items.