t rather the variability in this time. Reducing asymmetry for PTP messages passing through an unaware node is also not easy. As with PDV, the straightforward answer to limit asymmetry is to configure the transit node as a PTP-aware clock (TC or BC) wherever possible. Consider the following points about asymmetry in an unaware transit node: Queuing in an unaware node can cause asymmetry, especially when the amount and length of queuing varies based on the direction that the data is travelling (which is usually the case). If the PTP messages between master and slave are delayed more in one direction than the other, then that is asymmetry. Routing can cause asymmetry because routing protocols can calculate a different path for traffic in the upstream direction than that for the downstream traffic. This is especially the case in rings, where a slave clock can have two paths to the same GM, but with very different charac- teristics (the number of hops, for instance). Swapping between those two paths can also play havoc with the recovered timing signal. Traffic patterns and behavior can also cause asymmetry. If the PTP messages encounter a heav- ily congested traffic stream in one direction, and yet flow relatively unaffected in the other dir- ection, that is also asymmetry. Because the traffic flows are constantly changing, this form of asymmetry is dynamic and cannot be compensated for. The type and design of the network element itself can cause asymmetry. Some devices suffer from asymmetry internally because reducing it was not a design goal. This arises in devices that feature design choices such as oversubscription, whereby the device (usually for cost reasons) has internal bottlenecks in the packet processing path. For example, some nodes have asym- metry in the path in the direction of the user-network interface (UNI) to network-network inter- face (NNI) compared to the NNI-UNI direction. Using PTP over bundles or aggregated links can also introduce asymmetry. This technology of forming multiple physical interfa