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

[Guy Harris]

So here's some changes I propose to the list of options for the ISB.  I've put modified text in asterisks (plain-ASCII italicization), with a Rationale/explanation afterwards:

	isb_starttime:

	The isb_starttime option specifies the time the capture started; time will be stored in two blocks of four octets each. The format of the timestamp is the same as the one defined in the Enhanced Packet Block (Section 4.3).  *This option MAY appear in more than one ISB for an interface in a section, but if it does, the value of the option MUST be the same in all ISBs.*

Rationale: without a time machine, you can't change history, so you can't change the time the capture started.

Alternatively, you could say that a new isb_starttime indicates that the device was re-opened after, presumably, having been closed, in which case that should be explained.

Alternatively alternatively, we can have an idb_starttime to indicate when the capture started, deprecate isb_starttime, and have the ISB just say when the capture *ended*.

	isb_endtime:

	The isb_endtime option specifies the time the capture ended; time will be stored in two blocks of four octets each. The format of the timestamp is the same as the one defined in the Enhanced Packet Block (Section 4.3). *ISBs for an interface other than the last ISB for that interface in a section MUST not have this option.*

Rationale: once the capture is ended, you can't end it again without restarting it.

Alternatively, if you can have multiple isb_starttimes within a section, you can also have multiple isb_endtimes.

	isb_ifrecv:

	The isb_ifrecv option specifies the 64-bit unsigned integer number of packets received *from the interface* starting from the beginning of the capture.

	*For captures performed on a remote machine, this counts packets received from the interface on that machine.*

Rationale: not all interfaces are physical, e.g. a loopback interface.

Qualification added for remote capture - this is a statistic you'd get from the server, and thus could count packets not yet processed on the host doing the capture.

	isb_ifdrop:

	The isb_ifdrop option specifies the 64-bit unsigned integer number of packets dropped by the interface *or its driver before being filtered* due to lack of resources*,* starting from the beginning of the capture.  *"Resources" includes buffer resources in networking hardware and on the host.*

	*For captures performed on a remote machine, this counts only packets dropped on that machine.*

Rationale: clarify what sort of resources are being discussed, and note that this covers drops by the adapter (e.g., because a packet arrives when the receive ring is full) or the driver, not drops due to the filter rejecting a packet or due to the *capture mechanism* not having enough buffer space for a packet that passed the filter.

Comma inserted to separate the description of the statistic from the qualification that the counting starts at the beginning of the capture.

Qualification added for remote capture - this is a statistic you'd get from the server, and thus a statistic that doesn't count, for example, network drops in the packet stream from the server.

	isb_filteraccept:

	The isb_filteraccept option specifies the 64-bit unsigned integer number of packets accepted by *the* filter*,* starting from the beginning of the capture.  *Those packets need not have been delivered to the capturing program; they might have been dropped due to insufficient space in capture buffers, or they might have been stored in a capture buffer but not yet read by the capturing program at the time the statistics were obtained.*

	*For captures performed on a remote machine, this counts packets accepted on that machine.*

Rationale: clarify that these packets might subsequently be dropped due to lack of resources or might not have been dropped but also might not yet have been read by the application.

Comma inserted to separate the description of the statistic from the qualification that the counting starts at the beginning of the capture.

Qualification added for remote capture - this is a statistic you'd get from the server, and thus could count packets not yet processed on the host doing the capture.

	isb_osdrop:

	The isb_osdrop option specifies the 64-bit unsigned integer number of packets *accepted by the filter but* dropped by the operating system *due to lack of resources,* starting from the beginning of the capture.

	*For captures performed on a remote machine, this counts only packets dropped on that machine.*

Rationale: clarify that these are drops due to lack of resources (such as buffer space) in the part of the capture path that *follows* the filtering process.

Comma inserted to separate the description of the statistic from the qualification that the counting starts at the beginning of the capture.

Qualification added for remote capture - this is a statistic you'd get from the server, and thus a statistic that doesn't count, for example, packets received from the server but dropped on the *client* due to lack of resources.

And here are some additional options I propose:

	isb_filterreceive (code 9):

	The isb_filterreceive option specifies the 64-bit unsigned integer number of packets supplied to the filter, starting from the beginning of the capture.  Those packets might have been rejected by the filter, accepted by the filter but dropped due to lack of resources, or accepted and made available for processing.

	*For captures performed on a remote machine, this counts packets received by the filter on that machine.*

Rationale: this is the bs_recv BIOCGSTAT value from BPF and WinPcap, and we didn't yet have it.  That and isb_filteraccept lets you calculate the number of packets that *didn't* pass the filter, which is isb_filterreceive - isb_filteraccept.

	isb_remotesent (code 10):

	For a capture performed on a remote machine, the isb_remotesent option specifies the 64-bit unsigned integer number of packets sent from the remote machine after being captured.

Rationale: this is a statistic provided by the current WinPcap remote capture code.  For the rpcap protocol, it doesn't apply if the packet stream is delivered over TCP; if it's delivered over UDP, it's determined by each packet sent by the rpcap daemon being given a packet sequence number, so that - *if* the packets are delivered in order, which UDP doesn't guarantee - packet drops can be determined.

	isb_netdropped (code 11):

	For a capture performed on a remote machine, the isb_netdropped option specifies the 64-bit unsigned integer number of packets sent from the remote machine, but not successfully received from the remote machine due to lack of resources.

Rationale: this is a statistic provided by the current WinPcap remote capture code.  For the rpcap protocol, it doesn't apply if the packet stream is delivered over TCP; if it's delivered over UDP, it's determined by each packet sent by the rpcap daemon being given a packet sequence number, so that - *if* the packets are delivered in order, which UDP doesn't guarantee - packet drops can be determined.

No, the rpcap client code doesn't handle out-of-order delivery of packets when they're delivered over UDP.