Re: TTL etc Thu, 13 January 1994 19:36 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa10309; 13 Jan 94 14:36 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10305; 13 Jan 94 14:36 EST
Received: from by CNRI.Reston.VA.US id aa15348; 13 Jan 94 14:36 EST
Received: by (5.65c/Spike-2.0) id AA15837; Thu, 13 Jan 1994 13:16:54 -0500
Precedence: bulk
Return-Path: <>
Received: from by (5.65c/Spike-2.0) id AA15812; Thu, 13 Jan 1994 13:16:52 -0500
Received: from by (5.65/vix-inetgw-30may91) id AA29642; Thu, 13 Jan 94 10:14:31 -0800
Received: by; id AA08272; Thu, 13 Jan 1994 13:14:29 -0500
Message-Id: <>
Subject: Re: TTL etc
In-Reply-To: Your message of "Thu, 13 Jan 94 11:12:26 EST." <>
Date: Thu, 13 Jan 94 13:14:23 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
X-Mts: smtp

Just as another note the ICMP message stating time-exceeded (or better
yet hop count exceeded which is what most of the internet uses it for
and my tcp/ip customers) eventually will permit and cause reuse of those
transport pseudo resources used by the infrastructure.  So its not like
the transport just hangs out forever without a response when the
datagrams is discarded within the network.

Maybe Rob or someone from TCPLW can help here.  But, I think the
persist timer could actually end the transport connection (via abort or
orderly release) for TCP, as one extension to not using the network
protocol or datagram as timing mechanism for delay.