Post on 20-Dec-2015
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