g the time that the message was timestamped. What it does not know is the amount of time that elapsed from when the message was timestamped until it was received, mean- ing how long it took for the message to travel the intervening path (the transit time). To figure out that transit time, the slave receives timestamps from the master in order to calculate the round-trip time (much like the two-way delay measurement [2DM] introduced in "Chapter 2. Usage of Synchronization and Timing"). Dividing the round-trip time by two gives an estimate of the one-way time, what PTP calls the mean path delay. But for this calculation to be accurate, the forward transit time (master to slave) must be exactly equal to the reverse transit time (slave to mas- ter). The difference between the path transit time in either direction is known as delay asymmetry. There will always be some delay asymmetry present, even if in some circumstances it is almost negligible. The two-way transit time can be quite accurately determined, but the accuracy of the one-way value relies on the correctness of our assumption. This assumption and the consequences of delay asym- metry are the most important thing to understand about packet-based timing. As a convention, IEEE 1588-2008 (7.4.2) defines delay asymmetry as positive when the master->slave transit time is longer than the slave->master transit time. Thus: transit (master->slave) = mean path delay + delay asymmetry transit (slave->master) = mean path delay - delay asymmetry However, without an independent measurement of the delay asymmetry using some external tool or reference clock, PTP cannot detect it. Therefore, the mean path delay is used as an estimate of the one-way (forward) transit time, with the precondition that the network engineer must design a net- work that does not introduce excessive asymmetry. Any asymmetry will lead to direct time error on the slave clock because asymmetry undermines the assumption about how long the timestamp has been "in transit" between the master and the slave