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.
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>
participants (3)
-
Curtis Villamizar -
Jim Browning -
Mark Kent