I agree. and assuming that the NTP or xWAMP IP is carried over Ethernet I would like to ask what the authors are not concerned about the FCS ?
CRC can not be readily updated, and so needs to iterate over the entire payload, but is still calculated on the fly. So the UDP checksum, which CAN be readily updated, can certainly be. I realize practical reasoning that there are already hardware implementations for calculating the CRC. Yet I think that we need a very strong reason to do standardization work simply to avoid building a very small simple hardware module for the checksum. Y(J)S From: [email protected] [mailto:[email protected]] On Behalf Of Ron Cohen Sent: Friday, July 29, 2011 00:33 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
