Re: [ippm] Extending TWAMP for Monitoring Service KPIs

[P Muthu Arul Mozhi <[e-mail]>]

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

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]>; IETF IPPM WG <[e-mail]>
Cc: Peyush Gupta <[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