DOC PREVIEW
Berkeley COMPSCI 268 - Lecture Notes

This preview shows page 1-2-15-16-31-32 out of 32 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 32 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1 CS 268: Computer Networking L-2 Design Considerations 2 Design Considerations • How to determine split of functionality • Across protocol layers • Across network nodes • Assigned Reading • [SRC84] End-to-end Arguments in System Design • [Cla88] Design Philosophy of the DARPA Internet Protocols2 3 Outline • Design principles in internetworks • IP design 4 Goals [Clark88] 0. Connect existing networks initially ARPANET and ARPA packet radio network 1. Survivability ensure communication service even in the presence of network and router failures 2. Support multiple types of services 3. Must accommodate a variety of networks 4. Allow distributed management 5. Allow host attachment with a low level of effort 6. Be cost effective 7. Allow resource accountability3 5 Connecting Networks • How to internetwork various network technologies • ARPANET, X.25 networks, LANs, satellite networks, packet networks, serial links… • Many differences between networks • Address formats • Performance – bandwidth/latency • Packet size • Loss rate/pattern/handling • Routing 6 Challenge 1: Address Formats • Map one address format to another? • Bad idea  many translations needed • Provide one common format • Map lower level addresses to common format4 7 Challenge 2: Different Packet Sizes • Define a maximum packet size over all networks? • Either inefficient or high threshold to support • Implement fragmentation/re-assembly • Who is doing fragmentation? • Who is doing re-assembly? 8 Gateway Alternatives • Translation • Difficulty in dealing with different features supported by networks • Scales poorly with number of network types (N2 conversions) • Standardization • “IP over everything” (Design Principle #1) • Minimal assumptions about network • Hourglass design5 Standardization • Minimum set of assumptions for underlying net • Minimum packet size • Reasonable delivery odds, but not 100% • Some form of addressing unless point to point • Important non-assumptions: • Perfect reliability • Broadcast, multicast • Priority handling of traffic • Internal knowledge of delays, speeds, failures, etc. • Much engineering then only has to be done once IP Hourglass • Need to interconnect many existing networks • Hide underlying technology from applications • Decisions: • Network provides minimal functionality • “Narrow waist” Tradeoff: No assumptions, no guarantees. Technology!Applications! email WWW phone..."SMTP HTTP RTP..."TCP UDP…"IP" ethernet PPP…"CSMA async sonet..." copper fiber radio..."6 11 IP Layering (Principle #8) • Relatively simple • Sometimes taken too far Router Router Host Host Application Transport Network Link 12 Principle #7 • Be conservative in what you send and liberal in what you accept • Unwritten rule • Especially useful since many protocol specifications are ambiguous • E.g., TCP will accept and ignore bogus acknowledgements7 Survivability • If network disrupted and reconfigured • Communicating entities should not care! • No higher-level state reconfiguration • How to achieve such reliability? • Where can communication state be stored? 13 Network Host Failure handing Replication “Fate sharing” Net Engineering Tough Simple Switches Maintain state Stateless Host trust Less More Principle #2: 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 crashes • NOT okay to lose if an intermediate router reboots • Is this still true in today’s network? • NATs and firewalls • Survivability compromise: Heterogeneous network  less information available to end hosts and Internet level recovery mechanisms Connection State State No State 148 15 Principle #3: Soft-state • Soft-state • Announce state • Refresh state • Timeout state • Penalty for timeout – poor performance • Robust way to identify communication flows • Possible mechanism to provide non-best effort service • Helps survivability 16 Principle #4: End-to-End Argument • Deals with where to place functionality • Inside the network (in switching elements) • At the edges • Argument • There are functions that can only be correctly implemented by the endpoints – do not try to completely implement these elsewhere • Guideline not a law9 17 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 OK E2E Example: File Transfer • Even if network guaranteed reliable delivery • Need to provide end-to-end checks • E.g., network card may malfunction • The receiver has to do the check anyway! • Full functionality can only be entirely implemented at application layer; no need for reliability from lower layers • Does FTP look like E2E file transfer? • TCP provides reliability between kernels not disks • Is there any need to implement reliability at lower layers? 1810 19 Discussion • Yes, but only to improve performance • If network is highly unreliable • Adding 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 functionality 20 Examples • What should be done at the end points, and what by the network? • Reliable/sequenced delivery? • Addressing/routing? • Security? • What about Ethernet collision detection? • Multicast? • Real-time guarantees?11 Types of Service • Principle #5: network layer provides one simple service: best effort datagram (packet) delivery • All packets are treated the same • Relatively simple core network elements • Building block from which other services (such as reliable data stream) can be built • Contributes to scalability of network • No QoS support assumed from below • In fact, some underlying nets only supported reliable delivery • Made Internet datagram service


View Full Document

Berkeley COMPSCI 268 - Lecture Notes

Documents in this Course
Lecture 8

Lecture 8

33 pages

L-17 P2P

L-17 P2P

50 pages

Multicast

Multicast

54 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?