Another vote for packet drop detection
Charles Smutz
csmutz at masonlive.gmu.edu
Tue Jan 31 17:48:00 EST 2012
Carter,
If I understand correctly, what is proposed sounds great.
> There are several ways of reporting the "TCP unobserved bytes"
metric. We can provide a new printable field, we can call it "[sd]gap" ?
Also, I can expose all the TCP metrics, however, I'll need names for
them all. Using the packet traces from the wireshark site, we are
accurately tracking the loss that they describe, so I'd say its working.
Just need some testing. Please offer suggestions, and we'll make it
official.
Making this new statistic available on a per flow basis seems like the
best option. I'd be inclined to name this something like [sd]unobs (I
think TCP unobserved bytes is a really good name for this), but I'm
really bad at naming. [sd]gap is fine by me. [sd]miss seems to imply
something that should have been observed but wasn't so I could go with
it too.
What happens to this stat when you have flow record boundary (flow
record interval exceeded) such that data observed in the first record is
ACK'd in the second record? Not too concerned about this scenario
because I assume I can aggregate this problem away, but just curious
about this boundary condition. Assuming gap above takes this into account?
Really looking forward to this functionality,
Charles
More information about the argus
mailing list