Re: [ippm] Extending TWAMP for Monitoring Service KPIs

[Srivathsa Sarangapani <[e-mail]>]

Hi Muthu,

Answers inline:

—
Regards,
Vathsa


From: P Muthu Arul Mozhi <[e-mail]>
Date: Tuesday, July 19, 2016 at 12:03 PM
To: Srivathsa Sarangapani <[e-mail]>, IETF IPPM WG <[e-mail]>
Cc: Peyush Gupta <[e-mail]>
Subject: RE: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi Vathsa,

| I request you to please read the Verification part of Section 2.1.
| Services Keepalive Monitoring of draft draft-spv-ippm-monitor-
| implementation-services-kpi.txt Only after processing the TWAMP reply,
| if the bit 0 is NOT set, then ONLY the service should be declared as
| down and not if the UDP packet is lost.

So, what will the client do if the TWAMP test packet carrying the HTTP request/response is lost?
VAT>>>This SHOULD NOT be treated as the http server is NOT Alive. It is just TWAMP data probe lost because of network issue.

How will it conclude whether the HTTP service is running or not?
VAT>>>Till the next probe is exchanged the old status continues.

That's not described in the section you have mentioned above.

Regards,
Muthu

From: Srivathsa Sarangapani [mailto:[e-mail]]
Sent: Tuesday, July 19, 2016 7:29 AM
To: P Muthu Arul Mozhi <[e-mail]>; IETF IPPM WG <[e-mail]>
Cc: Peyush Gupta <[e-mail]>
Subject: Re: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi Muthu,

Answers inline:

—
Regards,
Vathsa


From: P Muthu Arul Mozhi <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 19, 2016 at 10:29 AM
To: Srivathsa Sarangapani <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: RE: [ippm] Extending TWAMP for Monitoring Service KPIs

Tunneling HTTP requests/responses inside TWAMP test (UDP) packets can cause many problems. For e.g, if those UDP packets are lost, it can give a false alarm that the HTTP service is down.
VAT>>>If UDP packets are lost, it does not mean the service is down. The proposal NEVER indicates anything like this. I am not sure why this ASSUMPTION was made.
I request you to please read the Verification part of Section 2.1. Services Keepalive Monitoring of draft draft-spv-ippm-monitor-implementation-services-kpi.txt
Only after processing the TWAMP reply, if the bit 0 is NOT set, then ONLY the service should be declared as down and not if the UDP packet is lost.

Adding reliability to TAMP test would probably be an overkill.

Moreover, a use cases like measuring the processing delay of a video service using the proposed method would require the media engine on the client endpoint to generate TWAMP test packets carrying RTP/UDP at specified rate/timing, which will be very hard to implement.
VAT>>> If the admin needs to understand the processing delay, then he needs to send the required data right? If you are indicating the generation of service packet is hard, then it is beyond the scope of this document. Whether TWAMP or any other protocol, he needs to generate the required payload.
But other part is valid, as to whether the Admin is really interested to know the service latency for each and every TWAMP test packet.
Possibly we can add a bit in every TWAMP data probe sent from client, to indicates whether for this particular packet the service latency is required to be calculated or not. Based on need, the admin can choose to set this bit. We will possibly incorporate this input as a part of the next revision.
Please let me know if you need more detailed answer here so that I can send it out.
Definitely inputs/discussions like this will help us to design the protocol in the best possible way. Thanks for your inputs!!!

Overall, I fail to see the benefit we get for the added complexity.

Regards,
Muthu

From: Srivathsa Sarangapani [mailto:[e-mail]]
Sent: Monday, July 18, 2016 3:53 PM
To: P Muthu Arul Mozhi <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi Muthu,

Answers tagged VAT2  inline:

—
Regards,
Vathsa


From: P Muthu Arul Mozhi <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 18, 2016 at 3:44 PM
To: Srivathsa Sarangapani <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: RE: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi Srivathsa,

| VAT>>>Say if the network admin wants to know the RTT + the
| liveliness of an application, then he need to send 2 probes
| every interval. One TWAMP probe for calculating RTT and one
| application specific probe to check the liveliness. So with
| our proposal the desired functionality can be achieved by
| just 1 probe. So this way, it reduces the number of probes
| by 50%. This would effectively use the network resources.

Well, you could do that by sending a single HTTP command and have the application return the result in a single command. I think the problem is with the choice of the protocol and not with the protocol deficiencies.
VAT2>>>Can you please elaborate on how would you get the RTT + liveliness using single HTTP command?
I hope you are not assuming RTT as the time when the probe was sent from application layer and when the probe was received by application layer.
The timestamping of Twamp is mostly implemented in the lowest possible layer(mostly in pfe data path) and that is what network admin is interested.

| VAT>>>Good question. I don’t think the main functionality of
| SIP, XMPP or RTSP is to Measure the IP performance Metric of
| the network.
We don't seem to be using TWAMP to measure the IP performance here anyway, instead to know the application liveliness, obtain the processing delay etc..
VAT>>>What made you think so?
In the TWAMP data probe, the timestamps to calculate the RTT is present by default. We want to add the http req/resp (assuming we are trying to probe a http server) as a part of payload which is currently unused to get the liveliness of the application.
I have specified the packet formats which indicate the TWAMP data packets containing all the earlier timestamps. Please let me know if this is not clear in the document so that I can EXPLICITLY add this information.

Regards,
Muthu

From: Srivathsa Sarangapani [mailto:[e-mail]]
Sent: Monday, July 18, 2016 11:44 AM
To: P Muthu Arul Mozhi <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi Muthu,

Thanks for your comments. Please see my answers inline:

—
Regards,
Vathsa


From: P Muthu Arul Mozhi <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 18, 2016 at 2:31 PM
To: Srivathsa Sarangapani <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: RE: [ippm] Extending TWAMP for Monitoring Service KPIs

I read these drafts and some of the review comments and arguments. While the justifications for this work has been primarily "why not use TWAMP for this purpose", I do not find arguments on why TWAMP is the appropriate protocol for the kind usages described in the draft.
VAT>>>TWAMP is widely used to calculate RTT between 2 network nodes.
Why shouldn’t it be used to piggyback more relevant information like liveliness. Please note currently the TWAMP data payload is not used. It is filled with either zeros or pseudo random values. With our extension this payload can be efficiently used to carry some more relevant information.

If the intention is to find whether a HTTP application is alive, one could send the HTTP request directly to the application and wait for a response.
VAT>>>Say if the network admin wants to know the RTT + the liveliness of an application, then he need to send 2 probes every interval. One TWAMP probe for calculating RTT and one application specific probe to check the liveliness. So with our proposal the desired functionality can be achieved by just 1 probe. So this way, it reduces the number of probes by 50%. This would effectively use the network resources.

OTOH, if the intention is to do the same for some other node Z, one could send a HHTP request to an application running in Z and let it initiate the HHTP request to the target application and pass on the result. We could also extend SIP, XMPP, RTSP or any other application protocol to communicate with Z. It isn't clear why TWAMP is more suitable than any of these protocols.
VAT>>>Good question. I don’t think the main functionality of SIP, XMPP or RTSP is to Measure the IP performance Metric of the network.
But IPPM Protocols are defined and designed for this purposes. I would like to paste some relevant text from the IPPM charter:
“The WG will seek to develop new metrics and models to more accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths.”


Regards,
Muthu

From: ippm [mailto:[e-mail]] On Behalf Of Srivathsa Sarangapani
Sent: Monday, July 18, 2016 7:58 AM
To: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi All,

New versions of the TWAMP Service Monitoring extension drafts are being posted after addressing the comments given by Greg, Qin and others in the mailing list.
We request you all to please go through the documents and reply back with your comments/suggestions.
The documents are in the below path:

Name:         draft-spv-ippm-monitor-methodology-services-kpi
Revision: 02
Title:        Monitoring Service KPIs using TWAMP - Methodology
Document date: 2016-07-17
Group:        Individual Submission
Pages:        20
URL:            https://www.ietf.org/internet-drafts/draft-spv-ippm-monitor-methodology-services-kpi-02.txt
Status:         https://datatracker.ietf.org/doc/draft-spv-ippm-monitor-methodology-services-kpi/
Htmlized:       https://tools.ietf.org/html/draft-spv-ippm-monitor-methodology-services-kpi-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-spv-ippm-monitor-methodology-services-kpi-02

Abstract:
   The TWAMP protocol provides a common architecture for two way
   measurements in the IP network.  However IP network performance are
   also affected by a set of L4-L7 service deployed in the network.
   Monitoring of these service performance in the IP network also plays
   a vital role in network optimization and application layer traffic
   optimization.  This capability is not supported by the existing TWAMP
   protocol.

   In this document, we extend TWAMP protocol to support service
   performance monitoring and service KPIs calculation.  Some of the
   existing fields in the TWAMP protocol are extended to support new
   modes for calculating these KPIs.  A set of new messages are added in
   the control protocol between TWAMP client (session sender) and the
   TWAMP server (session reflector).  Services here ranging from Layer 4
   to Layer 7 services,such as Http based services, Traffic load
   balancer, DPI, Video caching, real time streaming and IPSec.  The
   KPIs MAY be service latency, liveliness of an application, number of
   flows and sessions per service, load balancer statistics.

   There is a separate Draft[I.D-spv-ippm-monitor-implementation-
   services-kpi] that talks about implementation of monitoring these
   KPIs in the network using TWAMP.  Monitoring of these KPIs in the
   service plane with in a network play a vital role in optimum usage of
   network resources and improving the overall performance and capacity.


Name:         draft-spv-ippm-monitor-implementation-services-kpi
Revision: 02
Title:        KPI Metrics for Service Monitoring using TWAMP
Document date: 2016-07-17
Group:        Individual Submission
Pages:        9
URL:            https://www.ietf.org/internet-drafts/draft-spv-ippm-monitor-implementation-services-kpi-02.txt
Status:         https://datatracker.ietf.org/doc/draft-spv-ippm-monitor-implementation-services-kpi/
Htmlized:       https://tools.ietf.org/html/draft-spv-ippm-monitor-implementation-services-kpi-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-spv-ippm-monitor-implementation-services-kpi-02

Abstract:
   We are using a new method to calculate services KPIs and metrics in
   the network using TWAMP protocol.  This draft outlines the
   implementation of the service KPIs and there use cases in the service
   plane in the network.  The KPIs discussed in this draft include
   Service Latency and Application Liveliness detection.

   Service latency is defined as the time spent by the packet when it is
   injected in the service module or service card till the time,
   serviced packet is received back by the TWAMP server.  TWAMP server
   records the timestamp of the packet when it is injected into the
   service module and then again record the timestamp when it receives
   the packet afer service is applied in the data plane.

   Application Liveliness detection means whether the application is up
   and running in the network.  In case you want to monitor the http
   application or the dns server and verify if they are up and running,
   this method is applicable.  The implementation can be used for
   liveliness detection of any service in the network.


—
Regards,
Vathsa