Re: [dispatch] Dispatching WebTransport

[Victor Vasiliev <[e-mail]>]

That is definitely one of the things at the core of the problem; however,
that is a symptom, rather than a root cause.

The question here is not about existence of any single library, but rather
about a viable ecosystem.  WebSocket definitely has one ([0], [1]), and
RtcDataChannel does not, nor it appears on track of getting one any time
soon.  The hope here is that WebTransport will get one by virtue of
removing a whole bunch of complexity not required in the client-server case
(SDP and ICE), and piggybacking on the QUIC ecosystem for the rest.

[0] https://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations
[1] https://github.com/facundofarias/awesome-websockets

On Mon, Jun 17, 2019 at 10:34 AM Paul Kyzivat <[e-mail]> wrote:

> ISTM that your problem description below boils down to:
>
> There isn't a suitable library that provides a convenient interface to
> use data channels.
>
> So why don't you concentrate on creating such a library?
>
>         Thanks,
>         Paul
>
> On 6/17/19 9:35 AM, Victor Vasiliev wrote:
> > 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
> >
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>