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

Tue Nov 10 17:47:50 UTC 2015

Adding bufferbloat-fcc-discuss.

David

On Tue, Nov 10, 2015 at 10:45 AM, David Hilton <quercus.aeternam at gmail.com>
wrote:

> 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ì
> <http://dictionary.hantrainerpro.com/chinese-english/translation-shi_city.htm> (sure)
> - City, yes/correct, scholar,  to release/set free, to look at, to show,
> strength/influence/momentum, persimmon...
>
>
> http://dictionary.hantrainerpro.com/chinese-english/translation-shi_city.htm (follow
> 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?
>
> David
>
> 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:
>>
>> DIVERSE / DIFFUSE ACTION 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)
>>
>> BIGGEST CHALLENGES
>>
>> - 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.
>>
>>
>>
>> BIG SOLUTION
>>
>> 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/56b8825e/attachment-0001.htm>