Stuart Cheshire, a networking engineer and author of the game Bolo, writes about latency, TCP behavior, and protocol design.
HN links it for 'It's the Latency, Stupid' and his COBS paper, which one commenter calls an all-time favorite for its elegant solution.
That was one of the original goals of Zeroconf. In 2002, Stuart Cheshire said [1]:
> My hope is that in the future — distant future perhaps — your computer will only need one wired communication technology. It will provide power on the connector like USB and FireWire, so it can power small peripheral devices. It will use IP packets like Ethernet, so it provides your wide-area communications for things like email and Web browsing, but it will also use Zeroconf IP so that connecting local devices is as easy as USB or FireWire is today. People ask me if I'm seriously suggesting that your keyboard and mouse should use the same connector as your Internet connection, and I am. There's no fundamental reason why a 10Mb/s Ethernet chip costs more than a USB chip. The problem is not cost, it is lack of power on the Ethernet connector, and (until now) lack of autoconfiguration to make it work. I would much rather have a computer with a row of identical universal IP communications ports, where I can connect anything I want to any port, instead of today's situation where the computer has a row of different sockets, each dedicated to its own specialized function.
[1]: http://www.stuartcheshire.org/TheIdeaBasket.html
Sadly, instead of using existing successful networking systems and automating the configuration, we've created a new union-of-all-possible-protocols with a new connector (or 5) and made understanding the compatibility matrix a nightmare.
Don't forget the impact of network. I managed to get a several hundred times performance improvement on one occasion because I found a distributed query that was pulling back roughly 1M rows over the network and then doing a join that dropped all but 5 - 10 of them. I restructured the query so the join occurred on the remote server and only 5 - 10 rows were sent over the network and, boom, suddenly it's fast.
There's always going to be some fixed overhead and latency (and there's a great article about the impact of latency on performance called "It's the latency, stupid" that's worth a read: http://www.stuartcheshire.org/rants/latency.html) but sending far more data than is needed over a network connection will sooner or later kill performance.
Overall though, I agree with your considerations, and in roughish terms the order of them.
Don't forget that bandwidth is only half (and most of time not the important half) of the story. Latency and packet losses usually have much stronger effect on website performance (see this classic paper http://www.stuartcheshire.org/rants/Latency.html or any of velocity 2010 videos).
There are a couple of free and commercial products that enable you to emulate latency, packet loss and bandwidth at the same time, just google that.
These days I think circuit switching means virtual circuits with guaranteed bandwidth at each hop. Even the phone network used FDM/TDM for circuits, not separate wires. Anyway, circuits are more expensive than just running a packet-switched network lightly loaded. See http://www.stuartcheshire.org/rants/Networkdynamics.html and https://www-users.cse.umn.edu/~odlyzko/doc/network.utilization.pdf
Forgive my ignorance as I'm a software engineer and not a physicist. But does this means that in the future FTL communication will be possible. Every time I work with networking one thing always springs to mind. That is that the speed of light is a limiting factor. Will this mean that in the future latency issues will be a thing of the past?
http://www.stuartcheshire.org/rants/latency.html
At the risk of stating the obvious, I want to add a quote that I found very informative
> If you're given the choice between a low bandwidth private connection, or a small share of a larger bandwidth connection, take the small share.
From http://www.stuartcheshire.org/rants/latency.html