nanog mailing list archives

Re: C&W Peering Problem?


From: "Christopher A. Woodfield" <rekoil () semihuman com>
Date: Sat, 2 Jun 2001 10:53:53 -0400


It seems as if a good solution to this kind of an imbalance would be for 
the peering partners to agree to listen to each others' MEDs. That way 
access provider B gets the traffic handed to them a close to the 
destination as possible. True, that means they need a beefier backbone, 
but the value in the peering arrangements they don't lose as a result 
of imbalanced traffic would seem to compensate. Are there any known 
iplementations like this among backbone providers?

-C


My understanding, based on talking to some people who run networks like
@Home which are totally access providers, is that the theory they use it
this. Let's say you have network A, a big access network, and network H, a
hosting network.
If the two networks peer in San Jose, Dallas, Chicago, New York, and
Washington, DC, and network H's biggest data centers are in San Jose but
network A's biggest customer base is in New York, that means that network H
sends lots of traffic through the San Jose peering link, and then network A
needs to carry tons of traffic on their backbone all the way to New York.
Meanwhile, network A sends acks and similar things to network H, and a
majority of those go through the New York peering link, and are then taken
back to San Jose on network H. The problem, the way network A sees it, is
that they might need to get an OC48 between San Jose and New York, whereas
network H can get away with an OC3/OC12 on the same path.
Thus, network A finds it unjust that they have to pay all this money for
this OC48 when network H, which is the network sending them all this
traffic, can get away with a much cheaper circuit, and thus they use this
excuse to try and bill network H in order to make as much money as possible.
Thus the "free ride" argument..

---------------------------
Christopher A. Woodfield                rekoil () semihuman com

PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B


Current thread: