Re: TTL etc Thu, 13 January 1994 17:33 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa08287; 13 Jan 94 12:33 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08283; 13 Jan 94 12:33 EST
Received: from by CNRI.Reston.VA.US id aa12583; 13 Jan 94 12:33 EST
Received: by (5.65c/Spike-2.0) id AA06262; Thu, 13 Jan 1994 11:31:01 -0500
Precedence: bulk
Return-Path: <>
Received: from by (5.65c/Spike-2.0) id AA06234; Thu, 13 Jan 1994 11:30:58 -0500
Received: from by (5.65/vix-inetgw-30may91) id AA22538; Thu, 13 Jan 94 08:12:34 -0800
Received: by; id AA01474; Thu, 13 Jan 1994 11:12:32 -0500
Message-Id: <>
Subject: Re: TTL etc
In-Reply-To: Your message of "Wed, 12 Jan 94 22:40:33 EST." <>
Date: Thu, 13 Jan 94 11:12:26 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
X-Mts: smtp


Yeah the overload is a pain.  I think if we head towards making the
network layer datagram functionality become focused on assisting routing
infrastructure and less a function as an overload operation also for the
transport we would be doing the future world of networking a service.

Your idea of hop decrements based on some nominal time is a great idea.
It might be good to have an option to not implement the nominal time if
for some reason time was not the issue but just delivery?