PAIX

Thu Nov 14 22:05:45 UTC 2002

SS> Date: Thu, 14 Nov 2002 13:32:55 -0600
SS> From: Stephen Sprunk

SS> Incorrect.  Cheap longhaul favors a few centralized
SS> exchanges.  If there is no economic value in keeping traffic
SS> local, it is in carriers' interests to minimize the number of
SS> peering points.

True.  However, cheap longhaul / expensive local means providers
_will_ try to reduce loop costs, favoring "carrier hotels".

SS> Most vendor-neutral colos have cheap zero-mile loops.

Correct.  In my original post... are we discussing #1 or #2?  It
seems as if #2.  Where are we drawing the line between "carrier
hotel" and "exchange"?  I believe Paul was being perhaps more
nebulous than today's definition of "exchange" when he referenced
1500 sq-ft in-bottom-of-bank-building facilities.

SS> What is the cost of running N loops across town, vs. the cost
SS> of pushing that traffic to a remote peering location and
SS> back?  Be sure to include equipment, maintenance, and
SS> administrative costs, not just circuits.

"It depends."

SS> None of these applications require local exchanges.  There is
SS> a slight increase in end-to-end latency when you must use a
SS> remote exchange, but very few applications care about
SS> absolute latency -- they only care about bandwidth and
SS> jitter.

With bounded latency and "acceptable" typical throughput, one
seeks to minimize jitter and cost.  Jitter is caused by variable
queue time, which is due to buffering, which is a side-effect of
statmuxed traffic w/o strict { realtime delivery constraints |
QoS | TDM-ish architecture }... yes.  And N^2 makes full-mesh
irresponsible when attempting to maximize bandwidth... yes.
(I think buying full transit from 10 providers is well beyond
the point of diminishing return; no offense to INAP.)

Again... if loop is expensive, and providers are concentrated in
"carrier hotels" with reasonably-priced xconns... when does it
become an "exchange"?  Note that some exchanges do not provide a
switch fabric, but rather run xconns.

Sure, one must factor in all the costs.  The breakeven point
varies, if it exists at all.

SS> Distributed content assumes the source is topologically close
SS> to the sink.  The most cost-efficient way to do this is put
SS> sources at high fan-out areas, as this gets them the lowest
SS> _average_ distance to their sinks.  This doesn't necessarily
SS> mean that putting a CNN mirror in 100,000 local exchanges is
SS> going to reduce CNN's costs.

It depends.  Akamai certainly is overkill for smaller sites, and
perhaps not cost-effective for others.  However, high fan-out can
be a _bad_ thing too:  Assuming one has substantial traffic flow
to various regions, why source everything from NYC?  Why not
replicate in London, AMS, SJO, IAD, CHI, DFW, LAX, SEA, KSCY?

>From a source's point, distribution makes sense when cost of
geographically-diverse server presence (incremental admin/hw,
content distribution) is less than the cost of serving everything
from a centralized point.  Once that happens... if a substantial
portion of Internet traffic were sourced from one local point,
sinks would gravitate toward said point.

Of course, I may well be stuck in distance-sensitive mode.  If
local loop is the primary expense... we're back to what you said
about "few, centralized exchanges" and "many carrier hotels"?
So, where's the dividing line?

Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist at brics.com>, or you are likely to
be blocked.