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

[Nicholas Meredith]

> CODEL uses one queue for all flows, not one queue per flow and it's FIFO
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?

Kind Regards,


Nicholas Meredith
nicholas at udhaonline.net
Ph: 0430 042 913


On Thu, Feb 7, 2013 at 2:35 PM, Craig Askings <craig at askings.com.au> wrote:

> 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/b724b5c5/attachment.html>