[e2e] lifetime record of a UDP packet ?

[Olav Kvittem]

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
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.

[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?

Post by Olav Kvittem
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
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
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
http://mailman.postel.org/mailman/listinfo/end2end-interest

[Matt Mathis]

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.

Post by 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?

Post by Olav Kvittem
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.

Post by Olav Kvittem
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.

Post by Olav Kvittem
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
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
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
http://mailman.postel.org/mailman/listinfo/end2end-interest

_______________________________________________
end2end-interest mailing list
http://mailman.postel.org/mailman/listinfo/end2end-interest

[Theodore V Faber]

Post by Matt Mathis
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.

I seem to recall Tim Shepard doing that as (essentially) a party trick
in the 1990's.

- --
Ted Faber <***@aero.org>
Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373

[John Day]

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

John

Post by 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?

Post by Olav Kvittem
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
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
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
http://mailman.postel.org/mailman/listinfo/end2end-interest

_______________________________________________
end2end-interest mailing list
http://mailman.postel.org/mailman/listinfo/end2end-interest

[John Day]

;-) lol

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by John Day
Shouldn’t each layer should impose an upper bound on Maximum Packet Lifetime?

They can try. Seems to me that the E2E implies it won't always work...
- --
Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJYxw5vAAoJEFNjQnOBW8uObAEP/1D5WptXevba/d907LYHcnut
u9wyafvhLCFWMsBnFXtooYGwbSYjnZ+fxmvoRz35Vd0IrV8Ehzpr9uTC+uFCDedI
Dy3V8FhsEwOjOOkZl2h2CAV54+ySJi7w3lgdHl2zoBR/QJC3B74roXXKNfiTZ/kW
QiJA0hpXGznLaxuC+cMW3KLUdV7WEIkGFUlmJ5Hor+6/YOzPu5FzTmu44eevKdP7
+v+1oUwyraNVd9rkt05kdQGIiPJ89+MjMjHsMO/Z9tIIa8tIm1uHYEoa2MUDDbu8
9jFnJRJgafZnvNue431kTInTWJPWL87LTk+qCL4nzf1TRWfcTYNB5cOu2RV2h/DA
IRYXJ1HLj0D/yCFNaK94+HDnsUJRAPliGLG4ceCYeyfncgkQTW9jQoytk05lpSTs
n24NwuPSLDaFoZQZIw0kvw5hckrjyET0NS2nHA5xemexr4IC4QmphIMp372xPL2s
Exx39Rc2WPmKcpuz5l8g8y9S4YI4LptLADuc19fTOOljV+Lc2Ar8RDqH5y8QkwSD
ErHlQpdhGK5vihaaCpqhZ2parrJEUkCub4lnNoppaKM9RR+qx4g6x39uye9PgBjt
Fa964Y/SvqQ6Jz0Z/MkqGpZgu77oUHGRjt/c4lBYFPIZy4OVBHTLvMy63dnybMzZ
r9dyNjdxQDslnS6+bOEv
=1Rrj
-----END PGP SIGNATURE-----