Accurate TTL calculation

I previously thought that TTL is a counter of hopes to device. Today I learned that this is not so, but is connected with the processing time of packets.

Those maximum TTL = 255, equals the maximum packet lifetime in seconds, respectively, the question itself, I can’t understand how exactly TTL is calculated in my example:

I'm pinging google.dns, ttl=59, but =hops 10, initial ttl=64,i.e. the duration of processing by all nodes of my package was about 5 seconds (Somewhere, for example, 0.4,0.6 seconds, etc.?)

``````There are 10 hops:

1| 10.0.20.1
2| x.168.129
3| x.132.123
4| x.181.89
5| 5.x.253.245
6| 108.170.250.113
7| 142.251.49.158
8| 216.239.43.20
9| 72.14.236.73
``````

TTL is a hop counter, it's not a timing mechanism.

• Okey,why ttl equal 59? Aug 10, 2023 at 10:29

Initially, TTL was supposed to be decremented by the amount of seconds that a hop (router) required to process the packet, but at least by one (see RFC 791 3.1 Internet Header Format) (emphasis mine):

Time to Live: 8 bits

This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.

Since routers very quickly processed packets in far shorter periods than one second, even in the early 1980s, each hop universally decrements the TTL field by one.

I previously thought that TTL is a counter of hopes to device.

It largely is.

Today I learned that this is not so, but is connected with the processing time of packets.

The point of TTL was/is to place an upper bound on how long a packet could be "in" the internet.

The TTL was supposed to be decremented by the processing time of the packet in seconds. However it was also required to be decremented by at least one, even if the processing time was negligible.

In practice, processing times of greater than a second are basically unheard of in the modern internet. So the TTL gets decremented by exactly 1 at each hop. IPv6 formalised this and renamed the field to "hop count"

I can’t understand how exactly TTL is calculated in my example:

The return path may not be the same as forward path. So you cannot exactly predict what the return ttl will be based on the times or number of hops you see in traceroute.

You have 10 hops including the destination, 9 excluding it, so assuming an initial ttl of 64 and assuming the return packets followed the same path as the outward packets you would expect a ttl of 55 on the replies.

If you are seeing a value larger than that (and not so much larger that it indicates a different initial ttl), it suggests that the return path involved fewer hops than the forward path.

• Great answer, now I understand the truth for myself, thank you very much! Aug 22, 2023 at 8:52