Re: [ippm] Addressing Greg and Al's queries on drafts : draft-spv-ippm-monitor-implementation-services-kpi & draft-spv-ippm-monitor-methodology-services-kpi

[Srivathsa Sarangapani <[e-mail]>]

Hi Greg,

Thanks for your comments.
Let me try clarifying your questions inline and the need for why we are proposing TWAMP :

—
Regards,
Vathsa


From: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 18, 2015 at 8:17 AM
To: Srivathsa Sarangapani <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Peyush Gupta <[e-mail]<mailto:[e-mail]>>
Subject: RE: [ippm] Addressing Greg and Al's queries on drafts : draft-spv-ippm-monitor-implementation-services-kpi & draft-spv-ippm-monitor-methodology-services-kpi

Hi Vatsha,
many thanks for your thoughtful  consideration of my comments and the most detailed explanation of your proposals.
I think that you have formulated targeted requirements based on real use cases.
Vathsa>>>>Thanks a lot for going through my mail and coming back with questions.

But I don’t think that TWAMP is the right tool to address these requirements.
Vathsa>>>>Good that whatever we are discussing is a part of IPPM WG charter.

I think that some use cases may be addressed with already available tools, e.g. ICMP ping, TCP ping, and HTTP ping.
Vathsa>>>>I agree that ICMP ping, TCP ping, HTTP ping solves some part of the problem.
Http ping verifies if the http server(and the daemon) is really running or not. But if the customer wants to know what is the rtt between http server and some other node, then http ping will not get that value. Then he needs to run TWAMP session separately. Instead why not piggyback the http req along with TWAMP data payload and both the things are achieved at one shot. Http was just an example. It can be any service like DNS or even some proprietary services also.

In near future, the scenario could be that the in-between network is all based on SDN. So the network operator will definitely be interested to know the RTT in real time, the liveliness and also possibly the http server response latency.
The proposed extension would give these values seperately and this will surely help the network operator to optimize the necessary chunks in his domain.

