June 2001 - Test - lists.nanog.org

RE: 95th Percentile = Lame
by Joe Blanchard 04 Jun '01

04 Jun '01

Hmmm.. In reading this thread. Does this mean that if I send an 0xFFFF bit pattern to a network versus a 0x0000 pattern I'd be charged more for the energy consumption since all the 1's are high and consume more elecetric, and is there a larger charge for CA given the electric issues there? lol Well just had to throw that in since some of these comments are a bit far fetched.... just my 2¢s Happy Monday all. -Joe Blanchard

3 2

RE: 95th Percentile = Lame
by Joe Blanchard 04 Jun '01

04 Jun '01

Hmm, I thought 1's were high and 0's were low? lol Oh well, such is digital.. -Joe Blanchard -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Sunday, June 03, 2001 9:26 PM To: Joe Blanchard Cc: nanog(a)merit.edu Subject: RE: 95th Percentile = Lame > In reading this thread. Does this mean that if I send an 0xFFFF bit pattern > to a network versus a 0x0000 pattern I'd be charged more for the energy > consumption since all the 1's are high and consume more elecetric no, it's the transitions from 0 to 1 or vice versa that take the energy. that's why the nanog list is so repetitive, saves money. randy

1 0

Re: 95th Percentile again (was RE: C&W Peering Problem?)
by Paul Vixie 03 Jun '01

03 Jun '01

How quickly they forget. > UUNet bills for the MAXIMIUM 95th percentile on inbound OR outbound, > whichever is higher, as does AboveNet, and probably the majority of > networks trying to be like UUNet. In case this is unclear, AboveNet was the first to do 95th percentile, and UUNet was the first of those who have since followed in Dave Rand's footsteps. > But a significant portion of other networks will bill for the AVERAGE > under the 95th percentile. When I asked DLR why he those 95th percentile he claimed it was to account for the "averaged peak load" that a customer put on his backbone. Throwing away the highest 5% of samples was somewhat arbitrary -- could have been 4% or 6% and the result would've been about the same. What he was trying to get at was a way to make what the customer paid be related to what it cost him to provision backbone and peering links. It seems, based on the rest of the industry having followed his example, that he was onto something.

4 3

Re: 95th Percentile != Lame
by Richard A. Steenbergen 03 Jun '01

03 Jun '01

On Sun, Jun 03, 2001 at 08:16:28PM -0700, James Thomason wrote: > > This is very true. You have also in this example, defined your basis > of cost and could effectively say "Today, every bit that crosses my > network costs me X". This is a hard, quantified and total cost that > includes all of your provisioned capacity. Also, 95th percentile does not take into account peak hours for its pricing. You could push your peak traffic at off-peak hours and still be billed a very high amount. A more sensible system would be a different price for on-peak times. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: 95th Percentile != Lame
by Paul Vixie 03 Jun '01

03 Jun '01

> I still fail to see how "peak bits" or "bursted bits" are more expensive > than "regular bits". A 100Mbit FE port costs whatever it costs, and does > not fluctuate with usage. This is true of almost all of your links within > the network - excluding those where you have negotiated usage-based > billing. An OC3, point to point, costs as much as it costs irrelevant of > its usage. Therefore, every bit that crosses this circuit has a cost. > > Why not simply pass this cost on to the customer bit for bit? let's say that you've sold 1Gb/s of connectivity to each of 50 customers. if you don't do anything fancy in your backbone provisioning, two things will happen: (1) you will need 50Gb/s of peering connectivity to EVERY PEER and on EVERY BACKBONE LINK (just in case all five customers send full blast to the same destination at the same time, as in a DDoS or flash crowd scenario); (2) when you try to pass the costs of this provisioned capacity to all of your customers (equally), you will have noncompetitive rates. what actually happens is that you provision as much capacity (including whatever headroom your business plan calls for) as is actually needed, and then try to upgrade it fast enough so that your customers always get their bits through. it is not actually possible to get 50Gb/s worth of peering connectivity to most peers -- and if you could then they'd be dropping most of your traffic one hop inbound on their network anyway. charging for 95th percentile (highest of in or out, not additive) is a way to get those customers whose traffic puts the most strain on the provisioning plan to pay more. but consider another model for a moment. the power companies hereabouts use the monthly peak to set the rate (per KwH) for the month. so if you never hit them very hard then every KwH you buy from them is cheaper. this model correctly passes the provisioning (especially headroom) costs to commercial customers who put the most stress on the system, but also correctly rewards customers with lower costs based on them keeping their actual usage down. i'm not suggesting that this would apply perfectly to the IP transit situation, but it takes more of the relevant factors into account.

2 1

Re: 95th Percentile = Lame (fwd)
by James Thomason 03 Jun '01

03 Jun '01

