North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: BBN/GTEI
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 <[email protected]> > To: [email protected] > 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: [email protected] > Check the website for my Internet World articles - http://www.memra.com > > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | [email protected] [email protected] | = =----------------=
|