Subject: [Hls-interest] Feedback requested on WebTransport usage with HLS

From: "Law, Will" <[email-masked]>
Date: Fri, 11 Dec 2020 19:50:48 +0000

WebTransport is a standard being developed by the IETF [1], with the browser API being developed at W3C [2] with a latest draft [3] available. Within the WebTransport framework, two protocols are being considered  - QUICTransport and HTTPTtransport. Both are built on top of QUIC as  shown in the draft network stack diagram below. Both allow for the establishment of bi-directional and uni-directional reliable streams, as well as the unreliable transmission of datagrams. A working demo under Chrome v88+ (after you enable  Experimental Web platform features) is available at https://webrtc.internaut.com/quic/newtrial.html.

The primary differences between the two transports are summarized below:

HTTP3Transport

  *   Pooled with other HTTP3 traffic
  *   Inherits HTTP features such as load balancers, headers, firewall & proxy support
  *   Suggested target applications – general web, chats, pub/sub++

QUICTransport

  *   Dedicated connection between client and server. Server can optimize transport
  *   No HTTP3 dependency
  *   Suggested target applications – streaming video games, real-time media

The W3C WebTransport WG [2] is seeking feedback from the HLS community around the following questions:

  1.  Is WebTransport potentially useful for HLS?
  2.  Is there a preference for using HTTPTransport or QUICTransport?
  3.  Are there missing APIs in the current draft [3] that would be necessary for HLS to leverage WebTransport under a browser user-agent?

We are at the early (and hence optimal) point in which to inject these requirements and look forward to your feedback. Feedback to this thread will be collated and relayed as appropriate to either the IETF and/or W3C.

[1] - https://tools.ietf.org/html/draft-ietf-webtrans-overview-01
[2] - https://www.w3.org/groups/wg/webtransport
[3] - https://w3c.github.io/webtransport/

Cheers

Will
Co-Chair – W3C WebTransport WG

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 12 Dec 2020 10:47:07 +1100

My .02 - WebTransport is a low-level abstraction; effectively, it's WebSockets 2.0. That means that all that's exposed is a bidirectional stream; things like caching won't be exposed (and that's true with HTTP3Transport; the capabilities of HTTP aren't exposed in WebTransport).

As such, support from intermediaries like CDNs will be limited to basic functions like forward routing, DDoS protection, etc.; it won't be possible for them to know what's 'inside' the stream and do things like serve many clients from one forward stream.

It's true that standards for doing that work on top of WebTransport could be established, just like HTTP does for TCP (and now QUIC). However, I'd observe that hasn't happened to date for WebSockets. 

That said, I understand that some larger video platforms are experimenting with WebTransport, because it gives them more control over the stack. One possible future is that what they come up with coalesces into a de facto standard that gets supported and used elsewhere. However, that would be starting from a much lower base of support/interop than HLS; my understanding is that HLS uses HTTP precisely because it can be supported by CDNs and other parts of the ecosystem 'out of the box.' 

Anything's possible, of course, but one concern I have is that allowing big video platforms to define what's effectively a replacement for HLS gives them a lot of leverage in its design, which could very well favour them over smaller parts of the video ecosystem.

Cheers,

> On 12 Dec 2020, at 6:50 am, Law, Will <wilaw=[email-masked]> wrote:
> 
> 	• Pooled with other HTTP3 traffic
> 	• Inherits HTTP features such as load balancers, headers, firewall & proxy support
> 	• Suggested target applications – general web, chats, pub/sub++
>  
> QUICTransport
> 	• Dedicated connection between client and server. Server can optimize transport
> 	• No HTTP3 dependency
> 	• Suggested target applications – streaming video games, real-time media
>  
>  
> 	• Is WebTransport potentially useful for HLS?
> 	• Is there a preference for using HTTPTransport or QUICTransport?
> 	• Are there missing APIs in the current draft [3] that would be necessary for HLS to leverage WebTransport under a browser user-agent?
>  
> -- 
> Hls-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest

--
Mark Nottingham   https://www.mnot.net/

---

From: Roger Pantos <[email-masked]>
Date: Mon, 14 Dec 2020 09:19:46 -0800

> On Dec 11, 2020, at 11:50 AM, Law, Will <wilaw=[email-masked]> wrote:
> 
> WebTransport is a standard being developed by the IETF [1], with the browser API being developed at W3C [2] with a latest draft [3] available. Within the WebTransport framework, two protocols are being considered  - QUICTransport and HTTPTtransport. Both are built on top of QUIC as  shown in the draft network stack diagram below. Both allow for the establishment of bi-directional and uni-directional reliable streams, as well as the unreliable transmission of datagrams. A working demo under Chrome v88+ (after you enable  Experimental Web platform features) is available at https://webrtc.internaut.com/quic/newtrial.html <https://webrtc.internaut.com/quic/newtrial.html>.
>  
>  
>  
> Pooled with other HTTP3 traffic
> Inherits HTTP features such as load balancers, headers, firewall & proxy support
> Suggested target applications – general web, chats, pub/sub++
>  
> QUICTransport
> Dedicated connection between client and server. Server can optimize transport
> No HTTP3 dependency
> Suggested target applications – streaming video games, real-time media
>  
>  
> Is WebTransport potentially useful for HLS?
> Is there a preference for using HTTPTransport or QUICTransport?
> Are there missing APIs in the current draft [3] that would be necessary for HLS to leverage WebTransport under a browser user-agent? 

Hello Will, thanks for the heads-up.

I took a quick look at the WebTransport overview. My impression is that it’s focused on enabling bidirectional communication between endpoints. I don’t currently have anything in mind for HLS that would fit that model. But I’ll keep it in mind as an option if anything comes up.

Roger.

> [1] - https://tools.ietf.org/html/draft-ietf-webtrans-overview-01 <https://tools.ietf.org/html/draft-ietf-webtrans-overview-01>
> [2] - https://www.w3.org/groups/wg/webtransport <https://www.w3.org/groups/wg/webtransport>
> [3] - https://w3c.github.io/webtransport/ <https://w3c.github.io/webtransport/>
>  
>  
> Cheers
>  
> Will