On Wed, 01 May 2013 19:20:06 -0700 Simon Barber <[email protected]> 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
