Idea for US Internet Benchmarking System...

Wed Feb 14 20:05:41 UTC 1996

Matt and I have invented a way of expanding our Treno page to be far
more useful to the US ISP community.  This note is a brief description
of what we have in mind; we'd like to hear comments from providers on
whether they would be interested in this capability.

The current Treno server uses treno in an attempt to emulate TCP
behavior on a straight path from the PSC to an end site somewhere in
the Internet.  This feature, while useful, is somewhat limited in that
all of the benchmarking tests start with our single provider, MCInet.

We have found that, by using GRE tunnels, the vBNS, and some smoke and
mirrors, we can offer a Treno-type test starting at any router at any
NAP, traversing the Internet to a host of your choice, which then
returns ACKs to the Treno server via the NAP of your choice.

We believe that this very general capability, not rooted in any
provider or NAP, will be very useful to debugging Internet performance
problems.

More details on how this could work:  We would attach the Treno server
directly to the vBNS, where is would have a clear path to each of the
NAPs.  A GRE tunnel (RFC1701 & 1702 if you are unfamiliar) would be
set up between the Treno server and NAP routers owned by ISPs
interested in participating.  The Treno server would encapsulate
probes inside of GRE packets and deliver them to the appropriate exit
router.  This router strips off the outer headers, and forwards the
probes to their destination.  These packets use a source address based
on the NAP desired for return traffic.

For example, a provider wishing to test their infrastructure could
launch a Treno test which originates at the Sprint NAP and traverses
their infrastructure to the PacBell NAP.  The test would indicate the
overall throughput for the path.  The reverse test could be done
independently, allowing the isolation of assymetric problems.

Another example, a user seeing poor performance to a remote site.  The
user could indepently test performance from their closest NAP to each
of their site and the remote site.  If they wished, they could also
look at the view from another NAP or a third provider not related to
their site or the destination site.  After this analysis, it would be
trivial to file a trouble ticket with the provider who owns the
problem.  (An aside -- providers who participate would have access to
the logs, so the user filing the trouble report could simply send a
URL with the Treno summary indicating the problem.  This might greatly
aid the communication process between end-users and providers.  Heck,
we could even add a mailto: button to the page...)

We have tested the GRE tunneling capability on a local Cisco 7507, and
have found that the load placed on the router to de-encapsulate GRE
packets is about the same as what treno currently places on Cisco 7500
class routers.  If there is interest, and we procede with this idea,
we would include a rate throttle which would automatically stop a
treno test running at rates which would put more than a minimal load
on the routers performing the GRE tunneling.  For example, 100 pps
puts about a 5% load on our 7507.  If we throttled at this rate,
people would still be able to run tests up to speeds to 3.2 Mb/s at
FDDI size packets, or 1.2 Mb/s at ethernet sized packets.  It is in
principle possible for each GRE tunnel to define a different throttle,
so that heavily loaded NAP routers could be more protected than less
loaded routers.

In addition to rate throttling, we plan to update the Treno code to
run tests in reverse (starting at the end point and reducing the TTL,
rather than the current algorithm) and also to emulate, rather
precisely, the proposed TCP SACK (draft-ietf-tcplw-sack-00.txt)
behavior.

During the implemention of this plan, we would use a phased testing
period to give providers a chance to test and use the new server on
their infrastructure prior to openning it up to the general public.
It might also be feasible to keep separate provider access which
allows providers to do things to themselves (in order to debug
problems) which normal mortals using the server would not be able to
do.

The question we would like to pose to the provider community is, "Is
this interesting and useful?"  If the answer is yes, we will proceed
with our work.

For all you non-US people who have patiently read this far, don't
necessarily think you will be left out in the cold.  If the first
phase of this tool works, we are interested in exploring ways to
expand this capability to include non-US sites.

Please send us your feedback on these ideas.  Matt will also be at the
NANOG meeting tomorrow if you want to ask us questions directly.

--Jamshid & Matt

PS.  The current Treno server is at 

http://www.psc.edu/~pscnoc/treno.html