Hacker News Reader

Comment by zzzcpan | Hacker News Reader

I don't know, feels like a massive waste of resources and if Google is doing it simply because it can. It's probably much cheaper for everyone else to handle latency/throughput problems on the client side and application level, sticking to all the traditional networking, but not relying on it for quality. Even in the web browser we already can send all kinds of asynchronous requests to multiple servers in multiple datacenters, choosing the fastest response and making all kinds of decisions to where to send requests dynamically in real time.

And while I agree about overcomplicated routers and box-centric thinking in computer networks, it's pretty much impossible to change things because of the monopolistic nature of the ISP industry. They are very far from competing on the levels of quality where SDN could matter.

View on HN

From the description, it sounds like the routers have been reduced to more simple muxers, where a small tag added to the packet determines which port it goes over instead of trying to make a complicated decision all in one focal point.

This has pushed the decision back from the routers to the servers, where it scales with the number of hosts handling connections and can additionally be determined per /session/ instead of per packet. That state is held where sessions already need to be stored anyway instead of being duplicated in a router where it's entirely a burden.

Label switching is a pretty old concept. We had it at Inmos around 1990 and it wasn't new then.

The speedup from traditional MPLS already comes from the simple next-hop only lookup required by the router. There's no complicated decision making going on. Something central still manages the labels, that's the complexity but that's not new either.

Google still buy and use a ton of traditional mega (tera) high bandwidth networking gear. All of which will support regular label switching. But that doesn't sound cool and exciting so they always play that down. They can spin it that way if they like, network hardware vendors don't care because they are still selling them their boxes.

You really do no understand what Google is doing or how it works. The article does a poor job explaining. It is more like a virtual circuit switch network. It enables far less cost in equipment as no need to over provision. But a key feature is it makes latency far more determinate. This was necessary to make Spanner work.

Every vendor is moving to SDN and hardware is getting more and more generalized with more functions crammed into smaller die space. Google is just using its massive cash reserves and R&D capability to beat the vendors to the punch. They probably expect network vendors to go this way, and want to eventually sell these new routers as a service to customers the way they did with their search boxes. There's also the little problem of routers facing an ever-bigger internet and not getting any more efficient, so planning for the future means having better scaling routers.

From the keyboard of a Chromebook Pixel I think I can feel where this is going. I can see a time when ChromeOS works on this internal Google network for most of what it does, running on protocols that are orders of magnitude quicker than regular 'https://' style TCP/IP networking.

There is this danger that these pieces Google work on get joined up, e.g. Android apps on your Chromebook. With Google owning the network from the server 'encapsulated' over public networks and then on Google's own home router and on to Google gadgets like Chromebooks, there is a high likely hood that some glorified 'SPDY' that hooks in at OS level is going to happen. Therefore pieces of the puzzle may not have any obvious benefit, to take a train analogy, who would build a railway through Utah? On its own it might not make sense but as part of a transcontinental railroad it was an important part of the puzzle to get done. With Google there is some of this shrewd aspect with added 'moonshot' thrown in for good measure.

It's already happening with QUIC. Google is backporting as many improvements as they can into the traditional network stack though, like HTTP/2, BBR, and TLS improvements.

Reply on news.ycombinator.com