From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A073121F651 for ; Sat, 26 Jul 2014 16:15:10 -0700 (PDT) Received: from hms-beagle.home.lan ([217.231.210.84]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ll0tl-1WbI8727IT-00aqCE; Sun, 27 Jul 2014 01:14:58 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 27 Jul 2014 01:14:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03292B76-5273-4912-BB18-90E95C16A9F5@pnsol.com> <66FF8435-C8A5-4596-B43A-EC12D537D49E@gmx.de> <41DF4003-BAE8-4794-BEDF-EF2385F03685@gmx.de> <1406326625.225312181@apps.rackspace.com> To: David Lang X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:z3el8Cf5UuU/D7SpPtoTzdQuAJ+x9MgYmXs9W5n7jQbeLjwL2y3 o4BW7bSimsrn7Y+C06iHcNHgU2RVFlsh2NCjkhXVmT1owqDN4yExKXlIaWqTHIn0T8ECmqa 6IhTbT+ZkvHrwJLonqmRk+6J0o09foRq1NwgZvVnKXdESitV9BKc5fCfaXVz5yltwvEnzlF VTDCTbn9X6SgdaHVbFQFA== Cc: cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] Check out www.speedof.me - no Flash X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 23:15:11 -0000 Hi David, On Jul 27, 2014, at 00:30 , David Lang wrote: > On Sun, 27 Jul 2014, Sebastian Moeller wrote: >=20 >> On Jul 26, 2014, at 22:53 , David Lang wrote: >>=20 >>> On Sat, 26 Jul 2014, Sebastian Moeller wrote: >>>=20 >>>> On Jul 26, 2014, at 01:26 , David Lang wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> Individual services will degrade as they need more bandwidth than = is available, but that sort of degredation is easy for the user to = understand. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> This is a place to avoid letting perfect be the enemy of good = enough. >>>>>=20 >>>>> If you ask even relatively technical people about the quality of a = network connection, they will talk to you about bandwidth and latency. >>>>>=20 >>>>> 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 :-) >>>>>=20 >>>>>=20 >>>>> Everyone is already measuring peak bandwidth today, and that is = always going to be an important factor, so it will stay around. >>>>>=20 >>>>> 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. >>>>=20 >>>> Maybe we should follow Neil and Martin=92s 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). >>>=20 >>> That's debatable, if we call this a bufferbloat factor, the higher = the number the more bloat you suffer. >>>=20 >>> 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. >>=20 >> I am not in this for marketing ;) so I am not out for impressive = numbers ;) >=20 > well, part of the problem we have is exactly marketing, so we do need = to take that into account. >=20 > 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. >=20 > getting a marketing number here would be a huge help. Good point. >=20 >>>> 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 =93budget=94 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). >>>=20 >>> 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. >>>=20 >>> so I'm leaning towards the ratio making more sense when comparing = vastly different types of lines. >>=20 >> But for a satellite link with hight 1st hop RTT the buffer bloat = factor is always going to look minuscule=85. (I still think the = difference is better) >>=20 >>>=20 >>> 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. >>=20 >> No rather think of it that with increases latency pain = increases, not a threshold but a gradual change from good over = acceptable into painful... >>=20 >>=20 >>> 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) >>=20 >> Remember transcontinental long distance calls? If the delay gets = too long communication suffers especially in real time applications like = voip. >=20 > 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 >=20 > analog -> digital -> many routers -> digital -> analog >=20 > but the echo cancellation is so much more sophisticated that we don't = notice the delay as much It is more the fact that if you stop speaking in the US it will = take say 150 ms to reach my ear and even if I respond immediately it = will take the same time to come back to you. 300ms is an awkward long = pause and you might have already started your next sentence interfering = with my signal reaching your speaker=85 Now I am not sure about the = exact numbers but the longer the transmission delay the more awkward the = conversation... >=20 >>>=20 >>>>> 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. >>>>=20 >>>> Or make sure we always measure against the closest target (which = with satellite might still be far away)? >>>=20 >>> 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. >>=20 >> No the =93quality=94 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... >=20 > true >=20 > David Lang