[Bloat] [Bulk] Re: Motivating commercial entities? tell the sales manager (fwd)
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
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.
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.
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
> 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
> 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
More information about the Bloat