Design Principles for Internet & Wireless

Mobile Systems

Outline• Big picture

• The Problem

• The Design Goals

• The Solution: design principles– Wired Internet– Wireless and mobility

• The future

Automobiles663 Million

Telephones1.5 Billion

Electronic Chips30 Billion

X-Internet

Big Picture for global net: “X-Internet” Beyond the PC

Forrester Research, 2001

>100Million

407 Million

Internet Computers

Internet UsersToday’s Internet

“X-Internet” Beyond the PC

Forrester Research, May 2001

0

5000

10000

15000

2001200220032004200520062007200820092010

Millions

Year

XInternet

PCInternet

Success of a technology

• ENABLER: portable devices– Smart phones, PDAs, portable

computers, …

• DRIVER: new computing paradigm– Mobile computing, Pervasive

computing, ubiquitous computing

– Internet Web engineering

Enabler: Popularity of portable devices• Worldwide shipment of smart mobile

devices (wireless handhelds, handhelds, smart phones) (src: canalys estimates)– Nearly 19 millions shipment (Q2, 2006),

increased 55.5% from Q2, 2005.

• US (2005 data)– 350 million units in the shape of smartphone

(90%) or a handheld computer (10%).

Evolution of the Computer

Eniac, 1947

Telephone,1876

Computer+ Modem

1957

Early WirelessPhones, 1978

First Color TVBroadcast, 1953

HBO Launched, 1972

Interactive TV, 1990

Handheld PortablePhones, 1990

First PCAltair,1974

IBMPC,

1981

AppleMac,1984

ApplePowerbook,

1990

IBMThinkpad,

1992

HPPalmtop,

1991

AppleNewton,

1993

PentiumPC, 1993

Red Herring, 10/99

Game ConsolesPersonal Digital Assistants

Digital VCRs (TiVo, ReplayTV)

CommunicatorsSmart Telephones

E-Toys (Furby, Aibo)

Evolution of the Computer

PentiumPC, 1993

Atari HomePong, 1972

AppleiMac, 1998

Pentium IIPC, 1997

Palm VIIPDA, 1999

NetworkComputer,

1996

FreePC, 1999

SegaDreamcast,

1999

Internet-enabledSmart Phones,

1999

Red Herring, 10/99

Proliferation of diverseend devices and access networks

Infrastructure Options of Wireless networks

• Cellular networks– Single first/last-hop wireless– Wired backbone– Examples: 2/3G, 802.11 WLAN

• All-wireless– Multihop wireless– Examples: mesh networks, sensor networks,

ad hoc networks

• Hybrid– UCAN, ICAR, …

Cellular Infrastructure

2G/3G WANInfrastructure

Internet

• Wireless WAN: 2G/3G cellular infrastructure

• Wireless LAN: IEEE 802.11

802.11 LAN

Multihop Ad-Hoc Infrastructure

• Resource-constrained sensors• Potentially large population

Wireless Sensor Networks Mobile Ad-Hoc Networks

Low-End Middle-Ground

• Nodes with reasonable amount of resources

• Data rates upto 10s Mbps

High-End: Wireless Mesh Networks

• High-speed wireless backbone at >100Mbps

• Resource abundant• Promises to have both wide coverage and

high rate

The Problem: what is new from the wired Internet???• Fundamental challenges for wireless

and mobile networking design: – WIRELESS– MOBILITY

– Is it so obvious and too trivial???

• Map into each layer of the protocol stack

Wireless Impact on Protocol Stack

Partial network connectivity

Changing network quality: delay, throughput

Diverse data losses

Opportunistic connectivity

Time-varying link bandwidth

o Location-dependent error

o Hidden terminals

Application

Middleware and OS

Transport Layer

Network Layer

Link sublayer

MAC sublayer

Mobility Impact on Protocol Stack

Connection, disconnection

Disconnection, reconnection

Mobility-induced data losses

Topology change Time-varying capacity

o Link-layer handoffo Varying link quality

Application

Middleware and OS

Transport Layer

Network Layer

Link sublayer

MAC sublayer

The Goals

• Hide nasty impact of wireless– SAME QUALITY AS WIRED LINK !!

• Offer seamless services while mobile

Overall, “Anytime, anywhere” services

The Design Principles

How to develop the solution?

• The foundation for wireless is the Internet design principles

• The foundation for sensor networks is Wireless and Mobile design

Internet design principles

• #1: End to end argument

• #2: prioritized goals

Principle 1: End-to-end arguments for Internet

Problem statement: How to place the various solution components?

– given the freedom to implement a few functionalities in multiple “places” of the system (physical devices, or layers of protocols), where to implement them?

Goal: correctness, completeness, and performance tradeoff

