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

[Srivathsa Sarangapani <[e-mail]>]

Hi Al,

Thanks a lot for browsing through our draft.
Sorry, if the explanation is not clear in the draft. Please see my answers
inline:

-- 
Regards,
Vathsa




-----Original Message-----
From: "MORTON, ALFRED C (AL)" <[e-mail]>
Date: Tuesday, June 30, 2015 at 6:49 AM
To: Srivathsa Sarangapani <[e-mail]>, Dave Taht
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Peyush Gupta <[e-mail]>
Subject: 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?
Vathsa>>>No. 
If this alone was solving the purpose, then TWAMP does this functionality
as of today.

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?
Vathsa>>>We mean to say that the TWAMP reflector module should extract the
Service PDU from the TWAMP data packet.
Please note that this Service PDU is filled by Session-Sender when it
sends the Test packet.
The Session-Reflector should inject the Service PDU to the Service Block.
Once the packet is received back at the reflector from the Service Block,
it will reply back to Session-Sender.
By this the Session-Sender is sure of 2 things:
   - The box where Session-Reflector is running is alive
   - The Service Block is also working fine.

Say for example, the HTTP server might be alive but the HTTP Server daemon
might not be working.
So these kinds of problems can be caught using our proposed extension.

Another example would be say a Router is running some Services like
CGNAT(JFLOW,DPI) outside the box as a VNF(say on a X86 cots server).
This router can run a TWAMP Session-Reflectot and using our extension, the
Session-Reflectore SHALL inject a test Service PDU to CGNAT VNF.
Based on the reply(possibly comparing the reply packet with expected
packet), the Session-Sender can really know if the CGNAT module is working
as expected or not.
Not just the liveliness, other service parameters like:
 - How many sessions are currently running a part of this VNF(to know the
current load on a VNF)
 - What is the extra latency being introduced for enabling CGNAT service
in a VNF.
These information can be the basis for the network operator to spawn more
VNFs or use some Service block inside the router for some gold customers
and use VNF for other customers etc.

Basically we want to aid the Network administrator with the live data
regarding Service Load, Service latency etc so that he can plan his
network for best results.

Please let me know if you need more info and we can provide the same.

Al

> -----Original Message-----
> From: Srivathsa Sarangapani [mailto:[e-mail]]
> Sent: Monday, June 29, 2015 12:45 PM
> To: MORTON, ALFRED C (AL); Dave Taht
> Cc: [e-mail]; 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 <[e-mail]>
> Date: Tuesday, June 9, 2015 at 6:50 PM
> To: "MORTON, ALFRED C (AL)" <[e-mail]>, Dave Taht
> <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, Peyush Gupta <[e-mail]>
> 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)" <[e-mail]>
> Date: Monday, June 8, 2015 at 11:48 PM
> To: Dave Taht <[e-mail]>, Srivathsa Sarangapani
> <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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:[e-mail]] On Behalf Of Dave Taht
> > Sent: Monday, June 08, 2015 12:31 PM
> > To: Srivathsa Sarangapani
> > Cc: [e-mail]
> > 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
> > <[e-mail]> 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
> > > [e-mail]
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ippm
>