On Thu, Apr 19, 2001 at 05:18:02PM -0700, David Schwartz wrote:
So did you calculate, how much you are losing. It's less than 1% of a 1% of all flows. That means you catch up more than 99.99% of all flows. Not that bad. Furthermore NetFlow gives you the ability to offer value added (billing) services to your customers. For example ...
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
I get 3% loss. (26989+108825)*100/12278484 = 3%
Billing based upon total bytes transferred tends to create similar problems. Do you bill based upon bytes transferred per day? Per month? If so, it's still statistical sampling if you have some amount of 'paid bandwidth'.
And you can't collect this data from interfaces because interface rates include local traffic, which (for example) grossly overbills customers with newsfeeds.
... you may easily deduct News traffic from being billed. BTW: tell me how do you exclude News Traffic if you count the 95th %ile?
Our NetFlow accounting ignores the news flows as it ignores all local flows. We 'smear' each flow over the time period in the flow packet (start/end) as if its bytes were smoothly distributed over that time interval. We configure our routers to flush active flows every five minutes, rather than the default of 30, so the maximum time error is of the same order of magnitude as the sampling interval. We disclose this method to our customers, and they understand that it is statistical sampling. We also offer them a 'throttling' alternative that guarantees them either that they won't pay for any excess or that their excess will be capped at some particular dollar amount.
Billing based upon total bytes transferred is IMHO verfy fair and attractive from the point of a customer's view and tends to be a nightmare from an ISP's pespective especially if you don't just count bytes but are looking at the IP-addresses involved.
With a flat 'per byte' rate? I'm not sure how attractive people would find that. Plus, that costs the ISP the oppurtunit to charge people for bandwidth that they're not using (because we had to provide it to them anyway, in case they nedeed it).
Maybe a mixture of byte-counting and portspeed would give a fair billing model. BTW that's also the model you pay power for in Germany. Arnold Nipper / nIPper consulting mailto:arnold@nipper.de
You can do that. A DS3 costs X dollars per months plus Y dollars per gigabyte transferred (or Y per inbound gigabyte and Z per outbound gigabyte if necessarry). The 'problem' with that is a customer that alternates between 45Mbs and 0Mbps is charged the same as a customer that usees 22.5Mbps all the time, despite the very different costs to support them. You can fix all these problems by making the scheme more complex and thus (arguably) fairer. But my experience has been that customers tend to want simplicity. I do agree that you don't get much simpler than port cost plus byte cost. DS