Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!esosun!ucsdhub!sdcsvax!ucbvax!G.BBN.COM!CLYNN
From: CLYNN@G.BBN.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP echo
Message-ID: <[G.BBN.COM]30-Apr-87.10:26:56.CLYNN>
Date: Thu, 30-Apr-87 10:26:00 EDT
Article-I.D.: <[G.BBN.COM]30-Apr-87.10:26:56.CLYNN>
Posted: Thu Apr 30 10:26:00 1987
Date-Received: Sat, 2-May-87 01:08:00 EDT
References: <8704281601.AA00730@braden.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 27

Bob,

    The ICMP Echo Reply packet should start out with a new TTL value (in
    your terms, yes, the TTL should be reset).  This follows from my
    assumption that ICMP is a protocol layered above IP.

I do not agree with the "This follows" logic.  There are instancces in
the suite where a protocol "above" IP obtains information from the IP
header and later returns it for use in a subsequent IP datagram; the
two most obvious examples are the source and destination address, and
one could even consider the IP type-of-service and protocol fields to
be in this category.

I think the desire should be to specify a tool so that it provides as
much information as possible (without "external" knowledge of the
implementation details of particular components in the system).  The
information gained by resetting the TTL is variations over time in "x"
on the way back (where "x" is hops or seconds or some combination);
one learns nothing about the way out.  The information gained by not
resetting the TTL is both variations in "x", summed over out and back
AND, since you specified the original TTL, the absolute amount by which
"x" changed (out and back).  Resetting gives one-way second-order
information while the not resetting it gives two-way first and second
order information.  The question is, if we can only have one, which is
more generally useful?

Charlie