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

From: Srivathsa Sarangapani <[email-masked]>
Date: Mon, 8 Jun 2015 16:17:18 +0000

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.

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.

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

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

---

From: Dave Taht <[email-masked]>
Date: Mon, 8 Jun 2015 09:31:23 -0700

> (RFC 5357) to monitor service KPIs and monitor the liveliness of the

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

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

> lot of sense for the network operator for optimal network planning and

I agree that monitoring the effectiveness of these new technologies is
a goodness.

> more  VMs  for a services VNF when required and can shut down some of them

Well, more VMs does != less latency.

>
>
> --
> Thanks and Regards,
> Vathsa
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> 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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 8 Jun 2015 14:18:57 -0400

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:
> 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:[email-masked]] On Behalf Of Dave Taht
> Sent: Monday, June 08, 2015 12:31 PM
> To: Srivathsa Sarangapani
> Cc: [email-masked]
> Subject: Re: [ippm] Discussion on extending TWAMP to monitor service
> KPIs and detect liveliness of an application
> 
> > 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.
> > 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.
> 
> 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.
> > 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.
> 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.
> 
> > We therefore think that adding this new dimension to TWAMP protocol
> > would really be helpful for network monitoring and analysis.

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 9 Jun 2015 13:05:43 +0000

Hi Dave,

Thanks for your reply. Please see my answers inline:

-- 
Regards,
Vathsa

-----Original Message-----
From: Dave Taht <[email-masked]>
Date: Monday, June 8, 2015 at 10:01 PM
To: Srivathsa Sarangapani <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ippm] Discussion on extending TWAMP to monitor service KPIs
and detect liveliness of an 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).
Vathsa>>>
For RTT calculations the NTP synchronization should not matter.
Anyways the PTP(Precision Time Protocol) should provide more precision
than NTP which is being deployed of late.
For monitoring service KPIs like latency we are always interested in delta
and not the actual time stamps.
For other service KPIs like load, capacity we are not interested in time
at all.

Well, more VMs does != less latency.
Vathsa>>>I agree.
But just wanted to indicate that in some use cases,
when load(number of sessions) on a VM increases, there could be a
possibility of 
the service latency getting increased. So in such scenarios spawning new
VMs should help.

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 9 Jun 2015 13:20:31 +0000

Hi Al,

-- 
Regards,
Vathsa

-----Original Message-----
From: <MORTON>, "ALFRED C   (AL)" <[email-masked]>
Date: Monday, June 8, 2015 at 11:48 PM
To: Dave Taht <[email-masked]>, Srivathsa Sarangapani
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [ippm] Discussion on extending TWAMP to monitor service KPIs
and detect liveliness of an application

Hi Srivathsa and Dave,

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.

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

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Mon, 29 Jun 2015 16:44:16 +0000

Hi Dave,

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 <[email-masked]>
Date: Tuesday, June 9, 2015 at 6:35 PM
To: Dave Taht <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ippm] Discussion on extending TWAMP to monitor service KPIs

Hi Dave,

-- 
Regards,
Vathsa

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Mon, 29 Jun 2015 16:45:09 +0000

Hi Al,

-- 
Regards,
Vathsa

-----Original Message-----
From: Srivathsa Sarangapani <[email-masked]>
Date: Tuesday, June 9, 2015 at 6:50 PM
To: "MORTON, ALFRED C (AL)" <[email-masked]>, Dave Taht
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Peyush Gupta <[email-masked]>
Subject: Re: [ippm] Discussion on extending TWAMP to monitor service KPIs
and detect liveliness of an application

Hi Al,

-- 
Regards,
Vathsa

-----Original Message-----
From: <MORTON>, "ALFRED C   (AL)" <[email-masked]>
Date: Monday, June 8, 2015 at 11:48 PM
To: Dave Taht <[email-masked]>, Srivathsa Sarangapani
<[email-masked]>

Hi Srivathsa and Dave,

Vathsa>>>Good work.

regards,
Al

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 29 Jun 2015 21:19:10 -0400

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

> From: Srivathsa Sarangapani [mailto:[email-masked]]
> Sent: Monday, June 29, 2015 12:45 PM
> To: MORTON, ALFRED C (AL); Dave Taht
> Cc: [email-masked]; Peyush Gupta
> just
> > > some other attributes are to check whether a service node is alive
> or
> > not.
> > >
> just
> a

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 30 Jun 2015 04:44:42 +0000

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)" <[email-masked]>
Date: Tuesday, June 30, 2015 at 6:49 AM
To: Srivathsa Sarangapani <[email-masked]>, Dave Taht
<[email-masked]>

Hi Vathsa,

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