Access to the Internic Blocked

Tue Sep 3 20:16:50 UTC 1996

John Hawkinson <jhawk at bbnplanet.com> writes:

> Oh well, I guess we can put this right next to the patches to have
> traceroute send TCP SYNs to get through stupid
> firewalls.

Um, no, the right thing to do would be to design something
that doesn't revolve around something as kludgey as
sending back expensive-to-generate and difficult-to-
analyse ICMP responses, whether they're time exceeded,
port unreachable or echo replies.

An obvious (if a bit naive) approach would be to have a
small service which sends datagrams containing
high-resolution timestamps back to the client, so that one
can measure each half of the round-trip time.  One might
want to provide two time-stamps: one as early as possible,
and one as late as possible in the lifetime of the
receive-packet ---> transmit-packet code-path,
particularly if between acquisition of the two timestamps,
the CPU could be working on other tasks.

A better approach would take what's been learned from NTP
about skew and variable code-path runtimes, to allow both
endpoints to contribute to a better representation of the
RTT and each half of the RTT.   This is non-trivial, but
it's essentially what I'd say we want from ping.

I would consider it a plus if the server could, while
still remaining lightweight, be asked to acquire
timestamps from another host, so that one could observe
full and half RTTs between different parts of the Internet. 

Traceroute is a somewhat different animal.  There are
times when I'd like a small service which would tell me
the IP address of the next-hop a particular router has
towards a destination address that it is using to forward
real traffic.  Combining that and the timestamping service
gives you a traceroute-alike that works like this:

1. ask next-hop towards destination for timestamps, print RTT information
2. ask next-hop towards destination for what its (cached) next-hop is
3. if (2) results in the destination itself, ask it for timestamps and quit
4. tail-recurse through (1)

or

1. ask next-hop towards destination for what its using as the next-hop
2. memorize the result of (1)
3. if the result of (1) is not the next-hop itself, recurse through (1)
4. ask the entire list of addresses from (2) for
   timestamps, as close to simultaneously as possible

each of which has subtle differences and drawbacks,
particularly in the case of route flutter.

One could shade things a little differently and use a ttcp
or the like instead of or in addtion to step 1, which
could be quite useful for analysing congestion, although I
have concerns about the scalability of that approach given
that in most routers I know of, tcp services aren't
exactly lightweight.

However, I think that building analysis tools on top of
the side-effects of error conditions will either constrain
the utility of the analysis or force a design whereby
error conditions must be dealt with instantly rather than
lazily.  That strikes me as a bad design constraint.

	Sean.