From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 8B4693CB35 for ; Tue, 2 Nov 2021 10:03:01 -0400 (EDT) Received: by mail-lj1-x229.google.com with SMTP id j5so2537456lja.9 for ; Tue, 02 Nov 2021 07:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domos-no.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KGdkUzk8KeP79uB9bBVTKo4LdBoS+n3vTPSwcD42mh8=; b=E8Yd35m1lVOWaZWLGqxbL9Y3dPVfAlY6pOLAR3MhpG5SYHlcqECaoYhM43u+DByg9P mm8LUicE1jLIHe52FYSWeqJKFIx8I+N+bpFoDDmYnat7xC+TX37HlQbvOqIh02SoOs8G UnqFYdk0ra8hYWgu2oEUhyIs91SM/NQj1egXh5UuOtHqRiFZqWvnFf8JKrPGcjeqF1hD m5yXGgCDoCqgs85hD1L7aC0HtKKiYBjA5DX79ohO4HnF4MZj3Xb5FGk6phD/9FcJobd5 MNT4dCbGonqtDUrYcxQS32bLRzTex8oAT4I+qht8ga8FM+srP2+31hR1ea+WndKEl0YG DAOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KGdkUzk8KeP79uB9bBVTKo4LdBoS+n3vTPSwcD42mh8=; b=X7IDB8F22q/yMZ8oDhoirEXKvu3W0rq15VOME5qqEm4tw3p9tmviftTvF/IW5eGzQN wXQPWfH4DMhOL6YP/EcaiDA/Qoc2KWpFFoJwlyBs9EB67Lo58Cn3z/8VOekGUCaJdNIA lKfF7w+BYWFGoHnilk1+GlbQtkl5Gr4U3cCnc2FnyxOXNQ7IokRAe4Gp8XcFXHJPn0D1 KC3sF6/9tu33kzbMqkfsaZS94NSDwskSPwAm4oZcqEqGmWnQaSNEjY0u54tuDVgUbDNS z0ELaSomodkbs5Le54Rzy3jmUG8VJFksLnRUiI8YyYjcJoEBj4wEkbgr+dXLsQE5fj9o YbTQ== X-Gm-Message-State: AOAM531f0DHVB3LTLJj99BdL9lxokOzQ9no6gC03PhoSiutmnThfT0w/ TqgbQQTR+oQDd96V28KFEFeGB04ch1oGMuZ9jDJGdg== X-Google-Smtp-Source: ABdhPJyfXfGpIVM4vWGhJr4idNH+cC92mlYJbpe5eW91p/ol+KNQFIJ7ESdQ9wSIixEDZizd4GvHCm5ukAJrKBRSY88= X-Received: by 2002:a2e:3917:: with SMTP id g23mr39552581lja.417.1635861779601; Tue, 02 Nov 2021 07:02:59 -0700 (PDT) MIME-Version: 1.0 References: <875yta7o0h.fsf@toke.dk> In-Reply-To: <875yta7o0h.fsf@toke.dk> From: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= Date: Tue, 2 Nov 2021 14:02:47 +0000 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , bloat Content-Type: multipart/alternative; boundary="00000000000046718105cfcec083" X-Mailman-Approved-At: Tue, 02 Nov 2021 13:38:54 -0400 Subject: Re: [Bloat] Beyond Bufferbloat: End-to-End Congestion Control Cannot Avoid Latency Spikes 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, 02 Nov 2021 14:03:01 -0000 --00000000000046718105cfcec083 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback! Please find my answers below. > A direct consequence is that we need AQMs at all points in the internet > > where congestion is likely to happen, even for short periods, to mitiga= te > > the impact of latency spikes. Here I am assuming we ultimately want an > > Internet without lag-spikes, not just low latency on average. > > This was something I was wondering when reading your paper. How will > AQMs help? When the rate drops the AQM may be able to react faster, but > it won't be able to affect the flow xmit rate any faster than your > theoretical "perfect" propagation time... > So in effect, your paper seems to be saying "a flow that saturates the > link cannot avoid latency spikes from self-congestion when the link rate > drops, and the only way we can avoid this interfering with *other* flows > is by using FQ"? Or? > Yes, I agree, and that's a very nice way to put it. I would phrase the AQMs role as "mitigating the negative effects of transient congestion". Isolating flows from each other, for instance with FQ, is an important part of that in my opinion. I'm sure this is familiar to people on this list, but I'll summarize my views anyway. Whenever a queue forms the options are very limited: We can choose to drop packets, and we can choose the order in which the queue is emptied. FIFO service is one option, but we can also choose some other scheduling and/or packet loss scheme. FQ is just a specific choice here where latency is divided close to equally among different flows. I really like the following analogy to make this point very clear: "If you have a bag of 100 balls and withdraw one every second, how long does it take to empty the bag? Now, we can color half the balls red and the other half blue, and then pick the red balls first. It still takes 100 seconds to empty the bag." The same principle holds for packet scheduling, only we can drop packets as well (and thus not pay the delay cost of forwarding them). Once a queue has formed, the latency and packet loss *must* be divided among the different packets in the queue, and it's up to the scheduling part of the AQM to make that choice. What the correct choice is will depend on many things. > Also, another follow-on question that might be worth looking into is > short flows: Many flows fit entirely in an IW, or at least never exit > slow start. So how does that interact with what you're describing? Is it > possible to quantify this effect? > Thanks, this seems interesting! I'll have a think about this and get back to you. Cheers, --=20 Bj=C3=B8rn Ivar Teigen Head of Research +47 47335952 | bjorn@domos.no | www.domos.no WiFi Slicing by Domos --00000000000046718105cfcec083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback! Please find my answers below= .

