From martin.stiemerling at h-da.de Fri Mar 3 13:27:54 2017 From: martin.stiemerling at h-da.de (Stiemerling, Martin, Prof. Dr.) Date: Fri, 3 Mar 2017 21:27:54 +0000 Subject: [e2e] Call for participation: 20th International Conference on Networked Systems (NetSys 2017) Message-ID: Call for participation: 20th International Conference on Networked Systems (NetSys 2017) March 13 - 16, 2017, Goettingen, Germany http://netsys17.uni-goettingen.de/ The 20th Biennial Conference on Networked Systems (NetSys 2017) provides an international forum for engineers and scientists in academia, industry, and government to discuss recent innovations in the realm of networked systems ? including aspects of networking, distributed systems, communications, middleware, and applications. It is sponsored by German Computer Science society (Gesellschaft f?r Informatik (GI)) and the Information Technology society (Informationstechnische Gesellschaft im VDE (ITG)), technically co-sponsored by IEEE Communications Society (ComSoc) and in cooperation with ACM SIGCOMM. The conference program features 18 technical papers, 13 posters (PhD forum), 7 demos, 2 tutorials, 2 workshops (SDNFlex, SIREMTI), a funding opportunities session and a panel. See detailed schedule in http://netsys17.uni-goettingen.de/?page_id=768 Three keynote speakers are: Henning Schulzrinne (Columbia University, USA), Wieland Holfelder (Google Germany GmbH, Germany), Rolf Stadler (KTH ? Royal Institute of Technology, Sweden) Welcome to join us in Goettingen! Martin Stiemerling, NetSys'17 Publicity Co-Chair From olav.kvittem at uninett.no Mon Mar 13 07:18:25 2017 From: olav.kvittem at uninett.no (Olav Kvittem) Date: Mon, 13 Mar 2017 15:18:25 +0100 Subject: [e2e] lifetime record of a UDP packet ? Message-ID: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> 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. From jon.crowcroft at cl.cam.ac.uk Mon Mar 13 08:19:36 2017 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 13 Mar 2017 15:19:36 +0000 Subject: [e2e] lifetime record of a UDP packet ? In-Reply-To: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> References: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> Message-ID: 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 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. > From mattmathis at google.com Mon Mar 13 12:15:10 2017 From: mattmathis at google.com (Matt Mathis) Date: Mon, 13 Mar 2017 12:15:10 -0700 Subject: [e2e] lifetime record of a UDP packet ? In-Reply-To: References: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> Message-ID: 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 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 > 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. > From theodore.v.faber at aero.org Mon Mar 13 12:53:31 2017 From: theodore.v.faber at aero.org (Theodore V Faber) Date: Mon, 13 Mar 2017 19:53:31 +0000 Subject: [e2e] lifetime record of a UDP packet ? References: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/13/2017 12:48 PM, Matt Mathis wrote: > 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 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/ iQIcBAEBCgAGBQJYxvi6AAoJEFNjQnOBW8uOBqkP/j5PixeVnpo4uAg5QGWwCxck YUcoOAdBrHdVyh2af619QKT/0f3WTyx1SzZViyy+Wv5lKT81f+Zt3UCYiQ98FRcN gcZVk8Z/AMPt7tq4jpxknB/od8cpNDrZNlk+VDpMP3fV1ivrMLsZbz0wkvXic315 1xOSA4HXTMhiJ8FEesiTlnrRsY4vFLZWSmj5d37BxZgto2vbbu2V0mz7iiXJSOvr bGgYojS7csDfN1cCJZicPkgBXaFxAQDdPO6hXjbteaKJ6GnjEqFTE2+v0oQjUyEX BrnC6N96E5E6djpdx77VBpFHsmb8Euih/2HzfOxeohU51TEHL0c+u8eMDc2+zXys szK3ZCACpf8/sDK0t1+Xz8JKpFLi2D2Iq89l2piEwPL7WNcvUQwo0Yn/PNVXFxSH qiAmnZ+wUsSVpLoJiPF2QzupCq4dI+rL1txG4VsCiyFj2ZOun3T2EM8asE8uG+Pq 9pJFEVH/xgAAO6v6f4wT8qJveOVbgidBTcN5PITY+AkRQ/Z+3pfAL/DtOxXh6mvf +bOzVJcQ06AkkRmFZzoC34k/HY1OdHCcRy1IdVyNJ4OJrdnqDJCSueceWgQJpHpe 3xfz4zAzHxqzWTZKme0wbwws4e1+Ka0zqW5EF77jl9WYYxNtB9vKH2XvsXSr83gw Lu60Iy2pHaeHsjeRz5w7 =1aYK -----END PGP SIGNATURE----- From jeanjour at comcast.net Mon Mar 13 13:28:18 2017 From: jeanjour at comcast.net (John Day) Date: Mon, 13 Mar 2017 16:28:18 -0400 Subject: [e2e] lifetime record of a UDP packet ? In-Reply-To: References: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> Message-ID: Shouldn?t each layer should impose an upper bound on Maximum Packet Lifetime? John > On Mar 13, 2017, at 11:19, Jon Crowcroft 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 > 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. From theodore.v.faber at aero.org Mon Mar 13 14:26:08 2017 From: theodore.v.faber at aero.org (Theodore V Faber) Date: Mon, 13 Mar 2017 21:26:08 +0000 Subject: [e2e] lifetime record of a UDP packet ? References: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/13/2017 02:21 PM, John Day wrote: > 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... - -- Ted Faber 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----- From jeanjour at comcast.net Mon Mar 13 14:30:36 2017 From: jeanjour at comcast.net (John Day) Date: Mon, 13 Mar 2017 17:30:36 -0400 Subject: [e2e] lifetime record of a UDP packet ? In-Reply-To: References: <0d0ad633-ef73-afa7-9c43-16ae6d278158@uninett.no> Message-ID: <28F54608-BB80-470C-B742-6921F462572F@comcast.net> ;-) lol > On Mar 13, 2017, at 17:26, Theodore V Faber wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03/13/2017 02:21 PM, John Day wrote: >> 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... > > - -- > Ted Faber > 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-----