Approach: end-to-end arguments

Possible Approaches

• Telcom approach: “Smart CORE, Dumb Terminal”– The core ensures reliability

• TCP/IP approach: “Smart Terminal, Dumb CORE”– The terminal ensures reliability– Implicit assumption made: terminals have

more capabilities: computing power, storage, memory, etc.

What is end-to-end argument?• System: application, communication

subsystem and the rest

• End-to-end: – the function can completely and correctly

be implemented ONLY with the knowledge and help of the application standing at the endpoints of the communication system.

– Providing the function as a feature of the communication system is not feasible

– appeals to application requirement– Move a function upward in a layered system

closer to the application that uses the function

Example: reliability• Problem: transfer a file from host A

to B• Steps:

– At A, file system reads and passes the file to ftp

– At A, ftp passes it to data comm. System

– Packets of the file are transferred from A to B

– At B, ftp retrieves the file– At B, file system writes the data to

the disk

Example (continued)

• Threats:– Read error from the disk at A– Software errors in buffering and

copying data by file system, ftp, or network, at A or B

– Hardware errors at A or B– Transfer error in the network part– Host crashes at A or B

Options to handle threats• Option 1: reinforce EVERY step

– Using duplicate copies, timeout and retry, error detection, crash recovery, etc.

– Maybe Not feasible– Uneconomical

• Option 2: end-to-end check and retry– Implement “end-to-end” error

checking at Steps 1 and 5– Retry if checking fails

end-to-end approach in the example• Guarantee correctness and

completeness of reliable file transfer

• Reliability is the composite effects of all the components

• Reliability in the network alone is not sufficient for end-to-end reliability

• Application requirement is the key• Works if the error is not frequent

Two Forms of E2E Principle

• Horizontal: Push complexity outside the network core, into the end systems– Simple IP router, complex TCP end hosts

• Vertical: Push design to higher layers of the protocol stack– End-to-end reliability at the transport layer

in TCP/IP– Hop-by-hop reliability at the link layer in

telcom

When to use e-2-e?• A functionality should be pushed to

higher layers if possible, motivated by– Correctness and completeness– Reduced redundancy– Incremental deployment– More flexibility exposed to applications

• Unless implementing it at lower layers can achieve large performance gains that outweigh the cost of additional complexity at lower layers• IP multicast

More examples• Multicast: IP versus end-system

– Case against IP multicast• Stateful multicast architecture: Requires IP

routers to maintain group state• Vulnerable to flooding attack• Multicast address is needed for each group• Calls for infrastructure-level changes• Slow deployment• Implementing multicast congestion control at

higher layers?

– Case against end-system multicast• Performance penalty

Another example: security

• Security in a networking system• Bruce Schneier wrote in “Secrets and

Lies: Digital security in a networked world” (John Wiley & Sons, Inc; 2000)– Cryptography is not the Answer.– Cryptography is not sufficient from the

system perspective– “Security is a chain; it is only as secure as

the weakest link”– “Security is a process, not a product”

End-to-end Summary• Motivation:

– Correctness and completeness– Reduced redundancy– Incremental deployment– More flexibility exposed to applications

• Forms:• Vertical layer: push to higher layers• Horizontal layer: push outside the

network core• When not: Unless implementing it at

lower layers can achieve large performance gains that outweigh the cost of additional complexity at lower layers

Principle #2: Prioritizing Goals

• Prioritized Goals– Achieve the most important goal first– Make it working first, no optimization please

• Find a working solution first• Effectiveness is more import than efficiency

Case study: Internet & telephone network

List of Design Goals for Internet

• Connectivity: interconnection of distinguishable networks

• Robustness and survivability: communication continues in the presence of various degree of failures

• Flexible service: meet diverse application requirements

• Distributed management• Cost effectiveness• Ease for Plug-in: Easy to attach for new hosts• Accounting issue• Security ….

Fundamental Goal for Internet• Connectivity: Multiplexed utilization of existing

interconnected networks– Design choices: “Network of networks” or “multi-

modal network”• Internet: internetworking• Telcom: multi-modal operations (B-ISDN)

– Solution choices: Multiplexing versus integrating/unifying

• Overthrowing versus re-using existing solutions

– Internet level protocol must be independent of the hardware medium and hardware addressing

• Encourage/discourage diversity and heterogeneity

How IP achieves connectivity

• Guideline 1: If you cannot solve the problem at one layer, solve it at a higher layer– Global connectivity at the IP layer, not

the link layer or below• No need to discard link-layer

technologies, such as Ethernet, FDDI, radio, satellite, ….

– Gluing heterogeneous networks: IP address and IP router

Robust Connectivity: IP’s View1. Failures: Node and network outages

