From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 C725B3B260; Fri, 20 May 2016 13:31:39 -0400 (EDT) Received: by mail-lb0-x22c.google.com with SMTP id h1so37577319lbj.3; Fri, 20 May 2016 10:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OSbgTk/CLKc/UZQ+SL3K/cZ+P6bcKb3wdUNTcgP3Rs4=; b=E1DyVT28otZQ09qEWaSl86OguWqmT4JaxcybkXoN6ZEFRI2TvZPoQ/jEA83HMnPa7P wywK0kJRv8/B3VbdSrEhxiPYF2Swx9rb29QZTZ+HsOmTLkpQI/VgivyqAByuQlLxovKd 0QLUcsgGY4pzPUHTD97mRpVF2PxSBzNnkbt143ZG1AI7g37FDDA0vR3pP8LIhCL+S7K+ +YvEyDIIExgdGBKFBxmUXr/PCknd/1FQtMc3UbXzSIhI1JhsRh6IJr4IZxkcs4cwN5km /PH5PROj8K8ic66IhFfPMVSDhNqBoAy6SGkuVzTbBJynPZ7nUTVyE62LzKYd9N0BO026 OEPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OSbgTk/CLKc/UZQ+SL3K/cZ+P6bcKb3wdUNTcgP3Rs4=; b=Qi5zjXUQKHSh6YtwloFg9+VkJsOnxJlcB1pakEumaWlv0kpCTt8RNND7l8Mm/bMzl5 GlI6r2Kjvx3kYFWZQKmzYKSnRaSp1gFJKYvU2OqnlNKvAzoAoLY0EXim0y02S/0zB4kM v0djMUf9Rh3tsAZCLnZiULl720eOLm9B+wNy3cy4ZXS9nZchE/wrifUHC8qd9BIOlyqr rAW6AMkprCBJutmn8L9ufiWLssYd+fdBoUSPsQcOI6B+vomeOWoooG9hD0VZcVx2f6QJ 63Av7znlDL9oALbeeixjwq6ew93sgDhaLfmPFcNpN01BC4OxQ7ebigaAWb7z0q/Hgcf8 tiAg== X-Gm-Message-State: AOPr4FUygXUvVWcVJaxxRBE6Uz1bs+lI7ujTBBJAgNGkLB08vsljkihVepNvlmpEwaVKJg== X-Received: by 10.112.161.132 with SMTP id xs4mr1570917lbb.35.1463765498062; Fri, 20 May 2016 10:31:38 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-138-144.bb.dnainternet.fi. [188.67.138.144]) by smtp.gmail.com with ESMTPSA id k81sm3526766lfg.16.2016.05.20.10.31.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 10:31:37 -0700 (PDT) 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: Fri, 20 May 2016 20:31:35 +0300 Cc: moeller0 , cake@lists.bufferbloat.net, codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <42DB8BB8-AF01-4236-A2A0-3245C4880399@gmail.com> References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> To: David Lang X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] [Cake] Proposing COBALT X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 17:31:40 -0000 > On 20 May, 2016, at 19:03, David Lang wrote: >=20 > On Fri, 20 May 2016, Jonathan Morton wrote: >=20 >>>> If the relative load from the flow decreases, BLUE=E2=80=99s action = will begin to leave the subqueue empty when serviced, causing BLUE=E2=80=99= s drop probability to fall off gradually, potentially until it reaches = zero. At this point the subqueue is naturally reset and will react = normally to subsequent traffic using it. >>> But if we reach a queue length of codel=E2=80=99s target (for some = small amount of time), would that not be the best point in time to hand = back to codel? Otherwise we push the queue to zero only to have codel = come in and let it grow back to target (well approximately). >>=20 >> No, because at that moment we can only assume that it is the heavy = pressure of BLUE that is keeping the queue under control. Again, this = is an aspect of Codel=E2=80=99s behaviour which should not be duplicated = in its alternate, because it depends on assumptions which have been = demonstrated not to hold. >>=20 >> BLUE doesn=E2=80=99t even start backing off until it sees the queue = empty, so for the simple and common case of an isochronous flow (or a = steady flood limited by some upstream capacity), BLUE will rapidly = increase its drop rate until the queue stops being continuously full. = In all likelihood the queue will now slowly and steadily drain until it = is empty. But the load is still there, so if BLUE stopped dropping = entirely at that point, the queue would almost instantly be full again = and it would have to ramp up from scratch. >>=20 >> Instead, BLUE backs off slightly and waits to see if the queue = *remains* empty during its timeout. If so, it backs off some more. As = long as the queue is still serviced while BLUE=E2=80=99s drop = probability is nonzero, it will back down all the way to zero *if* the = traffic has really gone away or become responsive enough for Codel to = deal with. >>=20 >> Hence BLUE will hand control back to Codel only when it is sure its = extra effort is not required. >=20 > How about testing having BLUE back off not when the queue is empty, = but when the queue is down to the codel target. >=20 > If it's efforts are still needed, it will ramp back up, but waiting = for the queue to go all the way to zero repeatedly, with codel still = running, seems like a pessimistic way to go that will over-penalize a = flow that eventually corrects itself. I can think of three cases where BLUE might trigger on a flow which is, = in fact, responsive. 1) The true RTT is *much* longer than the estimated RTT - this could = reasonably happen if the estimated RTT is =E2=80=9Cregional=E2=80=9D = grade but the flow is going over a satellite link or two. Since the = queue limit is auto-tuned (in Cake) with the estimated RTT in mind, = it=E2=80=99s possible for a TCP in slow-start to bounce off the end of = that queue if it has a very long RTT, even though Codel is frantically = signalling to it over ECN. The damage here is limited to a few, = widely-spaced dropped packets which are easily retransmitted, with no = RTOs, and a somewhat excessive (temporary) reduction in the congestion = window. 2) Something downstream is munging the ECN bits and erasing Codel=E2=80=99= s signal. This should be a rare situation in practice, but effectively = leaves BLUE in sole charge of managing the queue length via packet = drops. It should be adequate at that job. 3) The flow is managed by DCTCP rather than a normal TCP. DCTCP=E2=80=99s= response to ECN signalling is much softer than standard, and I suspect = Codel will be unable to control it, because it doesn=E2=80=99t behave = the way DCTCP expects (which is something more akin to a specially = configured RED). However, DCTCP is (supposed to be) responsive to = packet drops to the standard extent, so as in case 2, BLUE will take = sole charge. I don=E2=80=99t really see how leaving Codel =E2=80=9Cprimed=E2=80=9D to = take over from BLUE helps in any of these situations. However, = Codel=E2=80=99s additional action superimposed on BLUE might result in a = stable state emerging, rather than the queue length oscillating between = =E2=80=9Cempty=E2=80=9D and =E2=80=9Cfull=E2=80=9D. This is best = achieved by having BLUE=E2=80=99s down-trigger *below* that of Codel. - Jonathan Morton