[Bloat] bloat in the industry

[Bloat] bloat in the industry

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]


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    [ 
	

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: [Bloat] bloat in the industry

[Eggert, Lars]

Hi,

On Feb 12, 2013, at 7:33, Michael Richardson <mcr@sandelman.ca> wrote:
> 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.

something else that (maybe in addition) could be useful would be to document the bufferbloat symptoms and causes in an RFC. Then you could refer your suppliers to said RFC and request them to state that their gear does *not* exhibit the documented issues.

In a second step, you'd want to be able to point to RFCs standardizing solutions to bufferbloat. But that may take longer to get done. Documenting the problem in an Informational RFC should be faster.

Lars

Re: [Bloat] bloat in the industry

[Michael Richardson]

>>>>> "Eggert," == Eggert, Lars <lars@netapp.com> writes:
    >> 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.

    Eggert> something else that (maybe in addition) could be useful
    Eggert> would be to document the bufferbloat symptoms and causes in
    Eggert> an RFC. Then you could refer your suppliers to said RFC and
    Eggert> request them to state that their gear does *not* exhibit
    Eggert> the documented issues.

I agree that this would help, it's the first step.

The document needs to be authored with someone with some serious
transport credentials.  I'm not such a person.

Transcribing Van Jacobson's IETF84 presentation would almost be enough...

(https://plus.google.com/107942175615993706558/posts/F6G2qAD6fPN)

-- 
]               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    [ 
	

Re: [Bloat] bloat in the industry

[Matthew Ford]

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@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@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
> 	
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [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@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@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