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