41–50 of 125 posts
Webtransport on Firefox currently has issues See: https://bugzilla.mozilla.org/show_bug.cgi?id=1969090
Semi-related and just FYI for Firefox users who visit Cloudflare-hosted, HTTP/3-using sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Earlier quoted context omitted.
Chrome and Firefox support WebTransport. Safari has announced intent to support it and they already use QUIC under the hood for HTTP/3. Cloud services are pretty TCP/HTTP centric which can be annoying. Any provider that gives you UDP support can be used with QUIC, but you're in charge of certificates and load balancing. QUIC is client->server so NATs are not a problem; 1 RTT to establish a connection. Iroh is an atte…
Last I checked, Iroh is gonna use WebRTC datachannels to run QUIC over SCTP
I immediately jumped ship to WebTransport when Chrome added support. But I suppose there's no other option if you need P2P support in the browser.
Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD
Semi-related and just FYI for Firefox users who visit Cloudflare-hosted, HTTP/3-using sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1979683
Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD
Is the load balancing of the relays out of scope? It doesn't seem to be addressed in the write up unless I missed it.
`relay.moq.dev` currently uses GeoDNS to route to the closest edge. I'd like to use anycast like Cloudflare (and QUIC's preferred_address), but cloud offerings for anycast + UDP are limited.
The relays nodes currently form a mesh network and gossip origins between themselves. I used to work at Twitch on the CDN team so I'd like to eventually add tiers, but it's overkill with near zero users.
The moq-relay and terraform code is all open source if you're super curious.
Watching the Big Buck Bunny demo at https://moq.dev/watch/?name=bbb on my mobile phone leaves a lot of horizontal black lines. (Strangely, it is OK on my PC despite using the same Wi-Fi network.) Is it due to buffer size? Can I increase it client-side, or should it be done server-side?
Also, thanks for not missing South Kora in your "global" CDN map!
Earlier quoted context omitted.
Hi! I have a few :) How close are we to having QUIC actually usable in browsers (meaning both browsers and infrastructure supports it, and it 'just works') How does QUIC get around the NAT problem? WebRTC requires STUN/TURN to get through full cone NAT, particularly the latter is problematic, since it requires a bunch of infra to run.
QUIC is already quite widely used! We see close to 10% of HTTP requests using HTTP/3: https://radar.cloudflare.com/adoption-and-usage As for the NAT problem, that's mainly an issue for peer-to-peer scenarios. If you have a publicly addressable server at one end, you don't need all of the complications of a full ICE stack, even for WebRTC. For cases where you do need TURN (e.g. for WebRTC with clients that may be on n…
Unfortunately the NAT problem is more common than you think :( Lot's of corporate networks use full cone NAT (I know ours does), and so does AWS (if you don't have a public IP, but go through igw), so some sort of NAT punchthrough seems to be necessary for WebRTC.
I wonder if WebTransport has its own solution to the problem.
But I guess you can always rely on turn - by the way, does MoQ have some sort of ICE negotiation mechanism, or do we need to build that on top?