[Battlemesh] [bufferbloat-fcc-signers] making wifi fast - analysis and ideas

David Hilton quercus.aeternam at gmail.com
Tue Nov 10 18:45:08 CET 2015

I would like to propose a name for this:

Pronounced: SureFi (uncertain spelling, see below).


It makes me think of some english words:
Sure, Certify, Jurify, Sure-fire

It is also similar to a chinese words:

Chinese: shì
- City, yes/correct, scholar,  to release/set free, to look at, to show,
strength/influence/momentum, persimmon...

the arrow to more translations)


There is a problem with the spelling. I think it's a little too long, plus
"surefi" is taken by a small (1-person) tech company for retail businesses
in NM, USA. ShurFi is available, but looks weird to me. SurFi is not
available. SirFi is shorter, but I'd prefer the root "sure" be clear, vs.
"sir". XrFi is short but not intuitive. SrFi might work, but might be read
as SeniorFi?

What do you all think?


On Thu, Oct 15, 2015 at 7:59 PM, Dave Taht <dave.taht at gmail.com> wrote:

> Below is some older analysis by a marketing expert of the
> make-wifi-fast project plan (although it is linked to in fcc wifi
> letter, it is so long that I doubt few as read as far as the detailed
> - and ongoing!!! - problems in wifi)
>  the planned - OPEN - engineering work on wifi is buried in the In
> closing section - here:
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit
> We are always looking for contributions of funds, resources, and
> engineering time towards actually making wifi better. I had hoped to
> kick off the per-station queuing portion of the effort last week,
> actually.
> Is there anyone here that is actually a member of the wifi alliance?
> Has anyone reached out to them?
> http://www.wi-fi.org/who-we-are/member-companies
> There are quite a large number of companies that have got their seven
> thousand dollar coffee cup from the alliance, after passing their
> lousy tests for certification.
> ... snip snip - analysis by bill weinberg of the make-wifi-fast plan ....
> Here are my main impressions of the material you supplied and the
> efforts required:
> About 1/3 fto 1/2 of the concrete actions required/recommended can
> occur "organically", that is, through ad hoc and semi-organized
> efforts of individuals and small teams.  The remaining work will
> require fairly dramatic engineering investments and also
> cross-industry changes in mindsets and practices - not something IMHO
> achievable without a paradigm shift (see below)
> - binary blobs and open behavior:  Even after 20 years of open source
> driving ecosystem expansion, key players remain incredibly guarded
> with regard to "their high-value IP" (herein intellectual property,
> not Internet Protocol), all the way down to low-level code in
> networking drivers.  In this case I speak from very direct experience,
> in particular with semiconductor suppliers who service the WiFi
> marketplace.  They are the real source of binary blobs, or more
> specifically, obfuscation and lack of access to chipset particulars
> and the code that should enable maximum wireless silicon ROI.  These
> companies, for better or worse, are IP-driven and almost always
> IP-paranoid, even in / especially around otherwise open source
> settings.  It will require a simultaneous carrot and stick approach to
> get them to abolish the blobs:  a clear value proposition to fully
> open source drivers and exposed MAC and performance assist
> technologies, and an unpalatable onus for continuing business-as-usual
> - legacy / backward wireless standard interoperability:  across the
> spectrum of IT we see how backward compatibility provides short-term
> business gain and long-term ecosystem pain.  My favorite examples
> include the x86 architecture, the ARM architecture, HTML attributes,
> legacy encryption standards (now enabling back-off exploits), the US
> and IPv4 and support for 16 and 32 bit infrastructure in an
> increasingly 64 bit world.    The WiFi document highlights how
> backward compatibility is killing WiFi performance.  My suggestion is
> the establish a new "basement", wherein devices after a certain point
> will only support newer standards, with explicit provision on how to
> handle legacy with parallel tech, as was the case in the early days of
> WiFi (e.g., with USB-based and SD-interface devices vs. native ones)
> - Co-opting the WiFi Alliance:  the WiFi brand is currently owned by
> the WiFi Alliance who, IMHO, think that they are doing a great job of
> managing the brand and of promoting WiFi evolution.  Not.
> I think the key is to "invent" a new WiFi.  It might really use the
> most advanced versions of existing tech, but it would get a new name,
> and most importantly, new standards that encompass many/most of the
> micro-solutions outlined in Jim Getty's "Make WiFi Fast" document, as
> follows:
> - a clean transition to the most advanced, forward-looking spec cum
> standard
> - a consortium to (re)brand the new medium (call it Firefly or what
> you will) and establish ground rules for participation, enforced by
> branding rights:
>     * no binary blobs ~ fully OSS drivers and other support code, up
> to a pre-defined level in the stack
>     * driver coding standards for Linux, Windows and RTOSes to promote
> openness, anti-buffer bloat, etc.
>     * specific provision for the use cases mentioned in Jim's document
> (e.g., multicast, mesh, IoT, etc. [pardon non orthogonal members])
>     * specific rules on how to continue supporting legacy 802.11* with
> completely parallel infrastructure (albeit in same sorry band)
>     * two (no less) strong founding members, comprised of one wireless
> chipset provider (of substance) and one OEM (ideal would be Intel and
> Cisco - dream on) and incentive for the rest of the gang to join on
> day 1 or 2
>     * special extraordinary efforts to get Asia on board - China in
> particular - to participate (concessions probably required, esp.
> around security, as before)
>     * start with a professional body management company (e.g., Global
> Inventures) but envision a small professional staff, especially to
> manage endowments and to instigate marketing
>     * such a new group would need to 1) subsume the WiFi Alliance, 2)
> co-opt it and effectively take its place, or 3) find a way to
> complement the WiFi Alliance.  The alternative is to stage a putsch
> and take over the WiFi Alliance from within, probably on the backs of
> key sponsoring members (see
> http://www.wi-fi.org/who-we-are/member-companies) (am I overstating
> the actual importance of WFA?)
> ...
> sincerely
> Dave Taht
> http://www.bufferbloat.net/projects/bloat/wiki/Daves_Media_Guidance
> _______________________________________________
> bufferbloat-fcc-signers mailing list
> bufferbloat-fcc-signers at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-signers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20151110/eaa4e0cc/attachment-0001.html>

More information about the Battlemesh mailing list