> No. > > The issue here is "incremental" cost. Once the circuits are all > provisioned, it doesn't matter what you send over them, true. But it's > not the *loops* that cost you money. It's the backbones. It's the > *aggregate* total of the speeds of the *router ports* (which is what > you're charging for, anyway), not the aggregate total of the speeds of > the *loops*, that is the real issue here. > > The telco charges me the same thing for the loop regardless of howmany > timeslots I provision the customer for in the router. I hear what you are saying here. But do you not think that these costs can be quantified, and reduced to a common denominator? Should not the cost of provisioning "excess" bandwidth be part of the BASIS cost you pass on to customers? Should not other networks who currently dump traffic to you "freely" pay that cost as well? In a simplified sane model: My Cost: Circuits c Power p Space s Equipment e Other o ---------------- c+p+s+e+o = C(ost) C + P(remimum) = Cost to Customer C + T(arrif) = Cost to Providers The cost (C) must be paid for every bit that traverses my network, either from customers or "peer" networks. The current non-quantified C is paid for completely by customers - SOMETIMES and MAYBE, since we bill on an average instead of a value. Some customers pay for other customers traffic, and some get traffic for free. Does your stock broker bill you on an average number of shares for a set of transactions? Or does he charge you a per share fee? Are you SURE? > > Since that's true, it's useful to have *some* way to allow the > provisioned bandwidth to float up a little closer to the aggregate > usable bandwidth in my backbone, since it does *in fact* not cost me > anything. > > (Anyone whose provisioned their backbone to 100% of their aggregate > access bandwidth -- in an access network, not a server farm one -- just > doesn't understand the business. *Everyone* bandwidth-surfs. The > billing approaches we're talking about are just a slightly better way > of matching the two numbers.) > > Cheers, > -- jra > -- > Jay R. Ashworth jra(a)baylink.com > Member of the Technical Staff Baylink > The Suncoast Freenet The Things I Think > Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 > > OS/X: Because making Unix user-friendly was easier than debugging Windows >

1 0

mae-east customer service (Re: A moment of silence)
by Sean Donelan 03 Jun '01

03 Jun '01

On Sun, 03 June 2001, Leo Bicknell wrote: > It appears that MFS finally went and did it, and the mae-east we > all came to know and love has finally been turned off. Please bow > your heads for a moment of silence. Can someone who is paying Worldcom for service at mae-east call mfs/worldcom and ask what the current status is? I understand worldcom doesn't have the best reputation as a customer service driven company, but someone in the organization must know the actual status of mae-east.

1 0

Re: A moment of silence.
by Richard A. Steenbergen 03 Jun '01

03 Jun '01

On Sun, Jun 03, 2001 at 08:48:27PM +0100, Simon Lockhart wrote: > > >It appears that MFS finally went and did it, and the mae-east we > >all came to know and love has finally been turned off. Please bow > >your heads for a moment of silence. > > So what is everyone going to do instead? > > Join MAE-East-ATM? > > Join PAIX-VA? > > Join ISPCondo? (Abovenet's NAP in 8100 Boone) WorldCom wants you to move to MAE-East-ATM, eventually moving everyone to their new facility in Ashburn VA. I think/hope most people will just move to PAIX-VA or Equinix-VA, or both. I tried to think of a good parody of American Pie for this occation, but I didn't want to stretch FDDI to end in a long-I, so I'm just gonna go with: Ding Dong the Wicked Witch is Dead. Now if only they'd kill off ATM too. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: 95th Percentile again (was RE: C&W Peering Problem?)
by Richard A. Steenbergen 03 Jun '01

03 Jun '01

On Sun, Jun 03, 2001 at 01:41:08PM -0400, Alex Rubenstein wrote: > > > > > No its not obvious. The SNMP byte counters are odometers - as long as > > you get two clean samples per counter wrap you can accurately count > > bytes. The trick is to ensure that you get a minimum of two clean > > samples of the odometer reading per counter wrap - for high speed > > interfaces that typically implies reading the MIB2 64 bit interface > > counters, or triggering an SNMP poll at relatively tight time > > intervals. > > 2^64 is 1.844 * 10^19 > > at 2.5 gb/s (OC48 line speed) (2,500,000,000 bits/sec), you transfer > 312,500,000 bytes/sec, or 298 megabytes/sec. > > 2^64 / 312,500,000 = 6.189 * 10^16 seconds per rollover. > > or, 1.719 * 10^13 hours > or, 1,962,741,057 years. > > My point: at least for the near future, 64 bit counters won't roll. Or thought about another way: 2^64 = 18446744073709551616 bytes/sec = 147573952589676412928 bits/sec. Which means a 64 bit counter will roll over in 5 minutes at 491913175298921376 bits/sec, or 491Pbps (Petabits/sec). Under the current naming scheme, this will be OC-9444732864. Better start planning for 128 bit counters, we wouldn't want to be stuck in something which doesn't scale. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

RE: 95th Percentile again (was RE: C&W Peering Problem?)
by E.B. Dreger 03 Jun '01

03 Jun '01

(Taking this back on list for people to critique as they please.) > Date: Sat, 2 Jun 2001 21:50:39 -0700 > From: David Schwartz <davids(a)webmaster.com> [ snip ] > The problem with these other billing methods is primarily that they fail > to reward people for taking effort to smooth out their usage. If my > customers can do their bulk transfers off-peak, I'd like to reward them > for it. That way they save me money. People would probably balk at the complexity and variability, but I've contemplated a two-stage billing model... Have the base rate determined purely by traffic volume, i.e. GB/mo. Now apply an adjustment factor based on x = (95th / mean). x = 1.00 is perfectly flat; give substantial discount x = 1.50 is a moderate sine wave; consider this typical T-3 x = 2.50 is a typical T-1 x = 1.00 to 1.249# --> 25% off x = 1.25 to 1.399# --> 10% off x = 1.40 to 1.799# --> standard rate x = 1.80 to 2.499# --> 10% surcharge x = 2.50 up ---------> 25% surcharge and so on. I'd need to look at numbers, so don't take the above as the right mix, but you get the idea. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 ---------------------------------------------------------------------------

1 0