<div dir="ltr"><div>Jonathan Newton over at Vodafone Group made some interesting observations about what happens when two of the optimal congestion controllers interact through a shared FIFO queue:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal"><span>If we take two flows E and F; E is 90% of
bandwidth and F 10%; the time for the congestion signal to reach the
sender for each flow is dE and dF where dE is 10ms and dF 100ms. We
assume no prioritisation
so they must share the same buffer at X, and therefore share the same
peak transient delay.</span></p><p class="MsoNormal"><span>We have an event at t0 where the bandwidth is halved.</span></p><p class="MsoNormal"><span>For time t0 to t0+dE (the first 10ms), the
total rate transmitted by both sources is twice (90%*10%)/50% the output
rate, so the component of the peak delay of this part is (2-1)*dE =
10ms</span></p><p class="MsoNormal"><span>For time t0+dE to t0+Fd (the next 90ms), the
total rate transmitted by both sources is (45%+10%)/50% of the output
rate, so the component of the peak delay of this part is (1.1-1)*dF-dE =
9ms</span></p><p class="MsoNormal"><span>Making the peak transient delay 19ms.</span></p></blockquote>
<p class="MsoNormal"><span><br></span></p><p class="MsoNormal"><span>This implies that moving some senders closer to the edge (e.g. CDNs) might help reduce lag spikes for everyone. It also implies that slow-responding flows can have a very big impact on the peak transient latency seen by rapidly responding flows. If the bandwidth sharing ratio in the above example is 50/50, then the peak transient delay will be 55 ms, seen by both flows. For flow E that's a big increase from the 10 ms we'd expect if flow E was alone. For C=3 the increase is even worse, with flow E going from 20ms to 100ms when sharing the link with flow F.<br></span></p><p class="MsoNormal"><span><br></span></p><p class="MsoNormal"><span>- Bjørn<br></span></p></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 2 Nov 2021 at 14:08, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am very pre-coffee. Something that could build on this would involve<br>
FQ. More I cannot say, til more coffee.<br>
<br>
On Tue, Nov 2, 2021 at 3:56 AM Bjørn Ivar Teigen <<a href="mailto:bjorn@domos.no" target="_blank">bjorn@domos.no</a>> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> I've recently published a paper on Arxiv which is relevant to the Bufferbloat problem. I hope it will be helpful in convincing AQM doubters.<br>
> Discussions at the recent IAB workshop inspired me to write a detailed argument for why end-to-end methods cannot avoid latency spikes. I couldn't find this argument in the literature.<br>
><br>
> Here is the Arxiv link: <a href="https://arxiv.org/abs/2111.00488" rel="noreferrer" target="_blank">https://arxiv.org/abs/2111.00488</a><br>
><br>
> 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 mitigate the impact of latency spikes. Here I am assuming we ultimately want an Internet without lag-spikes, not just low latency on average.<br>
><br>
> Hope you find this interesting!<br>
><br>
> --<br>
> Bjørn Ivar Teigen<br>
> Head of Research<br>
> +47 47335952 | <a href="mailto:bjorn@domos.no" target="_blank">bjorn@domos.no</a> | <a href="http://www.domos.no" rel="noreferrer" target="_blank">www.domos.no</a><br>
> WiFi Slicing by Domos<br>
> _______________________________________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
<br>
<br>
<br>
-- <br>
I tried to build a better future, a few times:<br>
<a href="https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org" rel="noreferrer" target="_blank">https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org</a><br>
<br>
Dave Täht CEO, TekLibre, LLC<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)"><font size="2">Bjørn Ivar Teigen</font></span></span></div><div><span style="background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)"><font size="2">Head of Research<br></font></span></span></div><span style="background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"><span style="font-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline;float:none">+47 47335952 |<span> </span></span><a href="mailto:name@domos.no" rel="noopener noreferrer" style="text-decoration:none;font-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">bjorn@domos.no<span></span></a><span style="font-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline;float:none"><span> </span>|<span> </span></span><a href="http://www.domos.no/" rel="noopener noreferrer" style="text-decoration:none;font-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">www.domos.no</a></span><br style="font-family:Slack-Lato,appleLogo,sans-serif;font-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:arial,sans-serif"><span style="font-style:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline;float:none">WiFi Slicing by Domos</span></span></font></span></span></div></div></div></div></div></div>