Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

dave@dthompson@toot.cat (2026-10-18 09:52:32)
I have been thinking about how QUIC, the new hotness in low-level transport protocols, might apply to OCapN. My initial findings suggest it would be a poor fit but I'm still doing research.

QUIC's killer feature, stream multiplexing, doesn't do anything for OCapN because 1) OCapN mandates only one connection may be open between any two peers at a time for reasons of reference equality (in the sense of eq? in Scheme) so there can't be multiple streams at this abstraction layer 2) OCapN mandates FIFO order of message delivery and 3) unlike HTTP, OCapN is async and doesn't use a request/response cycle so once a message is delivered the pipe isn't blocked waiting for a result. The remaining advantages of QUIC are relatively minor things like faster connection due to not having to wait for a TCP handshake before doing a TLS/Noise/whatever handshake and just not being ossified like TCP.

A reliable transport built on UDP would still be very useful for OCapN because you need UDP for NAT hole punching, but idk if there's anything that can be taken off the shelf and used as-is.
---Reply---
dave@dthompson@toot.cat (2026-10-19 21:52:25)
Some other reliable protocols built on UDP are 1) RUDP, made by Bell Labs for Plan9, which has a draft RFC from 1999 and 2) SCTP, notably used by WebRTC. I think I can rule out SCTP as a good fit because it has multistreaming (like QUIC) and multihoming which are both unnecessary for OCapN. RUDP seems much simpler but anything that was ever deployed seems to use something that forks from the draft spec, but perhaps it's a good starting point.

---Replies---

ArneBab@ArneBab@rollenspiel.social (2026-10-19 22:39:27)
@dthompson Can there be only one peer per program? If there are multiple vats on the other node, could they use the same QUIC connection but different streams on it? That could delay running out of ports when communicating with many people. Consumer-OS’es can have quite low concurrent connection limits.

Why do you see zero roundtrip handshakes as minor? (especially if you don’t have to wait for a response)

One advantage of QUIC is that is doesn’t stand out, since HTTP3 serves as cover traffic.

Vicent Ferrer@vicentfg@mastodont.cat (2026-10-19 23:14:36)
@dthompson  
A nitpick, SCTP doesn't run on top UDP, but IP directly. 

It is widely used on telco, but Internet middle boxes usually mess up with it. Something on top of UDP would be more reliable.

Tim Panton@steely_glint@chaos.social (2026-10-20 00:31:27)
@dthompson You could look at IL (also from plan9 and direct over IP but could probably run nicely over UDP or DTLS. )

Also - what are your target endpoints? 

I'm playing with RTCTransport which is basically ICE+DTLS + Browser API - which  might be interesting but you would have to add reliability somehow.

dave@dthompson@toot.cat (2026-10-20 03:59:30)
a point in favor of QUIC: it supports both reliable and unreliable communication over the same socket, so you could multiplex OCapN (reliable) and a video stream (unreliable).