<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:CMMI10;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:CMMI8;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:CMR10;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:CMSY10;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Fe;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Fg;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi David,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That’s an interesting point, and I think you’re right that packet arrival is poorly modeled as a Poisson process, because in practice packet transmissions are very rarely unrelated to other packet transmissions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But now you’ve got me wondering what the right approach is.  Do you have any advice for how to improve this kind of modeling?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m thinking maybe a useful adjustment is to use Poisson start times on packet bursts, with a distribution on some burst characteristics? (Maybe like duration, rate, choppiness?)  Part of the point being that burst parameters then have
 a chance to become significant, as well as the load from aggregate user behavior.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And although I think user behavior is probably often ok to model as independent (outside of a background average that changes by time of day), in some contexts maybe it needs a 2<sup>nd</sup> overlay for bursts in user activity to address
 user-synchronizing events...  But for some problems I expect this kind of approach might still miss important feedback loop effects, and maybe for some problems it needs a more generalized suite of patterns besides a “burst”.  But maybe it would still be a
 step in the right direction for examining network loading problems in the abstract?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Or maybe it’s better to ask a different question:<o:p></o:p></p>
<p class="MsoNormal">Are there any good exemplars to follow here?  Any network traffic analysis (or related) work you’d recommend as having useful results that apply more broadly than a specific set of simulation/testing parameters, and that you wish more people
 would follow their example?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Also related: any particular papers come to mind that you wish someone would re-do with a better model?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Anyway, coming back to where that can of worms opened, I gotta say I like the “language of math” idea as a goal to aim for, and it would be surprising to me if no such useful information could be extracted from iperf runs.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">A Little’s Law-based average queue estimate sounds possibly useful to me (especially compared across different runs or against external stats on background cross-traffic activity), and some kind of tail analysis on latency samples also
 sounds relevant to user experience. Maybe there’s some other things that would be better to include?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">Jake<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">"David P. Reed" <dpreed@deepplum.com><br>
<b>Date: </b>Fri,2021-07-09 at 12:31 PM<br>
<b>To: </b>Luca Muscariello <muscariello@ieee.org><br>
<b>Cc: </b>Cake List <cake@lists.bufferbloat.net>, Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>, Leonard Kleinrock <lk@cs.ucla.edu>, Bob McMahon <bob.mcmahon@broadcom.com>, "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>, "codel@lists.bufferbloat.net"
 <codel@lists.bufferbloat.net>, cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>, Ben Greear <greearb@candelatech.com><br>
<b>Subject: </b>Re: [Bloat] Little's Law mea culpa, but not invalidating my main point<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Len - I admit I made a mistake in challenging Little's Law as being based on Poisson processes. It is more general. But it tells you an "average" in
 its base form, and latency averages are not useful for end user applications.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">However, Little's Law does assume something that is not actually valid about the kind of distributions seen in the network, and in fact, it is NOT
 true that networks converge on Poisson arrival times.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">The key issue is well-described in the sandard analysis of the M/M/1 queue (e.g.
