Hi, Sorry for the late reply, I missed this thread. Ron, your observation is correct.
With that said, from the implementation perspective, there is a benefit to have a single procedure (and a single implementation) for updating the UDP checksum in a timestamped packet (PTP, NTP, OWAMP, TWAMP). So for PTP the UDP Checksum update clearly benefits from the Checksum Trailer. As for NTP and OWAMP, the benefit of using the Checksum Trailer is from having the same UDP checksum update flow as the one for PTP. At the end of the day this draft is about easy implementation - we are trying to define the Checksum Trailer in a way that will allow easy implementation, while not requiring any changes in existing implementations. Regards, Tal. From: [email protected] [mailto:[email protected]] On Behalf Of Ron Cohen Sent: Friday, July 29, 2011 12:33 AM To: [email protected] Subject: [TICTOC] The Need for Checksum Extension Hi, I'd like to clarify my comment during the meeting. According to RFC1612 Eqn 3 (incremental checksum update): HC' = ~(C + (-m) + m') = ~(~HC + ~m + m') Where HC' is the updated checksum, HC is the current (message) checksum, m' in the new value that is going to be written instead of the value m in the message. If I know that value of m is zero, I can calculate the new checksum using the old checksum and the new value alone. That is, if the NTP/OWAMP/TWAMP CPU sets the transmit timestamp to zero (i.e. m = 0), the FPGA or switch that measures the transmit timestamp once the first byte of the message is sent on the wire, can update the UDP checksum itself incrementally and doesn't need the extension. The extension is need only if you have to read the timestamp which appears later in the packet in order to update the checksum. This is very different from 'real' intermediate devices (i.e. transparent clocks) used by PTP. Best, Ron
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
