Re: [dispatch] Dispatching WebTransport

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
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 