From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E4DBA208ADC for ; Thu, 26 Sep 2013 02:39:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,984,1371106800"; d="scan'208";a="53460559" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 26 Sep 2013 02:39:46 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.240]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 26 Sep 2013 02:39:45 -0700 From: "Scheffenegger, Richard" To: Mikael Abrahamsson , "iccrg@irtf.org" Thread-Topic: [iccrg] [aqm] [Bloat] AQM deployment status? Thread-Index: AQHOuiT+ga27g5+120C/PxDftjwespnXwfwg Date: Thu, 26 Sep 2013 09:39:45 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25D8E29B@SACEXCMBX02-PRD.hq.netapp.com> References: <20130925143510.GA6191@sesse.net> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" , bloat Subject: Re: [Bloat] [iccrg] [aqm] AQM deployment status? 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: Thu, 26 Sep 2013 09:39:47 -0000 HI Mikael, [chair-hat off] > I'd venture to claim that putting RED on a device with a few milliseconds > worth of buffer depth is pretty much useless (for instance the Cisco 6704 > or 6724 linecards). So most datacenter equipment doesn't have this, or if > they do, it's not that usable even if they had (who cares about drop > probability when taildrop is being done at 4-5 ms buffer depth?). I'd state that people operating datacenters with request-response type data= exchange via TCP do care a lot about the microscopic drop distribution. Ty= pically, a tail-drop queue has the unfortunate property of losing the more = critical packets of such an exchange, leading to excessive "transaction" (h= igher level protocol) delays due to lengthy TCP loss recovery. Agreed, that is not the regular "internet" use case, but the same gear is b= eing deployed there... Richard Scheffenegger > -----Original Message----- > From: iccrg-bounces@irtf.org [mailto:iccrg-bounces@irtf.org] On Behalf Of > Mikael Abrahamsson > Sent: Mittwoch, 25. September 2013 21:25 > To: iccrg@irtf.org > Cc: aqm@ietf.org; bloat > Subject: Re: [iccrg] [aqm] [Bloat] AQM deployment status? >=20 > On Wed, 25 Sep 2013, Akhtar, Shahid (Shahid) wrote: >=20 > > Please see below examples of support for RED/WRED from switches (from > ALU and Cisco websites, search for RED or WRED in document): >=20 > I'd venture to claim that putting RED on a device with a few milliseconds > worth of buffer depth is pretty much useless (for instance the Cisco 6704 > or 6724 linecards). So most datacenter equipment doesn't have this, or if > they do, it's not that usable even if they had (who cares about drop > probability when taildrop is being done at 4-5 ms buffer depth?). >=20 > For higher end platforms, for instance all cisco CPU based routers (for > some value of "all") can be configured with RED, fair-queue or similar, > but they come with FIFO as default. This has been the same way since at > least the mid 90ties as far as I know, long way back to cisco 1600 device > etc. >=20 > Higher end Cisco equipment such as ASR9k, 12000, CRS etc, all support > WRED, and here it makes sense since they all have ~50ms worth of bufferin= g > or more. They also come with FIFO as default setting. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg