[e2e] lifetime record of a UDP packet ?

[John Day]

Shouldn’t each layer should impose an upper bound on Maximum Packet Lifetime?

John

> On Mar 13, 2017, at 11:19, Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> wrote:
> 
> 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.
>> 
> _______________________________________________
> 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.