The IP SLAs ICMP
jitter operation supports the following statistical measurements:
-
Jitter
(source-to-destination and destination-to-source)
-
Latency
(source-to-destination and destination-to-source)
-
Round-trip time
latency
-
Packet loss
-
Successive packet
loss
-
Out-of-sequence
packets (source-to-destination, destination-to-source, and round-trip)
-
Late packets
IP SLAs ICMP jitter
uses a two ICMP time stamp messages, an ICMP Timestamp Request (Type 13) and an
ICMP Timestamp Reply (Type 14), to provide jitter, packet loss, and latency. IP
SLAs ICMP jitter operations differ from IP SLAs ICMP echo operations in that
ICMP echo uses ICMP Echo request and reply (ping). Devices that are fully
compliant with RFC 792,
Internet Control
Message Protocol , must be able to respond to the time stamp messages
without requiring an IP SLA responder at the destination.
Note |
Cisco IOS devices
support RFC 792's timestamp requests and replies, but Cisco IOS-XR devices do
not support this.
|
The ICMP API sends a
configurable number of request message packets out of the interface. The data
(time stamp) that is received in the request is returned in a reply message
packet along with another time stamp. Every packet includes three time stamps:
an Originate (sent) Timestamp, a Receive Timestamp, and a Transmit (reply)
Timestamp.
IP SLAs utilizes the
time stamps to calculate jitter for each direction, based on the difference
between interarrival and interdeparture delay for two successive packets. If
the difference is positive, it is counted in positive jitter. A negative value
is counted in negative jitter. Separate measurements for the
source-to-destination and destination-to-source data paths can be used to
identify problems in your network because the paths can be different
(asymmetric).
Each ICMP packet
includes a sequence number in its header that is used to count the number of
packets received out of sequence on the sender. Both the sequence number and
the receive timestamps can be used to calculate out-of-sequence packets on the
source-to-destination path. If the receive time stamp for a packet is greater
than that of the next packet, the first packet was delivered out of order on
the source-to-destination path. For the destination-to-source path, the same
method can be applied. Note that if the packet is out of order on the
source-to-destination path, it should be returned out of order to the sender
unless there is also misordering on the destination-to-source path.
If any packet cannot
be sent due to an internal or unexpected error, or because the timerwheel slot
containing the packet is missed, it is counted as Packet Skipped. This metric
is very important because statistics are measured on sent packets only.
All timed-out packets
are counted towards Packet Loss. Successive packet loss is calculated by
counting, and adding, the number of successive dropped packets. Successive
packet loss is reported as minimum of successive packet drop and maximum of
successive packet drop.
All other statistics
are calculated using the same logic as a UDP jitter operation.