Subject: [dispatch] Dispatching WebTransport

From: Victor Vasiliev <[email-masked]>
Date: Mon, 17 Jun 2019 09:35:37 -0400

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

---

From: T H Panton <[email-masked]>
Date: Mon, 17 Jun 2019 15:12:56 +0100

> On 17 Jun 2019, at 14:35, Victor Vasiliev <vasilvv=[email-masked]> wrote:
> 
> 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.

Establish connections to where ? Between eachother P2P ? Or to any server? Or just to the originating server only? 

> 
> # 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:
> 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.
> 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).

Much, but not all, of the complexity of the webRTC stack is due to the NAT traversal and security commitments you need to do P2P. If you exclude the need to do NAT traversal and P2P
then it _could_ be much simpler. But it also gives you E2E encryption and low latency as side effects!

Work is in progress decoupling the APIs from the (dreaded) SDP and simplifying the developer experience.

That said, it is by no means un-managable - I've implemented pretty much the whole stack from scratch for small devices and I know of 2 other implementations which don't use libusrsctp 

> 
> 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).

SCTP is well defined nice protocol that suffers (IMHO) from a lack of 'coolness' due to being used by the telcos for most of it's life.
The head-of-line issue is a problem, but entirely fixable with small tweaks to SCTP protocol. (read it wasn't in the original requirements - so it doesn't do it).

> 
> 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.

I'd point out that 2.5bn endpoints support it right now - including _every_ smartphone shipped in the last 2 years. Last I heard DataChannel traffic was 0.1% of chrome's traffic 
which is _astonishingly_ high

> 
> # 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.
> 

It would be _great_ if that abstraction could _also_ work over SCTP data channels. That way you could cover the P2P use cases too.

> 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 <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 <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 <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'd really like to be clear what that problem is. 

> 
> 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.

Tim.

> 
> Thanks,
>   Victor.
> 
> [0] https://github.com/WICG/web-transport <https://github.com/WICG/web-transport>
> [1] https://discourse.wicg.io/t/webtransport-proposal/3508/9 <https://discourse.wicg.io/t/webtransport-proposal/3508/9>
> [2] https://news.ycombinator.com/item?id=13266692 <https://news.ycombinator.com/item?id=13266692>
> [3] https://github.com/quicwg/base-drafts/wiki/Implementations <https://github.com/quicwg/base-drafts/wiki/Implementations>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jun 2019 10:33:55 -0400

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:
> 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
> 
> 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:
> 
>     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.
>     information.  They usually use some in-house UDP-based protocol, and
>     often need to run on unusual platforms. 
> 
> 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.
> 
> 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
>     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.
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 17 Jun 2019 16:52:38 +0200

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:
> 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
>
>     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.
>
> 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.
>
> 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 
> 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).
>
> 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.
>
>     described in
>     https://tools.ietf.org/html/draft-vvv-webtransport-quic-00
>   * 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
>
> 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.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Jun 2019 17:01:34 +0200

On Mon, 17 Jun 2019 at 16:52, Sergio Garcia Murillo
<[email-masked]> wrote:
>
> From the draft:
>
>    WebTransport [OVERVIEW] is a protocol framework that enables clients
> 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?

I assume WebRTC is mentioned there because currently it's the only way
to have P2P data messaging in the Web. With QUIC + RTCIceTransport we
have RTCQuicTransport, which can be used for P2P data messaging
between browsers without depending on a WebRTC PeerConnection.

So if I'm not wrong, WebTransport will provide:

1) QuicTransport, which is a QUIC based communication between the
browser and a server. It may use streaming or datagram based messaging
(if QUIC-datagram spec becomes real). It does not use ICE at all and.

2) RTCQuicTransport, which is a QuicTransport created with a
RTCIceTransport, so suitable for two browsers to communicate in P2P
fashion. And the same: QUIC streaming or datagrams. No PeerConnection
here.

Whether SCTP can be used or not in this new model is unclear for me.
SCTP does not provide security/encryption, so SCTP packets should be
put on top of DTLS (as we do in WebRTC) or on top of QUIC (so it
should be QUIC-datagram to properly frame those packets) which does
not make any sense since it provides nothing that QUIC-datagram
already provides.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 18 Jun 2019 18:04:07 -0400

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