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

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

[Koen Holtman]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6530 bytes --]


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@lists.bufferbloat.net [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of David Collier-Brown
Sent: 05 March, 2015 13:47
To: Jonathan Morton; Dave Taht
Cc: bloat; davecb@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@spamcop.net           |                      -- Mark Twain

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

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

[Mikael Abrahamsson]

On Sun, 8 Mar 2015, Koen Holtman wrote:

> 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

There are two things that the wifi vendors need to do, one is related to 
bufferbloat, the other is not.

They need to make sure the drivers for their devices give enough support 
for the IP stack of the device to be able to handle bufferbloat.

They need to make sure multicast works much better than it does today. 
IPv6 relies on it.

If they can't fix this, then more people are going to rely on their cabled 
connections because wifi won't be good enough, and I would imagine this 
will make it less of a driver to upgrade their equipment to support newer 
Wifi standards, which sounds like that would hurt sales. If they do fix 
it, then whatever new standard they come up with will drive sales because 
now Wifi will work better and there would be a driver to upgrade for the 
userbase, for instance that they can watch multicast TV on their wifi 
(which plain doesn't work today).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[David Lang]

On Mon, 9 Mar 2015, Mikael Abrahamsson wrote:

> They need to make sure multicast works much better than it does today. IPv6 
> relies on it.

why does IPv6 rely on multicast?

multicast is never going to work that well on a busy wireless network, 
especially one that's encrypted with a different key to each station.

If this is a fundamental requirement of IPv6, I see it more likely that it will 
mean the avoidance of IPv6 on wireless networks rather than an avoidance of 
wireless networks in order to use IPv6

David Lang

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

[Steinar H. Gunderson]

On Mon, Mar 09, 2015 at 08:40:52AM -0700, David Lang wrote:
> why does IPv6 rely on multicast?
> 
> multicast is never going to work that well on a busy wireless
> network, especially one that's encrypted with a different key to
> each station.

It relies on multicast the same way IPv4 relies on broadcast
(ARP, DHCP). If you like broadcast better than multicast, you're
free to simply treat it as such.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

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

[David Lang]

On Mon, 9 Mar 2015, Steinar H. Gunderson wrote:

> On Mon, Mar 09, 2015 at 08:40:52AM -0700, David Lang wrote:
>> why does IPv6 rely on multicast?
>>
>> multicast is never going to work that well on a busy wireless
>> network, especially one that's encrypted with a different key to
>> each station.
>
> It relies on multicast the same way IPv4 relies on broadcast
> (ARP, DHCP). If you like broadcast better than multicast, you're
> free to simply treat it as such.

DHCP only needs to get to the dhcp server(s), not to all nodes. It's unusual for 
the DHCP server to be wireless rather than wired

For ARP, it only needs to get to other wireless nodes if you are doing wireless 
<-> wireless communication, which is relatively rare. And even there, the access 
point can 'cheat' if it has an ARP entry for the IP and reply directly rather 
than contacting every wireless node.

Explicit multicast, where the devices that want to listen to the multicast have 
to tell the access point that they want to listen to a particular multicast 
aren't too bad. It's the same overhead as unicast to each node. But this doesn't 
scale to lots of wireless nodes using multicast.

It's fairly common for wireless networks to not allow wireless <-> wireless 
communication, which cuts this off entirely.

David Lang

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

[Mikael Abrahamsson]

On Mon, 9 Mar 2015, David Lang wrote:

> On Mon, 9 Mar 2015, Mikael Abrahamsson wrote:
>
>> They need to make sure multicast works much better than it does today. IPv6 
>> relies on it.
>
> why does IPv6 rely on multicast?

Because that's how it was designed back in the 90ties, as an evolution to 
how IPv4 was designed in the 70-ties and 80-ties. On a wired LAN, this is 
extremely efficient.

> multicast is never going to work that well on a busy wireless network, 
> especially one that's encrypted with a different key to each station.

That depends on how you do the multicast. Some enterprise solutions will 
treat multicast as unicast and send the multicast packets as wifi-unicast 
to each station subscribed to that group. That's one way of working around 
the problem.

> If this is a fundamental requirement of IPv6, I see it more likely that 
> it will mean the avoidance of IPv6 on wireless networks rather than an 
> avoidance of wireless networks in order to use IPv6

IPv4 relies on broadcast and that has the same problem. However, IPv6 has 
more multicast than IPv4 has broadcast which makes the problem worse.

IEEE/wifi alliance are trying to replace wired networks, that means they 
need to make sure things work as well in Wifi as it does in wired 
networks. They're not doing a great job with this.

https://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01
https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00
https://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00

People are working in the IETF to try to see what can be done. What does 
IEEE do?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se