From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "hubrelay-rd.bt.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9CB6521F1EE for ; Sat, 28 Sep 2013 18:16:45 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 29 Sep 2013 02:16:41 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Sun, 29 Sep 2013 02:16:40 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Sun, 29 Sep 2013 02:16:33 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.233.167]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r8T1GSQT021164; Sun, 29 Sep 2013 02:16:29 +0100 Message-ID: <201309290116.r8T1GSQT021164@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 29 Sep 2013 02:16:28 +0100 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: <4527B7F6-F86C-4164-A80F-9C0D65FF0CEF@netapp.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "Scheffenegger, Richard" , "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 01:16:46 -0000 Mikael, The shallow marking theshold is not the most significant feature of the AQM in DCTCP. More importantly, it does not delay congestion signals by averaging them over a period equivalent to a worst-case RTT (about 100ms), like all other AQMs do (RED, PIE, CoDel etc). 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. For instance, the AQM in DCTCP signals to a flow in slow-start as soon as it crosses the threshold. So a flow with 20ms RTT will get the signal in 20ms, and a flow with 3ms RTT will get the signal in 3ms (e.g. to or from a CDN cache). Whereas all other AQMs will delay all signals for of the order of 100ms, even if the flow has a much shorter RTT (because all these other AQMs don't know the RTT of each flow, so they use a nominal worst-case RTT). The source can use the signal as soon as it arrives (which it does at the end of slow-start), or it can smooth the signal itself (which it does once it's in congestion avoidance phase). But it can smooth the signal over its own RTT, rather than guessing a worst-case RTT. CoDel taught us that the best line-rate auto-tuning an AQM can do is to use service time. DCTCP teaches us that the best RTT auto-tuning an AQM can do is /not/ to try to guess the RTT in the first place. Instead it is best to defer anything to do with RTT to the end-system. We should learn from both lessons. Bob At 08:04 28/09/2013, Eggert, Lars wrote: >Content-Language: en-US >Content-Type: multipart/signed; > boundary="Apple-Mail=_19C08185-C4A7-46F5-925E-BA32C00EB99A"; > protocol="application/pgp-signature"; micalg=pgp-sha1 > >On Sep 28, 2013, at 9:01, Mikael Abrahamsson > wrote: > > So in datacenter one wants to start marking ECN on packets very > soon into buffer depth, hoping sender will get feedback and > throttle back the speed way before one gets taildrops? > >Yep. There have been a bunch of papers on datacenter TCP variants >recently (look through the last 2-3 years of SIGCOMM papers, all online.) > >Lars > > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT