PPPoE and RADIUS accounting is the only "clean" way IMO.
If you do it with SNMP then in my opinion you would have to monitor the
device uptime also, and then the logic in the backend can then tell the
difference between a counter reset due to rolling over past 2^32 and
counter reset due to reboot. If it's a reboot you take the new counter
reading as bytes transferred in this time interval and you've simply
lost the data between the last sample and the reboot. That way you
undercount if anything. That sucks, but the alternative is to assume the
counter wrapped and add up to 4GB which might not have really
happened.....and that sucks worse.
I would push hard for almost any other method than SNMP, but if I had to
do it that's what I would aim for.
I'm not sure how I would handle attacks and such. I would assume the
system automatically billed for it so you'd have to have some procedure
to handle disputes and historical data to reference so you can resolve
the question after the fact. Maybe you also get a daily report which
you monitor for anomalous usage so you can alert the customer and nip it
in the bud.
I think most of us aren't doing UBB and all of these questions are a big
part of why we don't.
-Adam
On 12/31/2019 12:35 PM, Nate Burke wrote:
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
