Vadim Antonov <> Wed, 12 January 1994 23:49 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa16933; 12 Jan 94 18:49 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16929; 12 Jan 94 18:49 EST
Received: from by CNRI.Reston.VA.US id aa21213; 12 Jan 94 18:49 EST
Received: by (5.65c/Spike-2.0) id AA24081; Wed, 12 Jan 1994 17:12:05 -0500
Precedence: bulk
Return-Path: <>
Received: from by (5.65c/Spike-2.0) id AA24065; Wed, 12 Jan 1994 17:12:03 -0500
Received: from localhost by (8.6.4/1.34) id RAA17983; Wed, 12 Jan 1994 17:13:22 -0500
Date: Wed, 12 Jan 1994 17:13:22 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Vadim Antonov <>
Message-Id: <>


>We still want a nominal time associated with it, for when a router
>hangs onto a datagram for a longer than usual time (typically waiting
>for some kind of subnetwork setup). Probably 1/10 second is good; it
>must be less than IP's (1 sec) and less than CLNP (500 msec)

>It also seems that 8 bits is really sufficient.

Not at 1/10 seconds!  The problem is that there are links which
can delay a packet for up to a minute while establishing a connection.
We'll see more and more of them with the proliferation of dial-up IP
and the real cheap 19.2Kbps modems.

[Discarding a packet which initiated the connection is also not a good
idea because it's most likely a TCP init packet which will be retransmitted
with large delays and user is already irritated :-)]

I would propose "logarithmic" time -> TTL translation; i.e.

	1/16 sec delay equals 1 hop
	1/8 sec == 2 hops
	1/4 sec == 3 hops

etc.  I'm not sure what the implications of that scheme are.