Charles Sprickman spork at
Fri Aug 21 18:05:39 UTC 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 at>
> To: nanog at
> 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 at
> Check the website for my Internet World articles -        

=-----------------=                                        = 
| Charles Sprickman                       Internet Channel |
| INCH System Administration Team         (212)243-5200    |
| spork at                          access at  |
=                                         =----------------=

More information about the NANOG mailing list