Hi,


I took the liberty of setting up a couple of measurements using 6 of the probes you used, but with a starting hop of '1' so I could see the paths taken.


TCP: https://atlas.ripe.net/measurements/28919237/#probes

ICMP: https://atlas.ripe.net/measurements/28919338/#probes


None of the probes receive a response over ICMP (this is not uncommon), and five of the probes receive a response over TCP. Be aware that the UI will report the RTT for the last responsive hop in either case, *whether it's the target or not*. The actual result data reveals a more.


In the case of probe 17832, it doesn't reach the target in either case above; the low RTT is the last responsive hop very close to the probe.


17875 and 27091 take more reasonable paths over ICMP to the target, but over TCP appear to receive a response from the target at the second hop. In terms of what's handling that traffic, I don't know, but with latencies so low it's not very far upstream at all.


S.




On 27/01/2021 14:41, Hank Nussbacher wrote:

I found this presentation:
https://www.ripe.net/support/training/ripe-ncc-educa/presentations/measuring-reachability-of-your-web-server-using-ripe-atlas.pdf
 
I ran a test from 40 Israeli probes to see if there are any issues accessing zoom.us:
https://atlas.ripe.net/measurements/28912347/#probes [1st run]
https://atlas.ripe.net/measurements/28912916/#probes [2nd run]


It shows all in Israel getting to Zoom.us with an average of 150ms.
But 3 sites –  show under 1ms response time – as if they run some local proxy.   I checked with them and they said they have nothing local.

So how come probe 17832 gets .869ms and probe 17875 gets .610ms and probe 27091 gets .718ms to zoom.us?


Thanks,

Hank