Which means you need state (and the overhead that goes with it) for each connection within the network. That's horribly inefficient, and precisely the reason packet-switching won.

> An internet based on ATM would have been amazing.

No, we'd most likely be paying by the socket connection (as somebody has to pay for that state keeping overhead), which sounds horrible.

> You could now shave off another 20-100ms of latency for your FaceTime calls, which is subtle but game changing.

Maybe on congested Wi-Fi (where even circuit switching would struggle) or poorly managed networks (including shitty ISP-supplied routers suffering from horrendous bufferbloat). Definitely not on the majority of networks I've used in the past years.

> The horror of packet switching is all the buffering it needs [...]

The ideal buffer size is exactly the bandwidth-delay product. That's really not a concern these days anymore. If anything, buffers are much too large, causing unnecessary latency; that's where bufferbloat-aware scheduling comes in.

The latency benefit would outweigh the cost. Just absolutely instant video interaction.

And for the little bit of impact queueing latency has (if done well, i.e. no bufferbloat), I doubt anyone would notice the difference, honestly.

What I recall is that it was at a time when Internet folks had made enormous advances in understanding congestion behavior in computer networks, and other folks (e.g. my division of Motorola) had put a lot of time into understanding the limited burstiness you get with silence suppression for packetized voice, and these folks knew nothing about it.

You don't actually need all that much buffering.

Buffer bloat is actually a big problem with conventional TCP. See eg https://news.ycombinator.com/item?id=14298576

I already do this. But I cheat - I use a good router (OpenWrt One) that has built-in controls for Bufferbloat. See [How OpenWrt Vanquishes Bufferbloat](https://forum.openwrt.org/t/how-openwrt-vanquishes-bufferblo...)