From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8B09621F0F0 for ; Fri, 27 Sep 2013 23:59:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 11E4C9C; Sat, 28 Sep 2013 08:59:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0B1D39A; Sat, 28 Sep 2013 08:59:16 +0200 (CEST) Date: Sat, 28 Sep 2013 08:59:16 +0200 (CEST) From: Mikael Abrahamsson To: "Scheffenegger, Richard" In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25D969C5@SACEXCMBX02-PRD.hq.netapp.com> Message-ID: References: <20130925143510.GA6191@sesse.net> <012C3117EDDB3C4781FD802A8C27DD4F25D8E29B@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25D969C5@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sat, 28 Sep 2013 06:59:21 -0000 On Fri, 27 Sep 2013, Scheffenegger, Richard wrote: > 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 with drop tail queue management policy, is well known to > result in timely retransmission timeout-type recoveries. Tweaking OS > time granularities down to recover in few milliseconds on paths that > usually have a few dozen microseconds delay is often not good enough, > but even that is not for cautious. Ok, so this makes sense within a data center with ECN, but I fail to see any substantial upside deploying this in an environment where RTT is in the tens of ms because TCP won't have time to react. I seem to remember reading about enhancement to TCP where packets are actually sent out with spacing between packets instead of in line-rate bursts. If everybody started doing that then I would imagine there would be less tail-drop in large RTT environments with large TCP windows? -- Mikael Abrahamsson email: swmike@swm.pp.se