UUNET stops peering at MAE-West
curtis at ans.net
Mon Mar 25 17:18:32 UTC 1996
In message <01BB1909.0FDC0C60 at jfbb.atmnet.net>, Jim Browning writes:
> Why haven't more networks taken advantage of the PacBell NAP facility in San
> Jim Browning
Due to some poor initial choices in equipment (mostly due to a lack of
useful ATM choices at the time) PacBell got an early reputation for
moderate loss at very low throughput. They put their customers
requiring "high speed" on a single FDDI ring, which is the same things
causing trouble at MAE-West, soon to be upgraded.
Perhaps after the transition to the ABR capable switch, assuming also
that the router adapters will respect the RM cells and can all agree
on RFC1483 (and in addition RFC1577 would be nice), the PacBell NAP
will be a technically viable alternative. At that point it may become
strictly a business issue, with both MFS and PacBell offering an
interconnect in Northern California and Mae-West having the advantage
of claiming most of the initial business due to the choice of already
On a technical note, I'm not excited about ABR's concept of fainess.
I don't see the value to giving the VC to some small provider a fair
share of bandwidth outbound from the NAP as is given a large provider
with 2-3 orders of maginitude more TCP flows on the VC. It is not
technically feasible to set up a VC per large provider flow, and there
is no way to weight the VC. I'd prefer EPD/PPD since someone is
likely to be congested.
For example, consider traffic to provider A. Provider B and C each
provides 25% of the egress traffic. There are 10 other providers
pushing 5% each when things get congested. Provider B and C will be
losing 80% of their traffic before the others see any loss, even if
those providers only have a handful of users some of which are doing
wasteful things like running multiple unicast CuSeeMe flows. If
provider A is a small provider with a low speed link, the problem
isn't due to provider B and C. Provider A has too little egress
bandwidth, yet only traffic from B and C is affected.
This is a fundamental problem due to the need for hard state (separate
VC per actual user flow) to affect ABR (as opposed to no state at all
for EPD) and the infeasibility of setting up this hard state.
> From: Roy[SMTP:garlic at garlic.com]
> According to the night shift at UUNET's NOC, they have stopped
> peering at MAE-West.
> The fellow I spoke with said this will remain until the GigaSwitch
> is installed at MAE West scheduled for this week.
More information about the NANOG