concern over public peering points [WAS: Peering point speed publicly available?]

Sat Jul 3 06:07:06 UTC 2004

On Sat, Jul 03, 2004 at 01:00:35AM -0400, Patrick W Gilmore wrote:
> 
> On Jul 2, 2004, at 9:31 PM, Stewart, William C (Bill), RTSLS wrote:
> >Also, if you're dealing with ISPs that use public peering points,
> >those may be a performance concern, but in the US that's mostly not 
> >Tier1-Tier1.
> >(Linx is a different case entirely, assuming you want your traffic to 
> >be in London.)
> 
> Any particular reason you would worry about public peering points these 
> days?
> 
> The FDDI MAEs are dead, there is no head of line blocking any more.  
> Every ethernet or ATM switch running a NAP I've seen in the last ... 
> nearly half a decade is more than capable of passing all bits going 
> through it without a problem, and then some.

What is with people in this industry, who latch onto an idea and won't let
go? If someone was talking about 80286 based machines in 2004 we would all
be in utter disbelief, but you can still routinely find people talking
about "the MAEs" and "congested NAPs".

> There might be a concern that, for instance, a provider would show up 
> to a NAP, connect at GigE, then peer with 2 gigabits of traffic.  But I 
> fail to see why that is the public fabric's fault, or why things would 
> be any different on private peering.  The provider knows when their 
> connection is congested, be it an ethernet to a NAP or an OC to another 
> router.  I also have not seen that affect the packets not going to the 
> congested port (unlike some older NAPs).

a) Exchange points make a living convincing people to buy their product 
   just like everyone else. When stupid people who don't know what they're 
   doing buy transit, no one cares. When these same people who really 
   don't know how to peer or manage their capacity start jumping on the 
   "save money" or "improve performance" bandwagon without finding someone 
   experienced to run it, they do stupid things. :)

b) The price being charged for the public exchange ports is non-trivial
   (especially compared to the cost of transit these days!), and is billed 
   on a port basis instead of a usage basis (at least in the US). Since 
   public peering is treated as a "necessary evil", with traffic moved to 
   much more economical private peers when they start getting full, no one 
   wants to provision extra capacity ahead of demand (in fact, in the US 
   it is exceedingly rare to see anyone with 2 ports on a single public 
   exchange).

Personally I've never understood why US exchange port operators havn't
insisted on some kind of "80% utilization over Xth percentile and you must
upgrade" rule. Since you don't normally have an idea how hot your peer is
running their public port, you're really putting a *lot* of faith in your
peers' ability to manage their traffic when you peer with them over a
public exchange.

Given how poorly some folks do this, and how quickly a congested port can
degrate the reputation of an exchange point, it seems like this would at
least be a very basic safety net (doesn't help if they only have 1 OC12 of
backhaul off of that GigE port, but still better than nothing). Plus as
I'm sure we all know the price of the exchange point switch port is
covered by the first months' fees. What we're really paying for is the
faith that the EP operator will keep things up and running, prevent
forwarding loops, check for bad things being broadcasted, maybe invest in
a bigger switch down the road, and be able to convince others to join so
that there is a reason to bother peering there, etc. The extra cost of the
ports is really quite trivial.

> Public NAPs got a bad name many years ago because a few of them were 
> poorly run, and some other ones had some technical difficulties, and 
> some providers intentionally congested their public ports so they could 
> say "see, public peering sucks", and lots of other reasons.

Some still do. At the very least, I can personally think of at least 4
different folks with public GigE exchange ports sitting at 920-960Mbps
peak *RIGHT NOW*.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)