Which QoS classification should be applied to NTP?

Question

Cisco's Enterprise QoS Solution Reference Network Design suggests classifying NTP as network management traffic and marking it as CS2:

When addressing the QoS needs of Network Management traffic, Cisco recommends the following guidelines:

• Network Management traffic should be marked to DSCP CS2.
• Network Management applications should be explicitly protected with a minimal bandwidth guarantee.

Network management traffic is important to perform trend and capacity analysis and troubleshooting. Therefore, you can provision a separate minimal bandwidth queue for Network Management traffic, which could include SNMP, NTP, Syslog, NFS and other management applications.

Given that NTP is jitter-sensitive, why isn't NTP marked as Expediated Forwarding and treated the same as voice data?

Is there a reason why it should not be placed in the same low latency queue as voice?

Answer 1

Edited answer: NTP should be placed in the EF class (same as real-time voice packets) according to the IETF's RFC 4594 Configuration Guidelines for DiffServ Service Classes.

5.2. Mapping for NTP

From tests that were performed, indications are that precise time distribution requires a very low packet delay variation (jitter) transport. Therefore, we suggest that the following guidelines for Network Time Protocol (NTP) be used:

o When NTP is used for providing high-accuracy timing within an administrator's (carrier's) network or to end users/clients, the Telephony service class should be used, and NTP packets should be marked with EF DSCP value.

o For applications that require "wall clock" timing accuracy, the Standard service class should be used, and packets should be marked with DF DSCP.

Answer 2

NTP isn't particularly jitter-sensitive because it uses originate and transmit timestamps to keep track of delay. Ntp.org explains in detail how it keeps delay in check, but here's a snippet:

Synchronizing a client to a network server consists of several packet exchanges where each exchange is a pair of request and reply. When sending out a request, the client stores its own time (originate timestamp) into the packet being sent. When a server receives such a packet, it will in turn store its own time (receive timestamp) into the packet, and the packet will be returned after putting a transmit timestamp into the packet. When receiving the reply, the receiver will once more log its own receipt time to estimate the traveling time of the packet. The traveling time (delay) is estimated to be half of "the total delay minus remote processing time", assuming symmetrical delays.

The reason this isn't in the same category as network control is because this isn't directly responsible for the operation of routing/forwarding of packets. All of the things in the network management category are not critical components of the networking system as a whole. If you lost any packets related to SNMP, syslog, or NTP, you likely wouldn't even notice.

SNMP would simply retransmit that information since it's TCP based. Even if the connection dropped all together, nothing catastrophic would happen; you might just get a snmp agent not responding and then try again. If you lost syslog traffic (UDP), you would simply lose a blip of logging information, which is probably still contained within the buffer or in a log file on the device. Since NTP calculates delay based on previous packets, while also accounting for the maximum offset error, you really aren't running into any issues. Worst case scenario, your time drifts by a few picoseconds…

If you lost a packet related to routing, even for a second, you may be facing the entire system going down; rendering any other markings worthless. At that point, NTP would simply fall totally out of sync and rely on it's local ticker to keep time.