Re: [ippm] draft-cmzrjp-ippm-twamp-yang

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Vathsa,
Please see replies below, [ACM].

The main follow-up for authors is to check
the description of "repeat" in section 4.1.

Al

> 
> Dear Authors,
> 
> I had some comments on the draft in IETF 93rd Meeting and some of them
> are adopted. I have listed down the other comments which are still not
> addressed.
> These are some of the parameters which are already being supported in
> Juniper implementation of TWAMP client and Server.
> 
> Below are my questions, can you please comment
> 
>  - Section 5.1:
>    |        +--rw repeat?               uint32
> 
>    Thanks for making in uint32. Currently if it is 0, it means no more iterations.
>    If user wants to run the TWAMP sessions infinitely, how do we handle this?
>    So can we change it so that 0 indicates the iterations will run infinitely.
>    1-4294967295 can indicate the number of iterations.
>    The default value can be changed to 1 if required.
[ACM] 
Changing the Default to one would mean that all sessions would be repeated,
except those where repeat is set to zero. I think that *repeating test sessions* 
should be a feature that users have to request explicitly. I'd rather specify 
that non-repeating test sessions be the default.

Even though the value is uint32, the description still sounds binary:

   repeat and repeat-interval
           These two values together are used to determine if the TWAMP-
           Test session is to be run repeatedly.  Once a test session
           has completed, the repeat parameter is checked.  If the value
           indicates that this test session is to run again, then the
           parent TWAMP-Control connection for this test session is
           restarted - and negotiates a new instance of this TWAMP-Test
           session.  This may occur immediately after the test session
           completes (if the repeat-interval is set to 0).  Otherwise,
           the Control-Client will wait for the number of minutes
           specified in the repeat-interval parameter before negotiating
           the new instance of this TWAMP-Test session.  The default
           value of repeat is 0, indicating that once the session has
           completed, it will not be renegotiated and restarted.

I read this as the value of repeat controls whether the test session
repeats or not. There is no indication of a number of iterations,
or that the value of "repeat" should be decremented each time one 
test session completes. So, setting repeat = 1 will give the infinite
Test Session loop you are requesting.

> 
>  - Section 5.1:
>    In case of both twamp-session-sender and twamp-session-reflector, can
> we even store the timestamp of the last-sent-seq and last-rcv-seq
> packets?
>    Say along with the below fields:
>    |     +--ro last-sent-seq?             uint32
>    |     +--ro last-rcv-seq?              uint32
>    have 2 more fields
>    | +--ro last-sent-seq-time? uint64
>    | +--ro last-rcv-seq-time? uint64
>    This might give more insight on when the last packet was sent and
> when the last packet was received.
>    As TWAMP deals with RTT, storing the time stamps might make sense.
[ACM] 
Your request for specific timestamps is a bit unexpected.
We included the last sequence numbers to support a quick sanity
check on the test session (did the test terminate prematurely?
did the RT path fail during the test session?)

TWAMP's advantage over ICMP and other Echo replies is that it
requires the four T->R T->R time stamps to calculate both one-way delays
and the two-way delay without reflector processing time.
The test packets will have three of the four timestamps.
And the IPPM delay metric definitions specify storage of T,
the time every packet is sent, and the one-way/round-trip
delay for each packet. So, all of the needed time stamps
are in your results (?) .


> 
>  - Can we add a configuration on server side to add a list of client IPs
> from which the server can accept the connections?
>    Doing this gives an option to server to accept only genuine
> connection requests and not from some spurious clients.
>    This was discussed in July meet at Prague.
[ACM] 
I imagine that most TWAMP systems embedded in other devices
could rely on the device ACL to perform this function.
The TWAMP way to reject unwanted sessions this is to use 
Authenticated mode, of course. 

Although this could be a useful feature to add, I wonder
if there is an ACL YANG model already?  We could simply
re-use/reference what they have specified...

> 
>  - Wanted to propose addition of the below delay stats:
[ACM] 
In IPPM, we have defined RFCs for all the fundamental metrics.

For example:
http://tools.ietf.org/html/rfc2681
is Round-trip Delay.

In RFC 3393, we agreed not to use the term "jitter",
http://tools.ietf.org/html/rfc3393#section-1.1

