From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by huchra.bufferbloat.net (Postfix) with ESMTP id 55AA821F0F2 for ; Thu, 21 Feb 2013 04:47:38 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B33E4110B9 for ; Thu, 21 Feb 2013 13:47:36 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 74F024110A8 for ; Thu, 21 Feb 2013 13:47:36 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Feb 2013 13:47:36 +0100 Received: from [172.31.0.6] ([10.193.116.12]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Feb 2013 13:47:35 +0100 Message-ID: <51261767.7060501@orange.com> Date: Thu, 21 Feb 2013 13:47:35 +0100 From: MUSCARIELLO Luca OLNC/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <21027.1360683218@sandelman.ca> <42748A6D-5BE5-4B9A-8104-7063231875B2@isoc.org> In-Reply-To: <42748A6D-5BE5-4B9A-8104-7063231875B2@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2013 12:47:35.0914 (UTC) FILETIME=[9FB404A0:01CE1031] Subject: Re: [Bloat] bloat in the industry X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: MUSCARIELLO Luca OLNC/OLN List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 12:47:38 -0000 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 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