What Makes a Good Content Switch?

As stated earlier, not all content switches are created equal. In this section, we will try to determine the architectural features and functionality that differentiate one switch from another. Most content switch manufacturers are able to provide basic functionality, but we will see that session handling and content inspection depth are key areas. We would like to point out here that each content switch has its merits, and while each can handle content switching in general, it is up to the individual to ensure that the content switch selected has the architecture, performance, and functionality to provide the required services for a particular network design.

Session Setup vs. Simultaneous Sessions

Now that we understand the importance of sessions within content switches and how they handle and manipulate them, we can now see why session setup is more important than sessions supported.

Most traffic sent across content switches is HTTP. This is because content switching was traditionally focused in the dotcom world and was usually used to load balance Web sites. While this is still the case, the versatility of content switches has ensured that they are used in many other applications as well. HTPP, although sent across a connection-oriented protocol such as TCP, is almost a connectionless protocol. Each object retrieved for a Web page or similar is seen as a TCP session. Therefore, the switch needs to set up the session, serve the object, and tear down the session again. With many Web pages having 80 plus objects per page, you can see that many sessions will need to be set up and torn down by the switch. With HHTP 1.1 this is not as common. However, with that kind of requirement, a content switch needs to be able to handle busy networks and content sites.

Having a low session setup rate can impact the performance of a network and severely delay user response times. Some content switch manufacturers promote simultaneous session support as the key area in order to mask their inefficiencies in the session setup arena.

Let's look at an example. In Table 10-1, we can see that while content switch manufacturer A only supports 500,000 simultaneous sessions, it can set up and tear down 300,000 per second. Content switch manufacturer B can support 2,000,000 simultaneous sessions but can only set up 10,000 per second.

Table 10-1. Session per Second vs. Simultaneous Sessions

	M ANUFACTURER A	M ANUFACTURER B
Maximum simultaneous sessions supported	500,000	2,000,000
Maximum sessions setups per second	300,000	10,000
Time taken to set up 300,000 sessions	1 second	30 seconds

As can be seen, the ability to set up and tear down sessions is far more important than maximum simultaneous sessions. While we are not saying that a small amount of simultaneous sessions is satisfactory, it is important to consider the application being used and the delay incurred by slow session setup. In a typical browser environment, a user will open four TCP sessions to retrieve content. As can be deduced , the low-end or slower content switches will require a larger session capacity in order to let the users complete their request before moving on to the next user. Delay can be a huge issue in any server farm environment, and this delay comes to the forefront when we begin to actually inspect the content within the data.

Layer 4 “7 Handling

Content switches can typically function extremely well when using Layer 4 information to make load balancing decisions. The reason for this is that the Layer 4 information is at a known point within the data packet and will never change. The source IP address, destination IP address, and source and destination TCP ports will allow x bits from the front of the Ethernet packet because they are resident in the IP and TCP headers and will never move ”just the values will be different. It is therefore easy to develop ASICs to inspect those headers by counting x bits and scanning 4 bytes, in the case of an IP address. Once the necessary information is found, the switch can then make a load balancing decision. This is why Layer 4 switching is becoming readily available, as this functionality can be done in hardware because the data that is required is constant.

This changes, however, as we look at different applications and as we move up in to the upper layers of the OSI reference model. What happens when data manipulation is required in the case of streaming media or FTP load balancing? Often, addresses embedded within the data portion of the frame need to be manipulated (typically to the VIP of the site) for load balancing to take place. This type of functionality requires both brains and brawn. It is here that content switches begin to differ .

The minute we cannot predict the information required, or need to delay the session to see what application or content is being requested , is when the content switch needs to stand up and be counted. It is the content switch that has to manage these sessions; it is the content switch that needs to scan the packet looking for the character, or sequence of characters configured. These tasks will traditionally put a huge overhead on any device. Again, these tasks and requests are session driven, so now it becomes imperative that a content switch set these sessions up quickly, scan or manipulate the required information, and then send it on to the selected backend server. Session setup again takes precedence over maximum sessions supported, as the need to get the information from the user, send it to the server, and then forward the response is key to the whole user experience. A slow network will not have many users, and if it does, it is unlikely that they are enjoying the experience.