towards a delay-tolerant future: reconsidering some ... · delay tolerance should become an...

HELSINKI UNIVERSITY OF TECHNOLOGY DEPARTMENT OF COMMUNICATIONS AND NETWORKING

© 2009 Jörg Ott 1

Towards a Delay-tolerant Future: Reconsidering some Assumptions in Networking

Jörg Ott <[email protected]>

2 July 2009 tubs.CITY

CHIANTI

© 2009 Jörg Ott 2


Reconsidering the Internet Design…

Packets vs. circuits

QoS

Packet size (cell size)

End-to-end principle

Accounting

Number of layers

Layering principles

IP addresses

Locators vs. identifiers

IPv4 vs. IPv6 vs …

Security Trust

Best Effort

BGP

Routing structure Connectionless operation

MIddleboxes

Active networking

Hosts vs. interfaces

Communication paradigms

© 2009 Jörg Ott 3


The Internet

ISP

ISP

ISP

ISP

ISP

ISP

ISP

© 2009 Jörg Ott 4


The Mobile Internet is Not Connected   What we have: lots of wireless network infrastructure

  A patchwork of UMTS, WiMAX, WLAN, satellite (Iridium, …) covering significant parts of the planet… — yet not all

and powerful mobile endpoints with many of such radio interfaces   To connect to the infrastructure and to talk to each other

  What we still don’t have: sustainable ubiquitous connectivity for technical, practical, and economic reasons   Also social and legal

  Mimicking fixed network characteristics for wireless and mobile nodes is bound to fail

© 2009 Jörg Ott 5


Example: Coverage

© 2009 Jörg Ott 6


Performance Example: Throughput

© 2009 Jörg Ott 7


Performance Example: Delay and Loss

Cellular data (UMTS, GRPS) in a train (2007)

Multi-access train system (2009) (WiMAX, UMTS, GPRS)

© 2009 Jörg Ott 8


Link/path impairments/loss yield delay

Delay

Loss

Date Rate

“Short” delays inhibit interactivity and performance “Long” delays prevent service.

Disruption Data rate=0, loss=1, delay>Toutage

Reduced throughput,increased loss

Repair mechanisms, rate reduction

Del

ay

Delay Timeout Retry Failure “Manual repair”

© 2009 Jörg Ott 9


Mobile Applications

Rely on (continuous) connectivity to the infrastructure

Essentially have not changed from the corresponding fixed applications.

© 2009 Jörg Ott 10


Some Observations on (Mobile) Applications   Many applications are asynchronous in nature

  Theoretically no need for “always on” connectivity today   Examples: e-mail, file transfer, peer-to-peer, even presence and messaging

  Applications don’t communicate most of the time   Users read, type, or do other things (e.g., fetch-read cycle for the web)   Examples: web, e-mail, calendar, chat, presence, …

  Application semantics do not require permanent or “end-to-end” connectivity… …but many application protocols do!

  This motivates seamless connectivity and wireless QoS   Which are often suboptimal goals and sometimes unrealistic

© 2009 Jörg Ott 11


Scenario (0) Access Point

Web Content

Internet

© 2009 Jörg Ott 12


Scenario (1) Access Points

© 2009 Jörg Ott 13


Scenario (2)

Access Router

Access Points

© 2009 Jörg Ott 14


Scenario (3)

Access Router

Access Points

DNS Server

Campus Network

© 2009 Jörg Ott 15


Scenario (4)

Access Router

Access Points

DNS Server

Campus Network

Internet

Router

DNS Server

Router Router

© 2009 Jörg Ott 16


Scenario (5)

Access Router

Access Points

DNS Server

Campus Network

Internet

Router

DNS Server

Web Server

Router Router

© 2009 Jörg Ott 17


Infrastructure Dependencies   Infrastructure functions

  Autoconfiguration and access   Address resolution   User identification and authorization   Security certificate lookup, validation   Content retrieval (or other server-based operation)

  Infrastructure interactions   Autoconfiguration & access: 2 + timeout   Address resolution: 1 per non-cached DNS name, possibly recursive

  Web page: usually couple of external links   Not so much applicable for mail servers, etc.

  Applications   Sending mail: ~6+   Retrieving mail: ~6+   Web: highly variable: 1 – 100+

spiegel.de 113 objects 590 KB tubscity 20 objects 343 KB tagesschau.de 106 objects 484 KB amazon.com 88 objects 692 KB wetter.de 118 objects 699 KB portal.acm.org 17 objects 77 KB

© 2009 Jörg Ott 18


Infrastructure Dependencies

  Information repository for retrieval and storage

  Communication substrate

  Communication mediation mechanism

A

S

A

B

S

S

A

B

© 2009 Jörg Ott 19


Disconnections & Disruptions Delay   Intentional disconnections and unexpected disruptions

  Short- to long-term outage   Reconnecting may lead to a change of IP addresses

  Many short-term incremental fixes available from past research   Mobile IP, HIP, VPNs to preserve IP addresses   Transport layer mechanisms prevent losing TCP (and other) connections   Session layer robustness prevents applications from noticing such   (+ some support for selected applications)

  BUT while disconnected, data cannot flow   Connectivity loss, temporary path failures (re-routing)   Hard to distinguish from congestion, remote node overload or failure   Impossible to predict if and when operation will return to “normal”

  Delays may have a variety of further origins…

© 2009 Jörg Ott 20


Towards a Future Internet…

Three related issues to support mobile communications:

1. Communication substrate: Delay tolerance

2. Mediation: Enabling infrastructure-less operation

3. Revisiting application protocol design

