Spring 2009 L2 Internet Design Philosophy 1 2 Todays Lecture Layers and protocols Design principles in internetworks 3 Lots of Functions Needed Link Multiplexing Routing Addressingnaming locating peers ID: 329238
Download Presentation The PPT/PDF document "15-446 Distributed Systems" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
15-446 Distributed SystemsSpring 2009
L-2 Internet Design Philosophy
1Slide2
2
Today’s Lecture
Layers and protocols
Design principles in internetworksSlide3
3
Lots of Functions Needed
LinkMultiplexing Routing
Addressing/naming (locating peers)ReliabilityFlow controlFragmentationEtc….Slide4
4
What is Layering?
Modular approach to network functionality
Example:
Link hardware
Host-to-host connectivityApplication-to-application channels
ApplicationSlide5
5
Protocols
Module in layered structure
An agreement between parties on how communication should take place
Protocols define:Interface to higher layers (API)Interface to peer (syntax & semantics)Actions taken on receipt of a messagesFormat and order of messagesError handling, termination, ordering of requests, etc.Example: Buying airline ticket
Friendly greeting
Muttered reply
Destination?
Pittsburgh
Thank youSlide6
6
Layering
Host
Host
Application
Transport
Network
Link
User A
User B
Layering: technique to simplify complex systemsSlide7
7
Layering Characteristics
Each layer relies on services from layer below and exports services to layer aboveInterface defines interaction
Hides implementation - layers can change without disturbing other layers (black box)Slide8
8
The Internet Engineering
Task Force
Standardization is key to network interoperabilityThe hardware/software of communicating parties are often not built by the same vendor
yet they can communicate because they use the same protocolInternet Engineering Task ForceBased on working groups that focus on specific issuesRequest for CommentsDocument that provides information or defines standard
Requests feedback from the communityCan be “promoted” to standard under certain conditionsconsensus in the committeeinteroperating implementationsProject 1 will look at the Internet Relay Chat (IRC) RFCSlide9
9
E.g.: OSI Model: 7 Protocol Layers
Physical: how to transmit bits
Data link: how to transmit framesNetwork: how to route packetsTransport: how to send packets end2end
Session: how to tie flows togetherPresentation: byte ordering, securityApplication: everything elseTCP/IP has been amazingly successful, and it’s not based on a rigid OSI model. The OSI model has been very successful at shaping thoughtSlide10
10
OSI Layers and Locations
Bridge/Switch
Router/Gateway
Host
Host
Application
Transport
Network
Data Link
Presentation
Session
PhysicalSlide11
11
IP Layering
Relatively simple
Bridge/Switch
Router/Gateway
Host
Host
Application
Transport
Network
Link
PhysicalSlide12
12
The Internet Protocol Suite
UDP
TCP
Data Link
Physical
Applications
The Hourglass Model
Waist
The waist facilitates interoperability
FTP
HTTP
TFTP
NV
TCPUDPIPNET1
NET2NETn…Slide13
13
Layer Encapsulation
Get index.html
Connection ID
Source/Destination
Link Address
User A
User BSlide14
14
Protocol Demultiplexing
Multiple choices at each layer
FTP
HTTP
TFTP
NV
TCP
UDP
IP
NET1
NET
2NETn…
TCP/UDPIP
IPXPort NumberNetworkProtocol FieldType FieldSlide15
15
Multiplexing and Demultiplexing
There may be multiple implementations of each layer.
How does the receiver know what version of a layer to use?Each header includes a demultiplexing field that is used to identify the next layer.
Filled in by the senderUsed by the receiverMultiplexing occurs at multiple layers. E.g., IP, TCP, …
IP
TCP
IP
TCP
V/HL
TOS
Length
ID
Flags/Offset
TTLProt.H. ChecksumSource IP address
Destination IP addressOptions..Slide16
16
Is Layering Harmful?
Layer N may duplicate lower level functionality (e.g., error recovery)
Layers may need same info (timestamp, MTU)Strict adherence to layering may hurt performanceSome layers are not always cleanly separated.
Inter-layer dependencies in implementations for performance reasonsSome dependencies in the standards (header checksums)Interfaces are not really standardized.It would be hard to mix and match layers from independent implementations, e.g., windows network apps on unix (w/out compatibility library)Many cross-layer assumptions, e.g. buffer managementSlide17
17
Today’s Lecture
Layers and protocols
Design principles in internetworksSlide18
18
Goals [Clark88]
Connect existing networks
initially ARPANET and ARPA packet radio networkSurvivabilityensure communication service even in the presence of network and router failures
Support multiple types of servicesMust accommodate a variety of networksAllow distributed managementAllow host attachment with a low level of effortBe cost effectiveAllow resource accountability Slide19
19
Priorities
The effects of the order of items in that list are still felt todayE.g., resource accounting is a hard, current research topic
Let’s look at them in detailSlide20
20
0. Connecting Existing Networks
Many differences between networks
Address formatsPerformance – bandwidth/latencyPacket sizeLoss rate/pattern/handlingRoutingHow to internetwork various network technologiesSlide21
21
Address Formats
Map one address format to another?
Bad idea many translations neededProvide one common formatMap lower level addresses to common format Slide22
22
Different Packet Sizes
Define a maximum packet size over all networks?
Either inefficient or high threshold to supportImplement fragmentation/re-assemblyWho is doing fragmentation?Who is doing re-assembly? Slide23
23
Gateway Alternatives
TranslationDifficulty in dealing with different features supported by networks
Scales poorly with number of network types (N^2 conversions)Standardization“IP over everything” Minimal assumptions about network
Hourglass designSlide24
24
1. Survivability
If network disrupted and reconfigured:
Communicating entities should not care!No higher-level state reconfigurationHow to achieve such reliability?Where can communication state be stored?
Network
Host
Failure handing
Replication
“Fate sharing”
Switches
Maintain state
Stateless
Host trust
Less
MoreSlide25
25
Fate Sharing
Lose state information for an entity if (and only if?) the entity itself is lost.
Examples:OK to lose TCP state if one endpoint crashesNOT okay to lose if an intermediate router rebootsIs this still true in today’s network?
NATs and firewalls
Connection State
State
No StateSlide26
26
Soft-State
Basic behaviorAnnounce state
Refresh stateTimeout statePenalty for timeout – poor performanceRobust way to identify communication flowsPossible mechanism to provide non-best effort serviceHelps survivabilitySlide27
27
End-to-End Argument
Deals with where
to place functionalityInside the network (in switching elements)At the edgesArgument:
There are functions that can only be correctly implemented by the endpoints – do not try to completely implement these elsewhereSlide28
28
Example: Reliable File Transfer
Solution 1: make each step reliable, and then concatenate them
Solution 2: end-to-end check and retry
OS
Appl.
OS
Appl.
Host A
Host B
OKSlide29
29
E2E Example: File Transfer
If network guaranteed reliable deliveryThe receiver has to do the check anyway!
E.g., network card may malfunctionFull functionality can only be entirely implemented at application layer; no
need for reliability from lower layersIs there any need to implement reliability at lower layers?Slide30
30
Discussion
Yes, but only to improve performance
If network is highly unreliableAdding some level of reliability helps performance, not correctness
Don’t try to achieve perfect reliability!Implementing a functionality at a lower level should have minimum performance impact on the applications that do not use the functionalitySlide31
31
2. Types of Service
Best effort delivery
All packets are treated the sameRelatively simple core network elementsBuilding block from which other services (such as reliable data stream) can be built
Contributes to scalability of networkNo QoS support assumed from belowAccommodates more networksHard to implement without network supportQoS is an ongoing debate…Slide32
32
Types of Service
TCP vs. UDP
Elastic apps that need reliability: remote login or emailInelastic, loss-tolerant apps: real-time voice or videoOthers in between, or with stronger requirements
Biggest cause of delay variation: reliable deliveryToday’s net: ~100ms RTTReliable delivery can add seconds.Original Internet model: “TCP/IP” one layerFirst app was remote login…But then came debugging, voice, etc.
These differences caused the layer split, added UDPSlide33
33
3. Varieties of Networks
Minimum set of assumptions for underlying net
Minimum packet sizeReasonable delivery odds, but not 100%Some form of addressing unless point to point
Important non-assumptions:Perfect reliabilityBroadcast, multicastPriority handling of trafficInternal knowledge of delays, speeds, failures, etc.Much engineering then only has to be done onceSlide34
34
The “Other” goals
4. Management
Each network owned and managed separatelyWill see this in BGP routing especially5. Attaching a host
Not awful; DHCP and related autoconfiguration technologies helping.6. Cost effectivenessEconomies of scale won outInternet cheaper than most dedicated networksPacket overhead less important by the year
But…Slide35
35
7. Accountability
Huge problem.
AccountingBilling? (mostly flat-rate. But phones are moving that way too - people like it!)Inter-provider payments
Hornet’s nest. Complicated. Political. Hard.Accountability and securityHuge problem.Worms, viruses, etc.Partly a host problem. But hosts very trusted.AuthenticationPurely optional. Many philosophical issues of privacy vs. security.
Greedy sources aren’t handled wellSlide36
36
Other IP Design Weaknesses
Weak administration and management toolsIncremental deployment difficult at times
Result of no centralized controlNo more “flag” daysAre active networks the solution?Slide37
37
Summary: Internet Architecture
Packet-switched datagram network
IP is the “compatibility layer” Hourglass architecture
All hosts and routers run IPStateless architectureNo per flow state inside network
IP
TCP
UDP
ATM
Satellite
EthernetSlide38
38
Summary: Minimalist Approach
Dumb network
IP provide minimal functionalities to support connectivityAddressing, forwarding, routingSmart end system
Transport layer or application performs more sophisticated functionalitiesFlow control, error control, congestion controlAdvantagesAccommodate heterogeneous technologies (Ethernet, modem, satellite, wireless)Support diverse applications (telnet, ftp, Web, X windows)Decentralized network administration
Beginning to show ageUnclear what the solution will be probably IPv6Discussion: what are the implications for distributed system design?