Virtual Synchronization

Overview

The advantage of the Virtual Synchronization method is that one Sender device may measure towards hundreds or thousands of Responders without needing to provide a common synchronization source between them. Compared to NTP or PTP, the large number of samples used also adds robustness to the method.

Having a vendor-agnostic inline synchronization method that seamlessly interacts with unmodified third-party implementations of RFC 5357 TWAMP or Y.1731 ETH-DM gives the user access to an easy-to-use and powerful one-way network KPI and SLA monitoring tool. With integrated result storage and reporting, the Skylight product suite delivers a comprehensive solution for securing end-to-end performance in any modern network.

Importance of One-Way KPIs

Keeping track of one-way Key Performance Indicators (KPIs) such as packet loss, delay, jitter, and delay variation is important in today’s complex networks because changes or deviations that affect the path in only one direction will not be seen in their full extent with a roundtrip measurement method.

Consider a temporary delay increase from 20 to 60 ms in a roundtrip measurement. It cannot be determined whether this delay spike was caused by a dramatic increase from 10 to 50 ms in one direction, or a more modest increase from 10 to 30 ms on both paths.

An application that relies on one-way KPIs, such as Voice over IP or backhaul synchronization, will be impacted differently depending on whether packet loss or delay variation are concentrated to one direction as opposed to being present in both directions.

How to Measure One-Way Delay

To measure delay in only one direction for a transmitted measurement packet, there must be a distributed and common concept of time at the sending and receiving ends. To achieve this, the following methods are available:

• Use GPS as external clock source at both ends.
• Use a packet-based synchronization method from a common time reference (NTP or PTP).
• Use one end as an NTP server or PTP master for the other end.

Figure 1: GPS Common Time Source

Because both ends agree on the same time, it is easy for the receiving side to simply subtract the received timestamp from the transmitted timestamp to calculate the one-way delay.

The Virtual Synchronization method is reminiscent of packet-based synchronization methods and can, in a simplified way, be explained as a High-Resolution NTP or PTP synchronization method.

The next section gives an overview of these packet-based synchronization methods for better understanding of Virtual Synchronization.

NTP and PTP Synchronization Methods

Differences and Similarities Between NTP and PTP

Both the NTP and PTP protocols are based on packet exchanges between a Client and a Server (NTP) or a Slave and a Master (PTP). Fundamentally, the two protocols are quite similar. With NTP, for instance, the Client periodically sends UDP packets towards the Server to fetch the current date and time.

The difference between the two methods lies in how frequently these packets are sent. PTP packets can be more transparently forwarded in the network devices along the synchronization path (if the devices support PTP). With a generally higher frequency of packet exchange, PTP is considered more accurate than NTP due to the larger quantity of samples to select from when adjusting the clock.

A high-resolution NTP client, like the one available in the Skylight elements, provides an even higher packet rate than PTP and is, therefore, considered to have comparable accuracy.

Packet-Based Synchronization in Practice

This is not intended to cover all internals of the NTP or PTP protocols, but rather gives insight into what components and methods are used and how they provide a PM system with the needed clock information to achieve one-way delay metrics.

A PTP Master or NTP Server usually relies on an accurate clock to provide solid time-of-day timestamps. If no Atomic clock or similar is available, GPS might be used at the server side.

With NTP, for example, the clients in a packet synchronization system periodically ask the server what time it is and update their internal clock accordingly. This makes the Sender and Receiver use the same time-of-day and the delay can be calculated at the receiving end by subtracting the received and transmitted timestamps.

Figure 2: Packet-Based Common Time Source

Inline Packet-Based Synchronization

The same method can also be used in line if one of the PM devices acts as an NTP client or PTP slave. In this scenario, one usually elects to place the synchronization packets in the highest Class of Service (CoS) available to achieve the best possible result. Conceptually, it does not matter which side synchronizes towards the other. As long as they use the same time reference, the delay can be calculated at the receiving end by subtracting the received and transmitted timestamps.

Figure 3: Packet-Based Inline Synchronization

All packet-based synchronization methods are based on one assumption: the forward and reverse paths between the endpoints are symmetric in terms of latency. For example, if there is a fixed asymmetry caused by having a 1 Gbps link in one direction and a 100 Mbps link in the other, the time-of-day at the receiving end will carry a static offset error. This error is equal to the difference in latency between the two endpoints.

For example, the minimum delay for a 128-byte packet (NTP maximum size) to traverse a 1 Gbps link is about 1 µs, whereas on a 100 Mbps link, it is 10 times longer, around 10 µs. The NTP/PTP offset error in this case would be 4.95 µs.

Adding a router that would introduce a 1-ms symmetric overhead does not cause any change to the absolute offset error. So, from a performance monitoring and latency measurement standpoint, it reduces the percentage or error.

If the asymmetry is fixed and known, it is possible to compensate it when interpreting the measurement results. It is important to know that it is only the baseline, or static offset, that is affected by the asymmetry. Any delay variation during measurement will indicate the actual one-way variation. Delay Max - Delay Min for any given interval will give an accurate measurement of how large the delay variation was during the interval.

Virtual Synchronization

Virtual Synchronization (vSync) is a patented clock extraction algorithm similar in operation to the inline NTP and PTP synchronization methods. However, it is different in several important aspects:

• A selected PM session is used to carry the synchronization information.
• Due to the high packet transmit frequency (10 PPS or more), there is a gain in accuracy.
• There is no adjustment of either the remote or local clock.
• The Sender device (sensor control) keeps a Virtual Remote Clock for each Responder​.
• Dual one-way session types are used: TWAMP or ETH-DM.
• Dual one-way sessions are standard PM sessions that use four timestamps, two for each direction: T1 and T2 for Sender->Responder direction and T3 and T4 for the return path.
• The Responders are any standard RFC 5357 TWAMP or ITU-T Y.1731 ETH-DM third-party devices that employ hardware-assisted timestamping for PM packets.

vSync Operation

Figure 4: vSync

Comparing Figure 4 with Figure 3, one can see that the Responder acts like an NTP server (or PTP master) and the Sender has an NTP client (or PTP slave) for each Responder it communicates with. Since the Sender device may talk to several Responders, which most likely have different clocks, it cannot adjust its own time-of-day from what is seen from this Responder acting as a pseudo NTP Server/PTP Master. Instead, a Virtual Clock is kept for each unique remote Responder device that, which is used when interpreting the PM session timestamps to present the one-way KPI metrics.

As with all packet-based synchronization methods, this method will experience a fixed offset error if the synchronization line is traversing a network with asymmetric delay. For end-to-end measurements over multi-hop layer-3 networks where one-way latencies of tens of milliseconds are common, this asymmetry can in many cases be neglected, removing the need to compensate in retrospect. The variations to measure, usually caused by buffering in the network devices, will be accurately presented and are usually a few orders of magnitude larger than the comparatively small error caused by the network asymmetry.