From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 433A13CB35 for ; Tue, 27 Nov 2018 06:58:34 -0500 (EST) Received: by mail-qt1-x82c.google.com with SMTP id v11so21326453qtc.2 for ; Tue, 27 Nov 2018 03:58:34 -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=kldKp/h7xN9QAeHo+u/dTZXYoKMHWraMt8hNBuPztoo=; b=K9cjBczYH2xZsCvJbdMG0o899XaBmglEPEE6Xa3Fdx0I76+62VbQJ1GaTgW6de9nHz lXKmxFoFZXZaDvuvStU3JsjwF8Riy8YidPFE/2VUptSspaYDXheqnRK+7fJdhdn7MjLW R+KmHjIBl0Hj+cqF1F/GAknIwA0uB/ldFEZrBiofTnXSQLfjfbPIh2vtNttRaFmCVCnH lwoHXSzl+hVbmh+diiB+5uQDyKExZSEwMwOM7TKBTrMHHGeihlmGPNtUVISqa9J/zim2 M6/VdqMtiB3HNLxtE1zET2AqwhD2MsDW7gR2Z9mM/TCmCAXyhlN///xA3JTamvBDVEO7 vNuQ== 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=kldKp/h7xN9QAeHo+u/dTZXYoKMHWraMt8hNBuPztoo=; b=TkEfyfOlqoxUkvmjAJSniZPDNU8FauKTc66UofLCoxjocTEp1SaVqg9lSWpsqpAwEq HlMBQHTbGiiyAsMx0XxJ9Id8z+KGekRdFMzv+xtahU4SVLhKJhgv63FpyWiYtRdwOD3s P23wqeobbUkzQngCRwx9gyOAp4PzLEJT/GzZY53RdlhpM2DAik1maLl6ynMMaEy6wMCo 5m2Tftyy3HIA904kvdZG3e21RyDPwB/8SVACX5fbAz4WYU3ALmm+Xthqb+ecuXg/U6cd 7O5MXOykOZv5tvRB/W3SdqgBiyPoTqGJtnOOQ4qBw8FHLr3CGL2gnZieu7Tgx5+GBTVb 1aDg== X-Gm-Message-State: AGRZ1gLFsfpuUxc4910ynw60zDUrqacjsfa4vrmyUWLfp1fUTIdpQw9R dO+PmkIgRBVSO0IvqHwlkcF3AR6JBVWNbzWeon0= X-Google-Smtp-Source: AJdET5cV9tgnVgt2TaM1gYD2SIear3IzVC7ZyUsBW6pw57w0ZA8czmLybQyTJfm8thZn6oLcrSovdLwN1vMaGffaG1s= X-Received: by 2002:aed:2946:: with SMTP id s64mr30235361qtd.383.1543319913734; Tue, 27 Nov 2018 03:58:33 -0800 (PST) MIME-Version: 1.0 References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <86b16a95-e47d-896b-9d43-69c65c52afc7@kit.edu> <4ca89040-69cf-b429-d522-b0eac22b9f7b@kit.edu> In-Reply-To: <4ca89040-69cf-b429-d522-b0eac22b9f7b@kit.edu> From: Luca Muscariello Date: Tue, 27 Nov 2018 12:58:22 +0100 Message-ID: To: "Bless, Roland (TM)" Cc: Jonathan Morton , Mikael Abrahamsson , bloat Content-Type: multipart/alternative; boundary="0000000000003ba508057ba42b24" 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:58:34 -0000 --0000000000003ba508057ba42b24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A buffer in a router is sized once. RTT varies. So BDP varies. That=E2=80=99s as simple as that. So you just cannot be always at optimum because you don=E2=80=99t know what= RTT you have at any time. Lola si not solving that. No protocol could BTW. BTW I don=E2=80=99t see any formal proof about queue occupancy in the pape= r. On Tue 27 Nov 2018 at 12:53, Bless, Roland (TM) wrote: > Hi Luca, > > Am 27.11.18 um 12:01 schrieb Luca Muscariello: > > A BDP is not a large buffer. I'm not unveiling a secret. > > That depends on speed and RTT (note that typically there are > several flows with different RTTs sharing the same buffer). > The essential point is not how much buffer capacity is available, > but how much is actually used, because that adds queueing delay. > > > And it is just a rule of thumb to have an idea at which working point > > the protocol is working. > > No, one can actually prove that this is the best size for > loss-based CC with backoff factor of 0.5 (assuming a single flow). > > > In practice the protocol is usually working below or above that value. > > That depends on the protocol. > > > This is where AQM and ECN help also. So most of the time the protocol i= s > > 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 impossibl= e. > > No, it's possible. Please read the TCP LoLa paper. > > Regards, > Roland > --0000000000003ba508057ba42b24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A buffer in a router is sized once. RTT varies.
So BDP varies. That=E2=80=99s as simple as that.
So you just cannot be always at optimum because you d= on=E2=80=99t know what RTT you have at any time.
Lola si not solving that. No protocol could BTW.
BTW I don=E2=80=99t see =C2=A0any formal proof about = queue occupancy in the paper.



On Tue 27 Nov 2018 at 12:53, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
<= /div>
Hi Luca,

Am 27.11.18 um 12:01 schrieb Luca Muscariello:
> A BDP is not a large buffer. I'm not unveiling a secret.

That depends on speed and RTT (note that typically there are
several flows with different RTTs sharing the same buffer).
The essential point is not how much buffer capacity is available,
but how much is actually used, because that adds queueing delay.

> And it is just a rule of thumb to have an idea at which working point<= br> > the protocol is working.

No, one can actually prove that this is the best size for
loss-based CC with backoff factor of 0.5 (assuming a single flow).

> In practice the protocol is usually working below or above that value.=

That depends on the protocol.

> 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_codel helps to get very close to the optimum w/o<= br> > adding useless queueing and latency.
> With a single queue that's almost impossible. No, sorry. Just impo= ssible.

No, it's possible. Please read the TCP LoLa paper.

Regards,
=C2=A0Roland
--0000000000003ba508057ba42b24--