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

From: Srivathsa Sarangapani <[email-masked]>
Date: Thu, 25 Feb 2016 04:04:09 +0000

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.

 - 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.

 - 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.

 - Wanted to propose addition of the below delay stats:
    - 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