Seamless Access to Services for Mobile Users

Jennifer RexfordPrinceton University

http://www.cs.princeton.edu/~jrex

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 hosts3

IMP 0h1

h2

IMP 1

h4

h3PDP-11

SDS Sigma SDS 940

UCLA Stanford

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

6Allow 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 <interface address, flowID> pairs–Delivers data as instructed by the transport layer–Each end demultiplexes on its own identifiers

9

sC sS

a1

a2

a3

Host C Host S

a4

Resolving and Connecting

First packet from transport carries serviceID and its

response provides remote IP address

SYN serviceID XSYN serviceID X SYN-ACK IP addressSYN-ACK IP address

Browser

TCP

IP

a1 a2

Local flowIDLocal flowID Local & Remote flowIDLocal & Remote flowID

connect(fd, X)

Solution #3: Inband Signaling

• Notify remote end-point about changes– Send RSYN to the remote <interface address, flowID>– Indicate the new local <interface address, flowID>– For client mobility, VM migration, and interface switching

sC sSfS2

fS1fC1

fC2

a1

a2

a3

Host C Host S

a4

Putting it All Together

IP:port

IP:port

IP

a1 a2

http://service.com/http://service.com/

serviceID

flowID

IP

a1 a2

http://service.com/http://service.com/

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 (70-425 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

16http://www.cs.princeton.edu/~jrex/papers/serval11.pdf