IntroductionThe Serval End-host StackOvercoming the Limitations of Today's Network StackService Names with a Group AbstractionRewiring the End-Host Network StackServal ProtocolsExplicit Service RegistrationLate Binding Through On-Path ResolutionIn-band Signaling Between EndpointsSecurityServal ImplementationService Access LayerTransport LayerNetwork InfrastructureEvaluationApplication PortabilityHost Stack and Router PerformanceCase Study: Large-Scale Web ServicesServal for Front-End Web ServicesServal for Back-End Distributed StorageServal for VM ManagementIncremental DeploymentRelated WorkConclusionsDraft Jan 31, 2011. Do not distribute.A Service Access Layer, at Your ServiceMichael J. Freedman, Matvey Arye, Prem Gopalan, Steven Y. Ko,Erik Nordstr¨om, Jennifer Rexford, and David Shue − Princeton UniversityABSTRACTHistorically, Internet services provided clients with accessto the resources of a particular host. However, today’s ser-vices are no longer defined by a single host or confined to afixed location. Yet, the network architecture continues to im-pose an unfortunate coupling between hosts and services bybinding connections to topology-dependent addresses, ratherthan topology-independent service names—complicating ev-erything from server replication, load balancing, and virtual-machine migration, to client mobility and multi-homing.In this paper, we propose a new service access layerthat redefines the interaction between the network and trans-port layers. This layer provides the “thin waist” needed toenable direct communication on service names, decoupleservice connections from network identifiers, and enhancethe network’s awareness of service availability. We presentServal—a complete architecture built around this new lay-ering that handles server replication, network dynamics, anddiverse service-discovery techniques, while ensuring scala-bility, security, and the efficient handling of churn. By run-ning squarely above the network layer, Serval remains fullybackwards compatible with today’s IP networks. We presentthe design, implementation, and evaluation of a Serval pro-totype, focusing on datacenter replicated services, includingseveral real applications.1. INTRODUCTIONThe Internet is increasingly a platform for accessingdiverse services that run anywhere from racks of serversin datacenters to computers in people’s homes, mobilephones in pockets, and sensors in the field, and maymove at any time. Online services such as Web search,social networks, and virtual worlds operate at massivescales over distributed infrastructure, while localizedservices like office printers, media servers, and sensorshave limited scope or constrained resources. However,the Internet was designed at a time when networkedservices were much less distributed or dynamic. Thishas led to a mismatch between the traditional host-centric model that binds connections to fixed hosts withtopology-dependent addresses and what services needfor server replication, virtual-machine migration, mo-bility, multi-homing, or dynamic addressing.Rather than solving the problems of service bind-ing directly, today’s approaches manipulate the networklayer, leading to restrictive and somewhat clumsy so-lutions. For example, in today’s online services, loadbalancers repurpose IP addresses to refer to a groupof (possibly changing) service instances. Unfortunately,this requires all client traffic (rather than just the ini-tial connection request) to traverse the load balancers.Techniques for handling mobility and migration are ei-ther limited to a single layer-2 domain or introduce “tri-angle routing”. Hosts typically cannot spread a con-nection over multiple interfaces, and switching betweeninterfaces requires applications to initiate new connec-tions. Such inefficient “work arounds” introduce un-wanted complexity to service design and management.One way to address these shortcomings is a “cleanslate” redesign of the Internet architecture. A completeredesign may, in fact, be necessary to address core prob-lems like poor network-layer security and limited sup-port for multipath routing. However, we argue that theproblems faced by modern services can be resolved with-out changing either today’s network layer or overall ar-chitecture, but rather by redefining how the layers abovethe network layer relate to the underlying network. Weargue that a new service access layer—between the net-work and a modified transport layer—is the right placeto provide a minimal interface to unified functionalityfor service resolution and connection management.The service access layer is part of our larger Servalarchitecture that allows applications to communicatedirectly on service names. Serval resolves an appro-priate service instance at its current location, main-tains flow affinity to a service instance across networkand address changes, and improves service visibility inthe network. Serval introduces a refurbished networkstack, a new service-oriented BSD sockets API, andscalable service-level anycast spanning multiple layer-3domains. Yet, Serval is designed to minimize changes toapplications. We have implemented Serval and portedten different applications, including web browsers (Fire-fox) and servers (Mongoose and the Apache runtime),and evaluated our support for virtual-machine migra-tion and service dynamism in a replicated web tier anda distributed in-memory caching service.Our design of Serval rests on four key principles:Applications should bind to service names: Aservice can correspond to a group of one or more (possi-bly changing) processes offering the same named func-tionality at one or more geographic locations. In con-trast, today’s application APIs bind to the location (IPaddress) of a specific service instance and to the proto-col and port that offer the service. This binding com-plicates the management of load-balancing and replica-tion, as IP addresses and ports have an indirect andtransient relationship to actual services.Connections should continue across networkdynamics: Today’s services are bound to topology-dependent addresses, restricting the ability of servicesto migrate, support device mobility, and exploit multi-homing and multipath routing. One solution is to routeon flat names [3], but such routing does not scale aswell as IP routing. Instead, ongoing service connectionsshould have a dynamic relation to underlying networkaddresses, (re)negotiating them as