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

[Jesper Dangaard Brouer <jbrouer@redhat.com>]

On Wed, 01 May 2013 19:20:06 -0700 Simon Barber <simon@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.

The Linux implementation of fq_codel is actually doing a really nice
trick to distinguish between new and old flows.  Giving new flows
precedence and avoiding they get exposed to a round-robin delay from
all the old "bulk" data streams.

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.

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