Back when I was wearing a network admin hat, about ten to fifteen years ago, one question I tried answering was how to determine the time it took a network packet to travel one way. The ping command measures the round trip time:
[spc]lucy:~>ping -c 5 brevard.conman.org PING brevard.conman.org (66.252.224.242) 56(84) bytes of data. 64 bytes from brevard.conman.org (66.252.224.242): icmp_seq=0 ttl=49 time=26.7 ms 64 bytes from brevard.conman.org (66.252.224.242): icmp_seq=1 ttl=49 time=26.1 ms 64 bytes from brevard.conman.org (66.252.224.242): icmp_seq=2 ttl=49 time=26.9 ms 64 bytes from brevard.conman.org (66.252.224.242): icmp_seq=3 ttl=49 time=27.0 ms 64 bytes from brevard.conman.org (66.252.224.242): icmp_seq=4 ttl=49 time=27.1 ms --- brevard.conman.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 26.163/26.832/27.161/0.362 ms, pipe 2 [spc]lucy:~>
So, can one assume that the one way time is a bit over 13ms? Not really, because asymetric routing—where the path to a remote destination does not match the path from said remote destination—does exist. I've seen it happen several times while wearing my network admin hat. Yes, you can attempt to synchronize the clocks on the two systems—it's not easy [1], but it is possible if you work hard to achieve it. Over time, I found it easier to just use the round trip time as reported by ping and assume the path is symetrical.
I was reminded of that when I watched “Why no one has measured the speed of light [2].” It never occured to me that scientists haven't actually measured the speed of light at 299,792,458 meters per second, but used the round trip time to calculate it and just assume the timing is symetrical because it's impossible to synchronize clocks between two sites (for the purpose of measuring the speed of light). Kind of mind blowing if you ask me.
[1] https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/