From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1ECA121F416 for ; Thu, 29 May 2014 16:40:53 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B82DC20028; Thu, 29 May 2014 19:43:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 02C4863B0E; Thu, 29 May 2014 19:40:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E217C63AED; Thu, 29 May 2014 19:40:50 -0400 (EDT) From: Michael Richardson To: "David P. Reed" In-Reply-To: <3eb328c9-05fb-4594-81cc-71e6a623b977@katmail.1gravity.com> References: <1401048053.664331760@apps.rackspace.com> <1401290405.100110358@apps.rackspace.com> <3eb328c9-05fb-4594-81cc-71e6a623b977@katmail.1gravity.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Ubiquiti QOS X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:40:53 -0000 David P. Reed wrote: > ECN-style signaling has the right properties ... just like TTL it can > provide How would you send these signals? > A Bloom style filter can remember flow statistics for both of these local > policies. A great use for the memory no longer misapplied to > buffering.... Well. On the higher speed dataflow equipment, the buffer is general purpose memory, so reuse like this is particularly possible. On routers built around general purpose architectures, the limiting factor in performance is often memory throughput; adding memory rarely increases total throughput. Packet I/O is generally quiet sequential and so makes good use of wide memory data paths and multiple accesses per address cycle. Updating of tables such as Bloom filter or any other hash has a big impact due to the RMW and random access nature. All I'm saying is that quantity of memory is seldom the problem, but access to it, is. I do like the entire idea; it seems that it has to be implemented at the places where the flow converge, which is often in the DSL line card, or CTMS... -- ] 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 [