Re: TTL etc

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

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

Rob