From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 F017321F1EE for ; Sun, 29 Sep 2013 02:37:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 973899C; Sun, 29 Sep 2013 11:37:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DA0A9A; Sun, 29 Sep 2013 11:37:56 +0200 (CEST) Date: Sun, 29 Sep 2013 11:37:56 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201309290116.r8T1GSQT021164@bagheera.jungle.bt.co.uk> Message-ID: References: <20130925143510.GA6191@sesse.net> <012C3117EDDB3C4781FD802A8C27DD4F25D8E29B@SACEXCMBX02-PRD.hq.netapp.com> <6F314D4E-A03B-4273-A79B-EB14EDCF8274@netapp.com> <4527B7F6-F86C-4164-A80F-9C0D65FF0CEF@netapp.com> <201309290116.r8T1GSQT021164@bagheera.jungle.bt.co.uk> 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] [aqm] [iccrg] 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: Sun, 29 Sep 2013 09:38:00 -0000 On Sun, 29 Sep 2013, Bob Briscoe wrote: > The shallow marking threshold certainly keeps standing queuing delay > low. However, that's only under long-running constant conditions. During > dynamics, not waiting a few hundred msec to respond to a change in the > queue is what keeps the queuing delay predictably low. Dynamics are the > norm, not constant conditions. Well, my original question was in the context of a 3-5ms tail drop queue (such as are frequently available in lower end switches). My understanding from earlier experience is that TCP will severely saw-tooth under these conditions and only way I could see marking as being valuable was if the RTT was less than buffer depth (or at least very low). There was a discussion earlier on bloat-l regarding what the impact of a 10ms CoDel queuing scheme will have on 200ms RTT existing non-ECN TCP performance. Deep queues were invented to handle this specific use-case. One way would absolutely be for TCP to not send a lot of packets back-to-back but instead pace them out at the rate that actually makes the TCP rate be exact in a millisecond resolution instead of as it is today, perhaps tens or hundreds of milliseconds. I believe some implementations already do this. -- Mikael Abrahamsson email: swmike@swm.pp.se