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: Charles Sprickman
  • Date: Fri Aug 21 14:12:04 1998

Perhaps the best solution here is for BBN to purchase Exodus.

On Fri, 21 Aug 1998, Michael Dillon wrote:

> Date: Fri, 21 Aug 1998 10:30:47 -0700 (PDT)
> From: Michael Dillon <michael@memra.com>
> To: nanog@merit.edu
> Subject: RE: BBN/GTEI
> 
> On Fri, 21 Aug 1998, Goodwin, Dustin wrote:
> 
> > 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. 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> --
> 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        
> 
> 

=-----------------=                                        = 
| Charles Sprickman                       Internet Channel |
| INCH System Administration Team         (212)243-5200    |
| spork@inch.com                          access@inch.com  |
=                                         =----------------=





Discussion Communities


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


Merit Network, Inc.