From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 5FA443B29E for ; Tue, 27 Nov 2018 06:01:21 -0500 (EST) Received: by mail-qt1-x82f.google.com with SMTP id n32so21150340qte.11 for ; Tue, 27 Nov 2018 03:01:21 -0800 (PST) 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; bh=XMl3uccI3ITVFZqhhGBywSneNtWvY2n741yQcaD/vu4=; b=Ko5EnEGi9wxjUfsKAxK2F2v4CMqm9u1QoKtwgbwwWdRwWzhv7VkiWY6h2O1rbe1ilY z6r2s6EeEVjT24QKXHNURa19d9rSlBhd7KiKq/yJ9o2mkN6CFUy7sP+qhcIDE2r9I5rm TRy8IPCg/FbwwaKb7AVFqTjVVApvZCl5CKk+fW4Qy0VKR8vpvcdjuUQPjmJdpXfB63Wz mbW8zGyggxD90ftKfnfcEyYlGl4bTE5o3VF6MvsSmoBx7j8WjDNXdt0PhQ5CezdSQT/M e3wrz49/upmfcCFFDKjr2rRUXDNBPkVGyi8iUEiIPq3t8AzpPxKJxBcF5FEdfxAuhNP/ fBHg== 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; bh=XMl3uccI3ITVFZqhhGBywSneNtWvY2n741yQcaD/vu4=; b=XhvuBRDPUZmeiIYX86mpoc/hLlSxnhBK9xai3258pCzhUrOVAKRDrOtzBAwX9luM2F 9RfDk73jmvxGcB0/gpyrKx6Q350fA2C9NPe2SwMh/Yz+8cZCNGDOhl3VoZZrSnJjWq9B wjDEzQ0YSQwOxcuw5/ZxXpSQld3nzHnos/qaSPbfLeTEWxDppnj1Yq2orV1fO04wcqwl qgfTx8h4/CE1D1NW2SqPPzaEYosMh0eLO9JO0PqKPu9lKBMqeUoY/L/ZeVPKAeAEecQL whcxMq9j3TP09gbQtVLMzQ+eF5LVizxgjVRG0H/KkdINpDF50Sw3AcO2VTC2ntwmeg3y veyg== X-Gm-Message-State: AGRZ1gKxaUOOIScoe7cQEy1hvsldLEmybSDriKSNo6+3EcO3nFKxEf02 tTG0boBEtK2MAwG3M4+O9pVufFOAskzEshxT+VU= X-Google-Smtp-Source: AJdET5dHy5hS2g0/BHYVeeaMf7+r+s/kWtXhFPBBMQXBVlI6wifB9X+RsodYXe/RKAC2MrvLtAXxLeTw+YIvQp9qC7w= X-Received: by 2002:aed:2946:: with SMTP id s64mr30061323qtd.383.1543316480908; Tue, 27 Nov 2018 03:01:20 -0800 (PST) MIME-Version: 1.0 References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <86b16a95-e47d-896b-9d43-69c65c52afc7@kit.edu> In-Reply-To: From: Luca Muscariello Date: Tue, 27 Nov 2018 12:01:09 +0100 Message-ID: To: Mikael Abrahamsson Cc: "Bless, Roland (TM)" , Jonathan Morton , bloat Content-Type: multipart/alternative; boundary="0000000000009ee43d057ba35e4b" Subject: Re: [Bloat] when does the CoDel part of fq_codel help in the real world? 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, 27 Nov 2018 11:01:21 -0000 --0000000000009ee43d057ba35e4b Content-Type: text/plain; charset="UTF-8" A BDP is not a large buffer. I'm not unveiling a secret. And it is just a rule of thumb to have an idea at which working point the protocol is working. In practice the protocol is usually working below or above that value. This is where AQM and ECN help also. So most of the time the protocol is working at way below 100% efficiency. My point was that FQ_codel helps to get very close to the optimum w/o adding useless queueing and latency. With a single queue that's almost impossible. No, sorry. Just impossible. On Tue, Nov 27, 2018 at 11:50 AM Mikael Abrahamsson wrote: > On Tue, 27 Nov 2018, Luca Muscariello wrote: > > > link fully utilized is defined as Q>0 unless you don't include the > > packet currently being transmitted. I do, so the TXtteer is never idle. > > But that's a detail. > > As someone who works with moving packets, it's perplexing to me to > interact with transport peeps who seem enormously focused on "goodput". My > personal opinion is that most people would be better off with 80% of their > available bandwidth being in use without any noticable buffer induced > delay, as opposed to the transport protocol doing its damndest to fill up > the link to 100% and sometimes failing and inducing delay instead. > > Could someone perhaps comment on the thinking in the transport protocol > design "crowd" when it comes to this? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --0000000000009ee43d057ba35e4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A BDP is not a large buffer. I'm not unveiling a secre= t.=C2=A0
And it is just a rule of thumb to have an idea at which workin= g point the protocol is working.
In practice the protocol is usua= lly working below or above that value.
This is where AQM and ECN = help also. So most of the time the protocol is working at way=C2=A0
below 100% efficiency.

My point was that FQ_cod= el helps to get very close to the optimum w/o adding useless queueing and l= atency.
With a single queue that's almost impossible. No, sor= ry. Just impossible.



On Tue, Nov 27, 2018 at 11:50 AM Mikael = Abrahamsson <swmike@swm.pp.se>= ; wrote:
On Tue, 27 Nov 2018, Luca = Muscariello wrote:

> link fully utilized is defined as Q>0 unless you don't include = the
> packet currently being transmitted. I do, so the TXtteer is never idle= .
> But that's a detail.

As someone who works with moving packets, it's perplexing to me to
interact with transport peeps who seem enormously focused on "goodput&= quot;. My
personal opinion is that most people would be better off with 80% of their =
available bandwidth being in use without any noticable buffer induced
delay, as opposed to the transport protocol doing its damndest to fill up <= br> the link to 100% and sometimes failing and inducing delay instead.

Could someone perhaps comment on the thinking in the transport protocol design "crowd" when it comes to this?

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
--0000000000009ee43d057ba35e4b--