[Bloat] bloat in the industry

[MUSCARIELLO Luca OLNC/OLN]

Nothing to do with isoc but mostly with the subject of this thread.

A relevant place for solving problems like bufferbloat in the industry
is HGI http://www.homegatewayinitiative.org/
Most of commercial gateways to provide triple play services in the
home follow specifications coming  from this forum.

We have been working on solving "bufferbloat" in the ADSL uplink at FT by
using per-flow queuing (see also a previous mail by Jim Roberts) with
satisfactory results,  but no standard approaches are available from 
this forum.
The problem is known (not as bufferbloat) and  they probably need simple
solutions.

So every implementation, you do on your own, must be ported again
into new generation hardware/software. While Linux is often available in 
GW's CPEs,
it might happen that the fast-path is used by the switch and queuing is
managed by other packet processing units (different hardware, different 
code).

Standardization would help to avoid that. Softco and chipco should 
provide by
default this kind of solutions.

To conclude,  the ADSL uplink is becoming particularly important 
nowadays because
of "Cloud" services, so I believe HGI is a good place to consider.

Luca



On 02/21/2013 12:58 PM, Matthew Ford wrote:
> I'll note that ISOC has been pursuing work in this area for some time:
>
> 	http://www.internetsociety.org/blog/2012/11/its-still-latency-stupid
>
> We're now firmly at the point of figuring out what follow-up activities to pursue in 2013, and suggestions such as yours below are timely.
>
> Other suggestions are also very welcome, probably to me off-list is best.
>
> Mat
>
> On 12 Feb 2013, at 15:33, Michael Richardson <mcr at sandelman.ca> wrote:
>
>> 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 at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>> 	
>

-- 
France Telecom R&D - Orange Labs
MUSCARIELLO Luca - NMP/TRM
38 - 40, rue du General Leclerc
92794 Issy Les Moulineaux Cedex 9 - France
Tel : +33 (0)1 45 29 60 37
http://perso.rd.francetelecom.fr/muscariello