John Hawkinson <jhawk@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.