• Simple “Fail-Stop” Failure model: mainly physical device failures • Guideline 1: Reduce the scope of damage via limiting inter-

dependency (decoupling or loosely coupling) 1. Within each application– Problems: (1) how to handle application data– (2) select routes– Solution choices: (1) packetization; (2) packet switching versus circuit

switching» Inspired by the postal mail system

2. Among IP routers: Reduce the potential cascaded failures via less dependent on operations of other components in the system

– Problem: IP router may fail– Solution: “connectionless” within the network: no connection state

management for IP routers• Guideline 2: Notify others when things are wrong

– ICMP error report messages– Light signaling versus heavy signaling

Robust Connectivity: Scaling

• Guideline: “Divide & Conquer”– Solution: Hierarchical Routing– Routing to the network first, then the

host• Net-ID, (Subnet-ID), Host-ID

• No per-connection state within the network: keep the CORE DUMB!– push such states to the edge (end

hosts) of the network

What about other goals?

• So far so good for robust connectivity

• But how much do we weigh other goals?– Not bad at all

Flexible Service

• Simplicity implies flexibility

• Built on top of basic IP best-effort service

• Discard the approach of unified transport service design:– UDP, TCP, RTP, … …

• Remember: no performance assurances

Cost-effectiveness

What about efficiency?• Multiplexing is good

– Bursty data traffic --> on-demand service

• Header contributes overhead– Small packets

• Recovery from lost packets:– End-to-end retransmissions– Not link-by-link retransmissions

IP as a good show case

• It is a product of engineering art– The result is not rigorous, but the design process is

deliberate & scientific!• Full cycle: Design, Prototype, Experiment, Refine…

• Packet-switching system that allows for different realizations

• Live with failures: Not to prevent failures but how to react to them properly– Assume that failure is a norm rather than

exception on the Internet

Other Guidelines?

Many, but secondary, less visible

(Source: T. Anderson, et al, “Design guidelines for robust Internet protocols,” HOTNET)#1: value conceptual simplicity#2: minimize your dependency on others (receiver dependence in TCP fast recovery)#3: verify whenever possible (ECN) #4: protect your resources (TCP SYN Flood)#5: limit the scope of vulnerability#6: expose errors

Key Guideline for Wireless & Mobile Networking Design: Adaptation

• Many concrete forms/instantiations of adaptations• Adaptation to handle different dimensions of dynamics• Adapt to channel variations• Adapt to mobility

• Adaptation at different layers of protocol stacks• From PHY, LINK, to TRANSPORT and APP layers

• Numerous solutions/papers published• 38400 entries for google search “wireless adaptation”• 95800 entries for google search “mobility adaptation”• 40200 entries for google search “802.11 adaptation”

Forms for Adaptation• Model-referenced design

– Ideal model to capture expected performance/behaviors under idealized situ.

• Typically wired case: error-free, static settings

– Track the reference model under realistic conditions/scenarios

• Mobility, wireless channel dynamics, new features, …

• Opportunistic design approach– Make each perform under peak conditions– Exploit the system population– Leverage system diversity

• Multiple receivers, multiple devices, multiple applications/flows, …

Forms of Adaptation

• Horizontal coordination via “indirection”– Adaptation-aware proxy provides

indirection: act as converter/translator

• Vertical cross-layer interactions– Exchange information across layers– Make informed, concerted decision

among layers– Vertical cooperation in the protocol stack

What is NEXT for Wireless and mobile technology?

• It is not the end of the world, it is the end of the beginning

• Many new fronts for technology innovation!!!

Drivers for Wireless Research

Transport Layer

Network Layer

Link Layer

New Applications, Services, Requirements

New Wireless Communications Technology

Top

Down Bottom

Up

Bottom Up Driver: Wireless CommunicationsMany of them:

– Sector Antenna, antenna arrays, Smart antennas – Adaptive modulation, OFDM, MIMO – Spectrum sharing, cognitive radio, channel management– Multi-interface radios, device heterogeneity– …

Challenge: How to exploit these new PHY communication capabilities in the protocols?

Top Down Driver: User DemandMany of them:

• New applications– MMS, P2P image/video sharing, IP TV streaming, …

• New requirements– Security, privacy, robustness/dependability, distributed

management

• New services– Location-based service, Personalized service, …

• New trends– Interoperability of different wireless technologies

Challenge: How to support such new demands?

New Design Goals1. High Performance: #1: Does the system work?#2: How well does the system work?

Technical side: Deliver performance via exploiting PHY capability

2. Resilience#3: How long does the system work under failures?#4: Will the system continue to work under attacks?

Technical side: Renovate the protocols to ensure robustness and security

3. Tradeoff between performance & resilience