Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!A.BBN.COM!CLYNN
From: CLYNN@A.BBN.COM
Newsgroups: mod.protocols.tcp-ip
Subject: Re: time-to-live
Message-ID: <[A.BBN.COM]29-May-86.09:56:39.CLYNN>
Date: Thu, 29-May-86 09:56:00 EDT
Article-I.D.: <[A.BBN.COM]29-May-86.09:56:39.CLYNN>
Posted: Thu May 29 09:56:00 1986
Date-Received: Sat, 31-May-86 03:20:49 EDT
References: <86.05.29.0248.690@su-pescadero.arpa>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 16
Approved: tcp-ip@sri-nic.arpa

Steve,
	The TOPS-20 IP implementation does decrement the Time-to-live
field by more than one if the packet has been queued for more than a
second.  Note however, that this doesn't really apply to the major
source of output-queue delay which is in the layer(s) below IP.  The
timeout for received fragments is set from the time-to-live field, but
any additional fragment which is received will reset the timeout to
allow fragments from different retransmissions to be combined.

	The TOPS20 always decrements the Time-to-live, even when it is
the originating or receiving host (since the systems support multiple
network interfaces and will typically forward packets, route loops could
theoretically occur).  When a packet is received with a Time-to-live
of 1, the packet will be delivered to the higher layers, but not forwarded.

Charles Lynn