End-to-End Transport Layer Services in the MobilityFirst

Network

Kai Su, Francesco Bronzino, Dipankar Raychaudhuri, K.K. Ramakrishnan

WINLAB Research Review

Winter 2014

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?

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

Disney/movies/Toy_Story

Universal/Songs/The_Magic_Flute

RH

RH RH RH

ClientCopy

1Copy

2

Register(P:L) Register(P:L) Find(P:L)Get(Disney/movies/Toy_Story)

MobilityFirst: Service Abstractions

• Service Abstractions• Named Base Services.

• Direct Addressability for All Network Principals.

• Multi-Point Addressability.

Devices

Content

Context

Services

Host 1

Host 2Group1send(Group1, data)

send(A, data)NetworkObject A

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

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

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 store-and-forward (poor link BW/short disconnection) to DTN (longer disconnections)

• Storage can have benefits for wired networks as well

Initial Routing Path

PDU

High BW WiFi link

Re-routed pathFor delivery

MobileDevicetrajectory

TemporaryStorage atRouter

Low BWcellular link

MobilityFirst: Transition to a Name Based API

• 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

get(content-GUID)

Sensors

post(Ser-GUID, Sensor-Data, “DTN”)

open(“content-retrieval”, “wifi-only”)

Interface abstraction, no need for binding to specific interface

exec(Svc-GUID, Task, “Any”)

Offload responsibility of delivery to the network

ServiceData Center

Native support for content and services operations

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.

Different access technologies

Hop-by-Hop reliable transfer of large chunks of data

Wide support of mobile devices

Name representation of groups of network objects

Send(data, group1-guid)

get(content-guid)

Send and forget to a an aggregator service

Transport Protocol:Core Design Elements

GNRSProxy 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)

Storing event signaled to original sender

Hybrid unicast-multicast approach used for requesting retransmission of specific portions of the transmitted data

Reliable multicast support transparently provided to the application

Sporadic failures of network components are handled through end-to-end feedback

Efficient Content-based transfer: maintain sequencing and ordering at content level (not across contents): avoid head of line blocking

Periodic acknowledgements for large transfers. Efficiency for small files/contents

Congestion control distributed along the path through backpressure and end-to-end feedback

Sequencing, aggregation of chunks across different local interfaces

Design: Lightweight Reliable Transfer

• Three-way handshake to establish conn.

• Congestion recovery and error recovery both done on end-to-end basis. • Sender being stateful,

i.e.rely on receiver’s ack, to detect loss, failure, and congestion

TCP behavior

Node ripristinated

Node failure

Timeout occurs

Second timeout occurs after a longer wait due to exponential backoff

Timeout triggered based on estimated RTT

Design: Lightweight Reliable Transfer

• 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 NACK-based mechanism.

• Congestion control mechanisms scale back performance when congestion is detected along the communication path

Sporadic failures of network components are handled through end-to-end feedback

NACK timeout triggers if expected data is not received over the an expected interval of time

Lost chunk

Host sending large files or contents

(10,0) (10,1) (50,0) (50,1) (100,0) (100,1)0

5

10

15

20

25

Network setting (RTT(ms),packet loss ratio(%))

Ave

rage

th

roug

hp

ut

(Mb

ps)

TCP/IP

MF

Design: Lightweight Reliable Transfer

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

Lossy channels are decoupled and losses are handled locally

Proxy server handles retransmission due to disconnections

MF to HTTP Proxy

HTTP to MF Local

Proxy

Apache Server

Design: Support for Multicast/Anycast

• 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

GNRS

GUID MGUID / NA

M1 U1, U2, U3

U1 NA1

U2 NA2

U3 NA3

send(M1, data)

Multicast group M1 is used for transmitting data to the users in the group

Device specific guids are used for requesting retransmission of specific portions of the transmitted data

Design: Support for Real-Time Services

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

Src GUID Src NA Dst GUID Dst NA SID Transport.

“Real time” “Do not ack”

Network and Transport Header

Named objects allow for fast redirection of inflight packets

GNRSsend(guid, data, “real-time”)

If multiple interfaces are available, traffic can be distributed across

Conclusions

• We defined a set of requirements needed by and end-to-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 MobilityFirstarchitecture 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.