<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">CODEL uses one queue for all flows, not one queue per flow and it's FIFO</span><div style><span style="font-family:arial,sans-serif;font-size:13px">Thanks Craig, I was understanding it wrong. So while it is statistically very very likely to drop a packet from the high volume flow, it could still end up dropping anything, yeah?</span></div>
</div><div class="gmail_extra"><br clear="all"><div>Kind Regards,<br><br><br>Nicholas Meredith<br><a href="mailto:nicholas@udhaonline.net">nicholas@udhaonline.net</a><br>Ph: 0430 042 913</div>
<br><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 2:35 PM, Craig Askings <span dir="ltr"><<a href="mailto:craig@askings.com.au" target="_blank">craig@askings.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">CODEL uses one queue for all flows, not one queue per flow and it's FIFO. So that SIP or RTP packet could well have exceeded the maximum buffering time due to a few large packets that entered the queue before it. Multiple CODEL queues wouldn't really change much as the scheduler would still have to round robin (Weighted or not) it's way to each queue and the drop assessment is made on dequeue.<div>
<br></div><div>If you want multiple queues, for example a LLQ/priority queue for VoIP and CODEL for best effort or put traffic into multiple CODEL queues you still need QoS of some for to classify the traffic.<div><div class="h5">
<div><br><div><div>On 07/02/2013, at 1:36 PM, Nicholas Meredith <<a href="mailto:nicholas@udhaonline.net" target="_blank">nicholas@udhaonline.net</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">The idea behind such AQM implementations is for exactly this, the packet that get's dropped is from the flow with the queue that is growing to the latency delay threshold, which is measuring how long it remained buffered. So as I understand it, only the flow that is beginning to experience enough latency in the buffer will be getting packet drops, ie, a link that is about to become congested with web traffic while also sharing SIP connections will only see the web connection throttle back (since it was the one spiking) a bit before it ever congests the link, and no affect to SIP will be seen. Eventually this can't scale if throughput requirements grow well beyond the link's capacity, but that's true of QoS as well.</div>
<div class="gmail_extra"><br clear="all"><div>Kind Regards,<br><br><br>Nicholas Meredith<br><a href="mailto:nicholas@udhaonline.net" target="_blank">nicholas@udhaonline.net</a><br>Ph: <a href="tel:0430%20042%20913" value="+61430042913" target="_blank">0430 042 913</a></div>
<br><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 1:19 PM, Craig Askings <span dir="ltr"><<a href="mailto:craig@askings.com.au" target="_blank">craig@askings.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">My statement still stands for CODEL and other algorithms that drop packets once the buffer exceeds a latency threshold. They still have to drop packets, it's just a different metric for when you start to drop the packets. You still need QoS of some form to choose the loser.<span><font color="#888888">
<br></font></span><div><span><font color="#888888">Craig. </font></span><div><div><br><div><div>On 07/02/2013, at 1:07 PM, Nicholas Meredith <<a href="mailto:nicholas@udhaonline.net" target="_blank">nicholas@udhaonline.net</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">Ok so the buffers are now full and a voice packet arrives.</span><div><span style="font-family:arial,sans-serif;font-size:13px">Correct buffer management means the buffers can't get full. Look at CODEL as an example. I realise I should have mentioned earlier this is obviously not possible today, but it will be, and it's the correct solution to the problem.</span></div>
</div><div class="gmail_extra"><br clear="all"><div>Kind Regards,<br><br><br>Nicholas Meredith<br><a href="mailto:nicholas@udhaonline.net" target="_blank">nicholas@udhaonline.net</a><br>Ph: <a href="tel:0430%20042%20913" value="+61430042913" target="_blank">0430 042 913</a></div>
<br><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 10:21 AM, Craig Askings <span dir="ltr"><<a href="mailto:craig@askings.com.au" target="_blank">craig@askings.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Ok so the buffers are now full and a voice packet arrives. Do you want the router / switch to drop that voice packet or choose another packet to take one for the team? That is what QoS is for, even with small buffers you still need QoS to pick the loser.</div>
<span><font color="#888888"><div><br></div>Craig.</font></span><div><br><div><div>On 07/02/2013, at 10:11 AM, Nicholas Meredith <<a href="mailto:nicholas@udhaonline.net" target="_blank">nicholas@udhaonline.net</a>> wrote:</div>
<br><blockquote type="cite"><p dir="ltr">I don't follow, congestion won't cause latency if buffers are controlled correctly. How is QoS better in this case?</p>
<div class="gmail_quote">On 07/02/2013 9:27 AM, "Paul Brooks" <<a href="mailto:pbrooks-ausnog@layer10.com.au" target="_blank">pbrooks-ausnog@layer10.com.au</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 7/02/2013 8:10 AM, Nicholas Meredith wrote:<br>
><br>
> If bufferbloat gets resolved it will render QoS utterly redundant.<br>
><br>
perhaps...until a link went down and the streams re-routed to another path causing<br>
congestion, or more traffic thrown on the original path also causing congestion.<br>
Even if bufferbloat might 'get resolved', which it won't.<br>
<br>
P.<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div>
_______________________________________________<br>AusNOG mailing list<br><a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br><a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div><br></div></div><br>_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div></blockquote></div><br></div>