weight vs. volume (95th percentile vs transfer in M/Gbytes)

Deepak Jain deepak at ai.net
Wed Aug 8 20:03:08 UTC 2007



To enhance what Steve said here. Bytes transfered would be the average 
if you are using a tool that doesn't degrade its historical data stores. 
  There are certain adjustments to say MRTG that are available that will 
give you real bytes transfered.

Depending on the provider, Bytes transfered is very possibly a 
symmetrical sum (kind of like the way old Exodus used to add in the 95th 
in and 95th out to get your billable 95th). I'd verify that before I 
made a pricing decision.

You can't push your usage around in funny ways the way you can with 
95th, and the provider is making an assumption that your traffic levels 
will not skew their network's usage in an unfavorable way to them. It 
does incentivize you to be as bursty as you want, since there is no 
penalty. It does provide you much more realistic "credits" (your usage < 
your average is bandwidth that can be used elsewhere] for your low 
activity periods. Whereas 95th rewards you for time-shifting your peak 
usage around, bytes transfered or "average" usage gives you the same 
bill either way.

However, and this is the big thing. For any *large* volume of traffic, 
you will not get average pricing (unless your average = your max ;) ) 
because of the insanity your traffic patterns could follow.

I believe most CDNs charge by bytes transfered because their model is 
significantly decoupled from 95th usage and their premium (over moving 
the bits in a conventional way) may be sufficient to solve this. Not to 
mention, their application is typically bytes based, not burst-based.

DJ

Stephen Wilcox wrote:
> Hi Jim,
>  well transfer is equivalent to an ordinary average if you want to bring it back into something you can compare.. (so divide by number of seconds in a month and multiply by 8 to get to bits per second)
> 
> Average pricing should give you better rates as you can do some crazy bursting followed by periods of nothing and pay a fairly low fee that might for a 95%ile push the measured level up.. of course that tends to mean that the prices are a little higher.
> 
> I usually assume that peak (which for most traffic is equivalent to 95%) is about 3x the average.
> 
> 
> Ultimately tho these are different techniques and you should bear in mind the above and then apply it to your own situation to work out whether this would represent a cheap or expensive solution. 
> 
> If you do the conversion to average tho this should be easy to read off your current RRD graphs to work out a price comparison :)
> 
> Steve
> 
> On Wed, Aug 08, 2007 at 11:03:11AM -0400, Jim Mercer wrote:
>>
>> over the years, i've grown quite accustomed to feeling out pricing of bandwidth
>> based on 95th percentile peak utilization with various minimums and potential
>> tiers.
>>
>> i've always sorta viewed pricing by "bytes transferred" to be a consumer thing
>> that my uncle might pay when hosting his webpages showing his matchbox 
>> collection.
>>
>> now i'm faced with a jurisdiction where the only providers (all 2 of them) will
>> only give pricing in "bytes transferred".
>>
>> they are not interested in giving me pricing based on 95th percentile, and
>> as such i'm having a tough time budgetting for some of my applications.
>> (pisses me off because i'm sure _they_ are paying by 995th percentile)
>>
>> with 95th percentile, i could always trottle down the applications or figure
>> out what my estimated `overage might be.
>>
>> has anyone got a formula for comparing 95th percentile billing with bytes
>> transferred?
>>
>> -- 
>> Jim Mercer        jim at reptiles.org        +971 55 410-5633
>> "I'm Prime Minister of Canada, I live here and I'm going to take a leak."
>>    - Lester Pearson in 1967, during a meeting between himself and
>>     President Lyndon Johnson, whose Secret Service detail had taken over
>>     Pearson's cottage retreat.  At one point, a Johnson guard asked
>>     Pearson, "Who are you and where are you going?"
> 
> 



More information about the NANOG mailing list