> A direct consequence is that we need AQMs at all points in the interne= t
> where congestion is likely to happen, even for short periods, to mitig= ate
> the impact of latency spikes. Here I am assuming we ultimately want an=
> Internet without lag-spikes, not just low latency on average.

This was something I was wondering when reading your paper. How will
AQMs help? When the rate drops the AQM may be able to react faster, but
it won't be able to affect the flow xmit rate any faster than your
theoretical "perfect" propagation time...=C2=A0

So in effect, your paper seems to be saying "a flow that saturates the=
link cannot avoid latency spikes from self-congestion when the link rate drops, and the only way we can avoid this interfering with *other* flows is by using FQ"? Or?
=C2=A0
Yes, I agre= e, and that's a very nice way to put it. I would phrase the AQMs role a= s "mitigating the negative effects of transient congestion". Isol= ating flows from each other, for instance with FQ, is an important part of = that in my opinion.

I'm sure this is fami= liar to people on this list, but I'll summarize my views anyway.
Whenever a queue forms the options are very limited: We can choose = to drop packets, and we can choose the order in which the queue is emptied.=
FIFO service is one option, but we can also choose some oth= er scheduling and/or packet loss scheme. FQ is just a specific choice here = where latency is divided close to equally among different flows.
<= div>
I really like the following analogy to make this point v= ery clear: "If you have a bag of 100 balls and withdraw one every seco= nd, how long does it take to empty the bag? Now, we can color half the ball= s red and the other half blue, and then pick the red balls first. It still = takes 100 seconds to empty the bag." The same principle holds for pack= et scheduling, only we can drop packets as well (and thus not pay the delay= cost of forwarding them). Once a queue has formed, the latency and packet = loss must be divided among the different packets in the queue, and i= t's up to the scheduling part of the AQM to make that choice. What the = correct choice is will depend on many things.


Also, another follow-on question that might be worth looking into is
short flows: Many flows fit entirely in an IW, or at least never exit
slow start. So how does that interact with what you're describing? Is i= t
possible to quantify this effect?

Thank= s, this seems interesting! I'll have a think about this and get back to= you.

Cheers,
--
<= div>
Bj=C3=B8rn Ivar Teigen
Head of Research
=
+47 47335952 | bjorn@domos.no=C2=A0|=C2=A0<= /span>www.domos.no
WiFi Slicing by Domos
--00000000000046718105cfcec083--