Mailing List Archive

Why haven't more networks taken advantage of the PacBell NAP facility in San Francisco??
--
Jim Browning

----------
From: Roy[SMTP:garlic@garlic.com]

According to the night shift at UUNET's NOC, they have stopped
peering at MAE-West.

<snip>

The fellow I spoke with said this will remain until the GigaSwitch
is installed at MAE West scheduled for this week.

<snip>

>> Why haven't more networks taken advantage of the PacBell NAP facility
>> in San Francisco??

Both AADS (Chicago) and PacBell (SF) have suffered through
not-ready-for-prime-time hardware. Recent word (nanog) was
that PacBell was moving to a new improved switch (i.e., they are
going to switch switches).

MAE-West came about partially because of delays in getting
the SF NAP up and running.

I should note that I don't see any issues going over the SF NAP from
my neck of the woods.

-mark

P.S. It is sort of funny to have someone from domain atmnet.net
ask about the state of an ATM NAP. Kinda begging for someone
in the "other camp" to bash ATM.

At 12:07 AM 3/24/96 -0800, Mark Kent wrote:
>>> Why haven't more networks taken advantage of the PacBell NAP facility
>>> in San Francisco??
>
>I should note that I don't see any issues going over the SF NAP from
>my neck of the woods.
>
>-mark
>

Give it a try. Pacific Bell has upgraded the Bay Area NAP to Stratacom BPX
ATM switches and the new PacBell LA NAP will also be a BPX switch. These
switches have sufficient buffer size to manage OC-3 connections.

Check out our NAP stats page http://www.PacBell.COM/Products/NAP/Stats/ to
see how much aggregate traffic is already flowing through the Bay Area NAP.
Still some headroom left and no cell loss!

--Kent

In message <01BB1909.0FDC0C60@jfbb.atmnet.net>, Jim Browning writes:
> Why haven't more networks taken advantage of the PacBell NAP facility in San
> Francisco??
> --
> 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
proven technology.

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.

Curtis

> ----------
> From: Roy[SMTP:garlic@garlic.com]
>
> According to the night shift at UUNET's NOC, they have stopped
> peering at MAE-West.
>
> <snip>
>
> The fellow I spoke with said this will remain until the GigaSwitch
> is installed at MAE West scheduled for this week.
>
> <snip>