<div dir="ltr"><div>Thanks for the feedback! Please find my answers below.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> A direct consequence is that we need AQMs at all points in the internet<br>
> where congestion is likely to happen, even for short periods, to mitigate<br>
> the impact of latency spikes. Here I am assuming we ultimately want an<br>
> Internet without lag-spikes, not just low latency on average.<br>
<br>
This was something I was wondering when reading your paper. How will<br>
AQMs help? When the rate drops the AQM may be able to react faster, but<br>
it won't be able to affect the flow xmit rate any faster than your<br>
theoretical "perfect" propagation time... </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So in effect, your paper seems to be saying "a flow that saturates the<br>
link cannot avoid latency spikes from self-congestion when the link rate<br>
drops, and the only way we can avoid this interfering with *other* flows<br>
is by using FQ"? Or?<br></blockquote><div> </div><div>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. <br></div><div><br></div><div>I'm sure this is familiar to people on this list, but I'll summarize my views anyway.<br></div><div>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. <br></div><div>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.<br></div><div><br></div><div>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 <b>must</b> 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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, another follow-on question that might be worth looking into is<br>
short flows: Many flows fit entirely in an IW, or at least never exit<br>
slow start. So how does that interact with what you're describing? Is it<br>
possible to quantify this effect?<br></blockquote><div><br></div><div>Thanks, this seems interesting! I'll have a think about this and get back to you.<br></div></div><div><br></div><div>Cheers,<br></div>-- <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></div>