Connection Compressor


since my tunnel decapsulation code can't propagate the identity of the tunnel's parent and since the connection compressor doesn't work with IPv6 yet, I was wondering whether it actually still saves a significant amount of memory or not.

So, I've done some benchmarks and it appears that the connection compressor doesn't help much more these days given that we accept all packets by default.

* 107GB trace, 5M conns, with http and conn:
      memory and runtime unchanged.
same trace with bro-1.5, conn, http-request, http-response, filter that

* accepts all packets:
      runtime unchanged. Memory 202MB vs. 215MB

* same trace, only SYN,FIN,RST packets:
      memory and runtime unchanged

* pure SYN trace, 34M conns (==SYNs): that's the only case were I saw
   a difference:
    no-CC: 1613s, 276MB

So, all in all, it appears that the connection compressor doesn't help much anymore these days and given that has been in pain in the past and that we'd have to extend it to support IPv6 as well, I would opt for removing it.

(BTW, I've briefly talked to Robin about that before I did the benchmark and the thought was, that just disabling the connection compressor by default is not a good idea, since it would almost certainly fall in disuse and would succumb to bit-rot. So we should either keep it and leave it on per default, or remove the code)


I've done some measurements as well now and can confirm this. With
master in default mode, I also see only tiny savings in time and

So I agree that we should remove the compressor code. I'm sad to see
it go, but it's one of these pieces that complicate things
considerably and that's only worth it if there's a clear gain coming
out of it.



I've done some measurements as well now and can confirm this. With
master in default mode, I also see only tiny savings in time and

So just to confirm: for a high-speed SYN flooding attack, it's not much
help? That was the original motivation, after all.


I didn't try that (only "normal" traiffc) and it probably still helps
with that. But that was only part of the original motivation, which
started out from the general observation of many connections not
getting established. And another piece of the story was the separate
flood detector that starts sampling traffic from specific sources or
destinations (Seth, is that ported already?)

So I think the compressor still helps in some (extreme) situations,
and generally, performance-wise it certainly doesn't hurt to have it.
But I'm not sure it's worth the complexity: we keep running into
issues with the changes in semantics it introduces, it's on a separate
code path that needs to be integrated with all packet-level stuff, and
as Gregor said, it would also need more than just maintainance work in
the future, like adding IPv6 support.


Nope, but that's a perfect use case for the metrics framework (which I just got working on cluster deployments!). I can work on it this afternoon as an example use for the metrics framework.



We like setting record_state_history=T to record the flags that were seen during the connection, and found that the connection compressor didn’t play nicely with that, in some cases.

Sounds like more evidence for removing the conn compressor if possible. Also, state history is included in the new conn logs by default.


Not to pile on…

I disable the CC in some cases where i need better timing on connections. With CC enabled, it discards some of the duplicate packets. I may be in the minority though, I am not using Bro as an IDS. I use it as an analytical tool in my case.


I've done some tests with a trace that contains only SYNs. The trace has 10M syns and spans approx. 20min. I've also made the trace "faster" by changing the timestamps:

original (20min)
  * 227s 100MB with CC
  * 354s 320MB without
compressed to 2min
  * 221s 780MB with
  * 373s 2029MB without
compressed to 1min
  * 219s 1915MB with
  * 404s 5308MB without
compressed to 1min, tcp_SYN_timeout set to 1sec (instead of 5sec)
  * 219s 398MB with
  * 349s 714MB without

So, the compressor helps for massive SYN storms but IMHO not enough to make it worthwhile keeping it considering all the other tradeoffs mentioned in this thread.