Wrklog
New log ⌘⇧L·

QUIC for multi-stream agent sessions?

i recently spent time learning more about QUIC and the HTTP3 ecosystem

while researching my upcoming aiminterviews.com with Justin Uberti the creator of webrtc I came across this Chinese interview he did a few years ago where he talks about how QUIC could be huge for the webrtc ecosystem

I believe QUIC will have a significant impact on the future of WebRTC. The reason I say this is because creating a WebRTC server is still very difficult. HTTP-based applications already have great infrastructure, but creating a WebRTC server is a process of building from scratch. Being able to transmit WebRTC traffic via QUIC means that setting up cloud WebRTC endpoints and transmitting data to them will become much easier. It's also a good thing that we don't have to continue developing a completely separate transport protocol (and supporting libraries) for WebRTC.

https://juejin.cn/post/7039521638362120199

interesting also that John Carmack has been talking about this https://x.com/ID_AA_Carmack/status/2056780156535279812

one of the cool things about quic over webrtc is the no head-of-line (HOL) blocking and per track flow control (for vid audio or tokens etc)

last week i thought i'd try an experiment taking a quic protocol library and trying to build more of a webrtc style subscriber interface that let you assign these custom queuing behaviors to streams

this is basically how it works:

One QUIC connection from agent server to browser/client, carrying screen video, reasoning tokens, tool calls, and telemetry.

its a WIP but early performance tests are promising

it does well for server originated multi-stream bursts especially for worst case scenarios

there still isn't a good way to do browser p2p with quic

but the 0-round trip time is really cool and makes it feel super fast head to head with webrtc