Hacker News Reader

Comment by daurnimator | Hacker News Reader

Interesting idea I had: why not have many QUIC streams?

I think the only equivalent to UDP would be: 1 QUIC stream per packet, which avoids blocking inside a stream. I'm not into QUIC, but I guess creating and managing a (temporary) stream would have a lot more overhead than just sending an encrypted UDP packet.

The other downside is that the browser (currently only chrome anyway) would present QUIC to the user only in form of QUIC streams with HTTP on top - which means the browser would reject any streams with non HTTP content and there's no API in Javascript for working with other content. The XHR and fetch APIs will utilize QUIC but only for HTTP on top of it.

This means for transmitting unreliable and potentially unordered packets we would need a new browser API anyway. The webrtc data channel API allows to read/write this kind of data, but it's however bound to the webrtc protocol stack (SCTP/DTLS).

This would be the same as having a single QUIC stream, since QUIC already supports multiple data streams. The author addresses that with "Unfortunately, while head of line blocking is eliminated across unrelated data streams, it still exists within each stream."

However, you could use a pool of x streams; when sending an update for the tick 't' then use the (t mod x)th stream, and thus if one stream becomes blocking for some time then you do receive the next update (since it's using a different stream) and you can treat it something as (1/x) rate of UDP packet loss.

Are you thinking one stream per packet?

You could have a pool of them, right? Or would you have to actually tear it down after each packet

Maybe. Why not?

but QUIC uses UDP?

Reply on news.ycombinator.com