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

[Nicholas Meredith]

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