Hacker News Reader

Comment by honkhonkpants | Hacker News Reader

"staying in network and don't often have to worry about packet loss or congestion."

I don't think you would find many Googlers making this equivalence. If your network is highly utilized then it is characterized by both loss and congestion. The trick is optimizing throughput on a congested network without suffering from collapse.

Whenever you see anyone talking about "traffic engineering" or "software-defined networking" you should just mentally substitute "packet loss". The only thing that an SDN management plane can do is instruct nodes on the network to drop. Then you can imagine that a highly utilized SDN-managed network has high loss.

Edit: In Google's "B4" paper they show that their network operates at packet loss levels approaching 10%. See Figure 14 in http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf

View on HN

In my work, I don't deal with Internet traffic too much, so internal packet loss is mostly a sign of poor provisioning or technology (if it is the network's fault) or poor programming (if it is the endpoint's fault). Both of those are fixable. It is very rare to have true congestion and sometimes impossible (if it is a dedicated subnet with only a couple hosts).

For us latency is more important that throughput, so our needs don't match Google's. There are a lot of cases like this.

Some level of packet loss is not a sign of a problem, this is a common confusion which has lead to the buffer bloat issues, and many poor quality behaviours by apps within datacenters.

It's such a point of confusion that cloud providers don't want to even share the network error rates with customers since they feel they will misinterpret them.

If your network is provisioned such that no congestion is possible, I submit that it might not present very interesting challenges in the domain of flow control :-)

I just saying flow control for some thing latency is important as well as throughput. We have to make sure we not packet storming the network down, but we also want data delivered as soon as possible.

TCP is used in a lot of situations now from these dedicated intranets to wireless and from serving HTTP to low-latency games. I'm just hoping TCP isn't being pushed too far in one direction because a large institution lives on one side of the spectrum.

At my non SDN ISP we do not over provision any of the core connections in the network. We plan and implement link upgrades proactively to make sure congestion is never an issue in network. I have closely followed googles SDN papers and they have much lower costs in comparison. We actually use packet loss as an indicator that there is a hardware issue.

Reply on news.ycombinator.com