Re: TTL etc

Robert L Ullmann <> Fri, 14 January 1994 01:36 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa16218; 13 Jan 94 20:36 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16214; 13 Jan 94 20:36 EST
Received: from by CNRI.Reston.VA.US id aa22952; 13 Jan 94 20:36 EST
Received: by (5.65c/Spike-2.0) id AA02566; Thu, 13 Jan 1994 19:17:13 -0500
Precedence: bulk
Return-Path: <ariel>
Received: by (5.65c/Spike-2.0) id AA02556; Thu, 13 Jan 1994 19:17:11 -0500
Date: Thu, 13 Jan 1994 19:17:11 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert L Ullmann <>
Message-Id: <>
Subject: Re: TTL etc

Hi Jim,

Certianly it should be solved be the transport. The transport needs
*some* guarantee from the network layer(*) as part of its solution.
To generalize, the transport layer PDU must carry enough state that
the state is not repeated within the network layer's maximum delay.

(* the transport could use full timestamps, in whihc case a promise
of not delivering datagrams a few millenia later would be sufficient.
Somewhere in here there is a trade-off :-)

I said "denial-of-service" incorrectly in a previous message; you can
of course actually corrupt the data in transit, but not predictably,
so it is likely only to cause an application failure (seen in effect
as a denial of service.)

Suppose we say that if a datagram is held, and/or has transmission
delay exceeding 250 msec, that the TTL is decremented by 1+t, where
t is the time is seconds rounded *up* to an integer. That will turn
most of the extra delays into counts, while still having a range that
is nominally 4 minutes.

This seems to meet Vadim's objectives, while still meeting the intent
of the 500 msec nominal value in CLNP.

Note that the common implementation of traceroute is fairly slow and
inefficient. An implmentation that sends out tests over a range of
TTLs all at once and collates the results runs much faster :-) You
use a few cute tricks to ID the returns of course ...