1 / 16

Seamless Access to Services for Mobile Users

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.

hector
Télécharger la présentation

Seamless Access to Services for Mobile Users

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. The Internet Does Not Meet the Needs of Online Services

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

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

  5. Challenge #1: Multiplicity • Distributed server replicas • Early binding of domain nameto an IP address • Load balancers spreading loadover 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

  6. 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

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

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

  9. 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 a4 Host C Host S

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

  11. 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 X fC1 fS1 a1 a3 sC sS fC2 fS2 a2 a4 Host C Host S

  12. 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/ serviceID IP:port Application IP:port flowID Transport IP IP a1 a1 a2 a2 Network

  13. 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

  14. 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

  15. 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

  16. 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

More Related