Re: PAIX

["E.B. Dreger" <eddy+public+spam () noc everquick net>]

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?