North American Network Operators Group

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


  • From: Wayne Bouchard
  • Date: Fri Aug 21 14:44:30 1998

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

You mean GTE...

> On Fri, 21 Aug 1998, Michael Dillon wrote:
> > 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.

Lets not forget here that shortly after GTE picked up BBN, they also
picked up Genuity. Genuity still pretty much exists as an independant
entity. So when that is taken into account, GTE ALSO does web
hosting.. They just seperate the traffic off from the "BBN" traffic.

> > 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.

When you consider a web hosting company, often there are not the
resources to transit traffic to the best exit. Many companies buy
transit from one or more companies anyhow to be sure that they have
maximum reachability. If, for example, a company buys transit from MCI
and uses that to reach BBN, than it will have an impact on the traffic
ratios for the BBN/MCI interconnects. If enough similar companies take
MCI to get to BBN then it is entirely possible that the BBN/MCI
interconnect will become highly asymetric. So takeing into account
what just happened with Exodus, does this mean that BBN would try to
force MCI to buy transit from BBN?

This only goes so far before the whole thing breaks down. Granted that
the above is somewhat extreme example but it is most certainly
possible. The whole point behind private interconnects is to get
traffic to the destination with as few intermediary hops as possible
and to be able to better control congestion and loss between the
networks. If BBN's customers have trouble getting to certain popular
sites, they're going to complain to BBN. If the hosting company's
customers can't be accessed from certain sites, they're going to
complain to the hosting company. This means that both companies tech
support and operations centers get additional calls, additional work,
and additional headaches in trying to deal with traffic levels of some
third party. In many ways, its the third party that ultimately suffers
as they try to deal with both companies to resolve the issues.

IMO, asymetry is not a valid requirement for a private
interconnect. NOT having the interconnect hurts both companies.

Wayne Bouchard                             GlobalCenter
[email protected]
Network Engineer
(602) 416-6422   800-373-2499 x6422
FAX: (602) 416-9422