Re: [dispatch] Dispatching WebTransport

[Sergio Garcia Murillo <[e-mail]>]

 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?

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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch