curtis at wawa.ans.net
Thu Sep 1 15:16:10 UTC 1994
> 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.
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.
More information about the NANOG