<font face="arial" size="2"><p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Bob -</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I think it is great that Cisco has been looking at controlling buffer size in datacenters. However, I'm actually quite skeptical of the analysis here.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I think what is going on is that operating system scheduling delays (typical Linux scheduling of ACK packet generation for the TCP stack is very sloow compared to what the hardware is capable of doing if TCP were better implemented) are slowing the TCP connection.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Why would there need to be more than one packet of buffering if there is one flow over a link? That's the simple test case.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">So I think this is a "hotrodding" focused paper that is trying to get more throughput on a single TCP flow, where the bottleneck isn't in the link, but in the OS's crappy code design.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Now Linux's stack does just fine when the end-to-end rate is 1 Gb/s. Then on a typical server, the stack can pass work between the hardware interrupt handlers, through the thread scheduler, scheduling multiple different threads per packet arrival, which of course also adds to latency unnecessarily.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">But when a 1500 byte packet (12K bits) transits a 10 Gb/sec link, the latency between ends is around 1 microsecond.  A processor on the send and receive side can get down to 1 packet (12k bits) of buffering in the network in a well-thought out high-performance TCP, achieving under 10 microsecond user-space to user-space delivery. (not 100 microsecond).</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">So, BAD Linux design for datacenter TCP.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I'm very familiar with datacenter 10 and 40 Gb/s ethernet protocols in the kernel my company built. We use UDP now, and actually only because some datacenters require an IP header. We do RTT's with "one flow" using UDP that involve our appiication logic over a 10 GigE switch in around 50 microseconds out and back. And we haven't even tried squeezing that down. And we fill the 10 Gb/s link without needing 125 KB of "buffering".</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">The buffer sizes in the table aren't the lowest latency achievable, nor the lowest latency achievable for a flow-controlled link with full throughput.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">If you need a Cisco 9000 to correct for bad OS software by buffering too MUCH, then OK.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">But TCP implementations should ACK quicker than they do. Because we dont want such big buffers building up when UDP is flowing over the net, and the protocol on top of UDP can respond the way TCP is NOT responding. That just hurts UDP latency for those sharing these overbuffered links.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Basically, the buffering in the link should be in the network is one max Ethernet packet per active flow. No more. And even packet per source is already inside a typical (not cut-through) ethernet switch. Competing flows from the same source will block happily because Ethernet hardware doesn't admit another packet until the packet has been forwarded, so any buffering related to the end-machine applications is in the RAM of the end machine.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">On Wednesday, October 12, 2022 1:39pm, "Bob McMahon via Cake" <cake@lists.bufferbloat.net> said:<br /><br /></p>
<div id="SafeStyles1665609470">
<div dir="ltr">With full respect to open source projects like OpenWRT, I think from an energy, performance & going forward perspective the AP forwarding plane will be realized by "transistor engineers." This makes the awareness around bloat by network engineers needed even more because those design cycles take awhile. A <a href="https://anysilicon.com/tapeout/">tape out</a> is very different from a sw compile. The driving force for ASIC & CMOS radio features typically will come from IAPs or enterprise customers, mostly per revenues adds to their businesses. Customer complaints are years down the road from such design decisions so bloat mitigation or elimination needs to be designed in from the get-go.<br /><br />Bob<br /><br />PS. As a side note, data center switch architecture addressed latency & bloat with <a href="https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html">things like AFD & DPP</a> as described per a Cisco Nexus 9000. Notice their formula for queue size can be defined by a math calculation. A challenge with WiFi is that the phy rates are dynamic and have a large range so such tables aren't so straightforward and C cannot be so simply defined. In many ways the data center architects had an easier problem than we in the shared RF, battery powered, no waveguides, etc. have.<br /><br />
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>
<p class="gmail-pCMTBody" style="margin:0;padding:0;margin: 1px 0em 0.5em; padding: 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: inherit; font-size: 14px; line-height: 1.25; font-family: CiscoSans,Arial,sans-serif; vertical-align: baseline; color: #525252; text-align: justify; overflow: visible; break-before: page;"><span style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; font-variant: inherit; font-weight: inherit; font-stretch: inherit; font-size: 9pt; line-height: inherit; font-family: Arial,'sans-serif'; vertical-align: baseline; overflow: visible;">The needed buffer size is the bandwidth delay product value divided by the square root of the number of flows:</span></p>
</div>
<div>
<p class="gmail-pBody" style="margin:0;padding:0;margin: 5pt 0em 0.5em; padding: 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: inherit; font-size: 14px; line-height: 1.25; font-family: CiscoSans,Arial,sans-serif; vertical-align: baseline; color: #525252; overflow: visible;"><a class="gmail-show-image-alone" style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; font-variant: inherit; font-stretch: inherit; line-height: inherit; vertical-align: baseline; color: #005073; overflow: visible; word-break: break-word;" title="white-paper-c11-738488_16.jpg" href="https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.docx/_jcr_content/renditions/white-paper-c11-738488_16.jpg"><img id="gmail-Picture 46" style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; font-variant: inherit; font-weight: inherit; font-stretch: inherit; line-height: inherit; vertical-align: baseline; overflow: visible; max-width: 98%;" src="https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.docx/_jcr_content/renditions/white-paper-c11-738488_16.jpg" border="0" alt="white-paper-c11-738488_16.jpg" width="192" height="40" /></a></p>
</div>
<div>
<p class="gmail-pBody" style="margin:0;padding:0;margin: 1px 0em 0.5em; padding: 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: inherit; font-size: 14px; line-height: 1.25; font-family: CiscoSans,Arial,sans-serif; vertical-align: baseline; color: #525252; overflow: visible;">Here, C is the link bandwidth, RTT is round-trip time, and N is the number of long-lived flows (see reference 6 at the end of this document).</p>
</div>
<div>
<p class="gmail-pBody" style="margin:0;padding:0;margin: 1px 0em 0.5em; padding: 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: inherit; font-size: 14px; line-height: 1.25; font-family: CiscoSans,Arial,sans-serif; vertical-align: baseline; color: #525252; overflow: visible;">Using an average RTT of 100 microseconds in a data center network, Figure 11 shows the buffer size for different link speeds and various numbers of flows. Note that the buffer size decreases rapidly as the number of flows increases. For instance, on a 100-Gbps link with 2500 flows, only a 25-KB buffer is needed.</p>
<div class="gmail-pDefault" style="margin: 12pt 0pt 6pt 0px; padding: 1px 0px 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: inherit; font-size: 14px; line-height: inherit; font-family: CiscoSans,Arial,sans-serif; vertical-align: baseline; overflow: visible; color: #525252;"><span style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; font-variant: inherit; font-weight: bold; font-stretch: inherit; line-height: inherit; vertical-align: baseline; overflow: visible;">Figure 11.  <span style="margin: 0px; padding: 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-weight: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman'; vertical-align: baseline; overflow: visible;">  </span></span>Buffer Sizing for Different Link Speeds and Numbers of Flows</div>
<img src="cid:@ii_l95wqjui1" alt="image.png">
<p class="gmail-pBody" style="margin:0;padding:0;margin: 1px 0em 0.5em; padding: 0px; border: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: inherit; font-size: 14px; line-height: 1.25; font-family: CiscoSans,Arial,sans-serif; vertical-align: baseline; color: #525252; overflow: visible;"> </p>
</div>
</blockquote>
</div>
<br />
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Tue, Oct 11, 2022 at 3:24 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">Well, we've all been yammering for many years, and the message is<br /> getting through. Yes, at this point, changing the message to be more<br /> directed at engineers than users would help, and to this day, I don't<br /> know how to get to anyone in the<br /> C suite, except through the complaints of their kids. Jim got on this<br /> problem because of his kids. The guy that did dslreports, also. "my"<br /> kids are<br /><br /> At the risk of burying the lede, our very own dave reed just did a<br /> podcast on different stuff:<br /><a rel="noreferrer" href="https://twit.tv/shows/floss-weekly/episodes/701?autostart=false" target="_blank">https://twit.tv/shows/floss-weekly/episodes/701?autostart=false</a><br /><br /> Sometimes my own (shared with most of you) motivations tend to leak<br /> through. I really encourage the independent growth of user created and<br /> owned software, running on their own routers, and I'm very pleased to<br /> see the level of activity on the openwrt forums showing how healthy<br /> that part of our culture is. It would be a very different world if<br /> we'd decided to settle for whatever an ISP was willing to give us, and<br /> for things as they were, and I'm probably difficult to employ because<br /> of my<br /> fervent beliefs in anti-patenting, free and open source, and the right<br /> to repair...<br /><br /> ... but I wouldn't have my world any other way. I might die broke, but<br /> I'll die free.<br /><br /> On Tue, Oct 11, 2022 at 11:44 AM Rich Brown via Rpm<br /> <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br /> ><br /> ><br /> ><br /> ><br /> > On Oct 11, 2022, at 1:05 PM, Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com" target="_blank">bob.mcmahon@broadcom.com</a>> wrote:<br /> ><br /> > I agree that bufferbloat awareness is a good thing. The issue I have is the approach - ask consumers to "detect it" and replace a device with a new one, that may or may not, meet all the needs of the users.<br /> ><br /> ><br /> > Better is that network engineers "design bloat out" from the beginning starting by properly sizing queues to service jitter, and for WiFi, to also enable aggregation techniques that minimize TXOP consumption.<br /> ><br /> ><br /> > The Yes, but... part of my answer emphasizes awareness. How are the network engineers going to know it's worth the (minor) effort of creating properly-sized queues?<br /> ><br /> > There are two fronts to attack:<br /> ><br /> > - Manufacturers - This video is a start on getting their customers to use these responsiveness test tools and call the support lines.<br /> ><br /> > - Hardware (especially router) reviewers - It kills me that there is radio silence whenever I ask a reviewer if they have ever measured latency/responsiveness.  (BTW: Has anyone heard from Ben Moskowitz from Consumer Reports? We had a very encouraging phone call about a year ago, and they were going to get back to us...)<br /> ><br /> > Rich<br /> ><br /> ><br /> > Bob<br /> ><br /> > On Tue, Oct 11, 2022 at 6:57 AM Rich Brown <<a href="mailto:richb.hanover@gmail.com" target="_blank">richb.hanover@gmail.com</a>> wrote:<br /> >><br /> >><br /> >><br /> >> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br /> >><br /> >> > I think conflating bufferbloat with latency misses the subtle point in that<br /> >> > bufferbloat is a measurement in memory units more than a measurement in<br /> >> > time units.<br /> >><br /> >><br /> >> Yes, but... I am going to praise this video, even as I encourage all the techies to be sure that they have the units correct.<br /> >><br /> >> I've been yammering about the evils of latency/excess queueing for 10 years on my blog, in forums, etc. I have not achieved anywhere near the notoriety of this video (almost a third of a million views).<br /> >><br /> >> I am delighted that there's an engaging, mass-market Youtube video that makes the case that bufferbloat even exists.<br /> >><br /> >> Rich<br /> ><br /> ><br /> > This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.<br /> ><br /> ><br /> > _______________________________________________<br /> > Rpm mailing list<br /> > <a href="mailto:Rpm@lists.bufferbloat.net" target="_blank">Rpm@lists.bufferbloat.net</a><br /> > <a rel="noreferrer" href="https://lists.bufferbloat.net/listinfo/rpm" target="_blank">https://lists.bufferbloat.net/listinfo/rpm</a><br /><br /><br /><br /> -- <br /> This song goes out to all the folk that thought Stadia would work:<br /><a rel="noreferrer" href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br /> Dave Täht CEO, TekLibre, LLC</blockquote>
</div>
<br /><span style="background-color: #ffffff;"><span style="font-size: small;">This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.</span></span></div></font>