Towards a Delay-tolerant Future: Reconsidering some Assumptions in Networking. Reconsidering the Internet Design. Number of layers

Transcription

1 Towards a Delay-tolerant Future: Reconsidering some ssumptions in Networking CHINTI Jörg tt <jo@comnet.tkk.fi> 2 July 2009 tubs.city 2009 Jörg tt 1 Reconsidering the Internet Design Communication paradigms Packets vs. circuits Number of layers Hosts vs. interfaces IP addresses ctive networking QoS Layering principles est Effort Packet size (cell size) Connectionless operation Locators vs. identifiers Routing structure GP End-to-end principle IPv4 vs. IPv6 vs Security ccounting Trust MIddleboxes 2009 Jörg tt 2

2 The Internet ISP ISP ISP ISP ISP ISP ISP 2009 Jörg tt 3 The Mobile Internet is Not Connected What we have: lots of wireless network infrastructure patchwork of UMTS, WiMX, WLN, 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 lso social and legal Mimicking fixed network characteristics for wireless and mobile nodes is bound to fail 2009 Jörg tt 4

3 Example: Coverage 2009 Jörg tt 5 Performance Example: Throughput 2009 Jörg tt 6

4 Performance Example: Delay and Loss Cellular data (UMTS, GRPS) in a train (2007) Multi-access train system (2009) (WiMX, UMTS, GPRS) 2009 Jörg tt 7 Link/path impairments/loss yield delay Delay Loss Date Rate Repair mechanisms, rate reduction Reduced throughput,increased loss Delay Disruption Data rate=0, loss=1, delay>t outage Short delays inhibit interactivity and performance Long delays prevent service. Delay Timeout Retry Failure Manual repair 2009 Jörg tt 8

5 Mobile pplications Essentially have not changed from the corresponding fixed applications. Rely on (continuous) connectivity to the infrastructure 2009 Jörg tt 9 Some bservations on (Mobile) pplications Many applications are asynchronous in nature Theoretically no need for always on connectivity today Examples: , file transfer, peer-to-peer, even presence and messaging pplications don t communicate most of the time Users read, type, or do other things (e.g., fetch-read cycle for the web) Examples: web, , calendar, chat, presence, pplication 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 tt 10

6 Scenario (0) Point Internet Web Content 2009 Jörg tt 11 Scenario (1) Points 2009 Jörg tt 12

7 Scenario (2) Points 2009 Jörg tt 13 Scenario (3) Points DNS Server Campus Network 2009 Jörg tt 14

8 Scenario (4) Points DNS Server DNS Server Campus Network Internet 2009 Jörg tt 15 Scenario (5) Web Server Points DNS Server DNS Server Campus Network Internet 2009 Jörg tt 16

9 Infrastructure Dependencies Infrastructure functions utoconfiguration and access ddress resolution User identification and authorization Security certificate lookup, validation Content retrieval (or other server-based operation) Infrastructure interactions utoconfiguration & access: 2 + timeout spiegel.de 113 objects 590 K ddress resolution: 1 per non-cached DNS name, possibly recursive tubscity 20 objects 343 K Web page: usually couple of external links Not so much applicable for mail servers, etc. pplications Sending mail: ~6+ Retrieving mail: ~6+ Web: highly variable: tagesschau.de 106 objects 484 K amazon.com 88 objects 692 K wetter.de 118 objects 699 K portal.acm.org 17 objects 77 K 2009 Jörg tt 17 Infrastructure Dependencies Communication substrate Information repository for retrieval and storage S S S Communication mediation mechanism 2009 Jörg tt 18

10 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) UT 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 tt 19 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 tt 20

11 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 2009 Jörg tt 21 1) Towards Delay Tolerance Connection splitting: prevent applications from noticing Some issues ffects the end-to-end principle Introduces an additional (single) point of failure Need to identify challenged links Mobile nodes still require (direct) infrastructure access C P P 2009 Jörg tt 22

12 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 2009 Jörg tt 23 1) Towards Delay Tolerance Eliminate the overlay: Integrate delay-tolerant forwarding with the infrastructure nodes No dedicated nodes for special handling required anymore 2009 Jörg tt 24

13 2) Infrastructure-less peration a) Retrieval and mediation indirection Information-centric / content-based networking Decouple content and services from servers ddress 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 pportunistic and coordinated cooperation Simplest case: Caching vailable to some limited extent as infrastructure-based overlays Extend this notion into access networks and to mobile devices 2009 Jörg tt 25 2) Infrastructure-less peration b) utoconfiguration 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: pplied to mobile (ad-hoc) environments Information exchange around a table Targeted communication and open sharing 2009 Jörg tt 26

14 3) Fix pplication Protocols void 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 llows 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 tt 27 3) Fix pplication Protocols Minimize the dependency on infrastructure nodes void 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 uild adaptivity into protocols at all layers llow 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 tt 28

15 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!) verlay 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 tt 29 Short-term example: The CHINTI pproach 3 rd party provider CHINTI proxies CHINTI proxies ISP CHINTI ISP Internet ISP Servers, peers Mobile ISP Internet Mobile 2009 Jörg tt 30

16 Short-term example: The CHINTI pproach Targets Today s applications: mail, web, Incremental deployment Support for diverse business roles Deployment considerations: NTs and firewalls Portals, authentication Content filtering Mobile device Vehicle Support Network Internet/CSP Server CHINTI overlay connection C P U Plain end-to-end connection C P P 2009 Jörg tt 31 Mid-term example: Delay-tolerant Web Message-based protocol: HTTP encapsulated in DTN Single request yields entire page ggregation on the server side Compound responses in MHTML Native DTN web server Existing web browsers + local gateway Disconnected browsing + blogging Web client Gate R way R/ R/ Challenged, disconnected, or regular network R/ R/ web server HTTP-over-DTN with MHTML responses P C P 2009 Jörg tt 32

17 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 (20 years) old application protocols Prototyping and trialing is essential to understand the issues (usability, deployability, incentives) 2009 Jörg tt 33 CHINTI Jörg tt 34