Seamless Access to Services for Mobile Users Jennifer Rexford Princeton University Joint work with Matvey Ayre, Mike Freedman, Prem Gopalan, Steven Ko, Erik Nordstrom, David Shue

The Internet Does Not Meet the Needs of Online Services 2

Yesterday: Host-Centric Network ARPAnet was designed for resource sharing Naming, addressing, and routing on end hosts 3 IMP 0 h1 h2 IMP 1 h4 h3 PDP-11 SDS SigmaSDS 940 UCLAStanford ftp, telnet

Today: Service-Centric Internet Internet is now a platform for accessing services Services not tied to a particular host or location 4

Challenge #1: Multiplicity Distributed server replicas –Early binding of domain name to an IP address –Load balancers spreading load over the server replicas Multiple interfaces and paths –A connection can only use one interface on each host –Traffic flows over a single path 5 3G WiFi Separate service, connection, and interface naming

Challenge #2: Dynamism Client mobility –Seamless connectivity requires “triangle routing” –Connection cannot switch between interfaces Virtual machine migration –Only within a layer-2 domain –… not across subnets or data centers Server replica failure/recovery –Ad hoc updates to load balancers and DNS servers –IP address caching causes temporary outages 6 Allow automatic, dynamic updates during a connection

Serval: Rewiring the End-Host Network Stack for Online Services 7

Solution #1: Service Naming Applications should name services explicitly 8 connect(fd, serviceID) bind(fd, serviceID) listen(fd) Network stack must resolve service to instance for client Network stack must advertise service for server

Solution #2: Flow Naming Connection consists of multiple flows –Identified by pairs –Delivers data as instructed by the transport layer –Each end demultiplexes on its own identifiers 9 sCsC sSsS a1 a2 a3 Host CHost S a4

Resolving and Connecting First packet from transport carries serviceID and its response provides remote IP address SYN serviceID X SYN-ACK IP address Browser TCP IP a1a2 Local flowID Local & Remote flowID connect(fd, X)

Solution #3: Inband Signaling Notify remote end-point about changes –Send RSYN to the remote –Indicate the new local –For client mobility, VM migration, and interface switching sCsC sSsS f S2 f S1 fC1fC1 fC2fC2 a1 a2 a3 Host CHost S a4

Putting it All Together IP:port IP a1a2 serviceID flowID IP a1a2 Serval introduces a layer of indirection and defers mapping to topological identifiers until communication is established Application Transport Network

Prototype Implementation End-host network stack –Multi-platform (Linux, Android, BSD) –Runs in user space and in the kernel –Decentralized service discovery Ported applications –Iperf, TFTP, PowerDNS, Wget, Elinks, Firefox, Mongoose, Memcached, ApacheBench –Small code changes ( lines of code) Experiments –Competitive throughput with today’s TCP –Fast failover, load shedding, and VM migration 13

Incremental Deployment No changes to the network layer –Packet delivery based on IP addresses –IP addresses correspond to interfaces –Scalable routing based on hierarchical addresses Resolution of service names –Domain Name System (DNS) and front-end proxies –Later, routing first packet based on serviceID Unmodified hosts and applications –Proxies in front of clients or servers –Address translation in the network stack 14

Related Work Separating identity from location –By naming hosts: LISP, HIP, i3 –By naming services/data: SFR, LNA, DONA, CCN Migration/Mobility –Through indirection: Mobile-IP –Through in-band signaling: TCP Migrate Main differentiators of Serval –Comprehensive solution for online services –Solution that focuses on the end-host stack 15

Conclusion Service-centric networking –Multiplicity: multiple servers, interfaces, and paths –Dynamism: mobility, migration, and failover Rewiring the end-host stack –Resolving and registering service names –Connections consisting of multiple flows –Inband signaling to migrate flows to new addresses Without changing the network layer –Runs on top of IP addressing and packet delivery 16