© 2009 Jörg Ott 21


1) Towards Delay Tolerance   State-of-the-Internet: deliver or drop

  End-to-end approaches to resilience aim at suspending/resuming communications and at automating recovery

A

B

© 2009 Jörg Ott 22


1) Towards Delay Tolerance   Connection splitting: prevent applications from noticing

  Some issues   Affects the end-to-end principle   Introduces an additional (single) point of failure   Need to identify challenged links   Mobile nodes still require (direct) infrastructure access

A

B P

C P

© 2009 Jörg Ott 23


1) Towards Delay Tolerance   From dedicated proxies to a routing overlay

  Example DTN: Message-based communications   Large messages instead of small packets   Maintain the key packet forwarding of IP packets to preserve robustness

A

B

O

O

O

O

O

© 2009 Jörg Ott 24


1) Towards Delay Tolerance   Eliminate the overlay:

Integrate delay-tolerant forwarding with the infrastructure nodes

  No dedicated nodes for special handling required anymore

A

B

© 2009 Jörg Ott 25


2) Infrastructure-less Operation a) Retrieval and mediation indirection

  Information-centric / content-based networking   Decouple content and services from servers   Address by intention (content, function, role) rather than server name

  Reducing mapping/lookup indirection   Route on contents, by intention   Utilize late binding when addressing nodes   Provide generic nodes for rendezvous support

  Opportunistic and coordinated cooperation   Simplest case: Caching   Available to some limited extent as infrastructure-based overlays   Extend this notion into access networks and to mobile devices

© 2009 Jörg Ott 26


2) Infrastructure-less Operation b) Autoconfiguration and registration

  Provide persistent self-certifying identifiers for nodes   Location-independent   No need to dynamically obtain addresses for end-to-end operation   (Lower layer addresses may stay for network layer interactions)

  Litmus test: Applied to mobile (ad-hoc) environments   Information exchange around a table   Targeted communication and open sharing

© 2009 Jörg Ott 27


3) Fix Application Protocols   Avoid chattiness: minimize end-to-end interactions

  Keep messages self-contained (all-at-once)   Indicate context, include credentials   Minimizes the impact of delays

  Untangle application and transport layer state   Connections, reliability   Allows repeated setup, support migration to more delay-tolerant transport

  Separate protocol operation and content security   Decouple content from the node (originally) serving it   Keep application security independent of lower layers   Enables caching and autonomous operation

  Consider intermediaries explicitly in the design

© 2009 Jörg Ott 28


3) Fix Application Protocols   Minimize the dependency on infrastructure nodes

  Avoid third-party lookups and indirections   Supports flexible content, service, and peer discovery

  Design symmetric protocols that can talk directly without servers   Realize end-to-end semantics expressly at the application layer   Eliminates application layer conversion, e.g., in mail servers

  Build adaptivity into protocols at all layers   Allow users to define their own delay tolerance (rather than prescribing it)   No fixed timeouts, flexible semantics, …

  Non-delay-tolerant application protocols   Can continue working as before (e.g., for real-time traffic)

© 2009 Jörg Ott 29


Towards a Future Internet…   Incremental deployment imperative

  Don’t care about IPv4 vs. IPv6 vs. *   No need to touch the infrastructure – but may evolve in parallel

  Need to use TCP and UDP in the short to mid term

  Realize delay tolerance and content orientation as an overlay   Got plenty of real-world evidence for the latter today

  Start out application-specific (plenty of evidence!)   Overlay functions, content-aware routing, identifiers, …   Gradually revise/enrich application protocols and applications (“dual stack”)

  Strive for generalization, possibly using virtualization   Intertwine overlay and underlay functions

© 2009 Jörg Ott 30


Short-term example: The CHIANTI Approach

CHIANTI ISP

Internet

CHIANTI proxies

Servers, peers

3rd party provider CHIANTI proxies

Mobile Access ISP Internet

ISP A

ISP B

Access Mobile

© 2009 Jörg Ott 31


Short-term example: The CHIANTI Approach   Targets

  Today’s applications: mail, web, …   Incremental deployment   Support for diverse business roles

  Deployment considerations:   NATs and firewalls   Portals, authentication   Content filtering

Mobile device

Vehicle Support Access Network Internet/CSP Server

U

C P CHIANTI overlay connection

Plain end-to-end connection

A B

A

B P C P

A

B O

O

O

O

O A

B

© 2009 Jörg Ott 32


Mid-term example: Delay-tolerant Web Access

  Message-based protocol: HTTP encapsulated in DTN   Single request yields entire page   Aggregation on the server side   Compound responses in MHTML

  Native DTN web server   Existing web browsers + local

gateway   Disconnected browsing +

blogging

Web client

web server

Challenged, disconnected, or regular network

R/O

R/O

R/O

R/O BR

HTTP-over-DTN with MHTML responses

Gate way

A B

A

B P C P

A

B O

O

O

O

O A

B

© 2009 Jörg Ott 33


Some Conclusion   Disconnections, disruptions, delays are here to stay

  Yes, we should advance the infrastructure and improve networks   Delay tolerance should become an inherent property of a future Internet   Support for wireless nodes, mobility, and robustness in general

  Need for incremental deployment suggests overlays to start

  Need to fix O(20 years) old application protocols

  Prototyping and trialing is essential to understand the issues (usability, deployability, incentives)


© 2009 Jörg Ott 34

CHIANTI

http://www.netlab.tkk.fi/~jo/

http://www.chianti-ict.org/

http://www.future-internet.fi/

towards a delay-tolerant future: reconsidering some ... · delay tolerance should become an...

Documents