[dispatch] Dispatching WebTransport

[Victor Vasiliev <[e-mail]>]

Hello friendly IETF dispatchers,

I am writing about new work I want to bring to IETF.  The proposal is
called WebTransport.  It’s a combination of a Web API currently under
development in W3C WICG [0], a protocol framework and some protocols that
fit into that framework.  Combined, they would allow web applications to
establish WebSocket-like connections that instead of ordered reliable
messages use multiple streams and datagrams (datagrams are unreliable and
streams do not have head-of-line blocking).  This is highly useful for
real-time and other latency sensitive applications.

# Background

Historically, the only networking operations available to the Web
applications were sending HTTP requests and receiving HTTP responses.  That
model does not fit all applications well, so over time, more mechanisms
were added.  The two most relevant here are WebSockets (RFC 6455) and RTC
Data Channels (draft-ietf-rtcweb-data-channel).  WebSockets are a way for
Web applications to do bidirectional communication over a TCP connection;
they work great if TCP fits your transport needs, but perform poorly if
your application is latency sensitive and would, in non-Web context, use a
UDP-based protocol.  There are many different kinds of applications like
that, but I would like to highlight two major categories which I to some
extent surveyed when coming up with this proposal:

   1. Custom client-server chat/multimedia protocols (faster-than-DASH
   video streaming, game streaming, etc).  Those are usually developed by
   teams with a good amount of resources, and they are interested in tailoring
   the setup for their use case.
   2. Game developers.  Online games are commonly real-time in nature and
   benefit dramatically from ability to give up on transmitting old
   information.  They usually use some in-house UDP-based protocol, and often
   need to run on unusual platforms.

WebRTC Data Channels are a mechanism that provides a WebSocket-like
interface with unreliable delivery features.  On the wire, it’s
SCTP-over-DTLS, established using ICE and SDP.  In theory, this provides
users with enough functionality to build anything they need, since SCTP
messages can be unreliable and unordered.  In practice, while
RtcDataChannel is fairly straightforward to use for browser-to-browser
peer-to-peer communication, it has seen much lower adoption than WebSockets
in the client-server scenario, even considering the fact that its use cases
is naturally more niche.

The main reason for this is the incredible complexity of the WebRTC stack.
WebSockets are a fairly straightforward overlay on top of TCP and TLS;
there is a wide variety of implementations out there, and it's fairly easy
to write a new one (I wrote on myself in less than 1,000 lines of C++).
With data channels, however, once there is no browser to abstract all of
the complexity away, the web developers are required to understand and
implement (or at least integrate) SDP, ICE, STUN, DTLS and userspace SCTP.
While a lot of those have simplifications for this use case (ICE Lite) and
some protocols listed have a variety of implementations widely available
(DTLS), the entire system still requires going through hundreds of pages of
RFCs in order to understand it well enough to implement.  This complexity
barrier has precluded Data Channel adoption by communities of smaller
developers who don’t have resources to implement them, notably game
developers (see [1] and [2] for some discussion).

Even among the people who got past the complexity barrier, the feedback I
heard almost universally is that WebRTC Data Channels are hard to work
with.  From the feedback I gathered, the main problem is usually around the
transport protocol itself.  Userspace SCTP is essentially a monoculture:
virtually all implementations use libusrsctp, a 80,000-line adaptation of
FreeBSD SCTP implementation.  This lack of tool choice is fairly painful
since latency-sensitive real-time applications often require quite a bit of
tuning on the transport side to get the best performance (custom congestion
control, etc).  In addition, the limitations on the message size stemming
from both the API itself and the lack of widespread support for message
interleaving (RFC 8260) means that the developers have to roll their own
framing on top of SCTP messages if they want to avoid head-of-line-blocking
(this is particularly bad because the framing overhead in data channels is
already large as-is).

In summary, we have a system that technically provides what everyone wants,
but that nobody is happy with, and that is not usable by all but the most
well-resourced users.

# Proposal

Our initial idea for fixing this was to take QUIC and do what WebSocket did
to TCP: add security features that would make it safe to expose on the Web
(by adding origin checks, etc), but otherwise expose it as-is.  This would
get us out of libusrsctp monoculture (QUIC is not yet finished, but
it already has a fairly diverse implementation ecosystem, see [3]), and
remove all P2P-related complexity involving SDP and ICE.  The original
proposal for that was called QuicTransport; we showed it to various people,
and the feedback we got is that (1) the API should not be tied to a
particular transport (since we already switched once from SCTP to QUIC,
tying it to QUIC specificially would not be wise), and (2) it shouldn’t
fail hard when QUIC is unavailable.

As a result of that feedback, we abstracted it into a general-purpose
framework called WebTransport.  The overview draft,

  https://tools.ietf.org/html/draft-vvv-webtransport-overview-00

describes the framework itself, mainly the requirements the transport
protocols have to satisfy to be usable on the web through the API.  Within
this framework, we propose the following protocols:

   - QuicTransport -- a simple WebSocket-like adaptation of QUIC, described
   in https://tools.ietf.org/html/draft-vvv-webtransport-quic-00
   - Http3Transport -- a mechanism that allows creating custom non-HTTP
   streams within an HTTP/3 session, described in
   https://tools.ietf.org/html/draft-vvv-webtransport-http3-00.  This is
   sort of a version of RFC 8441 for QuicTransport.
   - FallbackTransport -- a TCP-based transport with multiplexed streams
   that can be used when QUIC is not available (e.g. on network that require
   CONNECT proxy).  We don’t have a draft specifically for this, and there are
   at least two approaches we could take here: either reusing HTTP/2 as a
   transport (i.e. just use draft-kinnear-httpbis-http2-transport), or
   building a protocol with QUIC-like semantics on top of WebSockest.  The
   earlier is a more straightforward way; the latter has the advantage of
   being fully polyfillable in JavaScript.


# Discussion

At this point, I am fairly certain that there is a problem here that needs
to be addressed.  I am formally requesting ART area to take this problem on.

I believe the drafts above would be a good starting point for discussion.
The design that they describe went through several iterations based on the
feedback I got when I discussed this work within a more narrow audience
(mostly people in QUIC working group), so we’re hopefully at least looking
in the right direction here.  I am requesting feedback on this proposal,
both on the overall plan and the specifics described in the drafts.  I hope
to discuss this in depth in Montreal, both at dispatch and (in more depth)
at a side-meeting.

Thanks,
  Victor.

[0] https://github.com/WICG/web-transport
[1] https://discourse.wicg.io/t/webtransport-proposal/3508/9
[2] https://news.ycombinator.com/item?id=13266692
[3] https://github.com/quicwg/base-drafts/wiki/Implementations