[Bro] A more parallel Bro

[Robin Sommer]

On Mon, Mar 02, 2009 at 10:25 -0600, dalbrech at illinois.edu wrote:

> real system.  So I built a simple tool I call "dns-packet-gen", which generates 
> pathological DNS packets constructed for their difficulty in parsing.  The tool 
> emits pcap traces containing DNS traffic with many records (50+), all of which 
> feature deeply-recursive DNS names. 

Neat. Is that tool available? 

> appreciate hearing them).  In either case, my bad DNS traffic only pushed the 
> binpac-based analyzers up to 13-14% of CPU time, which is still comparatively 
> tiny in relation to the EventMgr's CPU time.

Yeah. Some of our recent measurements indicate that for some
protocols (including DNS) script interpretation dominitates the
performance, with the analyzers being less of an issue. That's why
our first target for the multi-threaded Bro is to parallelize 
script interpretation.

> You're right about scale, modulo communications issues.  However, I think it's 
> important for a large-scale system to be designed in such a way as to gain 
> more performance as the architecture guys throw faster and faster chips over 
> the wall. 

Definitely. As I said, we're interested in both, from a research
perspective as well as for operations. 

> I'm wondering how you plan to address cache behavior in your multi-threaded 
> implementation of Bro.  Obviously, this is a really hard problem, and I'm not 
> sure how well-studied it is in the literature, especially in the context of IDS.  

That's an excellent question and I don't think it has been studied
in the IDS context yet. Our main strategy is to keep related state
together, e.g., by running all analysis involving the same
connection on the same core. It's hard to predict though how cache
effects will eventually turn out to hurt us, and we expect to do a
number of measurements in this regard once the multi-threaded Bro is
in a shape that we can actually measure something. Going from there,
I'm sure there'll be lots of further optimization potential.

> Fortunately, I have a lot of friends here that do high-performance computing 
> work (their long-range research agenda includes a 3000-core CPU tapeout), so 
> I'll talk to them about it.

I'd be glad to hear what they have to say as I'm not very familiar
with this space myself either. 

Robin

-- 
Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org