[Cerowrt-devel] [Bloat] Check out www.speedof.me - no Flash

[David Lang]

On Sun, 27 Jul 2014, Sebastian Moeller wrote:

> On Jul 26, 2014, at 22:53 , David Lang <david at lang.hm> wrote:
>
>> On Sat, 26 Jul 2014, Sebastian Moeller wrote:
>>
>>> On Jul 26, 2014, at 01:26 , David Lang <david at lang.hm> wrote:
>>>
>>>> But I think that what we are seeing from teh results of the bufferbloat work is that a properly configured network doesn't degrade badly as it gets busy.
>>>>
>>>> Individual services will degrade as they need more bandwidth than is available, but that sort of degredation is easy for the user to understand.
>>>>
>>>> The current status-quo is where good throughput at 80% utilization may be 80Mb, at 90% utilization it may be 85Mb, at 95% utilization it is 60Mb, and at 100% utilization it pulses between 10Mb and 80Mb averaging around 20Mb and latency goes from 10ms to multiple seconds over this range.
>>>>
>>>> With BQL and fw_codel, 80% utilization would still be 80Mb, 90% utilization would be 89Mb, 95% utilization would be 93Mb with latency only going to 20ms
>>>>
>>>> so there is a real problem to solve in the current status-quo, and the question is if there is a way to quantify the problem and test for it in ways that are repeatable, meaningful and understandable.
>>>>
>>>> This is a place to avoid letting perfect be the enemy of good enough.
>>>>
>>>> If you ask even relatively technical people about the quality of a network connection, they will talk to you about bandwidth and latency.
>>>>
>>>> But if you talk to a networking expert, they don't even mention that, they talk about signal strength, waveform distortion, bit error rates, error correction mechanisms, signal regeneration, and probably many other things that I don't know enough to even mention :-)
>>>>
>>>>
>>>> Everyone is already measuring peak bandwidth today, and that is always going to be an important factor, so it will stay around.
>>>>
>>>> So we need to show the degredation of the network, and I think that either ping(loaded)-ping(unloaded) or ping(loaded)/ping(unloaded) will give us meaningful numbers that people can understand and talk about, while still being meaningful in the real world.
>>>
>>> 	Maybe we should follow Neil and Martin’s lead and consider either ping(unloaded)-ping(loaded) or ping(unloaded)/ping(loaded) and call the whole thing quality estimator or factor (as negative quality or a factor < 0 intuitively shows a degradation).
>>
>> That's debatable, if we call this a bufferbloat factor, the higher the number the more bloat you suffer.
>>
>> there's also the fact that the numeric differences if you do small/large vs small/larger aren't impressive while large/small vs larger/small look substantially different. This is a psychology question.
>
> 	I am not in this for marketing ;) so I am not out for impressive numbers ;)

well, part of the problem we have is exactly marketing, so we do need to take 
that into account.

This is one of the things that has come up in multiple forums after the EFF 
announcement, people saying that they've heard of bufferbloat but don't have any 
way of measuring it or comparing notes.

getting a marketing number here would be a huge help.

>>> Also my bet is on the difference not on the ratio, why should people with bad latency to begin with (satellite?) be more tolerant to further degradation? I would assume that on a high latency link if at all the “budget” for further degradation might be smaller than on a low latency link (reasoning: there might be a fixed latency budget for acceptable latency for voip).
>>
>> we'd need to check. The problem with difference is that it's far more affected by the bandwidth of the connection than a ratio is. If your measurement packets end up behind one extra data packet, your absolute number will grow based on the transmission time required for that data packet.
>>
>> so I'm leaning towards the ratio making more sense when comparing vastly different types of lines.
>
> 	But for a satellite link with hight 1st hop RTT the buffer bloat factor 
> is always going to look minuscule…. (I still think the difference is better)
>
>>
>> As for th elatency budget idea, I don't buy that, if it was the case then we would have no problems until latency exceeding the magic value and then the service would fail entirely.
>
> 	No rather think of it that with increases latency pain increases, not a 
> threshold but a gradual change from good over acceptable into painful...
>
>
>> What we have in practice is that buffering covers up a lot of latency, as long as the jitter isn't bad. You may have a lag between what you say and when someone on the other end interrupts you without much trouble (as long as echo cancellation takes it into account)
>
> 	Remember transcontinental long distance calls? If the delay gets too 
> long communication suffers especially in real time applications like voip.

how much of that was due to echo cancellation issues compared to the raw 
latency? the speed of light across the country hasn't changed. and I'd actually 
bet that the signalling speed of a direct analog connection across the country 
was actually faster than the current mic to speaker signalling speed

    analog -> digital -> many routers -> digital -> analog

but the echo cancellation is so much more sophisticated that we don't notice 
the delay as much

>>
>>>> which of the two is more useful is something that we would need to get a bunch of people with different speed lines to report and see which is affected less by line differences and distance to target.
>>>
>>> 	Or make sure we always measure against the closest target (which with satellite might still be far away)?
>>
>> It's desirable to test against the closest target to reduce the impact on the Internet overall, but ideally the quality measurement would not depend on how far away the target is.
>
> 	No the “quality” will be most affected by the bottleneck link, but the 
> more hops we accumulate the more variance we pick up and the more measurements 
> we need to reach an acceptable confidence in our data...

true

David Lang