>> where in RFC791 can i find statement that TTL field has to be used
>> for reassembly buffer management?  i don't see any, [...]
> "Some higher level reliable connection protocols are based on
> assumptions that old duplicate datagrams will not arrive after a
> certain time elapses.  The TTL is a way for such protocols to have an
> assurance that their assumption is met."

This does not say that TTL has to be used for reassembly.  Note that it
says "arrive".  It is not unreasonable to assume that no further frags
will arrive after TTL seconds after the arrival of the first frag, but
that actually does not follow.  The actual time is the sending time
plus the original TTL, neither of which the receiving host can
determine.  Using the incoming packet's TTL plus the reception time is
a not entirely unreasonable-sounding approximation, but it can lose: if
the first fragment takes a fast path with many hops, but the second
fragment takes a slow path with few hops, an estimate based on the
first packet's TTL and arrival time will terminate reassembly
prematurely (because TTL is decremented by one per hop regardless of
time taken).

>> TTL field as the lifetime during transit (defined as "seconds" in
>> the past, used as "hop count" in reality).
> As others have stated, TTL _still_ means time to live.  Each hop
> rounds TTL up to the next second; what you observe is a special case
> for when all hops are < 1 sec, _not_ the strict definition.

Unfortunately itojun is right; many (most?) systems do not actually
implement decrementing the TTL every second they hold onto the packet.
A busy serial line can introduce well over one second of queueing
delay, but most/all systems will decrement the TTL by only one anyway.

Such systems _are_ rather severely broken; fortunately, as slow serial
lines get used less and less, they are becoming less common.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B