Yeah 330GB. The customer has no control over an aggressive strategy at
the CDN.
On 12/31/2019 12:01 PM, Ken Hohhof wrote:
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 <[email protected]> *On Behalf Of *Josh Luthman
*Sent:* Tuesday, December 31, 2019 10:39 AM
*To:* AnimalFarm Microwave Users Group <[email protected]>
*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 <[email protected]
<mailto:[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?
--
AF mailing list
[email protected] <mailto:[email protected]>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
AF mailing list
[email protected]
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
