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