[octoberfranklin]

Even 0-RTT connections still allocate connection state. IPFS learned this the hard way.

The mental model you need is the attacks that cause the Linux kernel to send SYN cookies. Learn how that attack works and you'll understand why you can't have connection state here (and neither does the Linux kernel during a SYN flood).

https://en.wikipedia.org/wiki/SYN_flood

https://en.wikipedia.org/wiki/SYN_cookies

It's much worse for DNS-like services, which is why after all these years DNS still uses UDP. Imagine if the root zone servers had to allocate connection state!

But it all depends on what you're using the DHT for. If you've decided "let's write a DHT that won't be used for naming or DNS-like purposes" then you'll probably get away with it.

[rklaehn]

I love mainline and also really appreciate how lightweight it is by just using UDP packets. But UDP packets have their limits. With the maximum MTU you can expect to work, the payload can't be more than about 1000 bytes, which is the limit of bep_0044.

But there are some use cases where you want to store a bit more than 1000 bytes. Not giant amounts, but maybe 4 KiB. Mainline won't ever be able to do this.

Iroh 0-rtt is very lightweight. On the network level you see one or two UDP packets flying in one direction, one or two UDP packets flying back, and that's the end of the interaction. You close the connection, and all state you have to retain is a session cookie on the client side.

It is still much heavier than bare UDP packets, but much lighter than a normal 1-rtt QUIC connection, which is already pretty lightweight.

Here are some details about 0-rtt. The API has changed slightly since then, but the basics remain the same of course: https://www.iroh.computer/blog/0rtt-api