From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Trust Network" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8688A200203 for ; Tue, 12 Feb 2013 08:30:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,650,1355126400"; d="scan'208";a="19944065" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 12 Feb 2013 08:30:08 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1CGU8JN026915; Tue, 12 Feb 2013 08:30:08 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0328.009; Tue, 12 Feb 2013 08:30:08 -0800 From: "Eggert, Lars" To: Michael Richardson Thread-Topic: [Bloat] bloat in the industry Thread-Index: AQHOCTaB/7Wm71WcZEK4vY4fyftScJh28CQA Date: Tue, 12 Feb 2013 16:30:06 +0000 Message-ID: References: <21027.1360683218@sandelman.ca> In-Reply-To: <21027.1360683218@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <69B9F5BE810A89469BF6A31AB0FABE3D@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dan York , "" Subject: Re: [Bloat] bloat in the industry X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:30:10 -0000 Hi, On Feb 12, 2013, at 7:33, Michael Richardson 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. =20 > 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 documen= t 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 solu= tions to bufferbloat. But that may take longer to get done. Documenting the= problem in an Informational RFC should be faster. Lars=