[Bloat] [Codel] Latest codel, fq_codel, and pie sim study from cablelabs now available

[Andrew McGregor]

It is quite reasonable for edge devices to not use SFQ but actual FQ with
one queue per flow (and some reasonable garbage collection heuristic).  Or
to use a few thousand queues.

Most of the time connection tracking will be enabled on an edge router
anyway, so the device is paying that overhead already.  May as well use it.


On Thu, May 2, 2013 at 12:20 PM, Simon Barber <simon at superduper.net> wrote:

> Or one could use more queues in SFQ, so that the chance of 2 streams
> sharing a queue is small. Even perhaps use a different strategy than
> hashing to distribute traffic to queues, although whatever strategy is used
> needs to be resistant to DoS attacks. Or one could classify the VoIP
> traffic and prioritise that. Another possibility is a heuristic approach -
> don't mix long lived bulk data streams in the same bucket as others.
>
> Simon
>
>
> On Wed 01 May 2013 05:00:27 PM PDT, Jonathan Morton wrote:
>
>>
>> On 1 May, 2013, at 11:26 pm, Simon Barber wrote:
>>
>>  Interesting to note that sfq-codel's reaction to a non conforming flow
>>> is of course to start dropping more aggressively to make it conform,
>>> leading to the high loss rates for whatever is hashed together with a VoIP
>>> flow that does not reduce it's bandwidth.
>>>
>>> One downside to SFQ really.
>>>
>>
>> The only real solution, for the scenario where this happens, would be to
>> somehow identify all the BitTorrent traffic and stuff it into a single
>> bucket, where it has to compete on equal terms with the single VoIP flow.
>>  The big unanswered question is then: can this realistically be done?  Does
>> BitTorrent traffic get marked as the bulk, low priority traffic it is, for
>> example?
>>
> ______________________________**_________________
> Codel mailing list
> Codel at lists.bufferbloat.net
> https://lists.bufferbloat.net/**listinfo/codel<https://lists.bufferbloat.net/listinfo/codel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130502/44d2e68c/attachment-0003.html>