<p dir="ltr">> Have you considered what this means for the economics of the operation of networks? What other industry that “moves things around” (i.e logistical or similar) system creates a solution in which they have 10x as much infrastructure than their peak requirement?</p>
<p dir="ltr">Ten times peak demand?  No.</p>
<p dir="ltr">Ten times average demand estimated at time of deployment, and struggling badly with peak demand a decade later, yes.  And this is the transportation industry, where a decade is a *short* time - like less than a year in telecoms.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 13 Dec 2017 17:27, "Neil Davies" <<a href="mailto:neil.davies@pnsol.com">neil.davies@pnsol.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 12 Dec 2017, at 22:53, <a href="mailto:dpreed@reed.com" target="_blank">dpreed@reed.com</a> wrote:</div><br class="m_-2579895552460910831Apple-interchange-newline"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">Luca's point tends to be correct - variable latency destroys the stability of flow control loops, which destroys throughput, even when there is sufficient capacity to handle the load.</div><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">This is an indirect result of Little's Lemma (which is strictly true only for Poisson arrival, but almost any arrival process will have a similar interaction between latency and throughput).</div></font></div></blockquote><div><br></div><div>Actually it is true for general arrival patterns (can’t lay my hands on the reference for the moment - but it was a while back that was shown) - what this points to is an underlying conservation law - that “delay and loss” are conserved in a scheduling process. This comes out of the M/M/1/K/K queueing system and associated analysis.</div><div><br></div><div>There is  conservation law (and Klienrock refers to this - at least in terms of delay - in 1965 - <a href="http://onlinelibrary.wiley.com/doi/10.1002/nav.3800120206/abstract" target="_blank">http://onlinelibrary.wiley.<wbr>com/doi/10.1002/nav.<wbr>3800120206/abstract</a>) at work here.</div><div><br></div><div>All scheduling systems can do is “distribute” the resulting “delay and loss” differentially amongst the (instantaneous set of) competing streams. </div><div><br></div><div>Let me just repeat that - The “delay and loss” are a conserved quantity - scheduling can’t “destroy” it (they can influence higher level protocol behaviour) but not reduce the total amount of “delay and loss” that is being induced into the collective set of streams...</div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">However, the other reason I say what I say so strongly is this:</div><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">Rant on.</div><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">Peak/avg. load ratio always exceeds a factor of 10 or more, IRL. Only "benchmark setups" (or hot-rod races done for academic reasons or marketing reasons to claim some sort of "title") operate at peak supportable load any significant part of the time.</div></font></div></blockquote><div><br></div><div>Have you considered what this means for the economics of the operation of networks? What other industry that “moves things around” (i.e logistical or similar) system creates a solution in which they have 10x as much infrastructure than their peak requirement?</div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">The reason for this is not just "fat pipes are better", but because bitrate of the underlying medium is an insignificant fraction of systems operational and capital expense.</div></font></div></blockquote><div><br></div><div>Agree that (if you are the incumbent that ‘owns’ the low level transmission medium) that this is true (though the costs of lighting a new lambda are not trivial) - but that is not the experience of anyone else in the digital supply time</div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">SLA's are specified in "uptime" not "bits transported", and a clogged pipe is defined as down when latency exceeds a small number.</div></font></div></blockquote><div><br></div><div>Do you have any evidence you can reference for an SLA that treats a few ms as “down”? Most of the SLAs I’ve had dealings with use averages over fairly long time periods (e.g. a month) - and there is no quality in averages.</div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">Typical operating points of corporate networks where the users are happy are single-digit percentage of max load.</div></font></div></blockquote><div><br></div><div>Or less - they also detest the costs that they have to pay the network providers to try and de-risk their applications. There is also the issue that they measure averages (over 5min to 15min) they completely fail to capture (for example) the 15seconds when delay and jitter was high so the CEO’s video conference broke up.</div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">This is also true of computer buses and memory controllers and storage interfaces IRL. Again, latency is the primary measure, and the system never focuses on operating points anywhere near max throughput.</div></font></div></blockquote><div><br></div><div>Agreed - but wouldn’t it be nice if they could? I’ve worked on h/w systems where we have designed system to run near limits (the set-top box market is pretty cut-throat and the closer to saturation you can run and still deliver the acceptable outcome the cheaper the box the greater the profit margin for the set-top box provider)</div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0px;padding:0px;font-family:verdana;font-size:10pt"> </p><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">Rant off.<br><br></div></font></div></blockquote><div><br></div><div>Cheers</div><div><br></div><div>Neil</div><div><br></div><br><blockquote type="cite"><div><font face="verdana" size="2" style="font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">On Tuesday, December 12, 2017 1:36pm, "Dave Taht" <<a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a>> said:<br><br></div><div id="m_-2579895552460910831SafeStyles1513118484"><div style="margin:0px;padding:0px;font-family:verdana;font-size:10pt">><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com" target="_blank">luca.muscariello@gmail.com</a>> writes:<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> > I think everything is about response time, even throughput.<br>> ><br>> > If we compare the time to transmit a single packet from A to B, including<br>> > propagation delay, transmission delay and queuing delay,<br>> > to the time to move a much larger amount of data from A to B we use<br>> throughput<br>> > in this second case because it is a normalized<br>> > quantity w.r.t. response time (bytes over delivery time). For a single<br>> > transmission we tend to use latency.<br>> > But in the end response time is what matters.<br>> ><br>> > Also, even instantaneous throughput is well defined only for a time scale<br>> which<br>> > has to be much larger than the min RTT (propagation + transmission delays)<br>> > Agree also that looking at video, latency and latency budgets are better<br>> > quantities than throughput. At least more accurate.<br>> ><br>> > On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>><br>> wrote:<br>> ><br>> > On Mon, 4 Dec 2017, <a href="mailto:dpreed@reed.com" target="_blank">dpreed@reed.com</a> wrote:<br>> ><br>> > I suggest we stop talking about throughput, which has been the<br>> mistaken<br>> > idea about networking for 30-40 years.<br>> ><br>> ><br>> > We need to talk both about latency and speed. Yes, speed is talked about<br>> too<br>> > much (relative to RTT), but it's not irrelevant.<br>> ><br>> > Speed of light in fiber means RTT is approx 1ms per 100km, so from<br>> Stockholm<br>> > to SFO my RTT is never going to be significantly below 85ms (8625km<br>> great<br>> > circle). It's current twice that.<br>> ><br>> > So we just have to accept that some services will never be deliverable<br>> > across the wider Internet, but have to be deployed closer to the<br>> customer<br>> > (as per your examples, some need 1ms RTT to work well), and we need<br>> lower<br>> > access latency and lower queuing delay. So yes, agreed.<br>> ><br>> > However, I am not going to concede that speed is "mistaken idea about<br>> > networking". No amount of smarter queuing is going to fix the problem if<br>> I<br>> > don't have enough throughput available to me that I need for my<br>> application.<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> In terms of the bellcurve here, throughput has increased much more<br>> rapidly than than latency has decreased, for most, and in an increasing<br>> majority of human-interactive cases (like video streaming), we often<br>> have enough throughput.<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> And the age old argument regarding "just have overcapacity, always"<br>> tends to work in these cases.<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> I tend not to care as much about how long it takes for things that do<br>> not need R/T deadlines as humans and as steering wheels do.<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Propigation delay, while ultimately bound by the speed of light, is also<br>> affected by the wires wrapping indirectly around the earth - much slower<br>> than would be possible if we worked at it:<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> <a href="https://arxiv.org/pdf/1505.03449.pdf" target="_blank">https://arxiv.org/pdf/1505.<wbr>03449.pdf</a><br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Then there's inside the boxes themselves:<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> A lot of my struggles of late has been to get latencies and adaquate<br>> sampling techniques down below 3ms (my previous value for starting to<br>> reject things due to having too much noise) - and despite trying fairly<br>> hard, well... a process can't even sleep accurately much below 1ms, on<br>> bare metal linux. A dream of mine has been 8 channel high quality audio,<br>> with a video delay of not much more than 2.7ms for AR applications.<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> For comparison, an idle quad core aarch64 and dual core x86_64:<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> root@nanopineo2:~# irtt sleep<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Testing sleep accuracy...<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Sleep Duration Mean Error % Error<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 1ns 13.353µs 1335336.9<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 10ns 14.34µs 143409.5<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 100ns 13.343µs 13343.9<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 1µs 12.791µs 1279.2<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 10µs 148.661µs 1486.6<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 100µs 150.907µs 150.9<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 1ms 168.001µs 16.8<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 10ms 131.235µs 1.3<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 100ms 145.611µs 0.1<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 200ms 162.917µs 0.1<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 500ms 169.885µs 0.0<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> d@nemesis:~$ irtt sleep<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Testing sleep accuracy...<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> Sleep Duration Mean Error % Error<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 1ns 668ns 66831.9<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 10ns 672ns 6723.7<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 100ns 557ns 557.6<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 1µs 57.749µs 5774.9<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 10µs 63.063µs 630.6<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 100µs 67.737µs 67.7<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 1ms 153.978µs 15.4<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 10ms 169.709µs 1.7<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 100ms 186.685µs 0.2<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 200ms 176.859µs 0.1<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> 500ms 177.271µs 0.0<br>><span class="m_-2579895552460910831Apple-converted-space"> </span><br>> ><br>> > --<br>> > Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a><br>> > ______________________________<wbr>_________________<br>> ><br>> ><br>> > Bloat mailing list<br>> > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>> > <a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>> ><br>> ><br>> ><br>> > ______________________________<wbr>_________________<br>> > Bloat mailing list<br>> > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>> > <a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>></div></div></font><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"></span><span class="m_-2579895552460910831BEGIN-ANTISPAM-VOTING-LINKS" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></span><div class="m_-2579895552460910831BEGIN-ANTISPAM-VOTING-LINKS" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline"><div><span style="font-size:inherit;font-style:normal;font-weight:normal;background-color:white;display:inline"><hr><br><a rel="nofollow" href="https://portal.roaringpenguin.co.uk/canit/b.php?c=s&i=03UJaRTkO&m=5027f7184ff5&rlm=pnsol-com&t=20171212" target="_blank">Spam</a><br><a rel="nofollow" href="https://portal.roaringpenguin.co.uk/canit/b.php?c=n&i=03UJaRTkO&m=5027f7184ff5&rlm=pnsol-com&t=20171212" target="_blank">Not spam</a><br><a rel="nofollow" href="https://portal.roaringpenguin.co.uk/canit/b.php?c=f&i=03UJaRTkO&m=5027f7184ff5&rlm=pnsol-com&t=20171212" target="_blank">Forget previous vote</a><br></span></div></div><span class="m_-2579895552460910831END-ANTISPAM-VOTING-LINKS" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"></span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">______________________________<wbr>_________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Bloat mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:Bloat@lists.bufferbloat.net" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Bloat@lists.bufferbloat.net</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.bufferbloat.net/listinfo/bloat" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
<br></blockquote></div></div>