[ih] firmware for innovation (was: Re: internet-future mailing list ?)

[Toerless Eckert via Internet-history]

On Wed, Dec 18, 2019 at 12:25:43PM -0800, Dave Taht wrote:
> > Hmm. Not sure if its really infeasible to get access to and modify 
> > WiFi firmware. I think to remember at least to have been toold that
> 
> If you know anyone....

Alas, only hearsay. And if youu go in to the smallest vendor
of such chip as a startup pitching them how they could double
their chip sales through alternative firmware in a non-wifi radio
market, thats a whole different ballpark then coming in as a
researcher. 

> > wrote modified or their own firmware for better / non-wifi radio
> > solution. But of course i don't know what the licensing conditions
> > where for the API to the chip itself.
> 
> I have been trying for 8 years to acquire source licenses for firmware
> for dsl and wifi chips, with no success. I intend to try a lot harder
> in the coming year, persuing multiple companies, and perhaps, even legal
> measures and the FCC. The first generation ax chips and drivers are
> awful - and 5G, worse.

Have lost track of DSL chips. In the past they where awfully feature
constrained, so no good way to make them do better buffering.

> I have wasted more time trying to come up with shapers that defeat the
> buffering in cable/dsl/wifi etc - rather than stuff that runs at line
> rate, merely because I couldn't find anyone at any company that could
> patch out the buffer allocation scheme for something sane.

Well, took a long time for folks to understand how to even do ingres
shaping and why you need it. Not sure that many products already
do it well.

Lots of stupid/complex remote BRAS shaping though.

> The only sane dsl driver in the world was custom written by free.fr, and
> they won't let it go. DSLAMs, fuggetabout it.

Well, the thought it to be critical to their business differentiation,
hard to blame them for not publishing it.

> In order to finally finish the bufferbloat work - and get rid of most of
> the need for expensive cpu shapers in favor of adaquate backpression - 
> We only need two algorithms in play - less than 1k lines of code -
> to solve the bufferbloat problem thoroughly - and the simplest, and the
> only one needed near the hardware - is the bql algorithm, invented in
> 2012, and universal across linux based ethernet devices today.

I thought PIE was fairly decent too, but of course i was surrounded by
that team back in the days it was done, so i do not have no good
overview of alternatives. Ultimately i think the best solution will
likely be a combination of per-hop AQM and end-to-end mechanisms, and
so far i have seen proposal mostly to focus ononly one of these two
control points.

> and in the firmware... all you need is one interrupt's worth of buffering.

If you have an algorithm only necessary because you assume to have
a limited timer resolution timer reaction entity ("interrup level"), then
i am a bit worried about the long-term necessity of it.

> > I believe the problem you seem to be referring to is more fundamental
> > for router/switch forwarding plane (research). Whereas WiFi chips
> > really are AFAIK mostly general purpose CPU/DSP based, the hardware
> > of switches / routers often has a much more convoluted model (e.g.: multi-stage).
> 
> dsl/cell/wifi are all binary blobs, almost universally. the only
> exception in the wifi world is the much heralded and aging ath9k chip.

Yes, and regulation to make it harder to violate regional frequency
requirements does not help innovation.

> Most of the designs on these technologies are very insecure and have
> full access to shared memory.
> 
> I agree that building switches is harder. Only netfpga has made the
> tiniest amount of progress there.

And feasibility in FPGA is not even a good proof for an
algorithm/approach to be feasible or ideal for custom asics because they
are sufficiently different from each othrer. Or so i was told by HW engineers.

> > Abstractions like P4 try to hide so much of those HW programming models
> > that several researchers i talked to have a very tainted opinion about what
> > router/switch forwarding hardware could do, and that of course influences also
> > how research and the industry at large seems to perceive what better
> > protocol functions would be feasible to support in next-generation 
> > high end router/switches.
> 
> Merely trying to get an invsqrt (needed for codel) into P4 has been a
> failure. P4 is mind-bendingly different and crude compared to the
> APIs on smarter enthernet cards... and 

Well, i never meant to imply that P4 would be useful as it stands today
for the core of any quos mechanisms. Indeed i think it is not, and
the long-term vision as i think i have heard from Nick is adding a 
concept of scheduled processing, and thats very difficult to put into
arbitrary chips.

> The smarter ethernet card vendors have all been swallowed up of late. 
> netronome just essentially went under. mellonox was purchased by
> nvidia. Intel just bought barefoot. There are three switch chips "out
> there", nobody working on gigE and the switches now appearing on
> integrated low end silicon are "copy and paste" affairs.

My impression was that SmartNICs are having a good business niche
in servers for stack and acceleration, especially for HW adjacent
stacks like RoCE and diagnostic/monitoring/clock-synchronization.

Then of course it would be up to third-parties to add firmware to
do more than host-stack code on such smart-nics, for forwaders.
Which brings us ack to the issue we discussed.

> Another thing I have hope for, though (trying to end on a more
> encouraging note) is I really like the work on packet pacing going on,
> where you can offload a packet and a time to send it, to the hw.

Yes. Well, there are some research papers in the last years pitching
PIFO/PIEO as a good underlying HW abstraction to enable flexible qos
in combination of calculation of rank by e.g: P4 or other programmable
forwarding plane.

Cheers
    Toerless
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history