July 2019 - ripe-atlas - mailman.ripe.net

Meta-information dumps for built-in measurements?
by Vasileios Giotsas 09 Nov '20

09 Nov '20

Is there any repository like https://ftp.ripe.net/ripe/atlas/measurements/ that contains meta-information about built-in RIPE Atlas measurements (the above repository contains meta-information only for public measurements)? I couldn't find anything similar in the new FTP repository at https://data-store.ripe.net/datasets/atlas-daily-dumps/ I guess using the API is an alternative but it would be more convenient to have such dumps Thanks, Vasileios

15 24

Feature Request to consider: DNS response IP header
by Jen Linkova 22 Jul '19

22 Jul '19

Hello, I have a number of use cases when it would be very useful to have access to the IP header of the measurement response packets. In my scenario I'd like to see TTL/Hop Limit of packets received in DNS measurements. So I'm curious if anyone else think it would be a useful feature and if there is some demand for such a feature - maybe the Atlas team could consider implementing it? Thanks! -- SY, Jen Linkova aka Furry

4 4

Question about built-in first/second hop latency measurements
by Joel Sommers 22 Jul '19

22 Jul '19

Hello all, For the built-in latency measurements to first/second hops, my assumption has pretty much always been that these are done with hop-limited probes (i.e., with TTL or hop limit set to 1 or 2). Is that true, or are these measurements taken using “direct” pings? Thanks! Joel

2 1

Scheduled work on RIPE Atlas
by Robert Kisteleki 18 Jul '19

18 Jul '19

Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local time. We expect complete unavailability of the service for a short while and further intermittent delays during the day. During this time the website (UI and APIs) will not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them will be impacted. Our apologies for the inconvenience. Regards, Robert Kisteleki

3 4

Re: [atlas] how to earn credits com236.294.813
by kiran.gunana＠colruytgroup.com 11 Jul '19

11 Jul '19

Hello Johan, My probe ID is 32256, It is registered and reachable from last 3 weeks, can you please check if I still need to do something to earn my credits. rg, kiran. ----- Original Message: com236.291.250 --------------------------------- From: Johan ter Beest (jterbeest(a)ripe.net) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] how to earn credits com236.259.148 Date: 11 July 2019 (12:07) Hi Kiran, You earn credits for the uptime of a probe and the delivered results for measurements that other hosts run towards your probe. Everything is explained here: https://atlas.ripe.net/docs/credits/ If your probe is not earning you any credits then there are two possible reasons: - your probe is not connected - you have not registered your probe so we don’t know who to give the credits to. I don’t know your probe ID so I. Cannot check but it’s most likely that it’s not registered. You can do that here: https://atlas.ripe.net/register/ If you send me a private email with your probe ID, I will give you the credits you should have earned in the last three weeks. Kind regards, Johan ter Beest RIPE Atlas. Team On 11 Jul 2019, at 09:10, kiran.gunana(a)colruytgroup.com wrote: Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia(a)gmail.com) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM <kiran.gunana(a)colruytgroup.com> wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

1 0

Re: [atlas] how to earn credits com236.259.148
by kiran.gunana＠colruytgroup.com 11 Jul '19

11 Jul '19

Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia(a)gmail.com) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM <kiran.gunana(a)colruytgroup.com> wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

3 2

how to earn credits com236.252.126
by kiran.gunana＠colruytgroup.com 11 Jul '19

11 Jul '19

Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

2 1

Re: [atlas] DNS RTT over TCP: twice as long than UDP?
by Ponikierski, Grzegorz 11 Jul '19

11 Jul '19

Just to confirm I verified what exactly dig measures. For example, this dig takes 8ms (which is always rounded): [gponikie@krk-mptoy atlas_day68_step1]$ dig +tcp example.com @1.1.1.1 ; <<>> DiG 9.14.3 <<>> +tcp example.com @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14416 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 5212 IN A 93.184.216.34 ;; Query time: 8 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Tue Jul 09 13:17:55 CEST 2019 ;; MSG SIZE rcvd: 56 If you check it with wireshark it looks like this: No. Time Source Destination Protocol Length Window size value Shift count Info 1 13:17:55.014898 192.168.1.83 1.1.1.1 TCP 78 65535 6 53593 → 53 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=676915370 TSecr=0 SACK_PERM=1 2 13:17:55.029784 1.1.1.1 192.168.1.83 TCP 74 29200 10 53 → 53593 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1412 SACK_PERM=1 WS=1024 3 13:17:55.029883 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [ACK] Seq=1 Ack=1 Win=262144 Len=0 4 13:17:55.030041 192.168.1.83 1.1.1.1 DNS 108 4096 Standard query 0x3850 A example.com OPT 5 13:17:55.038351 1.1.1.1 192.168.1.83 TCP 68 29 53 → 53593 [ACK] Seq=1 Ack=55 Win=29696 Len=0 6 13:17:55.038572 1.1.1.1 192.168.1.83 DNS 120 29 Standard query response 0x3850 A example.com A 93.184.216.34 OPT 7 13:17:55.038624 192.168.1.83 1.1.1.1 TCP 54 4095 53593 → 53 [ACK] Seq=55 Ack=59 Win=262080 Len=0 8 13:17:55.039580 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [FIN, ACK] Seq=55 Ack=59 Win=262144 Len=0 9 13:17:55.047201 1.1.1.1 192.168.1.83 TCP 68 29 53 → 53593 [FIN, ACK] Seq=59 Ack=56 Win=29696 Len=0 10 13:17:55.047273 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [ACK] Seq=56 Ack=60 Win=262144 Len=0 From this traffic looks like dig measures time between packets 4 (DNS query) and 6 (DNS response) which is precisely 8.5ms and matches what dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is expected . RTT can be measured on different layers for the same communication stream. In case of DNS over UDP we just ignores UDP overhead because it doesn't add any packets. With TCP additional packets are added which significantly increase time that end-user have to wait from first packet to get information that he/she needs. IMO RTT should always be measured from 1st packet to packet which has information that you have actual data. If we want to measure raw DNS performance without overhead then it must be explicitly market it measurement description. Regards, Grzegorz From: Giovane Moura <giovane.moura(a)sidn.nl> Date: Friday 2019-07-05 at 14:34 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] DNS RTT over TCP: twice as long than UDP? Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time

2 2

New on RIPE Labs: Internet Tools BoF Discovers Common Challenges for Network Operators
by Michela Galante 09 Jul '19

09 Jul '19

Dear colleagues, Here is a great summary provided by Sofia Silva Berenguer (APNIC) of the outcomes of the Internet Tools BoF organised at the recent LACNIC 31 meeting: https://labs.ripe.net/Members/sofia_silva_berenguer/internet-tools-bof-disc… Kind regards, Michela Galante RIPE NCC

1 0

DNS RTT over TCP: twice as long than UDP?
by Giovane Moura 05 Jul '19

05 Jul '19

Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time

3 2