as well as AI for stripping out commercials.

It really nails this nightmare scenario... and is also hilarious.

This basic exploration of fuschia's basic security was not promising. The article goes deep into how to build it before diving deep into the security bugs found.

zx_status_t sys_debuglog_create(zx_handle_t rsrc, uint32_t options, user_out_handle* out) { LTRACEF("options 0x%x\n", options); // TODO(fxbug.dev/32044) Require a non-INVALID handle. if (rsrc != ZX_HANDLE_INVALID) { // TODO(fxbug.dev/30918): finer grained validation zx_status_t status = validate_resource(rsrc, ZX_RSRC_KIND_ROOT); if (status != ZX_OK) return status; }

yes. a current term for this is in-network computing. incidences of the idea of doing computation with packets seem to be revisited every 10 years.

really great interview with van jacobson over here, DOCSIS-LL aims to reduce the request/grant cycle to under a ms, which would almost make it competitive with switched fiber.

"Not having fairness as a goal" is an old debate and has been essentially the position of bob briscoe for ages, who is highly influential in the design of things like L4S.

To tackle your analogy head on: Packets are not cars. Right there the analogy falls apart. Flows are not ambulances. Also... the paper was about the prospect of flow starvation under various conditions. However... being stuck with analogies...

I wish we didn't use the terms fairness or fair queuing as much as we do, because the real goal, when I talk about fairness of packets vs a vs flows, is "sufficient multiplexing".

Once you have good multiplexing, you can then deviate selectively to give a little priority towards the ambulances of the world, or (preferably), deprioritize the diesel trucks. However pre-reserving an ambulance-only lane, much like we have HoV lanes, is inefficient.

My viewpoint is best reflected in the sch_cake fq+aqm algorithms, bob's in the dualpi AQM.

In the context of this paper I am certain "my" algos will prevent starvation, less so with bob's.

I thought this was a very good paper in that in that it comprehensively showed the unknowability of e2e congestion control, without some assistance from the network. I think we will find ever more bounds like this on the internet if we keep looking. This paper was good also. I long ago concluded this, but it's nice to have more backup. Research into congestion controls can continue, while (I hope), everyone starts just pouring better multiplexing into every bottleneck link on the internet.

You just described fq_codel, fq_pie, and cake.

We tried to deprecate the term QoS in favor of something that does work, SQM. Even then, if you are running at the line rate, just something like fq-codel or cake suffice (without a shaper). They are very lightweight, yet massive improvements over a fifo, and solve the problems outlined in this paper (were they at the bottleneck).

There's been something of a quiet revolution here. I suspect the vast majority of slashdot readers are running fq_codel today, as it's the default in linux, osx, and ios, all third party router firmwares, and a lot of wifi.
Efforts to get it into more ISPs shapers via Preseem and LibreSQM have been going on for years.

I would have liked to have thought the ./ community had thoroughly grokked by now that we don't need more bandwidth in many cases, but better bandwidth, capable of multiplexing voip, video, web traffic, etc. Yer welcome.

You will always have congestion (RFC970) due to the nature of tcp. Most tcps will grab all the bandwidth until it gets a drop (funny video). What the paper shows is that delay based tcps can starve under more circumstances than previously understood.

. What's the answer? FQ (especially rfc8290), and AQM at every fbottleneck on the internet.

If all sides in this world would agree on shipping better routers, it would be cheaper and more effective.

Raising the bar to 100/20 with lousy queuing can be worse than 25/10 with good queuing. "Speed" is both bandwidth and delay, under load. Been trying to get the FCC to pay attention to both for years: https://docs.google.com/docume...

Home routers should be built to last 10+ years. And have software, continually updated, just as today's phones are. If we could just find a way upgrade every junked router in the world to *Wrt, and deploy those to everyone we'd have good queue management, ipv6, and the ability to sleep better at night,