"ds" == David Schwartz <davids@webmaster.com> writes: Any billing scheme based upon statistical sampling will, with some probability, err in the favor of one party or the other randomly. But it is important that the customer understands that he is being billed based upon statistical sampling and thus there are no "exact" measurements.
For methods based on "classic" NetFlow I disagree, see below.
I've looked at other ways and can't find any better. Billing based upon NetFlow, for example, is still statistical sampling since NetFlow loses a percentage of flows. For example, one of my VIP2-50's says:
368351628 flows exported in 12278484 udp datagrams 33838 flows failed due to lack of export packet 269989 export packets were dropped enqueuing for the RP 108825 export packets were dropped due to IPC rate limiting
Yes, and in addition you may lose flows on the path between the exporting router and the accounting postprocessor, or due to resource shortage in the postprocessor. However the way you handle this is that you don't bill for flows whose accounting records you have lost, so you always err in favor of your customer. This gives you the right incentive to dimension your accounting infrastructure so that loss is minimized. As long as the loss rate is in the ballpark you showed, the lost revenue probably doesn't justify the effort (VIP upgrades) to fix this. Of course your sampling problem occurs if the provider uses SAMPLED NetFlow and multiplies the actually measured traffic rates with the sampling interval. Regards, -- Simon.