Re: [LOOPS] Timestamps and delay measurements

["Zhouxingwang (Joe)" <[e-mail]>]

Hi Carsten, 

About the random VMs, some public cloud provider does not provide the synchronized time for their VMs by default, and the time difference between the VMs changes a little (found a 3750ms variation for like 40 hours roughly).
And for the cached timestamp, it will be a problem if LOOPS is implemented in high speed and memory limited device, like physical switch or router.

Thanks
Joe

-----Original Message-----
From: LOOPS [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: Thursday, October 17, 2019 3:29 AM
To: [e-mail]
Subject: [LOOPS] Timestamps and delay measurements

In the process of preparing the next version of the gen-info draft, there are a few items where it probably would be good to get wider input.

One of these is the use of timestamps.

Gen-info says that “block 1” reverse information (requested using the “ACK desirable” flag) has a wall clock time of reception of the forward packet that was triggering it.  This is a good way to measure one way latency if we believe the clocks on ingress and egress are synchronized; the quality of that synchronization limits the quality of the measurements.  The mechanism is still reasonable as a way to measure one way latency variance if we believe the clocks are maybe not synchronized, but do advance along the same time scale.

Question 1:
In your applications, would you expect to have reasonably synchronized clocks between ingress and egress?  Reasonable clocks at all?  Do you have data points, e.g., for random VMs in the cloud?

The prototype protocol described in appendix A uses a different form of timestamps: timestamps on a local timescale of the ingress (not further specified by the protocol) can be inserted by the ingress and are echoed back in ACKs.  (No information about time at egress is used.)  This can be used to cheaply obtain samples of round-trip time, including delays in sending back the ACK.  The timestamp is not strictly necessary if there is another correlation mechanism, as the timestamp can be stored at the ingress and retrieved if an ACK comes back.  This has two drawbacks:  (1) The timestamp needs to be stored with the cached packet, which may or may not be easy in a specific implementation, and (2) the correlation afforded by a packet sequence number has ACK ambiguity if the PSN is re-used in a retransmission (see the other message).

Question 2:
In your implementations, is it onerous to store a transmission timestamp with a cached (for retransmission) packet on the ingress?

The assumption of gen-info is that it is good to have samples of one-way delay in order to assess congestion, and that some measurement of round-trip delay is needed as an overall timing of retransmission and for ejecting cached packets.  Anything else you would expect LOOPS to measure in the way of timing?

Grüße, Carsten

-- 
LOOPS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/loops