TTL etc

[Robert L Ullmann <[e-mail]>]

 
Hi,

note that the TTL in IP has two functions overloaded onto it. One is
the hop count, used (primarily) to cause eventual datagram discard in
the case of a network layer loop.

The other is to allow an expectation by transport layers (e.g. the TCP)
that datagrams won't get delivered many minutes or 10's of minutes after
being sent. The TCP ISN and sequence space have a direct dependency on
this service of the network layer. While it is possible for a transport
to take direct responsibility for part of this (compare TCPLW PAWS), it
isn't easy to do it in every case (just consider a SYN delivered 10 or
15 minutes late.)

The nominal 1 second of IP (version 4) has proven to work well. I stated
in previous mail that the CATNIP nominal had to be less than the CLNP
(500 msec), but is this really true? Is it going to cause problems if
a CLNP datagram sent with TTL of (say) 150 were to actually last longer
than 75 seconds? If it got delivered 90 seconds after it was sent?

(In reality, this happens now; few implemtations actually do the required
decrement by-real-time on call setups such as that described by Vadim. Yet
the network continues to work ... :-)

Perhaps it should be a hop count, but any system holding a datagram
pending subnetwork setup taking more than about 2 seconds should count
it down at at least one "hop" per second? After all, it can easily traverse
real network links that take 1 second/hop without ever being held. (think
about a 1500 byte datagram being sent via a series of 9600bps links, at
about 1.6 seconds real time per link. Vadim's 19.2 links are going to
take 800 msecs for such datagrams, not likely to be accounted for by
either endpoint.)

Rob