ATM ABR service

["Kent W. England" <kwe () 6SigmaNets com>]

At 12:18 PM 3/25/96 -0500, Curtis Villamizar wrote:
> 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.

Curtis;

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.
>
> Curtis

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.

--Kent