Welcome to the world of Infosys Engineering! It is a half a billion plus organization that takes pride in shaping our engineering aspirations and dreams and bringing them to fruition. We provide engineering services and solutions across the lifecycle of our clients’ offerings, ranging from product ideation to realization and sustenance, that caters to a cross-section of industries - aerospace, automotive, medical devices, retail, telecommunications, hi tech, financial services, energy and utilities just to name a few major ones.

« May 2012 | Main | August 2012 »

July 24, 2012

The Business Use Cases of Software Defined Networking

Guest Post by
Saurav Kanti Chandra, Senior Technology Architect, Engineering Services, Infosys

The use case behind the invention of OpenFlow was accessing the flow and routing tables from internet routing for educational experimentations. SDN was all about OpenFlow in 2009. Today it has a much broader meaning. The wider applicability of SDN is rooted from its capability of abstracting network from topology and programming the network from a centralized management. 
Following are some business use cases of SDN:

Use case 1: SDN can be used to complement network virtualization (in marketer's term Network-As-A-Service). The traditional way of configuring the physical network for virtual machines is not elastic due to limitation in VLAN extensibility. SLA configuration for security, isolation and bandwidth is not capable of scaling out due to lack of flexibility in creating firewall rules, ACLs, policies and VPNs. Although network overlay architecture and newer protocols (VXLAN, NVGRE, VCDNI, NVO3) are there to somewhat alleviate the scaling pain, SDN addresses the pain point in a lot more profound way. In a nutshell, SDN makes it really easy to slice a physical network into virtual customized pieces and make that elastic (or on-demand).

Use case 2: SDN can be used in datacenter networking and cloud hosting infrastructure. It helps in hosting a multi-tenant datacenter on a common physical network infrastructure. SDN has the capability to insert new network services, integrate with layer 4+ services, steer per tenant basis traffic, control QoS and manage security. Servers have been virtualized and the virtual entities can migrate across datacenters for workload balance. The workload mobility can be extended deep into lower layers of network with help of SDN. 

Use case 3: Carriers are trying for years to provide a superior customer experience. They are making the network aware of the services offered. They are automating the monitor-action-control cycle by using deep packet inspection probes, scripted configurations and layer 4+ switches.  Eventually they are extending the automation benefits to customers in terms of service fulfillment and service assurance.    SDN empowers carriers to achieve the same objective in an easier way. A part of the SDN remains intrinsic to the network boxes (SDN API provider) and the other part gets used in applications (SDN API consumer). The innovative applications ensure customer experience through multiple software layers of orchestration. Steering traffic as per service requirement, optimizing the resource usages, shutting down a part of network during off-peak hours to save energy cost, elastically provisioning bandwidth are a few use cases of this. SDN can be used in the mobile access network for unifying LTE / 4G with offload ready Wi-Fi networks and in integrating technologies such as HotSpot 2.0.

Use case 4: Campus networks, especially the wireless LAN has already moved to the direction where control and access are separated. Hundreds of light weight access points are controlled and managed by a centralized controller over layer 2 or layer 3 tunnels. SDN can help in a better manageability by helping in rolling out newer services, bringing in openness from the vertically integrated and proprietary layers of network.

Finally, the timing is great. This is the time of hyper scale growth in data center usage, cloud services infrastructure, mobile broadband, mobile devices, BYOD. This is the era of "Big Data". All it means that datacenters need to utilize its assets to the fullest, network pipe bandwidth is to be used to the fullest, provisioning needs to be dynamic and a centralized management needs to tie all open ends.  A careful inspection will yield a lot more use cases in all of these where SDN undoubtedly plays a bigger role.

July 17, 2012

The Current State of Affairs of Software Defined Networking

Guest Post by
Saurav Kanti Chandra, Senior Technology Architect, Engineering Services, Infosys

Defining something by software is not a path breaking concept. We have always been doing this more and more smartly and bringing out the best architecture, design and technology to define an idea into a solution. Then why the world of networking is abuzz with the concept of "Software Defined Networking" (SDN)? The answer is twofold. The first point, SDN is not a single software solution. It is a concept to introduce programmability - a key attributes of software - into a hitherto closed arena of routing and forwarding in a network.  The second point, the timing is great as this is the time of hyper scale growth in data center usage. It can easily relate to a multitude of current day challenges faced in the networks of datacenter, hyper cloud, enterprise, campus and carrier.

In 2009, Kate Green introduced the term "Software Defined Networking" as one of the 10 emerging technologies (popularly known as TR10) in MIT publication "Technology Review (TR)". The context was a standard called OpenFlow,  developed by Stanford computer scientist Nick McKeown and his colleagues, which enables software to define the rules that tell switches and routers how to direct network traffic. Three years down the line, SDN remains firm on the objective of decoupling network traffic processing from the controlling logics and rules, but has extended its armor from OpenFlow to many other case specific strategies across the SDN ecosystem and value chain. There are interesting SDN strategies from proprietary Network Equipment Vendors as well.

The million dollar question in everyone's mind now is what will be the market adoption of various avatars of SDN. OpenFlow, representing SDN from its limited perspective, is the only official standard available and is placed by Gartner in Technology Trigger phase of hype curve in 2011 with less than 1% adoption. However, the Open Networking Summit held in April 2012, showed a huge interest on SDN from industry heavyweights and venture capitalists. IDC has forecasted a growth of SDN market (switching, routing, services & software) from 168 million USD in 2013 to 2 billion USD in 2016.  I think coming six months will be the phase to find the business use cases, different market and solution approaches and a frantic search for the "killer application" which can take some forms of SDN in main stream adoption.

The original problem was the limitation of accessing the flow and routing tables from internet routing. Nevertheless, if the network is abstracted from its topology and can be programmed remotely from a centralized management, it is usable in multitude of scenarios.

Servers have already been evolved to a dynamic and open value chain years ago and have been effectively capitalized by virtualization techniques.  SDN is helping network to follow the footsteps of server world. We like Big Macs.. err.. software because it has tantalizing idea of multi-layered value adds. We are loving software defined networking because the value added layers here are on the network.

Let's join the propel heads of the networking world and co-create the much coveted programmable network platform and much cherished killer application which will bring SDN to main stream adoption.

JEE: Server Performance and Configuration -Part 2

  1. Guest Posted by

Anupindi Ravi Shankar, Senior Technology Architect, Manufacturing,Infosys Limited.

In my previous blog post, we talked about WebSEAL configuration settings for performance improvement. In this blog we will discuss on the performance related configuration settings for IBM HTTP server.


Going by the Internet definition,  IBM HTTP server (IHS)  is a full-featured, cross platform enabled  Web server, based on Apache HTTP server (httpd.apache.org)  that runs on AIXHP- UX ,Linux, Solaris, Windows NT and z/OS.

An often and the most common scenario in JEE web applications deployment is that the web server is under utilized by making it as a mere load balancer before the application server cluster. Almost all web servers and especially IBM HTTP server provides many OOTB configurations to improve the web application response time and thereby improving the overall application performance.

In the below depicted illustrative deployment view of JEE web application, IBM HTTP server acts as a load balancer for the application server cluster. If you notice, IBM HTTP server layer itself is clustered enabled to provide high availability and to avoid the single point of failure. We will not be talking about clustering and other deployment related aspects in this blog but would focus mainly on the other capabilities provided by the IBM HTTP server.


secondBlogPost.jpg                                            Fig1: illustrative Deployment view of the Web Application

Any typical web UI page is composed of the following UI elements in JEE world.

1.       JSP template pages.

2.       External JavaScript files (JS).

3.       Cascading style sheets (CSS).

4.       Images (jpg/png/tif etc.)

Browser makes a separate GET request (as seen in the below snapshot) to download each of the static files from the server. Each such request puts extra burden on application server resources like thread pool, memory, I/O and CPU.In most of the cases the amount of time it takes to process each such request is comparatively high which leads to high response time of the web page.


 The better deployment option would be to host the static files on a separate JVM and free application server from serving the static content. This separate JVM can be none other than the web server itself.

The question still prevails is how the new JVM or web server help in reducing the number of GET requests made by the client browser. After exploring many of the configuration capabilities provided the IBM HTTP server, I found the following two configuration options to be most useful and satisfying the desired need.

1.       Gzip of static content.

2.       Static content caching.

Before I talk about the two configuration settings, it is very important to know that there are 2 different ways to make configuration settings to the IBM HTTP server. The first option is to make changes directly to the main configuration file (i.e. httpd.conf) and the second is to use .htaccess files. The second method allows making configuration changes on a per-directory basis.

secondblogdisclaimer.jpg Since my experience is with httpd.conf file, I will show how to make configuration settings in this file.

Gzip of static content

Gzip mainly refers to the file compression and decompression technology which is based on DEFLATE algorithm (combination of Lempel-Ziv and Huffman coding).It compresses and thereby reduces the size of the static files like JavaScript and CSS.

To enable HTTP server for Gzip following configuration need to be done in the httpd.conf file.

1.       Uncomment the following line

                LoadModule deflate_module modules/mod_deflate.so

2.       Add the following to compress html, plain text, javascript, CSS and JSON MIME types

<IfModule mod_deflate.c>

     SetOutputFilter DEFLATE

     AddOutputFilterByType DEFLATE text/html text/plain text/css application/x-

    javascript  application/json


Mod_Deflate module provides many other capabilities as shown below:-




BrowserMatch  Directive


By-pass Image compression


Input decompression


Dealing with proxy servers


Setting the compression level

For details pertaining to each of the above settings please refer to the following Apache link

Static content caching

IBM HTTP server provides the following capabilities to cache the static content.

1.       Module Expires Header to cache the static content at the browser level.

2.    Module cache and mem_cache to cache static content by the web server.

Module Expires Header to cache the static content at the browser level

To enable Expires Header directive following configuration need to be done in the httpd.conf file.

1.       Uncomment the following line

                 LoadModule expires_module modules/mod_expires.so

        2.   Add the following expires_module

              <IfModule expires_module>

                ExpiresActive On
               ExpiresDefault "access plus 1 month"
               ExpiresByType text/html "access plus 1 month 15 days"
               ExpiresByType image/jpeg "access plus 1 month 15 days"
               ExpiresByType image/jpg "access plus 1 month 15 days"
               ExpiresByType image/gif "access plus 1 month 15 days"
               ExpiresByType image/png "access plus 1 month 15 days"
               ExpiresByType application/x-javascript "access plus 1 day"
               ExpiresByType text/css "access plus 1 day"


In the above configuration I have specified ExpiresByType for different MIME Types.For images and html files the ExpiresByType is set to 45 days from the current date and for JavaScript and CSS files it is set to 1 day. This setting enables the web server to intercept the response header of the matching MIME types and add the Expires attribute. The updated response header will have attribute like this...

Expires: Wed, 17 Sep 2012 21:32:10 GMT

..which indicates to the web browser to cache the corresponding MIME type in its internal cache for the stipulated period of time as mentioned in the Expires attribute. In the above case the browser will cache the corresponding file till 17th September 2012 and will not send any GET request for it and serve the content from Cache. If all the static contents are cached like this then the number of GET requests send by browser will be reduced drastically, thereby improving the response time of the application.

In the above configuration, the expires header are generalized for all MIME types. There can be a scenario where we want to specify different expiry time for static contents of a particular directory without mixing them with the main configuration settings.IBM HTTP server also provides the capability to specify different expiry time for static contents. It can be achieved by adding the corresponding directory to the <location element as shown below:-

<Location /img>
ExpiresActive on  
ExpiresDefault "access plus 2 hours"

The above configuration specifies that all the images in the /img folder should have the Expires header value set as 2 hours from the access time. It boils down to the fact that the browser will cache these images of this directory for 2 hours and after 2 hours they will again be downloaded from the server. Within 2 hours all the requests for these images files will be served from the browser cache.

The drawback of the above approach is that, it increases the possibility of browser serving the stale content if the corresponding static files are changed on the server. To prevent browser from serving the stale content we can do one of the following:-

1. Enable ETAG in the web server configuration settings.
2. Append timestamp or some unique identifier to the static content URL

Module cache and mem_cache to cache static content by the web server

IBM HTTP server provides the in-memory caching of the static content to further improve the response time to serve the static content. In the absence of in-memory caching I/O operations are performed to serve the static content requests.

To enable mod_cache and mod_mem_cache directives following configuration need to be done in the httpd.conf file

1. Uncomment the following lines
         LoadModule cache_module modules/mod_cache.so     
         LoadModule mem_cache_module modules/mod_mem_cache.so

2. Add the following mod_cache and mod_mem_cache

<IfModule mod_cache.c>
CacheMaxExpire            172800
CacheIgnoreCacheControl   on
CacheEnable   mem /ProductImages

<IfModule mod_mem_cache.c>
MCacheMaxObjectCount        10000
MCacheMaxObjectSize            1000000 
MCacheMinObjectSize             0
MCacheSize                                  512000 
MCacheRemovalAlgorithm   GDSF (Greedy-Dual Size Frequency)

For in-depth details of each of the above configuration settings please visit the following Apache link

I hope these HTTP server configurations will come in handy when you are working on performance engineering for your Web Application. Do share with me your experience after using them.

In the next one, I will talk about remaining performance configuration settings for IBM HTTP server.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter