Classification offload is used to overcome the scalability limitations of in-place classifi-cation. These offload mechanisms push classification-related processing from classifiers to other entities with more semantic context or available processing resources per packet.
Different classification applications employ different application-specific offload solutions – for example, MPLS, Diffserv, and HTTP cookies. The lack of a generic classification
offload solution and the ad-hoc nature of existing solutions increases configuration hardness, and hampers network flexibility and efficiency.
In this section, we first describe various application-specific offload solutions. We then describe their limitations.
2.3.1 MPLS
Core routers typically have more total processing power than edge routers. However, a core router encounters substantially greater volumes of traffic per second than an edge router. As a result, a core router can afford to spend lesser time processing each packet than an edge router, inspite of having greater processing capabilities in aggregate.
Route lookup is the main classification activity of a router. Increasing number of autonomous systems and multi-homing have greatly increased routing table sizes at core routers [65, 77, 78, 80]. Consequently, the complexity of route lookup has significantly in-creased. Additionally, traffic engineering policies often add more complexity to a router’s classification operations.
Core routers use MPLS [25] at layer 2.5 to offload expensive route lookup and traf-fic engineering decisions to edge routers. Using a label distribution protocol [21], network administrators configure edge routers to add different labels to packets based on their des-tination IP address and the traffic engineering policies they match. The label distribution protocol also establishes next hop tables mapping labels to output interfaces at core routers.
A downstream core router can thus easily determine a packet’s next hop by looking up its label in its next hop table. Exact matching based label lookup is much simpler than longest prefix matching based route and traffic policy lookup. In this way, a core router improves its scalability by shedding some of its classification load to edge routers.
2.3.2 Diffserv
Most routers can provide different qualities of service (QoS) to different types of traffic.
For example, a router may accord high forwarding priority to VoIP traffic and low priority to data backup traffic. To provide different QoS to a packet, a router must first classify its traffic type and retrieve the appropriate QoS policy. Routers commonly identify traffic types by looking at packet transport port numbers or by looking deep into packet payloads.
These are complex operations that hinder the router’s scalability.
Routers use Diffserv [2] to push the identification of a packet’s QoS requirements to endhosts and ingress routers. Endhosts and ingress routers use local application context, QoS policies and traffic statistics to determine a packet’s QoS requirements. They convey the packet’s QoS class to downstream routers by setting the DSCP bits in its layer-3 (IP) header. A downstream router simply uses the DSCP bits to determine how the packet should be forwarded. As in the case of MPLS, it improves scalability by avoiding complex rule matching.
2.3.3 HTTP Cookies
An HTTP session may consist of multiple HTTP and HTTPS connections. For ex-ample, an HTTP session involving an online shopping experience includes multiple HTTP connections for browsing and adding items to the shopping cart, and HTTPS connections for payment and shipping information. If the application servers are stateful, then a load balancer must send all connections in a session to the same server instance for semantic correctness. Otherwise, shopping cart contents may be corrupted, or the server may lack the correct SSL connection parameters. Even if application servers are stateless, sending all connections to the same instance facilitates performance improvements through caching.
One simple strategy for the load balancer is to send all packets with the same source IP address to the same application server instance. This strategy has two limitations:
1. Different connections within an HTTP session may not have the same source IP
address. TCP connections from hosts in a home ISP network are often load balanced across multiple proxies or NATs. A proxy or NAT rewrites a packet’s source IP address with its globally routable IP address. Hence, the simple of strategy of relying on source IP addresses does not ensure that the same server instance is selected for all connections in a session. This problem is often called the AOL Mega Proxy problem [40, 11].
2. Relying solely on source IP addresses may result in coarse-grained load balancing and cause load skew. Connections from a large number of hosts behind a NAT or proxy will have the same source IP address. Sending all these connections to the same server may overload it.
Since source IP addresses are insufficient, load balancers currently rely on direct endhost support. A load balancer uses HTTP cookies [15] to offload HTTP session identification to the endhosts. When the load balancer sees an HTTP request without a cookie, it inserts a new cookie into the HTTP response. The cookie identifies the webserver instance selected for this session. The application, say web browser, at the endhost has local and semantic context to identify the multiple HTTP/HTTPS connections in an HTTP session. It includes the same cookie value in subsequent connections of the session. The load balancer reads the cookie value by reconstructing the transport stream and parsing the application, i.e., layer-7 headers. From the cookie value, it determines the server instance to be used for the connection.
2.3.4 Limitations
Each of the classification offload mechanisms described above is a point solution tailored to a particular application and operating at a single layer. The following are their three main limitations:
1. Configuration Hardness
A network administrator must separately implement and configure the different
clas-sification offload mechanisms corresponding to different applications. This increases network configuration complexity, and increases the probability for errors arising from the interactions between different mechanisms.
2. Inefficiency
Some offload solutions rely on expensive deep packet inspection. For instance, a load balancer must reconstruct the transport stream and parse layer-7 HTTP headers to simply read the HTTP cookie value. Such expensive operations are not a funda-mental component of classification offload, but are simply inefficiencies of the current mechanisms.
3. Inflexibility
Current offload mechanisms are inflexible since they are tailored to a specific applica-tion and protocol layer. A new classificaapplica-tion applicaapplica-tion will require re-inventing and deploying similar offload mechanisms. Due to the difficulty and costs of such re-design efforts, many applications are deprived of the benefits of classification offload.