Re: TTL etc

Vadim Antonov <avg@titan.sprintlink.net> Fri, 14 January 1994 05:28 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25051; 14 Jan 94 0:28 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25047; 14 Jan 94 0:28 EST
Received: from world.std.com by CNRI.Reston.VA.US id aa26281; 14 Jan 94 0:28 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA03938; Thu, 13 Jan 1994 23:48:43 -0500
Errors-To: catnip-request@world.std.com
X-Orig-Sender: catnip-request@world.std.com
Reply-To: catnip@world.std.com
Precedence: bulk
Return-Path: <avg@titan.sprintlink.net>
Received: from titan.sprintlink.net by world.std.com (5.65c/Spike-2.0) id AA03921; Thu, 13 Jan 1994 23:48:41 -0500
Received: from localhost by titan.sprintlink.net (8.6.4/1.34) id XAA22223; Thu, 13 Jan 1994 23:48:40 -0500
Date: Thu, 13 Jan 1994 23:48:40 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Vadim Antonov <avg@titan.sprintlink.net>
Message-Id: <199401140448.XAA22223@titan.sprintlink.net>
To: catnip@world.std.com
Subject: Re: TTL etc

>Note that the common implementation of traceroute is fairly slow and
>inefficient. An implmentation that sends out tests over a range of
>TTLs all at once and collates the results runs much faster :-) You
>use a few cute tricks to ID the returns of course ...

Speaking of traceroute. I would like to have an option
which will cause each gateway the packet passes to send a reply.
This way you will need to send only one packet (and there will
be no incosistent results in case of load balancing over diverse paths).

--vadim