UUNET Press Release on Peering

Strikes me that the terms "diversely routed" and "geographically diverse"
can be interpretted wildly.

You catch on quick. Who gets to do the audit? Other than the 'public'
interface between the providers, I don't think it is wise, or appropriate
to get into the internal design or business plans of competitors. You
really have to treat the rest of it as a black box. It hard enough to
predict what technology I'll need to deploy in my network without having
by hands tied by an agreement with a competitor. Thou shall use only
dedicated, fully-meshed, terrasterial clear-channel lines sounds great
until I discover the best way I can reach timbuktoo is over a ATM
satellite link.

DRA doesn't have large Web farms, but people build public libaries in
the darndest places. I'm always amused by providers that have peering
requirements their own networks, or existing 'peers' don't meet.

For most networks, I don't see a real problem dropping a couple extra
pairs of DS3s (assuming they were only at two NAPs to begin with).

There is a partition problem. Assume there are six points, and each
provider chooses four. Provider 1 could choose 1, 2, 3, 4. Provider 2
could choose 3, 4, 5, 6. Although each provider is at four points,
they only share two in common (3, 4). Which provider alters their business
plans to connect to eight places just so they have four common exchange
points?

If UUNet requires a DS3 interconnect at LINX, MaeWest, MaeEast and say
(for giggles) Australia -- AND a diversely routed DS3 backbone in the
U.S. that takes on an entirely different meaning than the above.

Don't giggle, DRA has an office in Melbourne. We don't have enough
traffic to justify multiple DS3/E3's to Melbourne, but looking at UUNET's
international map, neither do they. Every provider has their own
strengths and weaknesses, they are never exactly equal. Getting into
the internal network design of your competitor is just asking for trouble.
PSI and Sprint engineers used to battle over who had the better backbone
design. Neither ever convinced the other they were right.

I don't think its a good idea to require every backbone follow the exact
same design. We may have different 'major' routes than other providers,
and choose to deploy our 'big' links differently. That's one of the
strengths of the Internet, not a weakness. My design methodolgy may
be good, or it may be bad; but the design diversity between providers
hopefully means a "group think" mistake won't kill everyone.

Sean Donelan wrote:

DRA doesn't have large Web farms, but people build public libaries in
the darndest places. I'm always amused by providers that have peering
requirements their own networks, or existing 'peers' don't meet.

Do you feel that UUNET's own network doesn't meet the criteria set out
in the press release? How so?

Which of UUNET's peers who are able to continue to peer with them, would
you say do not follow the criteria set out in the press release?

Chris

Isn't there some issue like MCI and Sprint not being at 4 common NAPs w/
UUNet?

I know there is private peering going on, esp in St. Louis, but I think
the blanket peering requirments that get exceptions (ala AGIS' 5 NAP
requirement) are just a yard stick. If you aren't able to afford
800k/month, don't even bother (basically). Granted, those figures don't
seem as horrible as they were about, oh, 4 years ago...

-Deepak.

Deepak Jain wrote:

Isn't there some issue like MCI and Sprint not being at 4 common NAPs w/
UUNet?

I'm sure there are at least 4 points each where UUNET peers with MCI and
Sprint. Whether the peering is done at a public peering point or not
shouldn't make a difference. Obviously the need to peer is there,
otherwise the two companies would not have agreed to spend the money to
peer privately.

Chris

I know of at least one. I'm sure there are more. It seems,
that equity in traffic exchange may be an overriding
principle, although running many web-farms and small
backbone can certainly give you that.

For NASA this is a current snapshot of NAP traffic
exchange:

mae-w:

5 minute input rate 2888000 bits/sec, 632 packets/sec
5 minute output rate 2949000 bits/sec, 718 packets/sec

mae-e:

5 minute input rate 5458000 bits/sec, 2437 packets/sec
5 minute output rate 8041000 bits/sec, 2157 packets/sec

The flows are constrained by an over-worked backbone,
but as a general rule out > in. As I said, web-farms
and a small backbone will give you that :slight_smile:

Mark