- Test - lists.nanog.org

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

04 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 04 Jun '01

04 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 04 Jun '01

04 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 04 Jun '01

04 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

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

03 Jun '01

> i did not know abovenet was around in '89-90. thanks for the info. i'm ready to recant but i'd like to see the reference first.

2 1

apologia
by Paul A Vixie 03 Jun '01

03 Jun '01

i have now received private confirmation by several people, one of whom worked at uunet before abovenet was founded, telling me that abovenet was not first to offer 95th percentile. in my limited defense i have to say that abovenet was the first i ever bought from who offered it that way, but it now appears that my experiences in buying transit were very limited. my apologies to all. next time i promise to check my facts before posting.

1 0

RE: C&W Peering Problem?
by Sean Donelan 03 Jun '01

03 Jun '01

On Fri, 01 June 2001, Steve Schaefer wrote: > How is it that UUNet is getting a free ride? The ILEC's customer pays > for that line every month. (OK, the customer underpays, but the ILEC > gets to make it up in access charges as part of the regulation process.) > > The only reason that the traffic is unbalanced is that the ILEC's wrote > the rules to favor that traffic arrangement. Too late to whine about it. Since on the Internet the sender pays for sent traffic, and the receiver pays for received traffic, I've never understood the argument advanced by BBN/Genuity, UUNET and now apparently C&W that unbalanced traffic means someone is getting a free ride. If the customer pays flat-rate, you collect the same amount of money no matter how little traffic they send or receive. The 95% charging used by some providers is the greater of *either* inbound or outbound traffic. So imbalanced traffic to or from your customers is paid by your customers. So, can anyone explain why C&W, UUNET or Genuity care about traffic balance, other than to limit competition by providers who are better at attracting particular types of customers than them? If you are good at being a webhoster, your traffic will have one profile. If you are good at being an access provider, your traffic will have another profile. If you are mediocre at everything, I guess your traffic will be balanced.

7 6