North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: C&W Peering Problem?

  • From: Christopher A. Woodfield
  • Date: Sat Jun 02 10:56:33 2001 
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		[email protected]

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