[Bloat] [Bulk] Re: Motivating commercial entities? tell the sales manager (fwd)

Koen Holtman k.holtman at chello.nl
Sun Mar 8 16:46:51 EDT 2015


On bringing this to the Wi-Fi alliance: here is my personal perspective as 
a standards guy.

The WiFi alliance can be an interesting promotion channel for technical 
solutions to bufferbloat because it avoids having to explain bufferbloat 
to the general public,

However, you really do have to tell a business story, not just a technical 
story, if you are going to pitch a call to action to the Wi-Fi Alliance. 
That being said, if anybody in the bufferbloat community wants to try, the 
best route is probably not by trying to qualify for buying a 'private' 
Alliance membership.  The better route would be identify the Wi-Fi 
alliance representatives of an existing alliance member company 
(preferably a Wi-Fi chip vendor) and pitch a business story to them while 
convincing them to pitch it to the wider Alliance via Alliance channels. 
(They might even bring you along as a consultant.) If you cannot convince 
a single chip vendor that an action they take in their own stack is in 
their business interest, you are certainly not going to convince a larger 
group of them in the Wi-Fi Alliance that it is in their joint business 
interest.

What to pitch?  The best type of business story to pitch is one that 
involves promoting growth in the market for Wi-Fi chipsets.  So a possible 
pitch could be that solving bufferbloat promotes growth in the IoT market, 
which in turn means growth in the market for Wi-Fi chips that go into IoT 
products.  Here is the story.  One common way to do IoT is accoding to the 
following scheme: a Wi-Fi enabled sensor A will send an event to a cloud 
server CA, then the cloud server CA sends some message to another cloud 
server CB, and then this other cloud server CB sends a command to a Wi-Fi 
enabled actuator B in the same home.  This scheme is particularly nice if 
A and B are completely different products from completely different 
vendors with completely different embedded software release cycles -- such 
vendors often find it much easier to build and maintain the necessary 
cross-everything compatibility code inside their cloud servers -- no 
embedded flash memory budget problems and easier to monitor the attack 
surface.  In the normal case the whole interaction via the cloud will take 
<50 ms, but if for some reason there are bloated buffers, this interaction 
may take up to a few seconds -- not good.  End users hate this kind of 
unpredictable quality degradation, and having unhappy end users means less 
IoT market growth.  So it helps the market to solve bufferbloat.

I'm not saying that the above is a perfect story, but it is the best pitch 
I can come up with right now.  I'm also unclear on whether bufferbloat 
might sometimes even slow down direct local-subnet Wi-Fi communication 
between A and B. Under theoretical lab conditions and with certain buffer 
arrangements in the router probably yes; would be nice for the story if it 
would really happen in practice too.

In the Wi-Fi alliance, vendors come together to promote joint action. 
This may be the action of launching a technology with a certification 
regime, but it may also be a lower-key action less visible to the general 
public, like defining a common technical solution to bufferbloat that 
vendors can adopt on a voluntary basis, if and when the vendor technical 
people have convinced the vendor commercial people.  As bufferbloat is 
hard to explain to the public, the lower-key action is probably the one 
that is easiest to pitch here.  In practive, this means pitching that a 
Wi-Fi Alliance workgroup looks at the codel solution to decide if they 
want to recommend its broad adoption.

One thing that I am unclear on is whether the codel algorithms are mature 
enough to allow them to be pitched as a low-risk solution that Wi-Fi 
vendors could all adopt to fix bufferbloat. If I browse around I am 
getting a somewhat ambigous message. Based on various blog entries and 
presentations from around 2011/2012, I get the clear impression that 
fixing bufferbloat was an open research problem back then.  I do not find 
an equaly clear message that codel is a sufficiently matured solution. So 
if this research problem is now solved with codel, then a first step would 
be for the bufferbloat community get this message out in an unambiguous 
way.  Create some coverage that Wikipedia can cite.  Apart from that, like 
in the IETF, the technical people in the Wi-Fi alliance will value running 
code and multiple independent implementations.

Kind Regards,

Koen.

-----Original Message-----
From: bloat-bounces at lists.bufferbloat.net [mailto:bloat-bounces at lists.bufferbloat.net] On Behalf Of David Collier-Brown
Sent: 05 March, 2015 13:47
To: Jonathan Morton; Dave Taht
Cc: bloat; davecb at spamcop.net
Subject: Re: [Bloat] [Bulk] Re: Motivating commercial entities? tell the sales manager

There is an advantage for members of the Alliance to step out ahead of the pack, especially if they build components used in both portables and base stations, and then a lesser advantage that they still interoperate with less advanced systems.

A group like the Alliance would be more interested in having the technology implemented the same way for everyone, so as not to fragment the business and reduce everyone's profits.

If either of those motivations provides a way in, then so much the better.  If the Alliance does a technical conference, a presentation on how wired performance was improved might be interesting to their members.

--dave

On 03/03/2015 04:20 PM, Jonathan Morton wrote:
>
> It strikes me that the Wi-Fi Alliance might be able to help with the
> marketing side of deployment once we solve the Wi-Fi specific
> problems. They have a certification process which, at least in theory,
> could help ensure that implementations actually work as advertised in
> practice.
>
> The trick of course is that membership with them is expensive and you
> need to show a genuine business interest, rather than a technical one.
> Maybe there's a back route for bringing technical things to their
> attention.
>
> If so, and if we can find it, we might start seeing "Responsive
> Wi-Fi™" on boxes next year.
>
> - Jonathan Morton
>


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain

_______________________________________________
Bloat mailing list
Bloat at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


More information about the Bloat mailing list