<a href="https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/M/M/1_queue__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lFrNBSSE$">
https://en.wikipedia.org/wiki/M/M/1_queue</a>) , which is done only for Poisson processes, and is also limited to "stable" systems. But networks are never stable when fully loaded. They get unstable and those instabilities persist for a long time in the network.
 Instability is at core the underlying *requirement* of the Internet's usage.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So specifically: real networks, even large ones, and certainly the Internet today, are not asymptotic limits of sums of stationary stochastic arrival
 processes. Each esternal terminal of any real network has a real user there, running a real application, and the network is a complex graph. This makes it completely unlike a single queue. Even the links within a network carry a relatively small number of
 application flows. There's no ability to apply the Law of Large Numbers to the distributions, because any particular path contains only a small number of serialized flows with hightly variable rates.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Here's an example of what really happens in a real network (I've observed this in 5 different cities on ATT's cellular network, back when it was running
 Alcatel Lucent HSPA+ gear in those cities).<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">But you can see this on any network where transient overload occurs, creating instability.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">At 7 AM, the data transmission of the network is roughty stable. That's because no links are overloaded within the network. Little's Law can tell you
 by observing the delay and throughput on any path that the average delay in the network is X.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Continue sampling delay in the network as the day wears on. At about 10 AM, ping delay starts to soar into the multiple second range. No packers are
 lost. The peak ping time is about 4000 milliseconds - 4 seconds in most of the networks. This is in downtown, no radio errors are reported, no link errors.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So it is all queueing delay. <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Now what Little's law doesn't tell you much about average delay, because clearly *some* subpiece of the network is fully saturated. But what is interesting
 here is what is happening and where. You can't tell what is saturated, and in fact the entire network is quite unstable, because the peak is constantly varying and you don't know where the throughput is. All the packets are now arriving 4 seconds or so later.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Why is the situaton not worse than 4 seconds? Well, there are multiple things going on:<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">1) TCP may be doing a lot of retransmissions (non-Poisson at all, not random either. The arrival process is entirely deterministic in each source,
 based on the retransmission timeout) or it may not be.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">2) Users are pissed off, because they clicked on a web page, and got nothing back. They retry on their screen, or they try another site. Meanwhile,
 the underlying TCP connection remains there, pumping the network full of more packets on that old path, which is still backed up with packets that haven't been delivered that are sitting in queues. The real arrival process is not Poisson at all, its a deterministic,
 repeated retrsnsmission plus a new attempt to connect to a new site.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">3) When the users get a web page back eventually, it is filled with names of other pieces needed to display that web page, which causes some number
 (often as many as 100) new pages to be fetched, ALL at the same time. Certainly not a stochastic process that will just obey the law of large numbers.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">All of these things are the result of initial instability, causing queues to build up.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So what is the state of the system? is it stable? is it stochastic? Is it the sum of enough stochastic stable flows to average out to Poisson?<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">The answer is clearly NO. Control theory (not queuing theory) suggests that this system is completely uncontrolled and unstable.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So if the system is in this state, what does Little's Lemma tell us? What is the meaning of that hightly variable 4 second delay on ping packets, in
 terms of average utilizaton of the network?<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">We don't even know what all the users really might need, if the system hadn't become unstable, because some users have given up, and others are trying
 even harder, and new users are arriving.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">What we do know, because ATT (at my suggestion) reconfigured their system after blaming Apple Computer company for "bugs" in the original iPhone in
 public, is that simply *dropping* packets sitting in queues more than a couple milliseconds MADE THE USERS HAPPY. Apparently the required capacity was there all along! <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So I conclude that the 4 second delay was the largest delay users could barely tolerate before deciding the network was DOWN and going away. And that
 the backup was the accumulation of useless packets sitting in queues because none of the end systems were receiving congestion signals (which for the Internet stack begins with packet dropping).<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">I should say that most operators, and especially ATT in this case, do not measure end-to-end latency. Instead they use Little's Lemma to query routers
 for their current throughput in bits per second, and calculate latency as if Little's Lemma applied. This results in reports to management that literally say:<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">  The network is not dropping packets, utilization is near 100% on many of our switches and routers.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">And management responds, Hooray! Because utilization of 100% of their hardware is their investors' metric of maximizing profits. The hardware they
 are operating is fully utilized. No waste! And users are happy because no packets have been dropped!<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hmm... what's wrong with this picture? I can see why Donovan, CTO, would accuse Apple of lousy software that was ruining iPhone user experience!  His
 network was operating without ANY problems.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So it must be Apple!<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Well, no. The entire problem, as we saw when ATT just changed to shorten egress queues and drop packets when the egress queues overflowed, was that
 ATT's network was amplifying instability, not at the link level, but at the network level.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">And queueing theory can help with that, but *intro queueing theory* cannot.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">And a big part of that problem is the pervasive belief that, at the network boundary, *Poisson arrival* is a reasonable model for use in all cases.<o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in;overflow-wrap: break-word"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in;overflow-wrap: break-word">
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">On Friday, July 9, 2021 6:05am, "Luca Muscariello" <muscariello@ieee.org> said:<o:p></o:p></span></p>
<div id="SafeStyles1625856330">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">For those who might be interested in Little's law<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">there is a nice paper by John Little on the occasion <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">of the 50th anniversary  of the result.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><a href="https://urldefense.com/v3/__https:/www.informs.org/Blogs/Operations-Research-Forum/Little-s-Law-as-Viewed-on-its-50th-Anniversary__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lA4G3ETE$">https://www.informs.org/Blogs/Operations-Research-Forum/Little-s-Law-as-Viewed-on-its-50th-Anniversary</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><a href="https://urldefense.com/v3/__https:/www.informs.org/content/download/255808/2414681/file/little_paper.pdf__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lO1NjKU4$">https://www.informs.org/content/download/255808/2414681/file/little_paper.pdf</a></span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Nice read. </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Luca </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">P.S. </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Who has not a copy of L. Kleinrock's books? I do have and am not ready to lend them!</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">On Fri, Jul 9, 2021 at 11:01 AM Leonard Kleinrock <<a href="mailto:lk@cs.ucla.edu">lk@cs.ucla.edu</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">David,
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">I totally appreciate  your attention to when and when not analytical modeling works. Let me clarify a few things from your note.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">First, Little's law (also known as Little’s lemma or, as I use in my book, Little’s result) does not assume Poisson arrivals -  it is good for
<strong><span style="font-family:"Arial",sans-serif">any</span></strong> arrival process and any service process and is an equality between time averages.  It states that the time average of the number in a system (for a sample path
<em><span style="font-family:"Arial",sans-serif">w)</span></em></span><span style="font-size:10.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif">is equal to the average arrival rate to the system multiplied by the time-averaged time
 in the system for that sample path.  This is often written as   </span><span style="font-family:"CMMI10",serif;position:relative;top:6.0pt;mso-text-raise:-6.0pt">N</span><span style="font-size:8.0pt;font-family:"CMMI8",serif">TimeAvg
