I seem to remember seeing explanations that mobile carriers leave some data out 
of the calculations for billing or data cap purposes.  Like DNS lookups maybe?  
Also retries which LTE networks have a lot of.  Then there’s the zero rated 
data like certain video streams.  And I assume VoLTE data is not counted.

 

To answer Nate’s question, I expect most operators would only count the 
delivered data, not including what gets thrown out due to rate limiting.  Which 
seems a little unfair, it would be like a restaurant only charging you for what 
you ate, not what you ordered.  In this case, though, it would be like the 
restaurant never brought everything you ordered to your table.  Plus the 
concept that the customer “ordered” all that data isn’t quite true, he just 
subscribed to a service which decided to  send him all that data.

 

One philosophy I have that not everyone shares, is that you should charge for 
data usage or speed tier but not both.

 

So if you’re going to use UBB, maybe your speeds should be best available, 
which eliminates the problem.  Just deliver the excess traffic and then charge 
the customer for it.  That’s maybe why the mobile wireless and cable companies 
seem to be moving away from UBB toward data “caps” and “deprioritization” 
(throttling) once you hit the cap.  I guess another approach would be rate 
shaping rather than policing.  Put in a really deep queue so you deliver all 
that data to the customer eventually, although their latency will go sky high.  
Most TCP senders will eventually slow down when the ACKs are coming 500 or 1000 
msec delayed.  I get a little tired of the bufferbloat scolds who view this as 
a horrible flaw of some ISPs.  You’ve got to either deliver all traffic to 
customers without rate limits, or delay some of it, or throw some of it out.  
There’s really no other choice.  The people who say techniques like AQM and 
FQ-CODEL accomplish rate limiting without excessive latency are making an 
assumption about TCP senders, that dropping just the right packet will alert 
the sender to congestion and make them behave.  Maybe yes, maybe no.  It’s like 
assuming you can say the right thing to a schoolyard bully and he won’t take 
your lunch money.  Or that all Twitter trolls can be taken down with a clever 
comeback.

 

 

From: AF <af-boun...@af.afmug.com> On Behalf Of Josh Luthman
Sent: Tuesday, December 31, 2019 10:39 AM
To: AnimalFarm Microwave Users Group <af@af.afmug.com>
Subject: Re: [AFMUG] UBB Question, what network point do you bill on?

 

Verizon would probably do the 600 GB, but I'm not a UBB user.

 

If it was dropped at your head end and you didn't have to carry it through your 
network and by consequence the AP, I wouldn't see a problem with the 330.


 

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

 

 

On Mon, Dec 30, 2019 at 8:07 PM Nate Burke <n...@blastcomm.com 
<mailto:n...@blastcomm.com> > 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?



-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

Reply via email to