From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by huchra.bufferbloat.net (Postfix) with ESMTP id 28B6321F1A8; Tue, 7 May 2013 06:31:47 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id BBA6F2016E; Tue, 7 May 2013 09:42:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id DDAD463A7E; Tue, 7 May 2013 09:31:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BDB71639DF; Tue, 7 May 2013 09:31:05 -0400 (EDT) From: Michael Richardson To: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net In-Reply-To: <5181CD56.9050501@superduper.net> References: <51817A6F.1080006@superduper.net> <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> <5181CD56.9050501@superduper.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Codel] [Cerowrt-devel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:31:47 -0000 >>>>> "Simon" == Simon Barber writes: Simon> Or one could use more queues in SFQ, so that the chance of 2 Simon> streams sharing Simon> a queue is small. Even perhaps use a different strategy than Simon> hashing to Simon> distribute traffic to queues, although whatever strategy is Simon> used needs to be Simon> resistant to DoS attacks. Or one could classify the VoIP traffic and Simon> prioritise that. Another possibility is a heuristic approach Simon> - don't mix long Simon> lived bulk data streams in the same bucket as others. 1) try to give each IPv6 non-zero flow label stream to it's own bucket. (use a closed hashing strategy) Yes, this leverages an IPv6 feature which should promote v6... 2) otherwise, hash TCP and UDP streams into seperate pools. On simple networks with no gaming, this results in VoIP RTP flows and DNS always getting their own stream. On networks with agressive UDP flows which do not react, one needs another method to seperate the flows and penalize them individually. if NAT is involved, then conn-tracking can basically give every flow it's own queue, because they are already uniquely identified. I think that the number of queues for TCP streams can be smaller than for UDP streams, as the TCP streams are more likely to respond to congestion signals. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [