Last Lecture: What is the

Objective of Networking?
• Enable communication between applications on different
computers
• Web (Lecture 22)
15-441 Computer Networking • Peer to Peer (Lecture 23)
• Audio/Video (Lecture 20)
• Funky research stuff (Lecture 27)
Lecture 2 - Protocol Stacks
• Must understand application needs/demands (Lecture 3)
• Traffic data rate
• Traffic pattern (bursty or constant bit rate)
• Traffic target (multipoint or single destination, mobile or fixed)
• Delay sensitivity
• Loss sensitivity

Last Lecture:
Lots of Functions Needed Today’s Lecture

• Link
• Multiplexing • Layers and protocols
• Routing
• Addressing/naming (locating peers) • Design principles in internetworks
• Reliability
• Flow control
• Fragmentation
• Etc….
3 4

Page 1
What is Layering? What is Layering?

• Modular approach to network functionality Peer Layer Peer Layer

User A User B
• Example:
Application

Application
Transport
Application-to-application channels
Network
Host-to-host connectivity Link

Link hardware Host Host

Modular approach to network functionality

5 6

Layering Characteristics What are Protocols?

• An agreement between parties on
• Each layer relies on services from layer how communication should take Friendly greeting
place
below and exports services to layer above
• Interface defines interaction with peer on • Module in layered structure
Muttered reply
other hosts • Protocols define:
• Interface to higher layers (API)
• Hides implementation - layers can change • Interface to peer (syntax & semantics) Destination?
• Actions taken on receipt of a
without disturbing other layers (black box) messages
• Format and order of messages
• Error handling, termination, ordering of Pittsburgh
requests, etc.

• Example: Buying airline ticket Thank you

7 8

Page 2
The Internet Engineering Other Relevant
Task Force Standardization Bodies
• Standardization is key to network interoperability • ITU-TS - Telecommunications Sector of the International
• The hardware/software of communicating parties are often not built Telecommunications Union.
by the same vendor à yet they can communicate because they • government representatives (PTTs/State Department)
use the same protocol • responsible for international “recommendations”
• T1 - telecom committee reporting to American National
• Internet Engineering Task Force Standards Institute.
• Based on working groups that focus on specific issues • T1/ANSI formulate US positions
• interpret/adapt ITU standards for US use, represents US in ISO
• Request for Comments • IEEE - Institute of Electrical and Electronics Engineers.
• Document that provides information or defines standard • responsible for many physical layer and datalink layer standards
• Requests feedback from the community
• Can be “promoted” to standard under certain conditions
• ISO - International Standards Organization.
• consensus in the committee
• covers a broad area
• interoperating implementations
• Project 1 will look at the Internet Relay Chat (IRC) RFC

9 10

OSI Model: 7 Protocol Layers OSI Layers and Locations

• Physical: how to transmit bits

• Data link: how to transmit frames
Application
• Network: how to route packets
Presentation
• Transport: how to send packets end2end
Session
• Session: how to tie flows together Transport
• Presentation: byte ordering, security Network
• Application: everything else
Data Link

Physical
• TCP/IP has been amazingly successful, and it’s not
based on a rigid OSI model. The OSI model has Host Bridge/Switch Router/Gateway Host
been very successful at shaping thought

11 12

Page 3
IP Layering The Internet Protocol Suite
• Relatively simple
FTP HTTP NV TFTP Applications
Application
TCP UDP UDP TCP
Transport
Waist
IP
Network
Data Link
Link NET1 NET2 … NETn
Physical
Physical
The Hourglass Model
Host Bridge/Switch Router/Gateway Host
The waist facilitates interoperability
13 14

Layer Encapsulation Multiplexing and Demultiplexing

• There may be multiple
implementations of each
User A User B layer. TCP TCP
• How does the receiver know
what version of a layer to IP IP
Get index.html use?
• Each header includes a
Connection ID demultiplexing field that is
used to identify the next
layer. V/HL TOS Length
Source/Destination
• Filled in by the sender ID Flags/Offset
Link Address • Used by the receiver TTL Prot. H. Checksum
• Multiplexing occurs at Source IP address
multiple layers. E.g., IP,
Destination IP address
TCP, …
Options..

15 16

Page 4
Protocol Demultiplexing Is Layering Harmful?

• Multiple choices at each layer • Layer N may duplicate lower level functionality (e.g., error
recovery)
• Layers may need same info (timestamp, MTU)
• Strict adherence to layering may hurt performance
FTP HTTP NV TFTP
• Some layers are not always cleanly separated.
• Inter-layer dependencies in implementations for performance
TCP UDP reasons
• Some dependencies in the standards (header checksums)
Network IP TCP/UDP
IPX IP • Interfaces are not really standardized.
• It would be hard to mix and match layers from independent
Type Protocol Port implementations, e.g., windows network apps on unix (w/out
Field Field Number compatibility library)
NET1 NET2 … NETn
• Many cross-layer assumptions, e.g. buffer management

17 18

Today’s Lecture Goals [Clark88]

0 Connect existing networks

• Layers and protocols initially ARPANET and ARPA packet radio network
1. Survivability
ensure communication service even in the presence of
• Design principles in internetworks 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 accountability

19 20

Page 5
Priorities Goal 0: Connecting Networks

• The effects of the order of items in that list • How to internetwork various network
are still felt today technologies
• ARPANET, X.25 networks, LANs, satellite
• E.g., resource accounting is a hard, current networks, packet networks, serial links…
research topic
• Many differences between networks
• Let’s look at them in detail • Address formats
• Performance – bandwidth/latency
• Packet size
• Loss rate/pattern/handling
• Routing

21 22

Challenge 1: Challenge 2:
Address Formats Different Packet Sizes
• Map one address format to another? • Define a maximum packet size over all
• Bad idea à many translations needed networks?
• Provide one common format • Either inefficient or high threshold to support
• Map lower level addresses to common format • Implement fragmentation/re-assembly
• Who is doing fragmentation?
• Who is doing re-assembly?

23 24

Page 6
Gateway Alternatives IP Standardization

• Translation • Minimum set of assumptions for underlying net

• Minimum packet size
• Difficulty in dealing with different features • Reasonable delivery odds, but not 100%
supported by networks • Some form of addressing unless point to point

• Scales poorly with number of network types • Important non-assumptions:

(N^2 conversions) • Perfect reliability
• Broadcast, multicast
• Standardization • Priority handling of traffic
• “IP over everything” (Design Principle 1) • Internal knowledge of delays, speeds, failures, etc

• Minimal assumptions about network • Also achieves Goal 3: Supporting Varieties of Networks
• Hourglass design

25 26

IP Hourglass IP Layering (Principle 2)

• Need to interconnect many • Relatively simple

existing networks • Sometimes taken too far
email WWW phone..."

• Hide underlying SMTP HTTP RTP..." Applications!

technology from
TCP UDP…"
"

applications
IP"
"
Application
ethernet PPP…"

• Decisions: CSMA async sonet..."

copper fiber radio..."

Technology!
Transport
• Network provides minimal
functionality Network

• “Narrow waist” Link

Host Router Router Host

Tradeoff: No assumptions, no guarantees.
27 28

Page 7
Goal 1: Survivability Principle 3: Fate Sharing
• If network is disrupted and reconfigured… Connection
• Communicating entities should not care! State No State State
• No higher-level state reconfiguration
• Lose state information for an entity if and only if the entity itself
is lost.
• How to achieve such reliability? • Examples:
• Where can communication state be stored? • 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?
Network Host • NATs and firewalls

Failure handing Replication “Fate sharing” • Tradeoffs

• Survivability: Heterogeneous network à less information available
Net Engineering Tough Simple to end hosts and Internet level recovery mechanisms
Switches Maintain state Stateless • Trust: must trust endpoints more

Host trust Less More

29 30

Principle 4: Soft-state Principle 5: End-to-End Argument

• Soft-state • Deals with where to place functionality

• Announce state • Inside the network (in switching elements)
• Refresh state • At the edges
• Timeout state • Argument
• Penalty for timeout – poor performance • There are functions that can only be correctly
• Robust way to identify communication flows implemented by the endpoints – do not try to
completely implement these elsewhere
• Possible mechanism to provide non-best effort
service • Guideline not a law

• Helps survivability
31 32

Page 8
Example: Reliable File Transfer E2E Example: File Transfer
Host A Host B • Even if network guaranteed reliable delivery
• Need to provide end-to-end checks
Appl. Appl. • E.g., network card may malfunction
• The receiver has to do the check anyway!
OS OK OS • Full functionality can only be entirely implemented at
application layer; no need for reliability from lower layers

• Does FTP look like E2E file transfer?

• Solution 1: make each step reliable, and • TCP provides reliability between kernels not disks
then concatenate them
• Is there any need to implement reliability at lower
• Solution 2: end-to-end check and retry layers?

33 34

Discussion Examples

• Yes, but only to improve performance • What should be done at the end points, and
• If network is highly unreliable what by the network?
• Adding some level of reliability helps • Reliable/sequenced delivery?
performance, not correctness • Addressing/routing?
• Don’t try to achieve perfect reliability! • Security?
• Implementing a functionality at a lower level • What about Ethernet collision detection?
should have minimum performance impact on • Multicast?
the applications that do not use the functionality • Real-time guarantees?

35 36

Page 9
Goal 2: Types of Service Types of Service
• Principle 6: network layer provides one simple service: best • TCP vs. UDP
effort datagram (packet) delivery • Elastic apps that need reliability: remote login or email
• All packets are treated the same • Inelastic, loss-tolerant apps: real-time voice or video
• Others in between, or with stronger requirements
• Relatively simple core network elements • Biggest cause of delay variation: reliable delivery
• Building block from which other services (such as reliable data • Today’s net: ~100ms RTT
stream) can be built • Reliable delivery can add seconds.
• Contributes to scalability of network
• Original Internet model: “TCP/IP” one layer
• No QoS support assumed from below • First app was remote login…
• In fact, some underlying nets only supported reliable delivery • But then came debugging, voice, etc.
• Made Internet datagram service less useful! • These differences caused the layer split, added UDP
• Hard to implement without network support
• QoS is an ongoing debate…

37 38

Goal 4: Decentralization The “Other” goals

• Principle 7: Each network owned and

managed separately 5. Attaching a host
• Will see this in BGP routing especially • Host must implement hard part L à transport services
• Not too bad

• Principle 7’: Be conservative in what you send

and liberal in what you accept 6. Cost effectiveness
• Unwritten rule • Packet overhead less important by the year
• Packet loss rates low
• Especially useful since many protocol • Economies of scale won out
specifications are ambiguous • Internet cheaper than most dedicated networks
• E.g. TCP will accept and ignore bogus
acknowledgements • But…
39 40

Page 10
7. Accountability Other IP Design Weaknesses
• Huge problem
• Weak administration and management tools
• Accounting • Incremental deployment difficult at times
• Billing? (mostly flat-rate. But phones have become that way also -
people like it!) • Result of no centralized control
• Inter-ISP payments
• Hornet’s nest. Complicated. Political. Hard. • No more “flag” days
• Accountability and security
• Huge problem.
• Worms, viruses, etc.
• Partly a host problem. But hosts very trusted.
• Authentication
• Purely optional. Many philosophical issues of privacy vs. security.
• Greedy sources aren’t handled well

41 42

Summary: Internet Architecture Summary: Minimalist Approach

• Packet-switched • Dumb network

datagram network • IP provide minimal functionalities to support connectivity
TCP UDP • Addressing, forwarding, routing
• IP is the “compatibility • Smart end system
layer” • Transport layer or application performs more sophisticated
IP functionalities
• Hourglass architecture • Flow control, error control, congestion control
• All hosts and routers run Satellite • Advantages
IP • Accommodate heterogeneous technologies (Ethernet,
Ethernet ATM
• Stateless architecture modem, satellite, wireless)
• Support diverse applications (telnet, ftp, Web, X windows)
• no per flow state inside • Decentralized network administration
network
43 44

Page 11
Summary Changes Over Time à
New Principles?
• Successes: IP on • Developed in simpler times
everything! • Common goals, consistent vision
• With success came multiple goals – examples:
“This set of goals might seem to be • ISPs must talk to provide connectivity but are fierce
• Drawbacks… nothing more than a checklist of all the competitors
desirable network features. It is
important to understand that these
• Privacy of users vs. government’s need to monitor
but perhaps they’re goals are in order of importance, and • User’s desire to exchange files vs. copyright owners
totally worth it in the an entirely different network • Must deal with the tussle between concerns in design
context of the original architecture would result if the
Internet. Might not have order were changed.”
• Provide choice à allow all parties to make choices on
worked without them! interactions
• Creates competition
• Fear between providers helps shape the tussle

45 46

Page 12