Re: [ippm] Extending TWAMP for Monitoring Service KPIs

P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com> Mon, 18 July 2016 09:02 UTC

Return-Path: <p.muthu.arul.mozhi@ericsson.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB10F12D1C7 for <ippm@ietfa.amsl.com>; Mon, 18 Jul 2016 02:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJPluJ8ojKNj for <ippm@ietfa.amsl.com>; Mon, 18 Jul 2016 02:02:00 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FDD12D1C8 for <ippm@ietf.org>; Mon, 18 Jul 2016 02:01:57 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-31-578c9b030ff6
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 77.73.12516.40B9C875; Mon, 18 Jul 2016 11:01:56 +0200 (CEST)
Received: from ESESSMB309.ericsson.se ([169.254.9.160]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 11:01:55 +0200
From: P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com>
To: Srivathsa Sarangapani <srivathsas@juniper.net>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] Extending TWAMP for Monitoring Service KPIs
Thread-Index: AQHR4LlJs7ZNvrtoBUGJaILAXRFapqAd3QBg
Date: Mon, 18 Jul 2016 09:01:55 +0000
Message-ID: <256DB779817549478A1637DDB82E83051D89167B@ESESSMB309.ericsson.se>
References: <0BEE6422-CA88-457A-B651-66C2DE417D16@juniper.net>
In-Reply-To: <0BEE6422-CA88-457A-B651-66C2DE417D16@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_256DB779817549478A1637DDB82E83051D89167BESESSMB309erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7nC7L7J5wg9aPvBY9D94xW2y+/J3V on3GNiYHZo8lS34yeVxvusoewBTFZZOSmpNZllqkb5fAlbHr3DHWgg3LmCpufPnA3MB4ZR5T FyMHh4SAicSUZ+FdjJxAppjEhXvr2UBsIYEjjBJzNpd2MXIB2UsYJV7sOs0EkmATsJKYdXUt mC0iECQxrX0vC8gcZgE1idfPlUDCwgL2Es2TtrJBlDhInD85jQXCNpJYc+okWCuLgKrEk52N jCA2r4CvRNOHv0wQe+0kJvXNBbM5gebs7XoAVsMIdNv3U2vA4swC4hK3nsxngrhZQGLJnvPM ELaoxMvH/1ghbCWJtYe3s0DU50vMPdvACrFLUOLkzCcsExhFZyEZNQtJ2SwkZbPAPtOUWL9L H6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAuPu4Jbf ujsYV792PMQowMGoxMO74Hh3uBBrYllxZe4hRgkOZiUR3sZZPeFCvCmJlVWpRfnxRaU5qcWH GKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGKcf71u0Ti26iSWbrUXpc0pBzHybvx6X zWcFrL2cUfHiYCoPz31VuWqDKdu9lJr7f3Mr1623WHT71ctKtZev7mYsTXz78uolxfcHT81s Ydy4fXqQs4r8hLJF7XlTFvEGL7kQk7G7ZtPjA3yWBud5k+utk6R+XBf05bRqmCPD8uigxX/P HUGGM5VYijMSDbWYi4oTAZam+WK3AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/TnCeat5xcNLVLZ1ystZL3JklGc8>
Cc: Peyush Gupta <peyushg@juniper.net>
Subject: Re: [ippm] Extending TWAMP for Monitoring Service KPIs
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 09:02:08 -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:ippm-bounces@ietf.org] On Behalf Of Srivathsa Sarangapani
Sent: Monday, July 18, 2016 7:58 AM
To: IETF IPPM WG <ippm@ietf.org>
Cc: Peyush Gupta <peyushg@juniper.net>
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