[AusNOG] News: Telstra to clamp down on peer-to-peer

[Craig Askings]

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.

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.

On 07/02/2013, at 1:36 PM, Nicholas Meredith <nicholas at udhaonline.net> wrote:

> 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.
> 
> Kind Regards,
> 
> 
> Nicholas Meredith
> nicholas at udhaonline.net
> Ph: 0430 042 913
> 
> 
> On Thu, Feb 7, 2013 at 1:19 PM, Craig Askings <craig at askings.com.au> wrote:
> 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. 
> Craig. 
> 
> On 07/02/2013, at 1:07 PM, Nicholas Meredith <nicholas at udhaonline.net> wrote:
> 
>> > Ok so the buffers are now full and a voice packet arrives.
>> 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.
>> 
>> Kind Regards,
>> 
>> 
>> Nicholas Meredith
>> nicholas at udhaonline.net
>> Ph: 0430 042 913
>> 
>> 
>> On Thu, Feb 7, 2013 at 10:21 AM, Craig Askings <craig at askings.com.au> wrote:
>> 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.
>> 
>> Craig.
>> 
>> On 07/02/2013, at 10:11 AM, Nicholas Meredith <nicholas at udhaonline.net> wrote:
>> 
>>> I don't follow, congestion won't cause latency if buffers are controlled correctly. How is QoS better in this case?
>>> 
>>> On 07/02/2013 9:27 AM, "Paul Brooks" <pbrooks-ausnog at layer10.com.au> wrote:
>>> On 7/02/2013 8:10 AM, Nicholas Meredith wrote:
>>> >
>>> > If bufferbloat gets resolved it will render QoS utterly redundant.
>>> >
>>> perhaps...until a link went down and the streams re-routed to another path causing
>>> congestion, or more traffic thrown on the original path also causing congestion.
>>> Even if bufferbloat might  'get resolved', which it won't.
>>> 
>>> P.
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>> 
>> 
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130207/41a50584/attachment.html>