[ih] internet-future mailing list ?

[Dave Taht via Internet-history]

Toerless Eckert <tte at cs.fau.de> writes:

G> On Wed, Dec 18, 2019 at 11:35:13AM -0800, Dave Taht via Internet-history wrote:
>> Pretty good rant on a recent MIT paper from dave reed:
>> 
>> https://lists.bufferbloat.net/pipermail/bloat/2019-December/009453.html
>> 
>> but it's really not MIT's fault. They are locked out at the most basic
>> level - be it firmware or gates - from participating in what otherwise
>> could be an exciting next phase in wireless development.
>> 
>> About the only bright spot I see at the moment in terms of hardware, is
>> the burgeoning risc-v stuff. 
>
> 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....

> various startups are re-using larger bendors "WiFi" chipsets and
> 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.

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.

The only sane dsl driver in the world was custom written by free.fr, and
they won't let it go. DSLAMs, fuggetabout 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.

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

>
> 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.

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.

> 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 

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.

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.


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