Re: lifetime record of a UDP packet ?

The old FDDI interfaces would do this too.  I once unplugged a cable, went
to lunch and then captured the ~hour old packet, just to prove a point (I
think this was in about 1990).  I bet the actual record matches the time to
repair for some optical device...

Since you can construct any number that you have the patience for, it isn't
really a very interesting record.   "Accidentally captured in a production
network" is a bit interesting.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Mon, Mar 13, 2017 at 8:19 AM, Jon Crowcroft <[email protected]>
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 <[email protected]>
> 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
> > [email protected]
> > http://mailman.postel.org/mailman/listinfo/end2end-interest
> > Contact [email protected] for assistance.
> >
> _______________________________________________
> end2end-interest mailing list
> [email protected]
> http://mailman.postel.org/mailman/listinfo/end2end-interest
> Contact [email protected] for assistance.
>
_______________________________________________
end2end-interest mailing list
[email protected]
http://mailman.postel.org/mailman/listinfo/end2end-interest
Contact [email protected] for assistance.