| |||||||||||||
PhysicsPhysicsPosted Dec 12, 2011 11:49 UTC (Mon) by jlokier (guest, #52227)In reply to: Physics by marcH Parent article: Bufferbloat: Dark Buffers in the Internet (ACM Queue)
1 second ping time is just a plain bug/a joke. I often use cellular internet with a marginal signal that is oversubscribed, and 5 second ping times are quite common. Even 20 seconds at some times. As these are ping times to the cellular network access point, from an otherwise idle handset, it's quite possible this time cannot be improved by simply dropping packets early at any stage. In other words, it may not be a bufferbloat problem - and it may not be a bug either, if the RF link is simply too marginal and oversubscribed. As far as I can tell, these timings depend greatly on the strength of RF signal, and on the time of day. In this case the way forward looks like newer cellular technology. We all look hopefully at 4G/LTE, and (would be nice) better cross-carrier RF diversity. Even so, it's not clear that "speed of light" is an achievable latency on fully-subscribed large area wireless networks with large numbers of moving devices.
(Log in to post comments)
Physics Posted Dec 12, 2011 12:19 UTC (Mon) by marcH (subscriber, #57642) [Link]
> I often use cellular internet with a marginal signal that is oversubscribed, and 5 second ping times are quite common. Even 20 seconds at some times.
> [...] > In other words, it may not be a bufferbloat problem
Whenever you experience ping times over 1 second, something somewhere is buffering your ping (or pong) packet for more than 1 second. Even if this buffer is not "bloated" strictly speaking, holding on any packet for that long is WRONG and is definitely a BUG.
As an example, any link retransmission technique with timeouts over 1 second is simply not compatible with TCP/IP. Making that link technology compatible with TCP/IP is as simple as making it timeout (and drop packets) much, much sooner. It is really that simple.
Now again, finding the *optimal* timeout value is a very difficult problem. However, reducing a multi-seconds timeout to a reasonable 100-150 milliseconds value is NOT difficult at all and will make every user happier, while upsetting none.
Here is a supermarket analogy (for a change). You know that queues always become too long at peak time. Customers complain about it. You have money for two extra tills. But you do not proceed because it is oooh so hard to find the optimal number of tills.
> In this case the way forward looks like newer cellular technology.
This is throwing out the baby with the bath water. And the newer technology might make the same mistake again. And in any case it will not displace 2.5G/3G everywhere overnight.
> Even so, it's not clear that "speed of light" is an achievable latency
Of course it's not; you need some reasonable amount of buffering for a number of reasons.
Physics Posted Dec 12, 2011 12:47 UTC (Mon) by ekj (guest, #1524) [Link]
That's a bug. A packet is always either in-transit, being processed by a device, or being stored in a buffer for later processing and/or later sending.
The only way you can get 1+ seconds on local short-distance links, is by having the packet spend the huge majority of that time stored in some buffer. Which is a bug.
You want a sufficient bug that short term spikyness of packet-arrival does not needlessly cause lost packets when transmission a few milliseconds later would be preferable.
But 5 seconds, or even 1 second, worth of buffering is *way* too much, sure we can debate if you want 25ms or 250ms worth of buffering, and the answer is surely "it depends", but there's just no way 5 *seconds* worth of buffering can avoid causing an order of magnitude more problems than it solves.
|
|||||||||||||