Re: [ippm] Discussion on extending TWAMP to monitor service KPIs and detect liveliness of an application

Hi Srivathsa and Dave,

At the moment, some visibility of service KPIs are intended
to be measured with PDM:
https://tools.ietf.org/html/draft-elkins-ippm-6man-pdm-option-00
(and there is/was a call for interest 
http://www.ietf.org/mail-archive/web/ippm/current/msg03732.html
probably not too late to respond usefully on this wg call)

regarding:
> > Similarly they cannot figure out the liveliness of an application on a
> > server even though they can figure out that the server is alive.
> 
> Well said. liveliness as a default benchmark type would be good for just
> about everything. :)

By liveliness, what degree of response complexity is considered alive?
Possibilities beyond ICMP Echo include:
 - Opens connection on well-known port
 - sends expected greeting message
 - ...
 - completes entire transaction within time limit

regards,
Al

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Dave Taht
> Sent: Monday, June 08, 2015 12:31 PM
> To: Srivathsa Sarangapani
> Cc: ippm@ietf.org
> Subject: Re: [ippm] Discussion on extending TWAMP to monitor service
> KPIs and detect liveliness of an application
> 
> On Mon, Jun 8, 2015 at 9:17 AM, Srivathsa Sarangapani
> <srivathsas@juniper.net> wrote:
> > Dear IPPM,
> >
> > I would like to share something with you today.
> >
> > In the existing as well as next generation network architectures,
> > there are lot of new services getting added in the service plane with
> > in the network. services here include subscriber aware services, flow
> > based traffic load balancing, content delivery servers, real time
> > streaming applications and similar. The performance of these services
> > are monitored using set of attributes. some of the critical attributes
> > are latency introduced in the packet path, impact on network capacity
> and throughput.
> > some other attributes are to check whether a service node is alive or
> not.
> >
> > To Address some of these challenges, how about extending TWAMP
> > protocol (RFC 5357) to monitor service KPIs and monitor the liveliness
> > of the service or application.
> 
> I would like to see smokeping more widely used, and bandwidth presented
> at the same time as loss, ECN CE, and latency in more mtrg and cacti
> (and other widely used network management system) graphs.
> 
> While I would like to see more twamp deployments, it is kind of a
> headache to deploy (ntp time sensitivity for starters - that said, I
> would also like to see better timekeeping across the internet also).
> 
> >
> > Today TWAMP is used to measure just RTT between 2 Network Elements,
> > like routers, servers etc.
> > Since Routers are no more just forwarding packets but running lot more
> > services like CGNAT, DPI, IPSec, TDF and like.
> > Even Servers are used to run applications like DNS, HTTP over it.
> >
> > Existing standard protocols cannot measure the impact of enabling
> > service on packets that get routed via a router in terms of latency
> > and the throughput.
> > Similarly they cannot figure out the liveliness of an application on a
> > server even though they can figure out that the server is alive.
> 
> Well said. liveliness as a default benchmark type would be good for just
> about everything. :)
> 
> > With  the advent of SDN and VNFs, the latency of a VNF would really
> > make lot of sense for the network operator for optimal network
> > planning and deployment.
> 
> I agree that monitoring the effectiveness of these new technologies is a
> goodness.
> 
> > Based on the real time latency, the network operator can possibly
> > spawn more  VMs  for a services VNF when required and can shut down
> > some of them when not required.
> 
> Well, more VMs does != less latency.
> 
> >
> > We therefore think that adding this new dimension to TWAMP protocol
> > would really be helpful for network monitoring and analysis.
> > We request you all to please share your thoughts on the same.
> 
> 
> >
> >
> > --
> > Thanks and Regards,
> > Vathsa
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm
> 
> 
> 
> --
> Dave Täht
> What will it take to vastly improve wifi for everyone?
> https://plus.google.com/u/0/explore/makewififast
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm