From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 23CEB3B260; Fri, 20 May 2016 07:37:45 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LngRb-1bUn6X3Cpj-00hshC; Fri, 20 May 2016 13:37:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Fri, 20 May 2016 13:37:41 +0200 Cc: cake@lists.bufferbloat.net, codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> References: To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:ELoe8UFijZT/3PBzevy3kb8fnAX6bk7SRehKU9Ih2dyjA1J/JMm kcxE3/GK3d/rfB34g9epbBqU+A8yRO0VTXA2X+W12bHbEH24ji+E26Dyu5QguYEqAHsCpF5 kAYmqvadELTHp7YjftknUAnMcB2OkO7tw8SderqFoAVfc9fT4iZvY1nyH+w33sGoa14y8VM rvWTmSJ5rI1AfiN8+/83g== X-UI-Out-Filterresults: notjunk:1;V01:K0:vRf4jw8gavs=:+ZFAuDlBraVpZBIwb9jdRx uCb+b6otxt0mni3+fl9dGvAxPPbmm5URqB0oroj5zMvCXxrCwe2C6DPQcePU6a3yWt7+ayYxT qDBWG7JAe+xTQdU+Uiqwvh6/r1khGaA94/bht54sCFz3KOJ1BURCGv54rsimXvVgbj+C/QpQb rU8Wz+fkAvNGMcdw+KCpt/Q9VkhzTsi8vMp2BYdLy/wBzXGS7qC82hxXOrDlJNK5h3CQAYaTY M7giNcCgLSKQx0d3UbHxs/3a5BKSc6zQ+jrX+iPmsgl35temMOjgv+yqgJHmggNRQo365lg5E d5TFwOJolrB+8dDLO4sxolnG7uM5Nma3z3WWrLDHgGKKmUqE6C7bFpFTw/YtmbAlA9AMRZMW6 eg7iVTbETFPWzQXawSHdqZhm09zAdK2ab8NXKQkHK/QlPl1/N18WviCN0FCp9BOu5m5M5Q9AG 2SqhMFiDF/reZu2E2T1OlpzFeOd+CrkU9hr2TZND+2HJE4Oqzd+JF/IvGRzFTJneA+Tub+dxc YMzvR7rV+OKeK4U3c2sRwjyJx4ja8lS5zy2YVD6DQ4UwCGMO8r3TxRvxL4Pd7Uhi5X291wCiS dhLUrS3tB6KOe9pR5hkmjcwLWV7SlCZ5mm+plcH9i0hUfAM6zx4J0qVzkBOroiDZ/bUQnlPC5 VIbdnlUtAGmG9BuhrEWEyA+SCQRjmxzq2QVswR1s608f+1+Hicr3Ps+SRG4+nv+IerGY4AnqN tbp0Swy2KnNmR8b/5NhajAMLcaClc8rVDsUpSWPTrROXpOysXIjR5Ay3qjGQlurG85OnSCB8p eCS/kts Subject: Re: [Cake] Proposing COBALT 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: Fri, 20 May 2016 11:37:45 -0000 Hi Jonathan, interesting ideas. > On May 20, 2016, at 12:04 , Jonathan Morton = wrote: >=20 > With the recent debate over handling unresponsive flows in fq_codel, I = had a brainwave involving constructing a hybrid AQM which preserves = Codel=E2=80=99s excellent properties on responsive flows, while also = reacting appropriately when faced with a UDP flood. The key difficulty = was deciding when to switch over from the Codel behaviour to a PIE or = RED like behaviour. >=20 > It turns out that BLUE is a perfect fit for this job, because it = activates when the queue is completely full - an unambiguous signal that = Codel has lost the plot and is unable to control the queue alone. BLUE = was one of the more promising AQMs in the days immediately prior to = Codel=E2=80=99s ascendance, so it should be effective outside Codel=E2=80=99= s speciality. >=20 > The name COBALT, as well as referring to a nice shade of blue, can = read =E2=80=9CCodel-BLUE Alternate=E2=80=9D. That is important, alwas start with a good acronym ;) (now = really there are some EU funding programs that actually require you to = supply an acronym if applying for a grant). >=20 > It is unnecessary to explicitly =E2=80=9Cswitch over=E2=80=9D between = Codel and BLUE; they can work in parallel, since their operating = characteristics are independent. It may be feasible to simplify the = Codel implementation, since it will no longer need to handle overload = conditions as robustly. For example, the Codel section should use ECN = marking whenever possible, and never drop an ECN-Capable packet; the = BLUE section should ignore ECN capability and simply drop packets, since = the traffic is evidently not responding to any ECN signals if BLUE is = triggered. >=20 > One of the major reasons why Codel fails on UDP floods is that its = drop schedule is time-based. This is the correct behaviour for TCP = flows, which respond adequately to one congestion signal per RTT, = regardless of the packet rate. However, it means it is easily = overwhelmed by high-packet-rate unresponsive (or anti-responsive, as = with TCP acks) floods, which an attacker or lab test can easily produce = on a high-bandwidth ingress, especially using small packets. In essence I agree, but want to point out that the protocol = itself does not really matter but rather the observed behavior of a = flow. Civilized UDP applications (that expect their data to be carried = over the best-effort internet) will also react to drops similar to = decent TCP flows, and crappy TCP implementations might not. I would = guess with the maturity of TCP stacks misbehaving TCP flows will be = rarer than misbehaving UDP flows (which might be for example = well-behaved fixed-rate isochronous flows that simply should never have = been sent over the internet). >=20 > BLUE, by contrast, uses a drop *probability*, so its effectiveness on = floods is independent of the packet rate. If necessary, its drop rate = can increase to 100% in a reasonable amount of time. >=20 > A couple of details are necessary to integrate BLUE with a = flow-isolating qdisc: >=20 > BLUE=E2=80=99s up-trigger should be on a packet drop due to overflow = (only) targeting the individual subqueue managed by that particular BLUE = instance. It is not correct to trigger BLUE globally when an overall = overflow occurs. Note also that BLUE has a timeout between triggers, = which should I think be scaled according to the estimated RTT. That sounds nice in that no additional state is required. But = with the current fq_codel I believe, the packet causing the memory limit = overrun, is not necessarily from the flow that actually caused the = problem to beginn with, and I doesn=E2=80=99t fq_codel actuall search = the fattest flow and drops from there. But I guess that selection = procedure could be run with blue as as well. >=20 > BLUE=E2=80=99s down-trigger is on the subqueue being empty when a = packet is requested from it, again on a timeout. To ensure this occurs, = it may be necessary to retain subqueues in the DRR list while BLUE=E2=80=99= s drop probability is nonzero. Question, doesn=E2=80=99t this mean the affected flow will be = throttled quite harshly? Will blue slowly decrease the drop probability = p if the flow behaves? If so, blue could just disengage if p drops below = a threshold? >=20 > Note that this does nothing to improve the situation regarding = fragmented packets. I think the correct solution in that case is to = divert all fragments (including the first) into a particular queue = dependent only on the host pair, by assuming zero for src and dst ports = and a =E2=80=9Cspecial=E2=80=9D protocol number. =20 I believe the RFC recommends using the SRC IP, DST IP, Protocol, = Identity tuple, as otherwise all fragmented flows between a host pair = will hash into the same bucket=E2=80=A6 Best Regards Sebastian > This has the distinct advantages of keeping related fragments = together, and ensuring they can=E2=80=99t take up a disproportionate = share of bandwidth in competition with normal traffic. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake