4 ms·
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 fau
by jnordwick 10y ago
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.
- honkhonkpants 10y agoIf 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 :-)
- jnordwick 10y agoI 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.
- xorgar831 10y agoSome 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.