Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: BBN/GTEI

  • From: Owen DeLong
  • Date: Fri Aug 21 16:58:33 1998

> > Both companies get payed for providing a
> > service. Where is the problem? Why should BBN get a cut of what Exodus's
> > cutomers pay? BBN is trying to get payed to provide something it needs to
> > from Exodus. If BBN needs it, why would Exodus pay for it? Isn't BBN trying
> > to get payed twice?
> 
> You are asking about specifics and I have no idea what the answers are.
> Unless somebody speaks to both Exodus and BBN and gets around the NDAs
> that they have signed, I don't think anyone can know. 
> 
True.

> However, there is a more general issue here. If a company primarily hosts
> websites, then their traffic will be asymmetric with many more bytes going
> out than coming in. They must engineer their network to handle this
> asymmetry and any transit providers they have must also do so.
> Traditionally, peering only occurred between providers with a national
> network with at least 4 points of contact, spread out geographically. This
> requirement is so that each provider carries a roughly equal load of the
> traffic across expensive national longhaul circuits. It is this balanced
> transit load that makes them peers.
> 
Public Information:

	Exodus has a LARGE national backbone
	Exodus connects at:
	        MAE East
	        MAE West Ames
	        MAE West MFS
	        AADS NAP
	        PB NAP
	        MAE LA
	        SPRINT NAP
	        PAIX
	Exodus has private exchanges in place with a number of providers.


> In the case of a web hosting company, the bulk of the traffic is outgoing
> and if they do the standard shortest-exit routing with their peers, then
> the peer will be carrying a much larger transit load than the webhosting
> company. Of course, this could be solved by both parties doing
> longest-exit which places the largest transit load on the webhosting
> provider. But there is more.
> 
OK, so we're agreed on that issue.

> When the webhosting network touches down at only a few exchange points to
> peer with a provider who has an extensive network you will have a
> situation in which the peer is providing regional transit for free and
> must engineer their regional networks to deal with an asymmetric traffic
> pattern. For instance, if a webhosting provider touches down at San Jose,
> Chicago, DC and Dallas then they appear to meet the eligibility
> requirements for peering. But these peers end up providing full transit
> from Boston to DC, LA to San Jose, Denver to Dallas, and St. Louis to
> Chicago. This arises because one provider hosts lots of equipment close to
> an exchange point and the other provider interconnects many POPs in many
> cities.
> 
Exodus has facilities in Boston, New Jersey, Herndon (DC), Chicago, Irvine,
Santa Clara, and Seattle.  OK, we don't cover Denver, Dallas, or St. Louis,
but I have strong reason to believe that represents a very small fraction
of the traffic.  Further, when a provider sells access service to a customer
in Dallas, Denver, etc., it is not likely that any significant portion of
their traffic can be delivered to or accepted from an exchange point in
those places.  Therefore, any sane provider would expect to be transiting
a significant portion of the traffic supplied by/requested by that customer
from a city with a major exchange point or handoffs to multiple providers.
As such, I would think that transit would simply be part of their customer
pricing model.

> Somehow we need a way to quantify and measure the traffic and establish
> what peering is in terms of measurable quantities. A certain amount of
> asymmetry should be allowable but it can get out of hand. One way to deal
> with great asymmetry is to deny peering. Another way is to accept peering
> but measure the asymmetry and have a pricing structure for regional
> transit that applies after a certain point. Note that this is *NOT* the
> same as demanding that the webhosting peer become a transit customer.
> Since they are only using regional transit I would expect that the prices
> on the transit portion would be less than on a pure transit arrangement.
> 
An interesting thought, but you are still shifting the burden of cost from
the requestor of the data to the provider of the data.  Why, for example,
should University of California pay the cost of a customer in Dallas getting
a copy of Sendmail off of ftp.cs.berkeley.edu from say Irvine to Dallas?
It's actually pretty nice of them, in my opinion, to pay for it getting to
Irvine.  Is it unreasonable to ask the requestor to pay the freight for the
rest of the trip?

> However, for this to happen we would need some way to measure and quantify
> this regional transit. To date I don't think anyone has attempted to do
> anything like this except some Australian ISPs who have mapped the IPv4
> address space geographically so that they can manage their routing
> according to the cost of various intercontinental links without relying on
> somebody else's BGP announcements. I'm sure that we could use some sort of
> similar geographical mapping of IPv4 addresses to quantify how much
> regional transit a peer uses and thus establish a sliding scale between
> a pure transit customer and a pure peer.
> 
Only if you assume that the person sending the packet is responsible for the
costs of it arriving.  I don't think that's a proper economic model for the
internet, as the larger packet is almost always the response to the requestor.

> --
> Michael Dillon                 -               Internet & ISP Consulting
> Memra Communications Inc.      -               E-mail: michael@memra.com
> Check the website for my Internet World articles -  http://www.memra.com        
> 
> 
> 
Owen





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.