I had a recent conversation with a person active in the IETF transport area about bufferbloat. I was interested in what the transport area and the IETF, and the ISOC, could do to bring the issue of bufferbloat in devices to the appropriate places in vendor management. Said person said that *they* had no problems reaching the CTOs of various major router vendors, and that they were responsive to the question of bufferbloat. Great, but I don't know those people myself, and most of us do not. It also doesn't get the message out to people who work at medium and smaller sized vendors, or to organizations that do not think of themselves as being in layer-3/4 at all. (Gigabit layer-2 switch chipset vendors for instance) I wear a number of hats. One of them is CTO and Network Architect of a boutique VoIP provider in Montreal. On Thursday I will have a telecon with a large vendor about a new multi-protoco access switch. This will be the upstream device, and getting bufferbloat under control is critical. I know that on Thursday the sales person and the sales engineer will be unable to spell bufferbloat. I hope they will understand "AQM"... I've raised this with them before, but their organization has not yet socialized this issue throughout their ranks. What *I* need is a place, perhaps at isoc.org, where key contacts on the bufferbloat issue at each vendor can be kept, and I could refer sales person from vendor X to bufferbloat expert at vendor X. It needs to be vaguely wiki-ish and forum-ish (as much as I hate forums), so that even if we can't get vendor Z to fix their product, we can at least share information about what did work and what didn't work. (Bandwidth limits for instance, usually don't work even if they are possible, for VPN tunnels) Furthermore, when I encounter a vendor who is not on the list, I want to be able to refer them to a place where I can use an "appeal to authority" to get them to actually make their CTO pay attention. I have CC'ed Dan York, who likely isn't on this list. I am thinking a new "deploy 360" category... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [