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

[Srivathsa Sarangapani <[e-mail]>]

Hi Al,

Thanks a lot for the detailed answers.
Some questions inline. Please refer [SRI] for the same.

— 
Regards,
Vathsa








-----Original Message-----
From: "MORTON, ALFRED C (AL)" <[e-mail]>
Date: Sunday, March 6, 2016 at 3:12 AM
To: Srivathsa Sarangapani <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: draft-cmzrjp-ippm-twamp-yang

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.

>>>
[SRI] 
So with the current options, it is either run test sessions forever or only once.
If a user wants to run some test sessions for 10 times or 100 times, how can he achieve this with the current proposal?


> 
>  - 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 (?) .

>>>
[SRI] 
Sorry Al, I completely misunderstood the last-sent-seq as last SUCCESSFULLY sent sequence number which has been acked/replied by the server.
Hence I was proposing to store the timestamp along with the sequence number. I completely agree for last-sent-seq number there is no need to store the packet timings.

Just a thought. How about adding these new variables to aid quick sanity check/debugging purposes:
On session-sender

last-successfully-sent-seq and last-successfully-sent-seq-time : 
     This indicates the last sequence number, for which the session-reflector has acked/replied back and that was successfully received by session-sender.

On session-reflector 
last-successfully-rcv-seq and last-successfully-rcv-seq-time : 
     This indicates the last sequence number, the session-reflector has acked/replied back.


Based on whether the last-successfully-sent-seq and last-successfully-rcv-seq values, it can be known that whether the path from Session-Sender to Session-Reflector  has gone bad or the reverse path has gone bad.
Say, if both the values are same, then it means the Tx path from Session-sender has gone for a toss and if both are different then it means the Tx path(Rx path) from(to) Session-reflector(Session-sender) has gone bad.


> 
>  - 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…
>>>>
[SRI] Agreed. 


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

>>>>
[SRI]
I was not aware of this. We can drop jitter from the stats.
Can we include the RTT calculations for the probes? 

Also adding the max, min, average, peak-to-peak, stddev for RTT might be a good idea.

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.



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