Keep It Simple, Stupid. That's a classic architectural principle that still applies. Unfortunately folks who only think hardware want to add features to hardware, but don't study the actual real world version of the problem. IMO, and it's based on 50 years of experience in network and operating systems performance, latency (response time) is almost always the primary measure users care about. They never care about maximizing "utilization" of resources. After all, in a city, you get maximum utilization of roads when you create a traffic jam. That's not the normal state. In communications, the network should always be at about 10% utilization, because you never want a traffic jam across the whole system to accumulate. Even the old Bell System was engineered to not saturate the links on the worst minute of the worst hour of the worst day of the year (which was often Mother's Day, but could be when a power blackout occurs). Yet, academics become obsessed with achieving constant very high utilization. And sometimes low leve communications folks adopt that value system, until their customers start complaining. Why doesn't this penetrate the Net-Shaped Heads of switch designers and others? What's excellent about what we used to call "best efforts" packet delivery (drop early and often to signal congestion) is that it is robust and puts the onus on the senders of traffic to sort out congestion as quickly as possible. The senders ALL observe congested links quite early if their receivers are paying attention, and they can collaborate *without even knowing who the others congesting the link are*. And by picking the heaviest congestors with higher probability to drop, fq_codel pushes back in a "fair" way when congestion actually crops up. (probabilistically). It isn't the responsibility of routers to get packets through at any cost. It's their responsibility to signal congestion early enough that it doesn't persist very long at all due to source based rate adaptation. In other words, a router's job is to route packets and do useful telemetry for the end points using it at the instant. Please stop focusing on what is an irrelevant metric (maximum throughput with maximum utilization in a special situation only). Focus on what routers can do well because they actually observe it (instantaneous congestion events) and keep them simple. . On Thursday, July 8, 2021 10:40am, "Jonathan Morton" <chromati...@gmail.com> said:
> > On 8 Jul, 2021, at 4:29 pm, Matt Mathis via Bloat > <bloat@lists.bufferbloat.net> wrote: > > > > That said, it is also true that multi-stream BBR behavior is quite > complicated and needs more queue space than single stream. This complicates > the > story around the traditional workaround of using multiple streams to > compensate > for Reno & CUBIC lameness at larger scales (ordinary scales today). > Multi-stream does not help BBR throughput and raises the queue occupancy, to > the > detriment of other users. > > I happen to think that using multiple streams for the sake of maximising > throughput is the wrong approach - it is a workaround employed pragmatically > by > some applications, nothing more. If BBR can do just as well using a single > flow, > so much the better. > > Another approach to improving the throughput of a single flow is high-fidelity > congestion control. The L4S approach to this, derived rather directly from > DCTCP, > is fundamentally flawed in that, not being fully backwards compatible with > ECN, it > cannot safely be deployed on the existing Internet. > > An alternative HFCC design using non-ambiguous signalling would be > incrementally > deployable (thus applicable to Internet scale) and naturally overlaid on > existing > window-based congestion control. It's possible to imagine such a flow reaching > optimal cwnd by way of slow-start alone, then "cruising" there in a true > equilibrium with congestion signals applied by the network. In fact, we've > already shown this occurring under lab conditions; in other cases it still > takes > one CUBIC cycle to get there. BBR's periodic probing phases would not be > required > here. > > > IMHO, two approaches seem to be useful: > > a) congestion-window-based operation with paced sending > > b) rate-based/paced sending with limiting the amount of inflight data > > So this corresponds to approach a) in Roland's taxonomy. > > - Jonathan Morton > _______________________________________________ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
