[Bro-Dev] $history extensions - zero windows, logarithmic counts

[Vlad Grigorescu]

I think this is a useful feature. I'm a bit unclear on the logarithmic
counts. Take, for instance SaDtTtT. If I'm reading this correctly, I think
that means 10-99 retransmissions from orig, followed by 10-99 from resp,
then more retransmissions from orig (enough to reach a total of 100-999),
and similarly more from resp. However, I could also interpret it as 10-99
from orig, 10-99 from resp, 10-99 from orig, 10-99 from resp.

Another question I had was that most of these are TCP-specific. Would
checksum apply to UDP as well?

One downside of the logarithmic approach is that it makes it hard to search
for, since searching for 't.*t' means one thing for small conns, and
another for large conns. As you say, if what I care about is the overall
number compared to the number of packets, that feels more like a
percentage. To me, it'd seem more natural to use something like "0t" means
"of the total number of packets from the originator, 0-9% were
retransmissions," "1t" means 10-19%, etc.

What I'm left debating is whether adding numerical data to history is the
right approach, though. missed_bytes is a separate field, but it feels
similar. If we did something like the log approach for that, we'd lose
exact counts, but we'd have granularity on the direction. Maybe we add the
new letters, but don't repeat them and also add new fields for exact
bytecounts?

 --Vlad



On Fri, Jun 15, 2018 at 6:51 PM, Vern Paxson <vern at corelight.com> wrote:

> > Here we will not have cases where some repetitions are logarithmic, and
> > some (like for R) are not. I guess that makes sense, but I can see it
> > potentially being confusing.
>
> Yeah, I chewed on that too, but I don't see a better solution.  The
> semantics
> of repeated R are different, too (per the recent $history thread, it
> entails
> differing sequence numbers), so I think once that's the case, then it's
> not all that much more confusing if the significance of a repetition has
> different semantics too.
>
>                 Vern
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20180615/c35fbc94/attachment.html