IETF Logo Mail Archive

Re: TTL etc

bound@zk3.dec.com Thu, 13 January 1994 19:36 UTC

Received: from ietf.nri.reston.va.us 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 world.std.com by CNRI.Reston.VA.US id aa15348; 13 Jan 94 14:36 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA15837; Thu, 13 Jan 1994 13:16:54 -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: <bound@zk3.dec.com>
Received: from inet-gw-1.pa.dec.com by world.std.com (5.65c/Spike-2.0) id AA15812; Thu, 13 Jan 1994 13:16:52 -0500
Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/vix-inetgw-30may91) id AA29642; Thu, 13 Jan 94 10:14:31 -0800
Received: by xirtlu.zk3.dec.com; id AA08272; Thu, 13 Jan 1994 13:14:29 -0500
Message-Id: <9401131814.AA08272@xirtlu.zk3.dec.com>
To: catnip@world.std.com
Subject: Re: TTL etc
In-Reply-To: Your message of "Thu, 13 Jan 94 11:12:26 EST." <9401131612.AA01474@xirtlu.zk3.dec.com>
Date: Thu, 13 Jan 1994 13:14:23 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: bound@zk3.dec.com
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.

/jim

v2.23.0 | Report a Bug | By Email