Re: [dispatch] Dispatching WebTransport

[Peter Thatcher <[e-mail]>]

On Mon, Jun 17, 2019 at 7:52 AM Sergio Garcia Murillo <
[e-mail]> wrote:

> From the draft:
>
>    WebTransport [OVERVIEW <https://tools.ietf.org/html/draft-vvv-webtransport-quic-00#ref-OVERVIEW>] is a protocol framework that enables clients
>    constrained by the Web security model to communicate with a remote
>    server using a secure multiplexed transport.
>
>
> Although while I agree with your analysis regarding current webrtc dc and
> sctp status, if this is a pure client-to-server transport, why is webrtc
> mentioned in the background at all? shouldn't this be a replacement of
> websockets and NOT of the webrtc datachannels?
>

It's both a better WebSocket and a better RTCDataChannel.  Take your pick
of how you look at it.


> Best regards
> Sergio
>
>
> On 17/06/2019 15:35, 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 [e-mail]://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>