[e2e] lifetime record of a UDP packet ?

[Jon Crowcroft]

cool - nearest i recall was a bug in SIMPs which lost buffers and they had
a sort of inverse garbage collector that ran every 18 seconds (I think)
which looked at the heap of unallocated stuff and decided if things had got
there that shouldn't be and put them back in the right
thread/task/processes' pool, so every now and then, instead of taking
.72sec RTT (geo-synch orbit satellite up and down and up and down), took
nearly 19 seconds....

purist might say the TTL should have been decremented 18, but a meta-purist
might say "ah, but a SIMP isn't an IP router, so its layer 2 only", and a
post MPLS Person (20 years too late) would argue layer 2 devices should
decrement TTL too, to prevent loops and to bound the max seg lifetime in
the net so TCPs duplicate detection still operates correctly etc etc

i suppose this was around 1981?

On Mon, Mar 13, 2017 at 2:18 PM, Olav Kvittem <olav.kvittem at uninett.no>
wrote:

> Hi,
>
> Not very serious - just for old-timer entertainment ;-)
>
> I was doing a UDP   measurement stream with timestamped and sequence
> marked packets.
>
> On analyzing the stream I found a packet arriving 6737 seconds late -
> i.e. 1 hour 52 minutes.
>
> Is that oldest packet seen on The Internet or not ?-)
>
> Did it beat the trip time of the IP over Avian Carriers experiment ?-).
>
> I had naively set my reordering window to 10 seconds..
>
>
> It turned out that there was maintenance on an optical link on the path,
> so the link was taken down
>
> at the exact time of this event.
>
> Rerouting happened in about 50ms of the link going down and that was fine.
>
>
> So where did the packet spend the time ?
>
> An explanation might be that the packet was residing  in an output
> buffer in the router in front of the  link
>
> until it was up again and then sent on the link!
>
>
> I rule out local clock errors on the measurement devices, as these are
> NTP-controlled Linux systems and that it also happened to an
>
> independent pair of measurement nodes thorough the same router.
>
>
> So this looks like a router bug to me - ref RFC 1918 below.
>
> Accordingly the maximum lifetime with initial TTL 64 should be 64 seconds.
>
> I would guess that the router should be flushing the queue at some point
> during the event.
>
> However the router is old and out of support so we are not reporting it.
>
>
> best regards
>
>   Olav Kvittem
>
>
> >From the Rude/Crude log :
>
> ID=2 SEQ=1087254 SRC=129.242.2.140:3002 DST=158.39.3.57:10001
> Tx=1488765681.242718 Rx=1488765681.254802 SIZE=64
> ID=2 SEQ=413544 SRC=129.242.2.140:3002 DST=158.39.3.57:10001
> Tx=1488758944.142720 Rx=1488765681.260987 SIZE=64
> ID=2 SEQ=1087255 SRC=129.242.2.140:3002 DST=158.39.3.57:10001
> Tx=1488765681.252718 Rx=1488765681.264785 SIZE=64
>
> Tx, RX is Unix time for transmit and receive respectively
>
>
> RFC 1918 :
>
> 5.3.1 Time to Live (TTL)
>
>    The Time-to-Live (TTL) field of the IP header is defined to be a
>    timer limiting the lifetime of a datagram.  It is an 8-bit field and
>    the units are seconds.  Each router (or other module) that handles a
>    packet MUST decrement the TTL by at least one, even if the elapsed
>    time was much less than a second.  Since this is very often the case,
>    the TTL is effectively a hop count limit on how far a datagram can
>    propagate through the Internet.
>
> _______________________________________________
> end2end-interest mailing list
> end2end-interest at postel.org
> http://mailman.postel.org/mailman/listinfo/end2end-interest
> Contact list-owner at postel.org for assistance.
>