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

[Greg White]

BTW, the SFQ-CoDel code does support the "new" flows concept in much the
same way as the linux code, so this was already included in the simulation
results. 



On 5/6/13 2:47 PM, "Jesper Dangaard Brouer" <jbrouer at redhat.com> wrote:

>On Mon, 6 May 2013 21:46:35 +0300 Jonathan Morton
><chromatix99 at gmail.com> wrote:
>> On 6 May, 2013, at 8:54 pm, Jesper Dangaard Brouer wrote:
>> 
>> > A flow is considered "new" if no packets for the given flow exists
>> > in the queue.  It does not have to be a truly new-flow, it just
>> > have to send packets "slow"/paced enough, that the queue is empty
>> > when the next packet arrive.
>> > 
>> > Perhaps VoIP would fit this traffic profile, and thus would work
>> > better with the Linux fq_codel implementation, compared to the
>> > SFQ-Codel used in the simulation.
>> 
>> That doesn't work, because the with a sufficient number of BT flows,
>> the flow queue containing the VoIP flow is the fullest queue, not the
>> emptiest.  That's independent of the number of flow queues, including
>> the infinite case.  Think about it carefully.
>
>Yes, I agree.
>
>And as I mentioned, with the fq_codel implementation details, this is
>going to hit even earlier, as we have a limited number of flow/hash
>queues.
>
>> Looking at the implementation, it does have the problem that the match
>> for "if the flow already have packets in the queue" just looks to see
>> if the hash bucket is empty.  Thus 2 stream sharing a hash queue throw
>> this off.
>
>--
>Best regards,
>  Jesper Dangaard Brouer
>  MSc.CS, Sr. Network Kernel Developer at Red Hat
>  Author of http://www.iptv-analyzer.org
>  LinkedIn: http://www.linkedin.com/in/brouer
>_______________________________________________
>Codel mailing list
>Codel at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/codel