Internet testing

Matt Mathis mathis at pele.psc.edu
Tue Nov 1 20:50:36 UTC 1994


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--





More information about the NANOG mailing list