Transcript services

Seamless Access to
Services for Mobile Users
Jennifer Rexford
Princeton 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
ftp, telnet
SDS Sigma
h1
PDP-11
IMP 0
h2
UCLA
SDS 940
h3
IMP 1
h4
Stanford
• Naming, addressing, and routing on end hosts
3
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
3G
WiFi
Separate service, connection, and interface naming
5
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
Allow automatic, dynamic updates during a connection
6
Serval: Rewiring the End-Host
Network Stack for Online Services
7
Solution #1: Service Naming
• Applications should name services explicitly
connect(fd, serviceID)
bind(fd, serviceID)
listen(fd)
Network stack must
resolve service to
instance for client
Network stack
must advertise
service for server
8
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
a1
a3
sC
sS
a2
Host C
a4
Host S
9
Resolving and Connecting
connect(fd, X)
Browser
TCP
First packet from
transport carries
serviceID and its
response provides
remote IP address
IP
a1
a2
SYN serviceID X
SYN-ACK IP address
Local flowID
Local & Remote flowID
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
fC
sC
a1
a3
fS1
1
fC
2 C
Host
a2
a4
fS2
Host S
sS
Putting it All Together
Serval introduces a layer of indirection and defers mapping to
topological identifiers until communication is established
http://service.com/
http://service.com/
IP:port
Application
serviceID
IP:port
Transport
flowID
IP
Network
IP
a1
a2
a1
a2
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
http://www.cs.princeton.edu/~jrex/papers/serval11.pdf
16