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

Hi Vathsa,

I had a look at your draft tonight, but I clearly need to 
spend more time to try to figure out how these new features
work - take the keep-alive for example in section 5.1:

5.1.  Services Keepalive Monitoring

   The Session-Sender MAY send the Service PDU as part of the TWAMP-Test
   Packet Padding.  When Session-Reflector receives the TWAMP-Test
   packet, it SHALL extract the Service PDU.  Then Session-Reflector
   SHALL inject the Service PDU to the Service Block for service
   processing.

   Based on whether the Session-Reflector received the response, the
   Session-Reflector SHALL decide whether the Service is alive or not.

Are the test packets sent between Sender and Reflector the basis for 
evaluating Service liveliness?  If so, it seems that *any* successful
test packet received at the Reflector and then received back at the Sender
is enough to assess bi-directional service liveliness. I'm missing the
need for the Reflector to decide anything - it just has to re-use payload
in the packet it reflects?

Al

> -----Original Message-----
> From: Srivathsa Sarangapani [mailto:srivathsas@juniper.net]
> Sent: Monday, June 29, 2015 12:45 PM
> To: MORTON, ALFRED C (AL); Dave Taht
> Cc: ippm@ietf.org; Peyush Gupta
> Subject: Re: [ippm] Discussion on extending TWAMP to monitor service
> KPIs and detect liveliness of an application
> 
> Hi Al,
> 
> I hope you agree to our below comments.
> In continuation of the same idea, we have submitted a draft:
> https://datatracker.ietf.org/doc/draft-sp-ippm-monitor-services-kpi/
> 
> Request you to please go through the same and provide your
> comments/suggestions.
> 
> 
> --
> Regards,
> Vathsa
> 
> 
> 
> 
> -----Original Message-----
> From: Srivathsa Sarangapani <srivathsas@juniper.net>
> Date: Tuesday, June 9, 2015 at 6:50 PM
> To: "MORTON, ALFRED C (AL)" <acmorton@att.com>, Dave Taht
> <dave.taht@gmail.com>
> Cc: "ippm@ietf.org" <ippm@ietf.org>, Peyush Gupta <peyushg@juniper.net>
> Subject: Re: [ippm] Discussion on extending TWAMP to monitor service
> KPIs
> and detect liveliness of an application
> 
> Hi Al,
> 
> Thanks for your reply. Please see my answers inline:
> 
> --
> Regards,
> Vathsa
> 
> 
> 
> 
> -----Original Message-----
> From: <MORTON>, "ALFRED C   (AL)" <acmorton@att.com>
> Date: Monday, June 8, 2015 at 11:48 PM
> To: Dave Taht <dave.taht@gmail.com>, Srivathsa Sarangapani
> <srivathsas@juniper.net>
> Cc: "ippm@ietf.org" <ippm@ietf.org>
> Subject: 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)
> 
> Vathsa>>>Good work.
> We feel that service KPIs like load, latency etc for Router
> services(like
> DPI, CGNAT, IPSEC)
> may not be the scope of this extension. This is a good extension for
> host
> to host architecture.
> 
> 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
> Vathsa>>>
> For some TCP applications, opening a connection on well-known port is
> liveliness.
> For some UDP applications, receiving greeting message is liveliness.
> For some applications like HTTP, DNS it can be one 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
> 