|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Comments
> ATM immaturity - ATM itself isn't immature, it's the router and ADSU technology > that's immature. We've been running ATM in our lab since (believe it or not) > 1986, and switch vendors have been shipping equipment for about 3 years now. > We're beginning to see second generation products on the market right now. > Since the Toronto IETF, we've been running tests on the SF NAP configuration, > and the problems we've found (and fixed) have all been with the ADSU's or > routers. We do have a working configuration for the 1490/AAL5 protocol > stack, and are running load tests on it now. The first generation switches had a few hundred cells of buffering. This was 2-3 FDDI packets worth. For an IP WAN at any speed, that was a joke. So ATM switches at all usable for IP on a WAN (with long delay paths) and high speed (even 45 Mb/s) have just emerged in the last year as product. Even now, individual cells are tail dropped rather than entire AAL frames and there is no adequate support in current product to cooperate with TCP end-to-end congestion control by dropping complete AAL frames and by implementing a more intellegent drop strategy or congestion indication strategy than tail drop. Sure - the ATMF is discussing backpreasure and credits and other proposals have been made (or are pending). But this does not constitute mature product. In your testing, have you tried setting up two high speed TCP flows (ie: using RFC1323 and a big window) coming in the NAP at two DS3s and going out a third DS3 with a delay equivalent to a cross country path (about 70 msec)? What was the link utilization like? > Bi-lateral/multi-lateral NAP traffic agreements - There's no rules here at > all. The agreements are completely up to the NSPs who connect to the NAP. > A CIX-like arrangement where all parties agree to exchange traffic w/o > settlements is just as possible as N**2 bi-lateral agreements with traffic > sensitive settlements. The NAP managers and NSF have nothing to say here. IMHO - this is not my employers opinion - some guidelines might be in order. I suggest the following (excuse the style here - just trying to be as unambiguous as possible): No National Service provider (NSP) can refuse to accept traffic if the traffic is destined to a network for which that provider is providing primary connectivity and if that traffic is delivered to the NAP nearest the destination, except as noted below. Similarly, no NSP can refuse to forward traffic through their own infrastructure to the NAP closest to the destination if they are providing primary connectivity for the source, except as noted bleow. Primary connectivity for this purpose is the primary connectivity registered with the RA. There are only two exception to these rules. If policy of the destination itslef (not the provider) would exclude delivery of the traffic, the traffic may be dropped. The destination itself (either the final destination or an intermediate provider) may negociate with a high quality provider to have their destination address(es) advertised at equal metric at all NAPs (presumably for a fee) to certain other NSPs or all other NSPs. The purpose of the second case is to allow a client to choose a higher quality provider and then insure that traffic is usually symetric and will generally take the path between NAPs through the higher quality provider. NSF has made it clear that it does not want to be in the regulatory business. But if larger providers attempt unfair settlements something like this might be neccesary. Perhaps some other government entity might end up stepping in. We can only hope that things just work out or that NSF is at least asked for advise before any regulation is attempted. Repeat disclaimer - my employer has not endorsed these comments. It is purely my personal opinion. > As far as taking a long-range view on the Internet, I'll plead guilty. We're > already seeing congestion problems on the Internet today, and that's even > before we turn the video and audio applications completely loose. My concern > is that if we don't get enough capacity into the Internet, and really soon, > the growth rate is going to drop badly. I've lived on badly congested > Internets (remember the 56 Kb/s NSFNET?), and it's not an experience I > wish to repeat. > Dave If you haven't done performance testing considering long delay paths and what might occur when a bottleneck forms, you are not taking a long term view at all. You may not even be adequately considering the present. Throwing backplane or switching fabric bandwidth at the problem doesn't address problems of a bottleneck at an egress. Curtis - - - - - - - - - - - - - - - - -
|