I totally agree with Milo. The only problem that must be solved on day 1 is *STABLE* migration away from the single NSP model. I have two nightmares: The majority of either the NSPs or NAPs or both fail to pass acceptance because they are unstable at high load. This will prevent or delay migration away from the single NSP model. Worse: we do not discover this until Nov 1st. --------------------- PSC will be vBNS attached early next year. We (and our sister supercomputing centers) have high performance users all over the Internet (plus zero local users). We depend on our NSP, our user's NSP, and the interconnects for our day to day operations. Furthermore we can move a lot of data: e.g. the interface to our file archiver is TCP/IP based and routinely sustains transfers at disk rates (160 Mbit/s as we are currently configured). This is RFC1323 TCP, and in principle, any user (without privileges mind you) can turn the necessary knobs to max out the bottleneck in any path in the Internet, today, tomorrow, and next year. (Modulo various real-world limitations) I predict that stability in the presence of congestion will prove to be far more important than actual pipe size. --MM-- P.S. If you did not see my paper "Windowed Ping: An IP Layer performance Diagnostic" at INET'94/JENC5, get it from the ISOC www server or ftp.psc.edu,pub/net_tools/WPing.ps . This describes our preferred tool for testing connectivity to our customers. I'd prefer that it be used in October, rather than November. --MM-- P.P.S. I never have understood the point of real time... What would you do with a 5 day weather forcast that took 5 days to produce? ;-)