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 Class 3 International Server CA - G3" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 53A4721F1E7 for ; Fri, 27 Sep 2013 06:53:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,993,1371106800"; d="scan'208";a="94005943" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 27 Sep 2013 06:53:22 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.240]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 27 Sep 2013 06:53:22 -0700 From: "Scheffenegger, Richard" To: Mikael Abrahamsson Thread-Topic: [iccrg] [aqm] [Bloat] AQM deployment status? Thread-Index: AQHOuiT+ga27g5+120C/PxDftjwespnXwfwggAGaJ4CAADlvUA== Date: Fri, 27 Sep 2013 13:53:21 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25D969C5@SACEXCMBX02-PRD.hq.netapp.com> References: <20130925143510.GA6191@sesse.net> <012C3117EDDB3C4781FD802A8C27DD4F25D8E29B@SACEXCMBX02-PRD.hq.netapp.com> 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: "iccrg@irtf.org" , "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: Fri, 27 Sep 2013 13:53:24 -0000 Hi Mikael, the papers around DCTCP have probably the information you are looking for (= map/reduce type workloads, leading to incast issues - momentary filling of = queues; loosing the final segments of a TCP session [1], which is likely wi= th drop tail queue management policy, is well known to result in timely ret= ransmission timeout-type recoveries. Tweaking OS time granularities down to= recover in few milliseconds on paths that usually have a few dozen microse= conds delay is often not good enough, but even that is not for cautious. Apparently, this is seen important and valuable enough to motivate the unil= ateral deployment of DCTCP with Windows 8 server, even though the modificat= ion in the switches is then still necessary. Richard Scheffenegger [1] Google has presented the liklihood of packet loss per segment vs. burst= size; Figure 3 in this paper http://plus.url.google.com/url?sa=3Dz&n=3D138= 0288903097&url=3Dhttp%3A%2F%2Fstatic.googleusercontent.com%2Fexternal_conte= nt%2Funtrusted_dlcp%2Fresearch.google.com%2Fen%2F%2Fpubs%2Farchive%2F41217.= pdf&usg=3DlEiaJfELSWQoGNsDNsbQgbSO9RQ. > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Freitag, 27. September 2013 04:59 > To: Scheffenegger, Richard > Cc: iccrg@irtf.org; aqm@ietf.org; bloat > Subject: RE: [iccrg] [aqm] [Bloat] AQM deployment status? >=20 > On Thu, 26 Sep 2013, Scheffenegger, Richard wrote: >=20 > > I'd state that people operating datacenters with request-response type > > data exchange via TCP do care a lot about the microscopic drop > > distribution. Typically, a tail-drop queue has the unfortunate > > property of losing the more critical packets of such an exchange, > > leading to excessive "transaction" (higher level protocol) delays due > > to lengthy TCP loss recovery. >=20 > Do you know of simulations or similar that investigates this? I would lik= e > to understand why having RED on a 3ms buffer depth device makes a > difference and how much difference it makes. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se