> it 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.
Correct in principle. (1) These would be 1-9 followed by enough to
get to 10-99, since a single retransmission is already a 't' / 'T', and
(2) lower letters are responders rther than originators.
> However, I could also interpret it as 10-99
> from orig, 10-99 from resp, 10-99 from orig, 10-99 from resp.
Nope. The counter doesn't reset at any point, it's cumulative.
> Another question I had was that most of these are TCP-specific. Would
> checksum apply to UDP as well?
Right, it would apply to UDP too, just like is done presently for
the boolean indicator.
> As you say, if what I care about is the overall
> number compared to the number of packets, that feels more like a
> percentage.
Well, I think this is yes-and-no. For one, the overall percentage might
be quite small and still have a large impact on what's supposed to be a
high-speed transfer - particularly if it means that a connection entered
an extented timeout-and-back-off - so I don't know if there would be a
natural point of inspection for it. (It could also quite large but no big
deal because the connection is a runt.)
> 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.
I'm inclined to wait on refinements like this. Let's first see whether
having log-counter-style histories leaves people wanting more before
qualitatively changing the nature of the history field, or adding new
fields.
> Maybe we add the
> new letters, but don't repeat them and also add new fields for exact
> bytecounts?
I'm not following this. If we add new letters that don't repeat *and* we
add new fields, why do we need the letters given that the fields are there?
Vern
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
