<div dir="ltr">I'm wondering if the whole idea that throughput as the exclusive vector for optimization is a bit off. Even low latency high throughput designs has throughput as a driving vector. We now have high occupancy low latency (HULL) data center switches. We have to oversubscribe everything (and TCP is more than happy to oblige.) As a group, we all do this because of exactly why? <br><br>It reminds me of "weight" in the space program. Weight drove most every decision due the energy cost required to get mass out of the influence of earth's gravity. Structural integrity be damned - just make sure it has less mass.<br><br>An app setting TCP_NODELAY on a socket could signal the end to end path that the thing to optimize for this flow is latency, i.e. that the app writing this socket isn't going to be sending lots of data. In this case, the TCP feedback loop could adjust its vectors as an example. And TCP has little clue of what the app is going to do, though it can guess at it (and can guess wrong.)<br><br>I think WiFi/wireless (or no cables to act as wave guides) makes the problem quite challenging for lots of reasons. I also think the silo'ing of engineering both within companies and between companies adds to these engineering limitations. What is the OSI layer but a human abstraction? Why can't TCP be informed about PHY related things, and MACs be aware about TCP related things?  I here the call of blasphemy, "It must be end knowledge only!!"<br><br>Even the TCP assumption that a dropped packet is due to congestion is flawed. It might be due to walking past a microwave that is irradiating a bag of popcorn. Or the device orientation may change just enough that a new spatial stream is now available, instantly doubling capacity.  Or more radios can be used as CMOS radios are trending to abundance. <br><br>Just thinking out loud a bit. Sorry for the meandering in thoughts,<br>Bob<br><br><br><br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 7, 2021 at 1:27 AM Jeremy Harris <<a href="mailto:jgh@wizmail.org">jgh@wizmail.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 07/07/2021 00:49, Bob McMahon via Make-wifi-fast wrote:<br>
>  ABC (love the acronym)<br>
<br>
Conflict with Approrriate Byte Counting, though.<br>
<br>
> Does ABC try to<br>
> optimize throughput, latency or some combination, e.g. network power<br>
> (throughput/delay)?<br>
<br>
I read it as trying to optimize throughput of one specific link<br>
(the one next to the detecting location).  They didn't discuss<br>
what happens when there are two such on the path, and most of the<br>
presentation assumed that this link was the limiting one.<br>
-- <br>
Cheers,<br>
   Jeremy<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="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></blockquote></div>

<br>
<span style="background-color:rgb(255,255,255)"><font size="2">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.</font></span>