From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x242.google.com (mail-lb0-x242.google.com [IPv6:2a00:1450:4010:c04::242]) (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 BCA193B25D; Fri, 20 May 2016 06:04:13 -0400 (EDT) Received: by mail-lb0-x242.google.com with SMTP id mx9so5307259lbb.2; Fri, 20 May 2016 03:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=71QFIBdRluG8Nyp7zvOPrKxJ3SX18CIzYJji6CETcN8=; b=VZRdj6ey0Mzmz5/cO7GFO+sjWnjv2XDPAd3G0UoCUU8vl7E6daLV1EvLTc3RDYujVU pcDbEYC9kW8h3+O5vxa8QnGoLqX234rZl+AVT5jHAvTGOELQBepr5xlMxYMuyo+eXiSK AXhk09dpxvRCU3I/1616kIy3Vma8xALk0Gy1qxOYg/GQrdTaWSOAvW4sFKrJfuco5o9n k1RG8CznPCYnfYFeWPTMgDj209afKSvE7Wb3efFRz8h+BmRzpqTghOtbQcVWPHP0FMDg fXIOsVgq3pG0d5PNrri/EcE91ZCPAzuma9dHWwYLeurERPGBOyuATqVv/IVVXnEN3mCU 9cTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=71QFIBdRluG8Nyp7zvOPrKxJ3SX18CIzYJji6CETcN8=; b=gIonSvX2AstDTQ45T3G+KCg4UPGlSo+V0MfqkEksOU15Zm1cEU08GMUXFtFwEf+Q7F n1XjpDzrePcNXnLLi4Lz1x4VO8MjoqCY0A9IArk9Y2h3GbbfQIrlxBVXbRGxo4eXQKDa q4SbeN3dHidNBW+88T4MUPXN45IULwPE/4KQNEQAlgMYcC4VzFJ8v5feNKWz6CGZQNcg 2stjI05d3QSAf5ZyEo3eokuQziaXXXSyi0hMDj+/tkkzW6bN5y4vMrje6xYlHCYNQEt2 tkEFDDE94UbJwOJBPQGc9bE5kQ8HZHSf/R66s3UbOwGTL6btSaFL5r93Exu0TG1lBmvO 6k/g== X-Gm-Message-State: AOPr4FWkDZEy5DzqmEhmz0VoKNX6BWqnZRhPRPwPhw3fWmP09QoieOQhhy3UoQmu6F0XYA== X-Received: by 10.112.180.198 with SMTP id dq6mr761876lbc.142.1463738652314; Fri, 20 May 2016 03:04:12 -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 ns2sm3145778lbb.12.2016.05.20.03.04.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 03:04:11 -0700 (PDT) From: Jonathan Morton Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 20 May 2016 13:04:09 +0300 To: cake@lists.bufferbloat.net, codel@lists.bufferbloat.net Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Subject: [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 10:04:14 -0000 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. 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. The name COBALT, as well as referring to a nice shade of blue, can read = =E2=80=9CCodel-BLUE Alternate=E2=80=9D. 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. 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. 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. A couple of details are necessary to integrate BLUE with a = flow-isolating qdisc: 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. 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=99s = drop probability is nonzero. 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. 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. - Jonathan Morton