From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by huchra.bufferbloat.net (Postfix) with ESMTP id C93EA21F1A8 for ; Tue, 7 May 2013 06:43:42 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id EB8DA2016E for ; Tue, 7 May 2013 09:54:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0057863A7E; Tue, 7 May 2013 09:42:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E3931639DF for ; Tue, 7 May 2013 09:42:36 -0400 (EDT) From: Michael Richardson To: bloat X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [Bloat] a request I made to ISOC and IETF TSV AD 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, 07 May 2013 13:43:43 -0000 this is a FYI. ISOC says they are full for 2013. If someone can think of another entity to coordinate, and take some of the *outreach* load off of JG, DT, and friends, name it.. On May 6, 2013, at 3:49 PM, Michael Richardson wrote: > Welcome to the IESG, Spencer. > > I am putting my hat on as . > Novavision is a boutique business ISP in Montreal, Quebec has fiber in a > number of industrial parks. I'm the network architect and director of R&D. > We have serious bufferbloat issues that prevent us from deploying the > kind of service we want. In many cases I control both ends of the > layer-3, and I could deploy whatever I want. If only I could train the > sales engineers of my vendors... > Awhile ago I suggested to Dan York that ISOC should consider adding > bufferbloat to it's Deploy360-ish efforts. A key thing for me around > bufferbloat is: > a) convincing companies that it's real. A video hosted by > Vint or Bob Kahn, aimed at semi-technical CTOs would help. > > b) having convinced them that it's real, I need to find out what > they are doing about it, and what work arounds they might have. > > I suggest a well curated wiki for (b), with encouragement for > vendors to link directly to their "knowledge bases", etc. > > c) some point of contact for bufferbloat issues... > This would have to start with some kind of IETF led attempt to > actually find out who at various companies might be in charge > of figuring who is in charge of figuring out what the contact would > be. > > Some small vendor specific background. Novavision is a Juniper partner. > I explained that I couldn't buy a product until I had some clear > statements about bufferbloat plans from the sales engineer. I tried to get > the SE some contacts... I used various contacts I had @juniper.net, but > they came up blank. They didn't know how to address this question > either. I think that this is a industry wide problem. >