From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 D8CCD3B25E; Wed, 5 Oct 2016 10:22:00 -0400 (EDT) Received: by mail-lf0-x234.google.com with SMTP id x79so19403851lff.0; Wed, 05 Oct 2016 07:22:00 -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=mkVMya39KOg7FSbGzUIVISo5F3RE87YI0HHIX7d7x6g=; b=bWUEpIoLpzP718EA19kCX10CruXzs2W2FPpLhitudxkKkqKjU1hWHRPInr5grMdLHW Fzwo5NPzLGOBViP/CC+tx9XiKI4AZhspQqzN18OJepyVDuRyaSef2QgAO/axWLtxGVsH hi7k7z9UkUQRX2LyxAj3a9Ev9NpYPF1z5j7OrJAgnD65ccaTugrXktQ5r/4ERUa6D9/p XBKpYgybKQv8XdgI8ik0hFr6nuk77DHxLKH7f+vq8qnS6x5watuLyXcvm8KoW3HltD1o N8TEqjk5AdFJ35GePAvA5rFQo84cKduVqtACH6S/GETtJ9Xvf+YCDXwIE5sXTNXZlvAv k1gQ== 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=mkVMya39KOg7FSbGzUIVISo5F3RE87YI0HHIX7d7x6g=; b=IVEZ5NN3Pw/9EB88L1e3uS5hu2ZV+4pVybHtbcM7Q5R96CaGglw/mggE/vY25YYxfe joVNHEGzwCzkJKbUILtfQmYlWxZ+dmpemvZUtW//MlujxoXdF8uOjouEM0MhfxYBnzEg 714a7iU2SrTcVfPTtqrdGYiLTMpMczQs9gGJVoTaqIpXj8hPk9unZx3uhtdrcqm6vKcd deQ9bYb9x/nm9QIZAuFm9Bogk1/NBXDJBwFQwB5EBgrD6oEoWAhyNOcyg1anQU5bTrhO VzjhHadQ0N0fF7u5NmYFxUy4jw4wDLrQnbW5AgkPMhaDfzZVbW8sB+a/UlUqoP/qp7Z4 tgEA== X-Gm-Message-State: AA6/9Rl0dsqdldD3xTFMIF+6D76q9GR5oTMJhMIzaEnJ+5Ihe4rB/wX4Y6Q45Ue3AtbNpg== X-Received: by 10.25.27.195 with SMTP id b186mr4321595lfb.74.1475677319575; Wed, 05 Oct 2016 07:21:59 -0700 (PDT) Received: from [192.168.100.13] (37-33-90-35.bb.dnainternet.fi. [37.33.90.35]) by smtp.gmail.com with ESMTPSA id 72sm1697506lfx.3.2016.10.05.07.21.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Oct 2016 07:21:58 -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: <87oa2y6gma.fsf@toke.dk> Date: Wed, 5 Oct 2016 17:21:54 +0300 Cc: "Jason A. Donenfeld" , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net, WireGuard mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <87twcw9tih.fsf@toke.dk> <87ponk9if1.fsf@toke.dk> <87intc9dx2.fsf@toke.dk> <87intbfxit.fsf@toke.dk> <87eg3zf0my.fsf@toke.dk> <87oa2y6gma.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3124) Subject: Re: [Make-wifi-fast] [Cake] WireGuard Queuing, Bufferbloat, Performance, Latency, and related issues X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:22:01 -0000 > On 5 Oct, 2016, at 16:59, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > UDP floods are a concern, of > course, but CoDel doesn't deal well with those at all, so you'd = probably > want a different mechanism for that. Cake happens to have addressed the UDP flood problem by combining Codel = with BLUE. I call the combination COBALT. BLUE acts on a = percentage-drop basis, which makes it much better at handling unbounded = flood traffic compared to Codel=E2=80=99s drops-per-second basis. The way BLUE works means that it doesn=E2=80=99t kick in until Codel has = demonstrated complete inability to control the flow, which usually means = it=E2=80=99s an =E2=80=9Cunresponsive=E2=80=9D flow (ie. it doesn=E2=80=99= t respect normal congestion control signals). The two therefore work = together very naturally. It would also be reasonable to have the packet drops associated with = BLUE at enqueue time (ie. at the tail of the queue), so that they do not = occupy encryption bandwidth needlessly. Codel could still act at the = queue head, which is the best position to send congestion signals from. = Cake doesn=E2=80=99t split the actions like that, but it doesn=E2=80=99t = have a particular need to. I think it=E2=80=99s definitely a good idea to have separate Codel (and = BLUE) state per flow, which means they *do* need to be disambiguated at = the place the drops occur. Putting the queue ID in the cb along with = the enqueue time seems like a sensible way to do it. This would mean = that sparse flows both don=E2=80=99t get signalled to unnecessarily, and = don=E2=80=99t disrupt the sojourn-time pattern of bulk flows. - Jonathan Morton