End-to-End Transport Layer Services in the MobilityFirst Network

Transcription

1 End-to-End Transport Layer Services in the MobilityFirst Network Kai Su, Francesco Bronzino, Dipankar Raychaudhuri, K.K. Ramakrishnan WINLAB Research Review Winter 2014

2 Transport Services From TCP/IP to ICN Classical IP based End-to- End transport protocols focus in point to point communications. UDP: basic message base multiplexing. TCP: multiplexing, full reliability, ordered delivery of stream of bytes. RTP: focus on media streams. What about Information Centric Networks?

3 Information Centric Network Concepts Information Centric Networks architectures move the focus to end-to-end communications to named data retrieval. General characteristics: name-based, content-centric, instead of host-centric Each content is uniquely named Client requests content by its name, without caring about the location of the content Anycast & multicast are common transfer patterns RH Disney/movies/Toy_Story Universal/Songs/The_Magic _Flute RH RH RH Get(Disney/movies/Toy_Story) Copy 1 Copy 2 Client Register(P:L) Register(P:L) Find(P:L)

4 MobilityFirst: Service Abstractions Service Abstractions Named Base Services. send(a, data) Network Object A Direct Addressability for All Network Principals. send(group1, data) Multi-Point Addressability. Devices Content Context Services Host 1 Host 2 Group1

5 MobilityFirst: Introduction and Motivations Historic shift from PC s to mobile computing and embedded devices ~4 B cell phones vs. ~1B PC s in 2010 Mobile data growing exponentially Cisco white paper predicts 3.6 Exabytes by 2014, significantly exceeding wired Internet traffic Sensor/IoT/V2V just starting, ~5-10B units by 2020

6 MobilityFirst: Main Features Separation of names (ID) from network addresses (NA) Globally unique name (GUID) for network attached objects User name, device ID, content, context, AS name, and so on Multiple domain-specific naming services Global Name Resolution Service for GUID <-> NA mapping Hybrid GUID/NA approach Both name/address headers in PDU Fast path when NA is available GUID resolution, late binding option

7 MobilityFirst: Routing (GSTAR) Storage aware (CNF, generalized DTN) routing exploits in-network storage to deal with varying link quality and disconnection Routing algorithm adapts seamlessly adapts from switching (good path) to storeand-forward (poor link BW/short disconnection) to DTN (longer disconnections) Storage can have benefits for wired networks as well Initial Routing Path Temporary Storage at Router Low BW cellular link PDU Re-routed path For delivery Mobile Device trajectory High BW WiFi link

8 MobilityFirst: Transition to a Name Based API Interface abstraction, no need for binding to specific interface Service Data Center Offload responsibility of delivery to the network post(ser-guid, Sensor-Data, DTN ) open( content-retrieval, wifi-only ) Sensors get(content-guid) exec(svc-guid, Task, Any ) Name based communications based and end point access to name resolution service provides direct addressability of different internet objects (i.e. devices, contents, services, contexts, etc.) Name based communications provide the abstraction for message based communications and content/service specific operations. Support for application specific requirements, e.g. multi-access connectivity support. Natively support multipoint addressability Content Server Native support for content and services operations

9 Summary: Transport Protocol Requirements for MobilityFirst Support network heterogeneity, disconnection/mobility and failure recovery in coordination with the network provided functionality. Name based abstractions introduce requirements to support content/service centric operations and multipoint addressability (e.g. multicast, anycast). Exploit name based communications to support multihomed devices and services through multipath delivery. Support for reliable aggregation of multisource information (e.g. sensor information) Congestion control mechanisms in the context of a hop-by-hop reliable transport. get(content-guid) Hop-by-Hop reliable transfer of large chunks of data Send(data, group1-guid) Send and forget to a an aggregator service Different access technologies Name representation of groups of network objects Wide support of mobile devices

10 Transport Protocol: Core Design Elements GNRS Storing event signaled to original sender Proxy transport stores data for temporary disconnections. Sender is notified of store event. GNRS query reveals newfound reachability Mobile client changing location updates GNRS entry Send(guid, data) Efficient Content-based transfer: maintain sequencing and ordering at content level (not across contents): avoid head of line blocking Hybrid unicast-multicast approach used for requesting retransmission of specific portions of the transmitted data Sporadic failures of network components are handled through end-to-end feedback Reliable multicast support transparently provided to the application Sequencing, aggregation of chunks across different local interfaces Periodic acknowledgements for large transfers. Efficiency for small files/contents Congestion control distributed along the path through backpressure and end-to-end feedback

11 Design: Lightweight Reliable Transfer Timeout occurs TCP behavior Node failure Node ripristinated Three-way handshake to establish conn. Congestion recovery and error recovery both done on end-toend basis. Sender being stateful, i.e.rely on receiver s ack, to detect loss, failure, and congestion Second timeout occurs after a longer wait due to exponential backoff Timeout triggered based on estimated RTT

12 Design: Lightweight Reliable Transfer Host sending large files or contents Lost chunk Sporadic failures of network components are handled through end-to-end feedback Hop-by-hop error/congestion recovery at packet level Occasional failure recovery not resolvable through hop-by-hop retransmission is handled end-to-end. Only specific portions of data (chunks) are requested for retransmission through a NACKbased mechanism. Congestion control mechanisms scale back performance when congestion is detected along the communication path Average throughput (Mbps) TCP/IP MF NACK timeout triggers if expected data is not received over the an expected interval of time (10,0) (10,1) (50,0) (50,1) (100,0) (100,1) Network setting (RTT(ms),packet loss ratio(%))

13 Design: Lightweight Reliable Transfer Apache Server MF to HTTP Proxy Proxy server handles retransmission due to disconnections Lossy channels are decoupled and losses are handled locally HTTP to MF Local Proxy Interaction with transport proxies to store and retransmit because of mobility and disconnections. Retransmissions because of loss are handled locally. Connectionless protocol allows for small start-up and recovery times. Experimental scenario: webpage requests to a webserver. 1% loss probability on WiFi link. Comparison between TCP/IP and Mobilityfirst.

14 Design: Support for Multicast/Anycast Device specific guids are used for requesting retransmission of specific portions of the transmitted data send(m1, data) Multicast group M1 is used for transmitting data to the users in the group GUID M1 GNRS MGUID / NA U1, U2, U3 U1 NA1 U2 NA2 U3 NA3 Small scale multicast: reliability provided end to end transparently to the application through a mix of multicast and unicast messages. Lost data will be retransmitted via unicast unless loss affected a number of users above an appropriate threshold. Large scale: use of network infrastructure for aggregation and retransmission

15 Design: Support for Real-Time Services send(guid, data, real-time ) GNRS Named objects allow for fast redirection of inflight packets Network and Transport Header Src GUID Src NA Dst GUID Dst NA SID Transport. Real time Do not ack If multiple interfaces are available, traffic can be distributed across Network layer Service ID (SID) marks chunk as real time. Hop by hop reliability is not employed for marked chunks. Moreover, advanced delivery service Transport provides sequencing, aggregation across multiple paths reaching different local interfaces.

16 Conclusions We defined a set of requirements needed by and endto-end transport service in an Information Centric Network. We designed a collection of techniques that are meant to meet the defined requirements. We applied these design choices to the MobilityFirst architecture and developed a working prototype. Future work: Complete the development and verification of our prototype Provide a comprehensive use case based evaluation of our design.