ATM ABR service

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.


The Newbridge ATM switch was selected over three years ago. The new
Stratacom BPX (10Gbps) switches are now in place and working for NAP
service. The Newbridges are still in service for other applications.

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.

I think it's a bit optimistic to expect ABR routers real soon (the
standard is still pretty fresh), but the BPX will emit EFCI notification,
so the routers can use that if they want.

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.

If what you want is an "admit all with best effort" quality of service
then we should configure the NAP for UBR service and let each connection
or path fight for bandwidth "fairly" according to WFQ (if available in the
routers) or FIFO and TCP congestion avoidance.

If what you want is a "allocate minimums, share the rest" quality of
service then we should use ABR and set the minimum cell rate according
to what the parties to each circuit want.

What do NAP customers want? WFQ/FIFO sharing or pre-allocated ABR?

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.


It might make sense to map each flow onto a separate VC when that flow
is a campus network flow, but I don't think that scales to something the
size of the NAP.