From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 2C7773B2A4; Mon, 13 Aug 2018 18:28:54 -0400 (EDT) Received: by mail-qt0-x243.google.com with SMTP id d4-v6so19188033qtn.13; Mon, 13 Aug 2018 15:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dHk9noFhrAKosHwG2T1t8BjD5dFXBXNLfhc58B+rhek=; b=vao5XfmHkqmIjl1N7CgWo46B++Msn/9/A9W4xQ/d7OzAKvnviFfxzch8o5ZNnEeONS Dn/LVhjee4EzgV/utW9FWWCSaiVT9kcOkgq4jExd/pK4eApGFxA25LlvdHD9mGOmjgDC DUyuiJj8hUTBAh43LILbp8CEKs/FrPyYBIj6Iu/XwF/85MfJ4ft1ewFIOtAUayjCxn+y DwYLHPJ2c2JUxKIgLEBmB3rycYbEnBuTnHkgdXa6IPk0elTcBX/JjXrbq/ZS2WNcfgZx WCromWMLFf7G0eqwMf1u+4OP7dDhjUcfKi50w3BZCG9za9BihXZ+gMZzfqjrr9XlKj4k fuLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dHk9noFhrAKosHwG2T1t8BjD5dFXBXNLfhc58B+rhek=; b=YJeGL5WbFnnCEKSHUg2qubGQzBI5XhsbBSzgwmBfKXC5UNaOsF94r/gLV1r8FGJvsF gCeYQg0K/85hTQXbui5vIDre4FhL7InYBJx6WUoRLXcoc+EyuRmD/jKhQUDfkzi0hVmV S8U1L8zdFhGBvXxfcm52T2+migJ5vvvyn7IIF8fQ9azSMCQZTKs7X+XoJXeMcmxj1ezC VagNmQrlcWSQkw34B0z4TmqByNcMEWpQS7imrtA5zYmgOq/jWVRl3Jl3Erc255BSZ/JB Ou46cbqlkRHXjh8dYWB3iTttAI7wCSPmgAgfhxQ+l1OTz49JtcnT9CHQ+kXS862jzgjA u+2Q== X-Gm-Message-State: AOUpUlHGzTsC5fVyk9lX90Pqfs8N0DoQTibm2GSqFzyQTwiDLCS8gAOs Mi3be/TTWrtmVS2BrxM3tdiYdev96N3uVsldzVc= X-Google-Smtp-Source: AA+uWPyYSa24LOYRF7mejRRhU5tzMZwv3+V55oswzNainXDL7nJ/mAQhZf5Wjp7uohfiktdEO9y51MDxjNMZQ48rkPw= X-Received: by 2002:ac8:31cd:: with SMTP id i13-v6mr18763832qte.144.1534199333583; Mon, 13 Aug 2018 15:28:53 -0700 (PDT) MIME-Version: 1.0 References: <152717340941.28154.812883711295847116.malone@soybean.canonical.com> <4f67f9b3-05a1-8d15-0aee-dfe8ea730d7c@gmail.com> <73c25a21-0ace-b5ee-090e-d06fb3b8dc60@kit.edu> <3F65061F-4F05-4F3F-8A43-FFCC1D27F585@gmail.com> <61E48C91-AEF9-4FF4-9F83-45EC7148EC54@jonathanfoulkes.com> <9675C88A-FCC0-43EB-9C71-CBEFD67408CB@gmx.de> <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com> In-Reply-To: <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com> From: Dave Taht Date: Mon, 13 Aug 2018 15:29:22 -0700 Message-ID: To: Jonathan Morton Cc: Sebastian Moeller , bloat , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Bloat] ecn redux X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 22:28:54 -0000 On Tue, Jun 5, 2018 at 12:31 PM Jonathan Morton wro= te: > > > On 5 Jun, 2018, at 9:34 pm, Sebastian Moeller wrote: > > > > The rationale for that decision still is valid, at low bandwidth every = opportunity to send a packet matters=E2=80=A6 > > Yes, which is why the DRR++ algorithm is used to carefully choose which f= low to send a packet from. > > > =E2=80=A6and every packet being transferred will increase the queued pa= ckets delay by its serialization delay. > > This is trivially true, but has no effect whatsoever on inter-flow induce= d latency, only intra-flow delay, which is already managed adequately well = by an ECN-aware sender. > > May I remind you that Cake never drops the last packet in a flow subqueue= due to AQM action, but may still apply an ECN mark to it. That's because = dropping a tail packet carries a risk of incurring an RTO before retransmis= sion occurs, rather than "only" an RTT delay. Both RTO and RTT are always = greater than the serialisation delay of a single packet. > > Which is why ECN remains valuable even on very low-bandwidth links. I guess everybody knows at this point that I'm not a big fan of ecn. I'd done a bit of work on making "drop and mark" work in earlier versions of cake and completely missed that it had got ripped out until a month or two back. I'd like to point at this bit of codel, where it can, does, and will do bulk dropping, and increase the drop schedule, even drop the last packet in that queue, while overloaded, in an attempt to get things back to the real rtt. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/inc= lude/net/codel_impl.h#n176 years ago, even on simple traffic, codel would spend 30% of it's time here. On the kinds of massive overloads for the path roland has done, it wouldn't surprise me if it was > 90%. With ecn'd traffic, in this bit of code, we do not drain the excess packets, nor do we increase the mark rate as frantically. I've aways felt this was a major flaw in codel's ecn handling, and have tried to fix it in various ways. Even pie starts dropping ecn, when the drop probability exceeds 10%. > - Jonathan Morton > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619