Some, e.g. related to SFC, may require extensions to existing tools (like draft-ietf-mpls-residence-time<https://tools.ietf.org/html/draft-ietf-mpls-residence-time-00>) or new protocols.
Vathsa>>>>Not sure whether the draft covers non-mpls stuff.
Instead of a new protocol what is STOPPING US TO EXTEND TWAMP TO ACHIEVE THE MISSING FUNCTIONALITY.


                Regards,
                                Greg

From: ippm [mailto:[e-mail]] On Behalf Of Srivathsa Sarangapani
Sent: Wednesday, December 16, 2015 6:28 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Peyush Gupta; Srivathsa Sarangapani
Subject: [ippm] Addressing Greg and Al's queries on drafts : draft-spv-ippm-monitor-implementation-services-kpi & draft-spv-ippm-monitor-methodology-services-kpi

Hi Greg and Al,

Regarding the drafts: draft-spv-ippm-monitor-implementation-services-kpi  & draft-spv-ippm-monitor-methodology-services-kpi we had presented 3 use cases.
I am attaching the slides which we presented in the Yokohama meet. Please refer slides 5,7 & 9 which is being discussed here.

Greg had some questions on how this could be implemented and some questions on whether we are deviating from the behavior of TWAMP/IPPM WG.
Also Al wanted to get some more details on how this could be achieved. Below are the details:

We are not deviating from the IPPM WG's charter: https://datatracker.ietf.org/wg/ippm/charter/
The WG will seek to develop new metrics and models to more accurately characterize the network paths under test and/or the performance of transport and application layer protocols on these paths.
We are using the payload part of TWAMP which is currently not used. So basically we are effectively using the TWAMP data part.

We had presented 3 use cases in the meeting and below is the details of how we could achieve them:

I would like to take the use case of service latency and explain how it could fit in in the TWAMP world.
The TWAMP Client/Session Sender will embed the service PDU as a part of TWAMP Payload.
Currently TWAMP session reflector part might be implemented in data path of routers.
Just note that the Server part will still be implemented on the control path.
With this extension the timestammping part of Session Reflector would be in the data path and it could punt the TWAMP data packet to control path after timestamping it.
The other part of session reflector on the control path would now extract the service PDU from the TWAMP Payload, inject it to the service module.
The injecting of service module can be broken into below steps:
  - Control path would inject the packet to data path.
    On data path, it should note down the time(say T5) at which this packet is injected to service module
  - The service module will apply services on this PDU and once service processing is done, it would later send it back to data path.
  - In the data path, once this serviced PDU is received, the time(say T6) should be again noted and this packet injected back to Session Reflector on Control Path.
    The T5 and T6 can be informed via the reply packet itself or via some cookie based on the implementation.
  - The Session Reflector can now reply back with the actual TWAMP data packet to the TWAMP client/session sender.
  - Now the TWAMP client after receiving the packet back can calculate the service latency, which would be T6-T5.

Second use case is extending TWAMP to check liveliness of an Application along with the RTT. Say the TWAMP client want to know if HTTP server is alive or not.
The TWAMP Client/Session Sender will embed the HTTP Req as a part of TWAMP Payload.
Assuming the TWAMP Client/Server is implemented on Linux server, it might be using SO_TIMESTAMP(http://lwn.net/Articles/325929/) timestamping feature available.
With this extension, once when the server receives the TWAMP data packet, it could get the received timestamp from the kernel via cmsg header and would record the same.
Now the TWAMP module can call a third party exposed API/function to find out whether the Application under interest is Live or NOT.
For instance if it is a HTTP server, then TWAMP server could just use the open source module : libcurl .
The HTTP Request would be extracted from the TWAMP data packet and this will be injected using the libcurl library.
Once the HTTP response packet arrives, then it is sure that the http server is working. Till the response packet is received the TWAMP server would not respond back to the client.
There can be some timeout based on the application and if the response is not received within that time or if negative response is received, then it can be concluded that there is some issue with the HTTP server.
Once the HTTP response is received back, the TWAMP server will embed the HTTP response inside the TWAMP data packet and reply back to the TWAMP client/Session Sender.
So with one TWAMP probe both the RTT and the liveliness of the HTTP server can be figured out.
Please note that HTTP is just an example, it can be any other standard application like DNS etc or it can be any vendor specific application. The TWAMP is agnostic to any kind of application which it would be checking the liveliness. Also note that along with Liveliness the service latency can also be calculated in this case.
It is also possible that the Application is running on a different Physical or Virtual Machine altogether. The only requirement is that the API registered to TWAMP server should be able to send the request packet to the Application and receive the response packet from the application.
So NOW the Network admin with this extension, can understand the latency of the network, liveliness of an application and also the service latency of the application using active measurement. Based on these values he could optimize his network.


Third use case is extending TWAMP to get the session load of an Application along with the RTT. Say the TWAMP client is running on a TLB(Traffic Load Balancer)/SLB(Server Load Balancer) and want to know the session load on the Real Servers. TLB/SLB is a load balancer used to load balance the incoming traffic for the real servers. Today, it uses different means to know if the real server is running/alive or NOT and different methods to get the load on the Real server. So basically there are 2 different set of messages/means to achieve on goal of load balancing. Why can’t TWAMP be extended to club both the use cases to one?
The TWAMP server/Session Reflector will be running as a part of Real Servers.
With this extension, once when the TWAMP server receives the TWAMP data packet, it could get the received timestamp from the kernel via cmsg header and would record the same. Now the TWAMP server module can call a third party exposed API/function to find out the session load.
The exposed API can just be a callback function, or it could be some CLI/shell command/script which could be executed to know the session load. The output of the shell script/CLI command could be embedded inside the TWAMP data packet and replied back to the TWAMP client/Session Sender.
So the SLB/TLB can get the below info in one messages :
  - Is the Real Server up or not
  - The RTT between SLB/TLB and Real Servers
  - The session load on each of the Real Servers
It is also possible that the Real Servers can be Physical Servers or just an instance of a Virtual Machine.
W The only requirement is that the API registered to TWAMP server should be able to send the request packet to the Application and receive the response packet from the application.
So NOW the Network admin with this extension, can understand the latency of the network, liveliness of an application and also the service latency of the application using active measurement. Based on these values he could optimize his network.

With SDN kicking in, there is a good chance that some in between routers/switches are virtual routers and switches and the application is running as a part of VNF(Virtual Network Function). All the above use cases makes lot more sense when some part of network is virtualized.
In these environments it makes lot more sense to get service latency along with RTT and this will give clear indication to the Network Admin so that he can optimize the network.

Greg, Al, others request you to please have a look and comment on these drafts.

--
Regards,
Vathsa