</span><span style="font-family:"CMR10",serif;position:relative;top:6.0pt;mso-text-raise:-6.0pt">=</span><span style="font-family:"CMMI10",serif;position:relative;top:6.0pt;mso-text-raise:-6.0pt">λ</span><span style="font-family:"CMSY10",serif;position:relative;top:6.0pt;mso-text-raise:-6.0pt">·</span><span style="font-family:"CMMI10",serif;position:relative;top:6.0pt;mso-text-raise:-6.0pt">T</span><span style="font-size:8.0pt;font-family:"CMMI8",serif">TimeAvg
 . </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> Moreover, if the system is also ergodic, then the time average equals the ensemble average and we often write it as </span><span style="font-size:17.0pt;font-family:"Fe",serif">N</span><span style="font-size:17.0pt;font-family:"Fg",serif;position:relative;top:-4.0pt;mso-text-raise:4.0pt">
 ̄ </span><span style="font-size:17.0pt;font-family:"Fg",serif">= </span><span style="font-size:17.0pt;font-family:"Fe",serif">λ T</span><span style="font-size:17.0pt;font-family:"Fg",serif;position:relative;top:-4.0pt;mso-text-raise:4.0pt"> ̄ .</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;position:relative;top:-4.0pt;mso-text-raise:4.0pt">
  In any case, this requires neither Poisson arrivals nor exponential service times.  </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;position:relative;top:-4.0pt;mso-text-raise:4.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Queueing theorists often do study the case of Poisson arrivals.  True, it makes the analysis easier, yet there is a better reason it is often used, and that is because the sum
 of a large number of independent stationary renewal processes approaches a Poisson process.  So nature often gives us Poisson arrivals.  <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Best,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Len<o:p></o:p></span></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">On Jul 8, 2021, at 12:38 PM, David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">I will tell you flat out that the arrival time distribution assumption made by Little's Lemma that allows "estimation of queue depth" is totally unreasonable on ANY Internet
 in practice.<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">The assumption is a Poisson Arrival Process. In reality, traffic arrivals in real internet applications are extremely far from Poisson, and, of course, using TCP windowing, become
 highly intercorrelated with crossing traffic that shares the same queue.<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So, as I've tried to tell many, many net-heads (people who ignore applications layer behavior, like the people that think latency doesn't matter to end users, only throughput),
 end-to-end packet arrival times on a practical network are incredibly far from Poisson - and they are more like fractal probability distributions, very irregular at all scales of time.<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">So, the idea that iperf can estimate queue depth by Little's Lemma by just measuring saturation of capacity of a path is bogus.The less Poisson, the worse the estimate gets,
 by a huge factor.<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Where does the Poisson assumption come from?  Well, like many theorems, it is the simplest tractable closed form solution - it creates a simplified view, by being a "single-parameter"
 distribution (the parameter is called lambda for a Poisson distribution).  And the analysis of a simple queue with poisson arrival distribution and a static, fixed service time is the first interesting Queueing Theory example in most textbooks. It is suggestive
 of an interesting phenomenon, but it does NOT characterize any real system.<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">It's the queueing theory equivalent of "First, we assume a spherical cow...". in doing an example in a freshman physics class.<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Unfortunately, most networking engineers understand neither queuing theory nor application networking usage in interactive applications. Which makes them arrogant. They assume
 all distributions are poisson!<o:p></o:p></span></p>
