Hacker News new | ask | show | jobs
by Animats 3262 days ago
"Central server" for routing. Uh oh.

AT&T used to try to avoid centralization, but ended up with routing controlled from Bedminster, NJ.[1] An interesting comment from AT&T's NOC tour guide is that load doesn't vary much any more. AT&T used to have holiday calling surges and such, but now, in an always-on world, overall load is relatively steady.

[1] http://fortune.com/att-global-network-operations-center/

2 comments

You can easily employ redundancy for core services. Core functionality doesn't need to be synonymous with central point of failure. For example, you have three healthy copies of the core service running at all times, combined with failover. All software systems have a core function that must work or else the system fails, but that doesn't mean all software systems are centralized in any useful sense of the word.
The problem i would see with centralization of routing is not reliability, but rather susceptibility to censorship; as the old saying goes "The Net interprets censorship as damage and routes around it" - while one could argue that root dns servers are central-ish, they are hosted all over the world, so a single actor can hardly impose worldwide censorship. It is a known fact that malicious actors can manipulate BGP (see Hacking Team), but it is still better than putting all of our collective eggs in Google's basket...

Distributed things though, mesh networks, IPFS - that's what's giving me hope.

It's interesting to know that a traditional ISP like AT&T is heading the same way.

I think Google gets more freedom to try out some of these techniques because people still fundamentally think of them as a website (apart from Google Fiber, they don't serve end-users directly); whereas AT&T, being an ISP, is treated more like a water / power service, in that people expect them to be working by default, and going down is absolutely unacceptable.

AT&T, pre-Internet, had 10 major regions in the US, and switches had a fixed list of primary, secondary, and tertiary routes. The first "centralization" was simply that the priorities in the routing tables were changed every few minutes based on load. But if the central routing planner went down or was unreachable, everything still worked, just not as optimally.

What you don't want is software-defined networking where every new flow goes to Master Control for validation and routing. Some SDN systems do that, and they have a central point of failure and censorship.