RFC 5481 examined different two forms of packet delay variation,
including the version you describe below, which is called 
inter-packet delay variation (IPDV). We compared IPDV with 
the simple packet delay variation w.r.t minimum delay (PDV),
and found that most use cases were better served by the 
network characteristics measured by PDV. The Summary:
http://tools.ietf.org/html/rfc5481#section-7.3
 
The current solution in the YANG model is to refer to a 
Performance Metrics Registry.

   pm-index
           One or more Numerical index values of a Registered Metric in
           the Performance Metric Registry
           [I-D.ietf-ippm-metric-registry] comprise the pm-reg-list.
           Output statistics are specified in the corresponding Registry
           entry.

As you know, TWAMP RFCs control and provide active test packets which
are the basis for calculating metrics. By simply referencing a 
registered metric we avoid overlap and maintain TWAMP RFC's scope in
the YANG Model.

Some of us are creating a registry for IANA to help manage,
containing many metrics which are widely used and 
known to provide real network performance insight.
It is also possible to use the registry format to create 
a private registry.

-=-=-=-=-=-=-=-=-=-=-=-=-

>     - RTT shall be (Session-Sender Ingress Timestamp) - (Session-Sender
> Egress Timestamp) -
>                    ((Session-Reflector Egress Timestamp) - (Session-
> Reflector Ingress Timestamp))
>       (Session-Reflector Egress Timestamp) - (Session-Reflector Ingress
> Timestamp) : Shall be the server processing Time.
>     - Ingress Jitter
>     - Egress Jitter
>     - RTT Jitter
> The Ingress, Egress and RTT Jitters are as defined below:
> 
> jitter is defined to be the difference in relative transit time between
> two consecutive probes.
> From the diagram below, we can define this to be:
> 
> |        |
> |Si      |
> |  \     |
> |   \    |
> |    \   |
> |     \  |
> |      Ri|
> |        |
> |       /|
> |      / |
> |     /  |
> |    /   |
> |   /    |
> |  /     |
> | /      |
> |        |
> |Sj      |
> |  \     |
> |   \    |
> |    \   |
> |     \  |
> |      Rj|
> |        |
> |       /|
> |      / |
> |     /  |
> |    /   |
> |   /    |
> |  /     |
> | /      |
> Probe    Probe
> Sender   Responder
> 
> D(i,j) = (Rj - Sj) - (Ri - Si)
>        = (Rj - Ri) - (Sj - Si)
> 
> D(i,j) represents the measure of jitter between probes i and j in the
> egress (ie, Source to Destination) direction.
> 
> Similarly, we can also define jitter in the ingress direction (ie,
> Destination
> to Source) direction to be:
> 
> 
> |        |
> |\       |
> | \      |
> |  \     |
> |   \    |
> |    \   |
> |     \  |
> |      \ |
> |       \|
> |        |
> |      Si|
> |     /  |
> |    /   |
> |   /    |
> |  /     |
> | /      |
> |Ri      |
> |        |
> |\       |
> | \      |
> |  \     |
> |   \    |
> |    \   |
> |     \  |
> |      \ |
> |       \|
> |        |
> |      Sj|
> |     /  |
> |    /   |
> |   /    |
> |  /     |
> | /      |
> |Rj      |
> Probe    Probe
> Sender   Responder
> 
> D(i,j) = (Rj - Sj) - (Ri - Si)
>        = (Rj - Ri) - (Sj - Si)
> 
> Similarly, we can also define jitter for the round trip delays to be:
> 
> |        |
> |Si      |
> |\       |
> | \      |
> |  \     |
> |   \    |
> |    \   |
> |     \  |
> |      \ |
> |       \|
> |       /|
> |      / |
> |     /  |
> |    /   |
> |   /    |
> |  /     |
> | /      |
> |Ri      |
> |        |
> |Sj      |
> |\       |
> | \      |
> |  \     |
> |   \    |
> |    \   |
> |     \  |
> |      \ |
> |       \|
> |       /|
> |      / |
> |     /  |
> |    /   |
> |   /    |
> |  /     |
> | /      |
> |Rj      |
> Probe    Probe
> Sender   Responder
> 
> D(i,j) = (Rj - Sj) - (Ri - Si)
>        = (Rj - Ri) - (Sj - Si)
> 
> 
> -
> Regards,
> Vathsa