Re: TTL etc

Vadim Antonov <> Thu, 13 January 1994 21:29 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa13267; 13 Jan 94 16:29 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13263; 13 Jan 94 16:29 EST
Received: from by CNRI.Reston.VA.US id aa18134; 13 Jan 94 16:29 EST
Received: by (5.65c/Spike-2.0) id AA24111; Thu, 13 Jan 1994 14:52:50 -0500
Precedence: bulk
Return-Path: <>
Received: from by (5.65c/Spike-2.0) id AA24087; Thu, 13 Jan 1994 14:52:48 -0500
Received: from localhost by (8.6.4/1.34) id OAA20446; Thu, 13 Jan 1994 14:52:46 -0500
Date: Thu, 13 Jan 1994 14:52:46 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Vadim Antonov <>
Message-Id: <>
Subject: Re: TTL etc


>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?

Transport protocols rely on the knowledge that packets will be
destroyed after some pre-defined *physical* time to generate
unique ids and detect duplicates.  Thus, some time constraints are
necessary and implementation should be obligatory.

(I would also like to propose including upper bound on link latency
in the TTL time decrement -- with satellites you can get 300 ms delay
no matter what bandwidth the link is).  Two satellite hops will yield
1200 ms of roundtrip time even on absolutely free links.

Actually, it may make sense to separate two things: hop count (used
in loop prevention) and TTL (which is the upper limit for physical
lifetime assumed by transport protocols).  On fast hop TTL may be not
decremented at all (so it's possible simply to ignore TTL on things
like FDDI or Ethernet).

Unfortunately it also means that at least 2 bytes are necessary
(6 bits for up to 63 hops and 10 bits for 102 secs max lifetime with
100 ms decrements).