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
