MobilityFirst: High-level Architectural Updates Arun Venkataramani, Dipankar Raychaudhuri 1

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science From Design Goals to Current Architecture Host + network mobility No global root of trust Intentional data receipt Proportional robustness Content-awareness Evolvability Global name service Name certification Name resolution Context & M2M services Service migration Content storage & retrieval Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions Inter-,intra-domain routing Segmented transport Computing layer Management plane 2

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Global name service Global name service Name certification Name resolution: Auspice, DMap Context & M2M services Service migration Content storage & retrieval human_readable_name GUID Darleen Fishers phone 1A348F76 self-certifying GUID = hash(public-key) permits bilateral authentication GUID flexibly identifies principals: interface, device, person, group, service, network, etc. 3

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Global name service Global name service Name certification Name resolution: Auspice, DMap Context & M2M services Service migration Content storage & retrieval GUID NA NA 1 NA 2 GUID NA 1 resolve(GUID) data GUID NA 2 GUID NA 1 GUID NA 2 4

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Name certification Name resolution: Auspice, DMap Context & M2M services Service migration Content storage & retrieval Global name service: Content retrieval Global name service 5

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Global name service: Content retrieval Content CGUID [NA 1, NA 2, … ] Opportunistic caching + request interception GNRS CGUID [NA 1,NA 2,…] CGUID NA 1 NA 2 get(CGUID, NA 1 ) get(CGUID) 6

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Name certification Name resolution: Auspice, DMap Context & M2M services Service migration Content storage & retrieval Global name service: Content retrieval Global name service 7

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Indirection and grouping Indirection: D 1 D 2 Grouping: D {D 1, D 2, …, D k } Indirection and grouping enable context-aware services, content mobility, and group mobility 8

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Indirection + grouping: Multicast MGUID {T 1, T 2, …, T k } (terminal networks) MGUID {members(MGUID) | T i } (late binding) GNRS MGUID {T 1,T 2,…,T k } T1T1 TkTk T2T2 send_data(MGUID,T 1 ) send_data(MGUID,T 2 ) send_data(MGUID,T 3 ) 9

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Indirection+grouping: Context-awareness GUID_cab i [T 1, {type yellowcab, geo Times Sq.}] At source: CAID {T 1, T 2, …, T k } // terminal networks At terminal n/w: CAID {members(CAID) | T i } // late binding GNRS CAID {T 1,T 2,…,T k } T1T1 TkTk T2T2 send_data(CAID,T 1 ) send_data(CAID,T 2 ) send_data(CAID,T 3 ) CAID 1 members(CAID) {T 1, T 2, …, T k } 10

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Indirection+grouping: Content directories Moving massive content directory from NA 1 to NA 2 C1 {CDID, name nbc.com/content1} CDID {NA 1 } GNRS NA 1 nbc.com/* NA 2 CDID [NA 2 ] C1 NA 2 get(C1,NA2) GUID 1 GGUID NA 2 11

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Group mobility Group GUIDs help reduce update overhead even when no actual data transfer is happening GUID i GGUID GGUID NA 1 GNRS NA 1 NA 2 GGUID NA 2 GUID 1 NA 2 send(GUID 1,NA2) GUID 1 GGUID NA 2 12

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science From Design Goals to Current Architecture Host + network mobility No global root of trust Intentional data receipt Proportional robustness Content-awareness Evolvability Global name service Name certification Name resolution Context & M2M services Service migration Content storage & retrieval Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions Inter-,intra-domain routing Segmented transport Computing layer Management plane 13

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Scaling interdomain routing NA1 NA2 Function: Route to Scale: Millions of NAs huge forwarding tables NA3 … … … … … … … … … … … … … … … … … … … … data) NetworkInterface NA12 NA26 NA31 NA42 … … NA

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Scaling interdomain routing Function: Route to scalably Approach: Core and edge networks to reduce state T1T1 T2T2 T3T3 T4T4 T5T5 T6T6 X2 X3 X1 Global name service GUID [X 2,T 4 ] GUID X 2,T 4 data Few interdomain routing design efforts maturing 1.Vnode + pathlet routing + link-state + telescoping updates 2.Bloom routing 3.Core-edge routing with *-cast through name service 15

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Multihoming and multipath Global name service: Multihomed resolution GUID_src {[X 3,R 1 ], [X 3,R 2 ], …,[X 3,R m ]} GUID_dst {[X 1,T 1 ], [X 2,T 2 ], [X 1,T 2 ], …, [X 2,T k ]} GUID_dst {TE_policy prefer WiFi for delay-tolerant downloads} T1T1 T2T2 TkTk R1R1 R2R2 RmRm X1 X2 X3 16

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science From Design Goals to Current Architecture Host + network mobility No global root of trust Intentional data receipt Proportional robustness Content-awareness Evolvability Global name service Name certification Name resolution Context & M2M services Service migration Content storage & retrieval Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions Inter-,intra-domain routing Segmented transport Computing layer Management plane 17

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Computing layer Programmable computing layer enables service flexibility and evolvability Routers support new network services off the critical path Packets carry (optional) service tags for demuxing Integration with active GUID resolution in global name service Packet forwarding/routing Computing layer CPU Storage Virtual Service Provider Content Caching Privacy routing anon 18

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science From Design Goals to Current Architecture Host + network mobility No global root of trust Intentional data receipt Proportional robustness Content-awareness Evolvability Global name service Name certification Name resolution Context & M2M services Service migration Content storage & retrieval Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions Inter-,intra-domain routing Segmented transport Computing layer Management plane 19

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Segmented block transport Segment = contiguous sequence of links Storage routers available at segment boundaries Unit of transmission a named block = large contiguous chunk of data (not small packets as in E2E TCP) ISP1 ISP3 ISP2 Block 4G WiFi Storage router Storage router Segment 1 Segment 2 20

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science From Design Goals to Current Architecture Host + network mobility No global root of trust Intentional data receipt Proportional robustness Content-awareness Evolvability Global name service Name certification Name resolution Context & M2M services Service migration Content storage & retrieval Key insight: Logically centralized global name service enhances mobility, security, and network-layer functions Inter-,intra-domain routing Segmented transport Computing layer Management plane 21

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Management plane Management plane to enable Visibility into network performance metrics Access-controlled querying of intradomain state Logically centralized decision-making Early detection and response to security problems Client-assisted collection of management data AP Control & Management Plane Network Mgmt. API Data Plane Data packets 22

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Architecture: Why logically centralized? Indirection-based Logically centralized Network-layer 23

Auspice: A Global Name Service for a Highly Mobile Internetwork Arun Venkataramani (with Abhigyan Sharma, Xiaozheng Tie, David Westbrook, Hardeep Uppal, Emmanuel Cecchet) University of Massachusetts Amherst 24

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Global name service as geo-distributed key-value store 25 Global name service resolve(GUID,…) value(s) GUID: { {NAs:[[X 1,T 1 ],[X 2,T 2 ],…}, {geoloc:[lat, long]}, {TE_prefs: [prefer WiFi,…]}, {ACL: {whitelist: […]}}, … } resolve(GUID,…) value(s)

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Auspice design goals 1.Low response time: Replicas of each names resolver should be placed close to querying end-users 2.Low update cost: Number of resolver replicas should be limited to reduce replica consistency overhead 3.Load balance: Placement of replicas across all names should prevent load hotspots at any single site 4.Availability: Sufficient number of replicas so as to ensure availability amidst crash or malicious faults 5.Consistency: Each name resolvers consistency requirements must be preserved

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Trade-offs of traditional approaches Replicate everything everywhere: + Low response times - High update cost under mobility, load imbalance Few primary replica plus edge caching: + Low update bandwidth cost - Consistency requirements may limit caching benefits - Load balance vs. response time trade-offs Consistent hashing with replication + Good load balance - High response times (randomization, locality at odds) - Dynamic replication, consistency coordination, load balance

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Auspice resolver replica placement 28 Locality-awareLoad-aware

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Replica controllers Active replicas XX X XXXXXXX End-hosts or local name servers First request for name X Typical request for name X to nearby active replica Load reports Locality-aware, load-aware, consistent Migrate replicas Mapping algorithm + Paxos to compute active replica locations Auspice resolver placement engine

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Paxos Sequential consistency Lineariazability create_replica(.) shutdown_replica(.) migrate_replica(.) AmericaEuropeAsia report_load(.) Auspice service migration (in-progress)

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Auspice implementation & evaluation Implemented mostly in Java (~22K lines of code) Supports mysql, MongoDB, Cassandra, in-memory store HTTP API for request/responses Flexible keys and values [GUID, NA], [GUID, IP], [name, IP] Near-beta version deployed on eight geo-distributed Amazon EC2 locations Extensive evaluation on larger clusters and PlanetLab settings Mobile socket library for seamless mid-session client and server migration 31

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Auspice vs. alternate proposals 32

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Auspice vs. commercial managed DNS 33

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Application scenario: Emergency geo-cast Demo by Emmanuel Cecchet 34

U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Questions? 35