Deployability

Deployability of GOff depends on the incentives offered to participating entities, the ease with which existing applications can be supported, and the amount of administrative control over the deployment domain (for instance, open Internet versus tightly controlled data center).

Classifiers are incentivized by the new functionality and complexity reduction enabled by GOff. Similar to incentives for participation in TCP congestion control, helpers are incentivized by the promise of better performance (i.e., higher throughput, lower latency) from their local firewalls, first hop routers or load balancers at websites they visit. However, a helper is less incentivized to participate, irrespective of lower performance, when it has a conflict of interest with a classifier. For instance, an end host has a conflict of interest with a remote firewall that wishes to drop its packets. Within a single administrative domain, GOff adoption may be ‘forcefully incentivized’, i.e., mandated.

GOff deployability also depends on its ease of implementation and integration into exist-ing networks. GOff requires modifyexist-ing helpers and classifiers. The close similarity between the GOff and BSD socket libraries and the small number of lines to port existing applications demonstrate that GOff can be easily integrated into existing applications. GOff daemon functionality can be embedded in future OS versions or can be installed as a standalone system service (as described in Section 6.3).

An Internet-wide GOff deployment does not require a fork-lift upgrade of the entire network. GOff traffic can co-exist with non-GOff traffic, and only entities wishing to benefit from the CLayer need to be upgraded. However, a GOff-enabled connection between two endhosts requires all classifiers and forwarding elements on the path between them to be GOff-aware or to ignore the CLayer headers and forward packets unmodified. For example, layer-2 switches and simple layer-3 routers simply forward GOff packets unmodified even though they are not GOff-aware. However, a non-GOff-aware layer-4 router or firewall may consider GOff packets as malformed/suspicious and thereby drop them. Such drops are possible even if the CLayer header is tucked into an IP option [57] rather than implemented as a separate layer. Hence, an endhost can open a GOff-enabled connection with another endhost only after running a path discovery protocol to ascertain GOff support.

A data center network is a more ideal candidate for GOff deployment than the wide area Internet. The single administrative domain enables us to easily modify endhosts, as advocated by other new data center network architectures like Monsoon [61]. Moreover, the multiple new data centers being built today [22] offer hope for a cleanslate GOff

imple-mentation. A proxy at the data center ingress can cleanly separate the data center network from the Internet, and adds the appropriate CLayer headers. The implementation of such a proxy that can scale to data center workloads is an open challenge. This approach however confines GOff functionality and benefits to within the data center. For example, we cannot offload HTTP session identification to endhosts in the Internet.

6.3 Implementation

We prototyped GOff using Click [72] and GOff-enabled a variety of helper and classifier applications. Table 6.1 lists the line count for the core GOff code (C++) and extra lines (C/C++) required to port existing applications.

The GOff implementation at a helper node consists of two parts – a daemon and a network socket library. The daemon implements the core GOff functionality, i.e., control plane signaling and data plane classification. Helper applications interact with the daemon through GOff socket library calls, as described in Section 6.1.2. In an ideal clean slate implementation, the functionality implemented by the daemon will be part of the OS net-work stack and the socket library will be direct system calls. However, in our prototype, the daemon is a userlevel Click router, with which the socket library interacts over a local TCP connection. The daemon uses the tun [93] device to intercept outgoing packets and to transfer incoming packets to regular network processing after stripping out CLayer headers.

GOff-enabling an existing helper application often simply involves replacing BSD socket calls with their GOff equivalents. For example, porting wget required changes in just 10 lines of code. GOff-enabling applications like the elinks web browser, which support richer semantics like HTTP sessions consisting of multiple TCP flows, requires slightly more work.

The application must remember the session handle for inclusion in clconnect calls for all TCP connections in the same session. Often, as in the case of elinks, we only need to augment existing session data structures in the application code with an extra field to store the GOff session handle.

Table 6.1. Lines of code of our prototype GOff implementation

Our prototype GOff implementation also supports unmodified helper applications, since its core functionality is implemented by the standalone daemon. However, classification semantics are restricted to those the daemon can infer without application input. For example, it cannot aggregate TCP connections into HTTP sessions. However, it can classify all packets originating from the same host. Such information can be used by simple layer-3 load balancers to correctly spread traffic. Unlike using source IP addresses, this method does not violate HTTP session stickiness nor causes load skew in the presence of NATs or Mega Proxies.

GOff processing in a layer-4 classifier like a QoS router mainly involves adding Class-Reqs, extracting CLayer headers from packets and using the embedded classification results to appropriately forward them. Using libraries from our core GOff code, we GOff-enabled existing Click modules implementing different classifier functionality in under 200 lines of code on average. GOff-enabling the haproxy layer-7 load balancer was similar to that of a helper application, albeit using some additional GOff socket calls to retrieve classification results from the daemon.

We used Google protobufs [13] to encode/decode CLayer headers, instead of designing our own header format. Although the dynamic nature of protobufs slightly increases header

size and encode/decode complexity over a fixed width format, it greatly increased the pace and ease of prototyping.