So then those doing UBB, how do you data collection for the bits? (I
don't do UBB, it was just a thought exercise)
SNMP of the sub SM? This may be affected by reboots/RF Drops causing
the counters to reset/not read.
Netflow at the Tower router? This could record bits that don't get
delivered because of RF drops or loading of the AP. Especially if
you're doing QOS in the AP/SM.
Netflow at the Core? Problems as below, or do you just presume some
overhead and bill at 60% of this value.
Do all 3 and have a fancy system average them all together?
I don't use RADIUS/PPPoE, But I guess that this may be the solution,
are there caveats to it too? If it records the data as it goes through
the PPPoE Server, bits could be dropped later on before getting to the
customer.
How do you accurately bill what is delivered to the customer, and what
liability do you incur for bad data? Or do you have an Iron Clad EULA
that the customer signs in the blood of their first born, that you're
not responsible for mistakes in throughput calculation.
And if a customer get's a DDOS, do you bill them for that too?
On 12/31/2019 11:09 AM, [email protected] wrote:
For those of you doing UBB, do you bill based off of the bits coming
into your network destined for the customer, or the bits that actually
reach the customer?
I was just looking at a new customer who must have been re-syncing his
gaming system, had his connection maxed out for about 40 hours. The CDN
delivering it must have been doing that connection stuffing thing.
Netflow data from the network edge showed that 30-40mb/s was destined
for his IP Address, but because of bandwidth queuing, only 20mb/s was
delivered to him (his package limit).
How would you have billed this customer? 600GB of usage, or 330GB of usage?
330. Can't bill for what you didn't deliver.
Jared
--
AF mailing list
[email protected]
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
