Subject: [ippm] Extending TWAMP for Monitoring Service KPIs

From: Srivathsa Sarangapani <[email-masked]>
Date: Mon, 18 Jul 2016 05:57:38 +0000

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

---

From: P Muthu Arul Mozhi <[email-masked]>
Date: Mon, 18 Jul 2016 09:01:55 +0000

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.

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

Regards,
Muthu

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

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Mon, 18 Jul 2016 09:43:47 +0000

Hi Muthu,

Thanks for your comments. Please see my answers inline:

—
Regards,
Vathsa

From: P Muthu Arul Mozhi <[email-masked]>
Date: Monday, July 18, 2016 at 2:31 PM
To: Srivathsa Sarangapani <[email-masked]>, IETF IPPM WG <[email-masked]>
Cc: Peyush Gupta <[email-masked]>
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

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: P Muthu Arul Mozhi <[email-masked]>
Date: Mon, 18 Jul 2016 10:14:30 +0000

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.

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

Regards,
Muthu

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

Hi Muthu,

—
Regards,
Vathsa

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

Regards,
Muthu

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

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Mon, 18 Jul 2016 13:52:52 +0000

Hi Muthu,

Answers tagged VAT2  inline:

—
Regards,
Vathsa

Date: Monday, July 18, 2016 at 3:44 PM

Hi Srivathsa,

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

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: P Muthu Arul Mozhi <[email-masked]>
Date: Tue, 19 Jul 2016 04:59:31 +0000

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

Sent: Monday, July 18, 2016 3:53 PM

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

To: P Muthu Arul Mozhi <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 19 Jul 2016 05:28:57 +0000

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Date: Tuesday, July 19, 2016 at 10:29 AM

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

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: P Muthu Arul Mozhi <[email-masked]>
Date: Tue, 19 Jul 2016 06:33:24 +0000

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? How will it conclude whether the HTTP service is running or not? That's not described in the section you have mentioned above.

Regards,
Muthu

Sent: Tuesday, July 19, 2016 7:29 AM

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 19 Jul 2016 06:42:51 +0000

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Date: Tuesday, July 19, 2016 at 12:03 PM

Hi Vathsa,

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

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 19 Jul 2016 06:57:59 +0000

Hi Vathsa,
I think what Muthu points to is that your proposal are for Service layer OAM, not Overlay, in this case SFP OAM. As you agree that test packets should be application specific, that, I think, moves discussion onto different networking layer. I think that it is helpful to understand what being measured and how that fits into multi-layer OAM paradigm. And, as I’ve noted earlier, TWAMP Test not really been designed as Echo Request/Echo Reply protocol. There are abundance of protocols, e.g. ICMP, LSP Ping, etc., to do that. Using hammer to drive screw in doesn’t seem as the best solution to me.

                Regards,
                                Greg

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: P Muthu Arul Mozhi <[email-masked]>
Date: Tue, 19 Jul 2016 07:12:18 +0000

| Till the next probe is exchanged the old status continues.

How long should the cline wait before sending the next probe? HTTP over TCP will automatically retransmit and timeout.

All we are saving for the liveness use case is a couple of TCP segments, by tunneling the HTTP request/response inside the TWAMP test data packets. This, as I said earlier, doesn't look a big saving compared to the added complexity.

Regards,
Muthu

Sent: Tuesday, July 19, 2016 8:43 AM

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Hi Vathsa,

Regards,
Muthu

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: P Muthu Arul Mozhi <[email-masked]>
Date: Tue, 19 Jul 2016 08:29:57 +0000

I agree with Greg that this is more of a service/application layer OAM problem than of a network/overlay OAM problem. Trying to address the former using the later techniques could add a lot of complexity which needs to be justified thru' tangible benefits.

Regards,
Muthu

From: Gregory Mirsky
Sent: Tuesday, July 19, 2016 8:58 AM
To: Srivathsa Sarangapani <[email-masked]>; P Muthu Arul Mozhi <[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: Peyush Gupta <[email-masked]>
Subject: RE: [ippm] Extending TWAMP for Monitoring Service KPIs

Hi Vathsa,

                Regards,
                                Greg

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 19 Jul 2016 08:43:56 +0000

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Date: Tuesday, July 19, 2016 at 12:42 PM

How long should the cline wait before sending the next probe? HTTP over TCP will automatically retransmit and timeout.
VAT>>>It depends on what is the time interval between successive probes. Normally it would be in terms of milli-seconds or seconds.
Even in case of TCP failure, HTTP will take a few seconds to realize the server/network is down. Here TCP is taking care of re-transmissions and in the former case TWAMP probe interval will take care new transmissions.

All we are saving for the liveness use case is a couple of TCP segments, by tunneling the HTTP request/response inside the TWAMP test data packets.
VAT>>>liveliness in just one KPI we are discussing about. There are other KPIs like service latency, service load etc.

This, as I said earlier, doesn't look a big saving compared to the added complexity.

Regards,
Muthu

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Hi Vathsa,

Regards,
Muthu

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 19 Jul 2016 08:49:54 +0000

Hi Greg,

I think we had discussed about this service OAM in earlier mails. I am pasting the relevant content from my earlier mail for easy reference:

I could see the even OAM tool RFC 7276 refers to TWAMP to calculate RTT. Similarly, OAM can refer to these extension drafts for calculating keepalive and service latency for a particular service.

Regarding RFC 7555, I could see that this is mostly dealing with MPLS networks and its operations. I could not see that this is used to calculate liveliness or latency of any other specific functionality.

—
Regards,
Vathsa

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

Hi Vathsa,

                Regards,
                                Greg

Hi Muthu,

Answers inline:

—
Regards,
Vathsa

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Hi Srivathsa,

Regards,
Muthu

Hi Muthu,

—
Regards,
Vathsa

Regards,
Muthu

Hi All,

Abstract:

Abstract:

—
Regards,
Vathsa