We are ready to perform end-to-end performance testing across the new NSF architecture. PSC has a whole battery of TCP and IP diagnostics available from a test network, which can be exercised without exposing any production users to untested infrastructure. The network psc-hs-test (192.88.115), containing only the host voyager-115.psc.edu (192.88.115.29) is being announced to ANSnet (AS690), and from ANSnet to all peers at the NAPs. It is not announced by ANSnet to any other interconnects or providers. We encourage all providers to accept this route via the NAPs as soon as possible. If an RSP announces a test network to their new NSP, and also has the route announced across the NAPs, we can establish end-to-end connectivity through the new infrastructure. We are in a position to exercise such a path at loads beyond those attainable by most users. Depending on the target host available at the RSP, we can run large window TCP, mping or Jamshid's instrumented traceroute. We do need to be careful about maximum load because some of the segments are carrying production traffic. Since TCP "does the right thing" in the presence of congestion, TCP tests can be run at what ever bandwidth the network will support. We will limit IP performance tests to avoid sustained or high packet loss. I can not stress how important it is to do these tests as early as possible. We first used psc-hs-test in January of 1991, to maul the then brand new T3 NSFnet. We persisted in demonstrating that it didn't work, and Merit/ANS persisted in fixing it. At that time we had the undivided attention of the developers and they were able to do prime-time backbone software reloads and hardware upgrades. Once we agreed that it was working (it took about a month), we have never had problems with it. By hindsight, this saved us from all of the anguish suffered by NEARnet and others when they migrated to infrastructure which was beyond the capability of available diagnostic tools. Please test the path to voyager-115.psc.edu, and please let us help you meet the needs of your customers. PSC will be much happier to do gratis testing before any traffic cutover, than to address user complaints about infrastructure which is already in production. Drop a note to pscnet-eng, and we will arrange some tests. Thanks, --MM-- P.S. There is an issue of acceptance criteria: We are not parties to the provider contracts, and are not in a position to tell providers what they should deliver to their customers. Furthermore, it is known that much of the technology is being pushed into service faster than comfortable. None the less, we believe that there are some minimal requirements that should be met in all parts of the R&E Internet, if not the entire Internet. Required on day one (Note the vague words): - Mostly not congested. - Low loss when not congested. - Sufficient queuing to smooth some of the inherent burstyness. - Sane congested behavior at likely choke points. Sane means that actual IP throughput should be constant or at worst fall gently with load rising beyond the onset of congestion. It is my belief that there are a substantial number of users who will complain bitterly if the Internet fails to meet these "requirements". Note that these requirements are not sufficient to assure stable TCP operation. In the longer term, additional things are need: full D*B queues at all choke points and a strategic packet drop policy, such as RED, for early congestion notification. Also router implementations that can not do LSRR (source route) and ICMP at full rate greatly complicate sectionalizing problems on long paths. When the routers implement the entire protocol at full speed, it is trivial to localize performance problems to within one hop. However, in most commercial routers the less used parts of the protocol take a different, longer code path, which is almost always far more congested and lossy than any problematic primary path. A workaround is to install fast workstations near key interconnects. The workstations can be used as diagnostic probes/targets to test long paths section by section. --MM--