</div>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">On Tuesday, July 6, 2021 9:46am, "Ben Greear" <<a href="mailto:greearb@candelatech.com" target="_blank">greearb@candelatech.com</a>> said:<o:p></o:p></span></p>
</div>
<div id="gmail-m_272466165573362254SafeStyles1625772289">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">> Hello,<br>
> <br>
> I am interested to hear wish lists for network testing features. We make test<br>
> equipment, supporting lots<br>
> of wifi stations and a distributed architecture, with built-in udp, tcp, ipv6,<br>
> http, ... protocols,<br>
> and open to creating/improving some of our automated tests.<br>
> <br>
> I know Dave has some test scripts already, so I'm not necessarily looking to<br>
> reimplement that,<br>
> but more fishing for other/new ideas.<br>
> <br>
> Thanks,<br>
> Ben<br>
> <br>
> On 7/2/21 4:28 PM, Bob McMahon wrote:<br>
> > I think we need the language of math here. It seems like the network<br>
> power metric, introduced by Kleinrock and Jaffe in the late 70s, is something<br>
> useful.<br>
> > Effective end/end queue depths per Little's law also seems useful. Both are<br>
> available in iperf 2 from a test perspective. Repurposing test techniques to<br>
> actual<br>
> > traffic could be useful. Hence the question around what exact telemetry<br>
> is useful to apps making socket write() and read() calls.<br>
> ><br>
> > Bob<br>
> ><br>
> > On Fri, Jul 2, 2021 at 10:07 AM Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a><br>
> <<a href="mailto:dave.taht@gmail.com" target="_blank">mailto:dave.taht@gmail.com</a>>> wrote:<br>
> ><br>
> > In terms of trying to find "Quality" I have tried to encourage folk to<br>
> > both read "zen and the art of motorcycle maintenance"[0], and Deming's<br>
> > work on "total quality management".<br>
> ><br>
> > My own slice at this network, computer and lifestyle "issue" is aiming<br>
> > for "imperceptible latency" in all things. [1]. There's a lot of<br>
> > fallout from that in terms of not just addressing queuing delay, but<br>
> > caching, prefetching, and learning more about what a user really needs<br>
> > (as opposed to wants) to know via intelligent agents.<br>
> ><br>
> > [0] If you want to get depressed, read Pirsig's successor to "zen...",<br>
> > lila, which is in part about what happens when an engineer hits an<br>
> > insoluble problem.<br>
> > [1] <a href="https://urldefense.com/v3/__https:/www.internetsociety.org/events/latency2013/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4l8XdbVoc$" target="_blank">
https://www.internetsociety.org/events/latency2013/</a><br>
> <<a href="https://urldefense.com/v3/__https:/www.internetsociety.org/events/latency2013/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4l8XdbVoc$" target="_blank">https://www.internetsociety.org/events/latency2013/</a>><br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jul 1, 2021 at 6:16 PM David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a><br>
> <<a href="mailto:dpreed@deepplum.com" target="_blank">mailto:dpreed@deepplum.com</a>>> wrote:<br>
> > ><br>
> > > Well, nice that the folks doing the conference  are willing to<br>
> consider that quality of user experience has little to do with signalling rate at<br>
> the<br>
> > physical layer or throughput of FTP transfers.<br>
> > ><br>
> > ><br>
> > ><br>
> > > But honestly, the fact that they call the problem "network quality"<br>
> suggests that they REALLY, REALLY don't understand the Internet isn't the hardware<br>
> or<br>
> > the routers or even the routing algorithms *to its users*.<br>
> > ><br>
> > ><br>
> > ><br>
> > > By ignoring the diversity of applications now and in the future,<br>
> and the fact that we DON'T KNOW what will be coming up, this conference will<br>
> likely fall<br>
> > into the usual trap that net-heads fall into - optimizing for some<br>
> imaginary reality that doesn't exist, and in fact will probably never be what<br>
> users<br>
> > actually will do given the chance.<br>
> > ><br>
> > ><br>
> > ><br>
> > > I saw this issue in 1976 in the group developing the original<br>
> Internet protocols - a desire to put *into the network* special tricks to optimize<br>
> ASR33<br>
> > logins to remote computers from terminal concentrators (aka remote<br>
> login), bulk file transfers between file systems on different time-sharing<br>
> systems, and<br>
> > "sessions" (virtual circuits) that required logins. And then trying to<br>
> exploit underlying "multicast" by building it into the IP layer, because someone<br>
> > thought that TV broadcast would be the dominant application.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Frankly, to think of "quality" as something that can be "provided"<br>
> by "the network" misses the entire point of "end-to-end argument in system<br>
> design".<br>
> > Quality is not a property defined or created by The Network. If you want<br>
> to talk about Quality, you need to talk about users - all the users at all times,<br>
> > now and into the future, and that's something you can't do if you don't<br>
> bother to include current and future users talking about what they might expect<br>
> to<br>
> > experience that they don't experience.<br>
> > ><br>
> > ><br>
> > ><br>
> > > There was much fighting back in 1976 that basically involved<br>
> "network experts" saying that the network was the place to "solve" such issues as<br>
> quality,<br>
> > so applications could avoid having to solve such issues.<br>
> > ><br>
> > ><br>
> > ><br>
> > > What some of us managed to do was to argue that you can't "solve"<br>
> such issues. All you can do is provide a framework that enables different uses to<br>
> > *cooperate* in some way.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Which is why the Internet drops packets rather than queueing them,<br>
> and why diffserv cannot work.<br>
> > ><br>
> > > (I know the latter is conftroversial, but at the moment, ALL of<br>
> diffserv attempts to talk about end-to-end applicaiton specific metrics, but<br>
> never, ever<br>
> > explains what the diffserv control points actually do w.r.t. what the IP<br>
> layer can actually control. So it is meaningless - another violation of the<br>
> > so-called end-to-end principle).<br>
> > ><br>
> > ><br>
> > ><br>
> > > Networks are about getting packets from here to there, multiplexing<br>
> the underlying resources. That's it. Quality is a whole different thing. Quality<br>
> can<br>
> > be improved by end-to-end approaches, if the underlying network provides<br>
> some kind of thing that actually creates a way for end-to-end applications to<br>
> > affect queueing and routing decisions, and more importantly getting<br>
> "telemetry" from the network regarding what is actually going on with the other<br>
> > end-to-end users sharing the infrastructure.<br>
> > ><br>
> > ><br>
> > ><br>
> > > This conference won't talk about it this way. So don't waste your<br>
> time.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Wednesday, June 30, 2021 8:12pm, "Dave Taht"<br>
> <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a> <<a href="mailto:dave.taht@gmail.com" target="_blank">mailto:dave.taht@gmail.com</a>>> said:<br>
> > ><br>
> > > > The program committee members are *amazing*. Perhaps, finally,<br>
> we can<br>
> > > > move the bar for the internet's quality metrics past endless,<br>
> blind<br>
> > > > repetitions of speedtest.<br>
> > > ><br>
> > > > For complete details, please see:<br>
> > > > <a href="https://urldefense.com/v3/__https:/www.iab.org/activities/workshops/network-quality/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4la_Ro0d0$" target="_blank">
https://www.iab.org/activities/workshops/network-quality/</a><br>
> <<a href="https://urldefense.com/v3/__https:/www.iab.org/activities/workshops/network-quality/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4la_Ro0d0$" target="_blank">https://www.iab.org/activities/workshops/network-quality/</a>><br>
> > > ><br>
> > > > Submissions Due: Monday 2nd August 2021, midnight AOE<br>
> (Anywhere On Earth)<br>
> > > > Invitations Issued by: Monday 16th August 2021<br>
> > > ><br>
> > > > Workshop Date: This will be a virtual workshop, spread over<br>
> three days:<br>
> > > ><br>
> > > > 1400-1800 UTC Tue 14th September 2021<br>
> > > > 1400-1800 UTC Wed 15th September 2021<br>
> > > > 1400-1800 UTC Thu 16th September 2021<br>
> > > ><br>
> > > > Workshop co-chairs: Wes Hardaker, Evgeny Khorov, Omer Shapira<br>
> > > ><br>
> > > > The Program Committee members:<br>
> > > ><br>
> > > > Jari Arkko, Olivier Bonaventure, Vint Cerf, Stuart Cheshire,<br>
> Sam<br>
> > > > Crowford, Nick Feamster, Jim Gettys, Toke Hoiland-Jorgensen,<br>
> Geoff<br>
> > > > Huston, Cullen Jennings, Katarzyna Kosek-Szott, Mirja<br>
> Kuehlewind,<br>
> > > > Jason Livingood, Matt Mathias, Randall Meyer, Kathleen<br>
> Nichols,<br>
> > > > Christoph Paasch, Tommy Pauly, Greg White, Keith Winstein.<br>
> > > ><br>
> > > > Send Submissions to: <a href="mailto:network-quality-workshop-pc@iab.org" target="_blank">
network-quality-workshop-pc@iab.org</a><br>
> <<a href="mailto:network-quality-workshop-pc@iab.org" target="_blank">mailto:network-quality-workshop-pc@iab.org</a>>.<br>
> > > ><br>
> > > > Position papers from academia, industry, the open source<br>
> community and<br>
> > > > others that focus on measurements, experiences, observations<br>
> and<br>
> > > > advice for the future are welcome. Papers that reflect<br>
> experience<br>
> > > > based on deployed services are especially welcome. The<br>
> organizers<br>
> > > > understand that specific actions taken by operators are<br>
> unlikely to be<br>
> > > > discussed in detail, so papers discussing general categories<br>
> of<br>
> > > > actions and issues without naming specific technologies,<br>
> products, or<br>
> > > > other players in the ecosystem are expected. Papers should not<br>
> focus<br>
> > > > on specific protocol solutions.<br>
> > > ><br>
> > > > The workshop will be by invitation only. Those wishing to<br>
> attend<br>
> > > > should submit a position paper to the address above; it may<br>
> take the<br>
> > > > form of an Internet-Draft.<br>
> > > ><br>
> > > > All inputs submitted and considered relevant will be published<br>
> on the<br>
> > > > workshop website. The organisers will decide whom to invite<br>
> based on<br>
> > > > the submissions received. Sessions will be organized according<br>
> to<br>
> > > > content, and not every accepted submission or invited attendee<br>
> will<br>
> > > > have an opportunity to present as the intent is to foster<br>
> discussion<br>
> > > > and not simply to have a sequence of presentations.<br>
> > > ><br>
> > > > Position papers from those not planning to attend the virtual<br>
> sessions<br>
> > > > themselves are also encouraged. A workshop report will be<br>
> published<br>
> > > > afterwards.<br>
> > > ><br>
> > > > Overview:<br>
> > > ><br>
> > > > "We believe that one of the major factors behind this lack of<br>
> progress<br>
> > > > is the popular perception that throughput is the often sole<br>
> measure of<br>
> > > > the quality of Internet connectivity. With such narrow focus,<br>
> people<br>
> > > > don’t consider questions such as:<br>
> > > ><br>
> > > > What is the latency under typical working conditions?<br>
> > > > How reliable is the connectivity across longer time periods?<br>
> > > > Does the network allow the use of a broad range of protocols?<br>
> > > > What services can be run by clients of the network?<br>
> > > > What kind of IPv4, NAT or IPv6 connectivity is offered, and<br>
> are there firewalls?<br>
> > > > What security mechanisms are available for local services,<br>
> such as DNS?<br>
> > > > To what degree are the privacy, confidentiality, integrity<br>
> and<br>
> > > > authenticity of user communications guarded?<br>
> > > ><br>
> > > > Improving these aspects of network quality will likely depend<br>
> on<br>
> > > > measurement and exposing metrics to all involved parties,<br>
> including to<br>
> > > > end users in a meaningful way. Such measurements and exposure<br>
> of the<br>
> > > > right metrics will allow service providers and network<br>
> operators to<br>
> > > > focus on the aspects that impacts the users’ experience<br>
> most and at<br>
> > > > the same time empowers users to choose the Internet service<br>
> that will<br>
> > > > give them the best experience."<br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > > Latest Podcast:<br>
> > > ><br>
> <a href="https://urldefense.com/v3/__https:/www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lLMPP3q8$" target="_blank">
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/</a><br>
> <<a href="https://urldefense.com/v3/__https:/www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lLMPP3q8$" target="_blank">https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/</a>><br>
> > > ><br>
> > > > Dave Täht CTO, TekLibre, LLC<br>
> > > > _______________________________________________<br>
> > > > Cerowrt-devel mailing list<br>
> > > > <a href="mailto:Cerowrt-devel@lists.bufferbloat.net" target="_blank">Cerowrt-devel@lists.bufferbloat.net</a><br>
> <<a href="mailto:Cerowrt-devel@lists.bufferbloat.net" target="_blank">mailto:Cerowrt-devel@lists.bufferbloat.net</a>><br>
> > > > <a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/cerowrt-devel__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lu5wVUaY$" target="_blank">
https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
> <<a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/cerowrt-devel__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lu5wVUaY$" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a>><br>
> > > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Latest Podcast:<br>
> > <a href="https://urldefense.com/v3/__https:/www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lLMPP3q8$" target="_blank">
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/</a><br>
> <<a href="https://urldefense.com/v3/__https:/www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lLMPP3q8$" target="_blank">https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/</a>><br>
> ><br>
> > Dave Täht CTO, TekLibre, LLC<br>
> > _______________________________________________<br>
> > Make-wifi-fast mailing list<br>
> > <a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br>
> <<a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">mailto:Make-wifi-fast@lists.bufferbloat.net</a>><br>
> > <a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/make-wifi-fast__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lit3ThNE$" target="_blank">
https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
> <<a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/make-wifi-fast__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lit3ThNE$" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a>><br>
> ><br>
> ><br>
> > This electronic communication and the information and any files transmitted<br>
> with it, or attached to it, are confidential and are intended solely for the use<br>
> of<br>
> > the individual or entity to whom it is addressed and may contain information<br>
> that is confidential, legally privileged, protected by privacy laws, or otherwise<br>
> > restricted from disclosure to anyone else. If you are not the intended<br>
> recipient or the person responsible for delivering the e-mail to the intended<br>
> recipient,<br>
> > you are hereby notified that any use, copying, distributing, dissemination,<br>
> forwarding, printing, or copying of this e-mail is strictly prohibited. If you<br>
> > received this e-mail in error, please return the e-mail to the sender, delete<br>
> it from your computer, and destroy any printed copy of it.<br>
> ><br>
> > _______________________________________________<br>
> > Starlink mailing list<br>
> > <a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
> > <a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/starlink__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lgGXxLkE$" target="_blank">
https://lists.bufferbloat.net/listinfo/starlink</a><br>
> ><br>
> <br>
> <br>
> --<br>
> Ben Greear <<a href="mailto:greearb@candelatech.com" target="_blank">greearb@candelatech.com</a>><br>
> Candela Technologies Inc <a href="https://urldefense.com/v3/__http:/www.candelatech.com__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4laCFWpfI$" target="_blank">
http://www.candelatech.com</a><br>
><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">_______________________________________________<br>
Starlink mailing list<br>
<a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
<a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/starlink__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lgGXxLkE$" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">_______________________________________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br>
<a href="https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/make-wifi-fast__;!!GjvTz_vk!BT68CF5LoYeU1mMi8k8WTNLAhUoaYX7fzILHhoETQXGTqQJQK8-TaS4lit3ThNE$" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><o:p></o:p></span></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>