From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 719443BA8E for ; Wed, 6 Jun 2018 02:53:13 -0400 (EDT) Received: from [172.16.11.169] ([134.76.241.253]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lp3x6-1fu1pv0zm0-00evF1; Wed, 06 Jun 2018 08:53:07 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sebastian Moeller In-Reply-To: <6AD85E99-BCD8-4548-AAA4-F5B08599C7AD@gmail.com> Date: Wed, 6 Jun 2018 08:53:05 +0200 Cc: Jonathan Foulkes , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <36BE9775-A306-4DA3-B2D9-430FF07E391C@gmx.de> 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> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.8.2) X-Provags-ID: V03:K1:OyX0xXrya0y3mPW6FjmqugNSPrSYLmV0+G+adi0kg5cPIZwLgKU Gwyo1LkUwE1tBDrNxfbBPgJRMRLWTweTtb922cYP5dKhtcKpD0zkafrsbIhhqxs+iuznxxY neSVEqbdn6Wn4gbG7c7ZUAMA1pWeSmDgKEqc2ximo+XGdFaczwFPO1F4EBYfgoPBI8Oz8j+ yKE391NHSHLlS9/wPfl1A== X-UI-Out-Filterresults: notjunk:1;V01:K0:PWhqfpMdGJw=:sPWZz2UCSjBn1dnk0jWyYB JhslQ48SZYFjBHrHFpijFM6NGXkiDbGw3BPgDsIuAbF7hXO3h13LgILvVSmL9/ZbiJQoCCMha jaEW+sYVqc7W4F/UyM3rK0m8ZmLb05MjWesoXRnQLrhMSQPfUGxF6i6EUp7jb4IbyyN/P/hC9 PEbYlP4Vv+YykSObFdeMGohHTC65p5lhUXGgwHsG0hItPjdL5KBSOgQcjinz9dvzhn1cXwE/o Mzh2d0TSRqUYNm9FrQ7Fwq3ZPZ7jJIUqel+uNq+0doLf96iJd4VRkaKT8s9eUhM2K5QkRtZ6T 4WRL/TAnjT1TDDkVFvyZVTS2TfWovNmrIF0LedSIRyWwvbLauf+tnTXAB80oci8jhjXy/XjTJ FcAkPJq63dOPiAZhCYjTgljuKeUMUKhEEoP1j/XtCsm7TNQKMcb8m9jHBB2kaJ1pzdZQ/97u2 Q1txTl5wj+PFve1U6SrSefYKyzQJgDwsoBqJduLHYwpC1UsGffWuk2guC6ODEe61Nwosgu3wG FEm7tsbQcSRNqFy3u9yaKXiZcUsK4EVEAig9qiQojyr0O5aT/RSlGoMZhA7Mc3lUu+dPzRHO+ zK1wWTvWcnr/yH8umSc0aQIY4mS+GRZfPpCACJtogKpg/4oaIggvcvtIvMo/9pz5X5NQ8jJvC GPNam2rjxENtI4qVfBTmYcLVlJ04HdhAy81cezztTuqo9hSULtXY+ACKckde//bsuJmwQJD9X 90EKtTqO4Qy+PmhvppYFj90FEim8HZxRvA1PzBD8R8A2afDJLO41DhYqMLr8JI8U/XHDv5L3k o2pBwLb 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: Wed, 06 Jun 2018 06:53:13 -0000 Hi Jonathan, > On Jun 5, 2018, at 21:31, Jonathan Morton = wrote: >=20 >> 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 >=20 > Yes, which is why the DRR++ algorithm is used to carefully choose = which flow to send a packet from. Well, but look at it that way, the longer the traversal path after the = cake instance the higher the probability that the packet gets dropped by = a later hop. So on ingress we in all likelihood already passed the main = bottleneck (but beware of the local WLAN quality) on egress most of the = path is still ahead of us.=20 >=20 >> =E2=80=A6and every packet being transferred will increase the queued = packets delay by its serialization delay. >=20 > 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. I am not sure that I am getting your point, at 0.5Mbps every = full-MTU packet will hog the line foe 20+ milliseconds, so all other = flows will incur at least that 20+ ms additional latency, this is = independent of inter- or intra-flow perspective, no?. >=20 > 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. =20 I believe this not dropping is close to codel's behavior?=20 > 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. Thanks for the elaboration; clever! But dropping a packet will = instantaneous free bandwidth for other flows independent of whether the = sender has already realized that fact; sure the flow with the dropped = packet will not as smoothly revover from the loss as it would deal with = ECN signaling, but tat is not the vintage point from which I am looking = at the issue here.. >=20 > Which is why ECN remains valuable even on very low-bandwidth links. Well, I guess I should revisit that and try to get some data at = low bandwidths, but my hunch still is that=20 >=20 > - Jonathan Morton >=20