From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AD29D3B2A3 for ; Sat, 24 Dec 2016 12:22:47 -0500 (EST) Received: by mail-lf0-x244.google.com with SMTP id y21so22289681lfa.0 for ; Sat, 24 Dec 2016 09:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RWBfAFDJXMjRfi2J1OXa+vyyTcYe/zCB1Nakv0VOL4Y=; b=EssaLdGxmX8/AsMjORGMHhUN+ExYK75Du5kBNbhIpQekrBq4/shRMKQwgOcOwWHv9i fH+3I9ix2+jo7ch9dbFCA4dsR9bwt06UxvAL+qFARLk7lWXtK0dkrqi6XLKANB7HoePy hjsTDsMXB7dYiR0F0Vl5D+3N0wVhpV7BFKpZG+GAW/im78dkTF4Es4O5ZCPfzsPcgEra fvK+2LIf0HC2vcaaKakvxwvyuhN9bMl7Bzd8xRt+RctfEXxOm7uX+y56wzpahU32NqYr nnFl27uVqzUTwB+x6OEDSx5WbUu6BDL2DKv7sOTx2C0Cy/YbmK6jYtOS+CES8B73T4Lr Yemw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RWBfAFDJXMjRfi2J1OXa+vyyTcYe/zCB1Nakv0VOL4Y=; b=YAqf+zjmN64oKHvHuWIP4jcJ+R02MCwLr1Rk0fxBXeYSoKcLTf8t+CpPcmmVrWqQN6 sLM3Cwp0uu2D1AJDIpInMd2wHZ18w3u4WB84vjKCihdiAdxkCnGqtlsDzhWRwywmRLr6 ueX/qHJCXDPPSSmYUodVyzycjiKyDramgCh1vagKom/SGX3x+8lv4eR4Gdc3C5H1Gw0I qqJQORSba5aytzF+GZY5mufa3+pPFwkTzXSrzEmULyzxDRNt8xQRUOxDwBfHrwNsYVCj 0plYWjRfbJR3Wbp0QV/EHx3QshpU/+bvDZKkErnQdZ6gLy4atJfLj1dqkrYtQ86Wb/EQ 9APQ== X-Gm-Message-State: AIkVDXItohBVVarSuEw5LSOXmHCnPu5etLOGeKtl7VEWoXdL1TtH1yxTlKthBDza+xMT6A== X-Received: by 10.25.204.86 with SMTP id c83mr4199895lfg.107.1482600166493; Sat, 24 Dec 2016 09:22:46 -0800 (PST) Received: from [192.168.100.13] (37-136-37-228.rev.dnainternet.fi. [37.136.37.228]) by smtp.gmail.com with ESMTPSA id t26sm3895778lja.48.2016.12.24.09.22.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 24 Dec 2016 09:22:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Sat, 24 Dec 2016 19:22:43 +0200 Cc: Sebastian Moeller , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <76C6FEF2-4939-4601-9F78-43B3077C39E4@gmail.com> References: <20161222174349.5bd5dffd@xeon-e3> <9A8ACB3B-8411-414E-B2C3-ABE2C276B351@gmail.com> <606D54F6-59FB-49D6-A969-F26434EF9292@gmx.de> To: Benjamin Cronce X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] upstreaming cake in 2017? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 17:22:48 -0000 > On 24 Dec, 2016, at 17:55, Benjamin Cronce wrote: >=20 > What was also interesting is the flows consuming the majority of the = buffer were always in flux. You would think the same few flows that were = consuming the buffer at one moment would continue to, but that is not = the case, TCP keeps them alternating. That sounds like the links are not actually congested on average, and = the flows which temporarily collect in the buffer are due to transitory = bursts - which is what you=E2=80=99d expect from a competently-managed = backbone. A flow-isolating AQM doesn=E2=80=99t really help there, = though Cake should be capable of scaling up to 10Gbps on a modern CPU. Conversely, there have been well-publicised instances of congestion at = peering points, which have had substantial impacts on performance. I = imagine the relevant flow counts there would be very much higher, = definitely in the thousands. Even well-managed networks occasionally = experience congestion due to exceptional loads. The workings of DRR++ are also somewhat more subtle than simply counting = the flows instantaneously in the buffer. Each queue has a deficit, and = in Cake an empty queue is not normally released from tracking a = particular flow until the deficit has been repaid (by cycling through = all the other flows and probably servicing them) and decaying the AQM = state to rest, which may often take long enough for another packet to = arrive for that flow. The number of active bulk flows can therefore exceed the number of = packets actually in the queue. This is especially true if the AQM is = working optimally and keeping the queue almost empty on average. While fq_codel does not explicitly assign queues to specific flows (ie. = to avoid hash collisions), the effects of hash collisions are similarly = felt under the same circumstances, resulting in the colliding flows = failing to receive their theoretical fair share of the link, even if = they never have packets physically in the queue at the same time. With that said, both fq_codel and Cake should work okay with statistical = multiplexing to handle exceptional flow counts. In such cases, Cake=E2=80= =99s triple-isolate feature should be turned off, by selecting either = =E2=80=9Chosts=E2=80=9D or =E2=80=9Cflows=E2=80=9D modes. I could run = an analysis to show how even the multiplexing should be. - Jonathan Morton