[c-nsp] understanding the IP SLA "icmp-jitter" calculations

[Martin T]

Nathan, Saku,

I did some further debugging and improved my lab-setup in a way that
now I'm in control of the values of "Originate timestamp", "Receive
timestamp" and "Transmit timestamp" fields in ICMP "Timestamp reply"
message sent by my lab-server.

This "Number Of RTT:" field is actually the number of received ICMP
"Timestamp reply" messages. For example, if one has following
configuration:

ip sla 300
 icmp-jitter 192.168.11.2 source-ip 192.168.11.1 num-packets 100
ip sla schedule 300 life forever start-time now

..and 50% packet loss towards the router, then "Number Of RTT:" in "sh
ip sla statistics" output will be ~50 as 100 ICMP "Timestamp request"
messages were sent.

Now I'm able to answer to my second question. If RTD - STS(used to
calculate source to destination latency) is negative, then no one-way
latencies are shown. Debug output for this scenario can be seen below:

.Apr  5 13:11:34.516: IPSLA-OPER_TRACE:OPER:300 Rev Seq: 1, Id: 4071
        STS: 47494097  RTD: 47494087 STD: 47494088  RTS: 47494515


If RTS - STD(used to calculate destination to source latency)
calculation is negative, then no one-way latencies are shown. Debug
output for this scenario can be seen below:

.Apr  5 13:15:42.524: IPSLA-OPER_TRACE:OPER:300 Rev Seq: 1, Id: 4071
        STS: 47742035  RTD: 47742045 STD: 47742535  RTS: 47742524

In both cases, the two-way latency(RTS-STS) was shown.
I also created a practically impossible scenario where STD was smaller
than RTD, but this didn't seem to have no affect.

If RTS-STS is negative:

.Apr  5 13:00:52.507: IPSLA-OPER_TRACE:OPER:300 Rev Seq: 1, Id: 4071
        STS: 46852709  RTD: 46851707 STD: 46851709  RTS: 46852507

.. then this "Number Of RTT: 1                RTT Min/Avg/Max: 1/1/1
milliseconds" line is shown.

I think that in my first e-mail the calculation was actually
"35725395-2183208743" and not "35725395-35725095" as it should have
been. In other words, I guess that during the two-way latency
calculation the Cisco router didn't take into account, that it set the
most significant bit to mark the "Originate timestamp" field as
non-standard value.

And answer to my third question in my first e-mail is that for
accurate one-way delay measurements the clocks in source and
destination needs to be in sync within the same millisecond.


Let me know if you have any further questions regarding this or
anything was unclear.


Martin


On Thu, Apr 4, 2019 at 9:29 PM Saku Ytti <saku at ytti.fi> wrote:
>
> Nathan does raise interesting point.
>
> What if the RTT means just round time trip of X. Like it's not
> specifically 'RTD' so it is conceivable that's RTT Jitter.
>
> On Thu, 4 Apr 2019 at 21:07, Martin T <m4rtntns at gmail.com> wrote:
> >
> > Hi Nathan,
> >
> > > I could be wrong, but doesn't the output you provided above represent 1 ms of jitter?
> >
> > Yes, but the output of "sh ip sla statistics" in my first e-mail shows
> > that RTT(round-trip time) is 1ms.
> >
> >
> > Martin
> >
> > On Thu, Apr 4, 2019 at 8:47 PM Nathan Lannine <nathan.lannine at gmail.com> wrote:
> > >>
> > >> csr1000v#ping 192.168.11.2
> > >> Type escape sequence to abort.
> > >> Sending 5, 100-byte ICMP Echos to 192.168.11.2, timeout is 2 seconds:
> > >> !!!!!
> > >> Success rate is 100 percent (5/5), round-trip min/avg/max = 300/300/301 ms
> > >> csr1000v#
> > >
> > >
> > > Hello, Martin,
> > >
> > > I could be wrong, but doesn't the output you provided above represent 1 ms of jitter?
> > >
> > > Thank you,
> > > Nathan
>
>
>
> --
>   ++ytti