From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x244.google.com (mail-la0-x244.google.com [IPv6:2a00:1450:4010:c03::244]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 532E021F1FE; Mon, 18 May 2015 08:41:33 -0700 (PDT) Received: by lamq1 with SMTP id q1so460245lam.1; Mon, 18 May 2015 08:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=etMyay5ARYwWgsXAPWuG8IynC8FBDVaQEOQmHnp4drI=; b=AYI3UWxYda9ECQv/Zxug950/7af4jZ0NaFXuLi0C08NPXdI/gg1oZjUzNpnap3VggA 24nbDOt1aBO6gYnjXZ6NQhMLKKZFnIk+YoUE/LP6GOJBVXwI3mxd3y6ubD9pcdArW0DZ 5K/6y78BW3l8OEsLWC5IuqrQqymT9DOJtt0k5fyo6GvWtVUqoTQorbb309CHPGb/HDSP jXxulZJJBwk6Ln5YfSE1dZIojzzyKPn+6fJVvLoR6S13Eg0QwmJb0ZwgbBVhsaGJ6ILj OjTUKteJ7WUJWM3MI8M3lDKzZJCc6Pkd0hdyoX5dZPpJJYHXIk4hBK1EpD/bz0ix30h+ b6+Q== X-Received: by 10.112.138.195 with SMTP id qs3mr17199217lbb.47.1431963645675; Mon, 18 May 2015 08:40:45 -0700 (PDT) Received: from bass.home.chromatix.fi (37-136-63-124.rev.dnainternet.fi. [37.136.63.124]) by mx.google.com with ESMTPSA id u10sm2783010laj.33.2015.05.18.08.40.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 08:40:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=utf-8 From: Jonathan Morton X-Priority: 3 (Normal) In-Reply-To: <1431961775.459218261@apps.rackspace.com> Date: Mon, 18 May 2015 18:40:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1431919815.385726792@apps.rackspace.com> <55597353.2010408@superduper.net> <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1431961775.459218261@apps.rackspace.com> To: dpreed@reed.com X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net, "Klatsky, Carl" , Simon Barber , cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:42:15 -0000 > On 18 May, 2015, at 18:09, dpreed@reed.com wrote: >=20 > I'm curious as to why one would need low priority class if you were = using fq_codel? Are the LEDBAT flows indistinguishable? Is there no = congestion signalling (no drops, no ECN)? The main reason I ask is that = end-to-end flows should share capacity well enough without magical and = rarely implemented things like diffserv and intserv. The Cloonan paper addresses this question. = http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf Let me summarise, with some more up-to-date additions: Consider a situation where a single application is downloading using = many (say 50) flows in parallel. It=E2=80=99s rather easy to provoke = BitTorrent into doing exactly this. BitTorrent also happens to use = LEDBAT by default (via uTP). With a dumb FIFO, LEDBAT will sense the queue depth via the increased = latency, and will tend to back off when some other traffic arrives to = share that queue. With AQM, the queue depth doesn=E2=80=99t increase much before ECN marks = and/or packet drops appear. LEDBAT then behaves like a conventional = TCP, since it has lost the delay signal. Hence LEDBAT is = indistinguishable from conventional TCP under AQM. With FQ, each flow gets a fair share of the bandwidth. But the = *application* using 50 flows gets 50 times as much bandwidth as the = application using only 1 flow. If the single-flow application is = something elastic like a Web browser or checking e-mail, that might be = tolerable. But if the single-flow application is inelastic (as VoIP usually is), = and needs more than 2% of the link bandwidth to work properly, that=E2=80=99= s a problem if it=E2=80=99s competing against 50 flows. That=E2=80=99s = one of the Cloonan paper=E2=80=99s results; what they recommended was to = use FQ with a small number of queues, so that this drawback was = mitigated by way of hash collisions. Adding Diffserv and recommending that LEDBAT applications use the = =E2=80=9Cbackground=E2=80=9D traffic class (CS1 DSCP) solves this = problem more elegantly. The share of bandwidth used by BitTorrent (say) = is then independent of the number of flows it uses, and it also makes = sense to configure FQ for ideal flow isolation rather than for = mitigation. - Jonathan Morton