From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ihemail2.lucent.com", Issuer "Entrust Certification Authority - L1C" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id EE3C821F1AA for ; Sun, 15 Dec 2013 07:16:55 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBFFGoZv013234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Dec 2013 09:16:52 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBFFGo0Q029161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Dec 2013 16:16:50 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.70]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 15 Dec 2013 16:16:50 +0100 From: "Scharf, Michael (Michael)" To: Jonathan Morton , Naeem Khademi Thread-Topic: [Bloat] What is a good burst? -- AQM evaluation guidelines Thread-Index: AQHO+ZEgwTM4/auAo0uQw7eUDgf+cppVWtso Date: Sun, 15 Dec 2013 15:16:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D14C5DF@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: , <33D65DCB-B4CC-4D2C-8ED9-E3685AF7D820@gmail.com> In-Reply-To: <33D65DCB-B4CC-4D2C-8ED9-E3685AF7D820@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: bloat Mainlinglist Subject: Re: [Bloat] What is a good burst? -- AQM evaluation guidelines 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, 15 Dec 2013 15:16:56 -0000 There are ongoing discussions in the IETF TCPM working group on sender-side= pacing:=0A= =0A= http://www.ietf.org/mail-archive/web/tcpm/current/msg08167.html=0A= =0A= http://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf=0A= =0A= Insight or contributions from further implementers would be highly welcome.= =0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: bloat-bounces@lists.bufferbloat.net [bloat-bounces@lists.bufferbloat.n= et]" im Auftrag von "Jonathan Morton [chromatix99@gmail.com]=0A= Gesendet: Sonntag, 15. Dezember 2013 13:26=0A= An: Naeem Khademi=0A= Cc: bloat Mainlinglist=0A= Betreff: Re: [Bloat] What is a good burst? -- AQM evaluation guidelines=0A= =0A= On 15 Dec, 2013, at 7:35 am, Naeem Khademi wrote:=0A= =0A= > the question remains: "what is a good burst (size) that AQMs should allow= ?"=0A= =0A= The ideal size of a TCP congestion window - which limits the size of a burs= t on a TCP flow - is equal to the natural bandwidth-delay product for the f= low. That involves the available bandwidth and the natural RTT delay - ie.= without added queueing delay.=0A= =0A= Codel operates on this basis, making an assumption about typical RTT delays= , and permitting queue residency to temporarily rise to that value without = initiating marking operations. A larger burst would be evidence of a conge= stion window that is too large, or an overall sending rate that exceeds the= bandwidth at the link the codel queue controls. A persistent queue is alw= ays taken as evidence of the latter.=0A= =0A= In a datacentre or on a LAN, natural RTT delays are much shorter (microseco= nds) than on the general Internet (milliseconds) - conversely, available ba= ndwidth is typically much higher (Gbps vs. Mbps). The two factors approxim= ately cancel out, so the bandwidth-delay product remains roughly the same i= n typical cases - although, of course, atypical cases such as satellite lin= ks (seconds of latency) and major backbones (extreme aggregate bandwidth an= d Internet-scale delays) also exist. However, RTT is more consistent betwe= en installations than bandwidth is (factor of ten difference in typical ran= ge of ADSL link speeds, factor of a hundred in WiFi), so Codel uses a time = basis rather than a byte-count basis for regulation, and is by default tune= d for typical overland Internet latencies.=0A= =0A= Fq_codel, as with other FQ-type qdiscs, tends to improve pacing when multip= le flows are present, by interleaving packets from different queued bursts.= Pacing is the general absence of bursts, and can be implemented at source= by a TCP sender that spreads packets within a congestion window through an= interval of time corresponding to the measured RTT. AFAIK, very few TCP i= mplementations actually do this, probably due to a desire to avoid interrup= t overheads (the CPU would have to be woken up by a timer for each packet).= It strikes me as feasible for NIC hardware to take on some of this burden= .=0A= =0A= - Jonathan Morton=0A= =0A= _______________________________________________=0A= Bloat mailing list=0A= Bloat@lists.bufferbloat.net=0A= https://lists.bufferbloat.net/listinfo/bloat=0A=