[pcap-ng-format] Questions about the ISB statistic counter options

[Guy Harris]

I was looking into providing a replacement for libpcap/WinPcap's pcap_stats() call, so that

	1) the set of statistics it provides can be easily extended without raising binary compatibility issues

and

	2) if a capture mechanism *can't* supply certain statistics, it doesn't have to provide a "fake" value of 0 or "maximum value" or....

I'm thinking of something where the application provides an array of items containing:

	an ISB option type code;

	a "present"/"absent" flag;

	a 64-bit value location;

and libpcap/WinPcap fills it in, setting the "present" flag to 1 and the value location to the value for statistics it can provide and setting the "present" flag and the value location to 0 for statistics it can't provide, and with pcap_stats() and, in WinPcap, pcap_stats_ex() implemented atop that call.

So, while checking to see which ISB statistics options correspond to which statistics various capture mechanisms can provide, some questions came up:

	isb_filteraccept: "The isb_filteraccept option specifies the 64-bit unsigned integer number of packets accepted by filter starting from the beginning of the capture."

	Does this include packets accepted but then dropped due to lack of capture buffer space?  I infer from the description of isb_usrdeliver that it does, but we should probably explicitly indicate that.

	isb_osdrop: "The isb_osdrop option specifies the 64-bit unsigned integer number of packets dropped by the operating system starting from the beginning of the capture."
      
	What if packets were dropped by OS code *before* being handed to the capture mechanism?  If those are counted, most if not all packet capture mechanisms would be incapable of providing that statistic - those capture mechanisms *do* count packets *they* dropped because the capture buffer was too small, but don't count packets dropped by the OS before they even got to see them.

	isb_ifdrop: "The isb_ifdrop option specifies the 64-bit unsigned integer number of packets dropped by the interface due to lack of resources starting from the beginning of the capture."

	Does this include "dropped because the interface overran the receive ring for the adapter" but not include, for example, "dropped because the CRC was bad"?  And does "resources" include packet capture mechanism buffers?

The packet capture mechanisms out there that provide statistics provide some or all of:

	the number of packets handed to the packet capture mechanism - there's no ISB statistic for that;

	the number of those packets that passed the filter in that mechanism, *even if they were then discarded because there wasn't any space for them in the capture mechanism's buffers* - that sounds like isb_filteraccept;

	the number of *those* packets that were discarded because there wasn't space for them in the capture mechanism's buffers - is that what isb_osdrop was intended to be?

There's also

	isb_usrdeliv: "The isb_usrdeliv option specifies the 64-bit unsigned integer number of packets delivered to the user            starting from the beginning of the capture.  The value contained in this field can be different from the value 'isb_filteraccept - isb_osdrop' because some packets could still be in the OS buffers when the capture ended."

That would presumably maintained by libpcap/WinPcap itself, if by "the user" we mean "the application doing the capture" (rather than "delivered to the user" meaning "provided to userland code by the kernel").