From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 BA8623BA8E for ; Tue, 5 Jun 2018 15:31:34 -0400 (EDT) Received: by mail-lf0-x233.google.com with SMTP id n15-v6so5357020lfn.10 for ; Tue, 05 Jun 2018 12:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8wuxGoEn6ZYNUuT5IWhchcbxFJefUOh9A5hjhtwdRTE=; b=hsQAeCY/vvFCInJ/pjZPeAKsJV2iQ32e0SOTmOxBx6jucfXP7z3mMV+jDAxb6R3gPm DFthIrUGf+Q+P1hvq9s84oY98Cb7kTYluOqbYGM3JtILbYYshhwmjVRwuLeMdWW88TI9 RmlmWeLm3yrYLLewU9rOBjBkjxasENGo/HO25XQxR94R9sjodCsngH6erXbsuEyYtELg rVALbpGf/wonTK+C11py29eUgZ+5wunpvG+QmMW3G8zynpP+Q42H/o77wZgthcV3qyH0 MlX10QSaBnRGv7Nq1MPvN3KCaRt2p75nN3mhs28f8wXvVAJIpdWSfMZvjMMcrcJ6d3xb pS5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8wuxGoEn6ZYNUuT5IWhchcbxFJefUOh9A5hjhtwdRTE=; b=Df/eWThcMmyKbAf42e9Fhdz5ncxy/uVYy2RDgFBeY08/ZXV36aB7rlVjaJAeXau2IP 4/XtFq9RgrFyCPpNPmaoQdEQcydUm7jx9lh1ZrxO0To+3P7x4oQJoa/Lx6Wk+f72a6Tt dK6dDzyHE0iuMReDEvF7ecGmTfXu2Ar9qfBS6JLV2DDrjO45L00k5N6DP7IjNf2XdqIr S5E8FZP7it6dcYhBye90jeFIXX0Iem+37T3s7Wo8ryirCvL520DF8ULVgz/U4M75f/gU Z/Ll+d1BYbMV5gkgl+sxi/oTtaURVOd1loMoq1jIQr4YQZyeRtqsVsmaX0q33TMzgArc WJSg== X-Gm-Message-State: ALKqPwdhRICpyHA9iUuat+7qnAjtgQxofYKVODVZKycFPPzvKCnLK7Mr q9qHfjXZt667JAKmcLQpeMA= X-Google-Smtp-Source: ADUXVKKfBFYkY6YalBFyRkUbDauW419KZU+zFW5lL+U+aV/XhkF0rPzJlsR6A0vJS/M7etnFtxOIKg== X-Received: by 2002:a2e:9e57:: with SMTP id g23-v6mr15842614ljk.37.1528227093537; Tue, 05 Jun 2018 12:31:33 -0700 (PDT) Received: from [192.168.239.216] (83-245-236-31-nat-p.elisa-mobile.fi. [83.245.236.31]) by smtp.gmail.com with ESMTPSA id y12-v6sm10589742lji.34.2018.06.05.12.31.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 12:31:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jonathan Morton In-Reply-To: <9675C88A-FCC0-43EB-9C71-CBEFD67408CB@gmx.de> Date: Tue, 5 Jun 2018 22:31:30 +0300 Cc: Jonathan Foulkes , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com> 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> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.6.18) Subject: Re: [Bloat] [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking 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: Tue, 05 Jun 2018 19:31:35 -0000 > On 5 Jun, 2018, at 9:34 pm, Sebastian Moeller wrote: >=20 > 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 = flow to send a packet from. > =E2=80=A6and every packet being transferred will increase the queued = packets delay by its serialization delay. This is trivially true, but has no effect whatsoever on inter-flow = induced 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 retransmission 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. - Jonathan Morton