ip revisited taekyoung kwon [email protected] courtesy of kevin lai and ion stoica with berkeley jim...
TRANSCRIPT
![Page 1: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/1.jpg)
IP revisited
Taekyoung [email protected]
Courtesy of Kevin Lai and Ion Stoica with Berkeley
Jim Kurose with UmassHenning Schulzrinne with Columbia
![Page 2: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/2.jpg)
Network Core: Circuit Switching
network resources (e.g., bandwidth) divided into “pieces”
• pieces allocated to calls• resource piece idle if not used by owning call (no
sharing)• dividing link bandwidth into “pieces”
– frequency division– time division
![Page 3: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/3.jpg)
Network Core: Packet Switching
each end-end data stream divided into packets
• user A, B packets share network resources
• each packet uses full link bandwidth
• resources used as needed,
resource contention: • aggregate resource
demand can exceed amount available
• congestion: packets queue, wait for link use
• store and forward: packets move one hop at a time– transmit over link– wait turn at next linkBandwidth division into
“pieces”Dedicated allocationResource reservation
![Page 4: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/4.jpg)
Network Core: Packet Switching
Packet-switching versus circuit switching: human restaurant analogy
• other human analogies?
A
B
C10 MbsEthernet
1.5 Mbs
45 Mbs
D E
statistical multiplexing
queue of packetswaiting for output
link
![Page 5: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/5.jpg)
Packet switching versus circuit switching
• 1 Mbit link• each user:
– 100Kbps when “active”– active 10% of time
• circuit-switching: – 10 users
• packet switching: – with 35 users,
probability > 10 active less than .0004
Packet switching allows more users to use network!
N users
1 Mbps link
What is statistical multiplexing gain?
![Page 6: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/6.jpg)
Packet switching versus circuit switching
• Great for bursty data– resource sharing– no call setup
• Excessive congestion: packet delay and loss– protocols needed for reliable data transfer, congestion
control• Q: How to provide circuit-like behavior?
– bandwidth guarantees needed for audio/video apps– still an unsolved problem
Is packet switching a “slam dunk winner?”
![Page 7: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/7.jpg)
Packet-switched networks: routing
• Goal: move packets among routers from source to destination
• datagram network: – destination address determines next hop– routes may change during session– analogy: driving, asking directions
• virtual circuit network: – each packet carries tag (virtual circuit ID), tag determines
next hop– fixed path determined at call setup time, remains fixed thru
call– routers maintain per-call state
![Page 8: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/8.jpg)
Delay in packet-switched networks
packets experience delay on end-to-end path
• four sources of delay at each hop
• nodal processing: – check bit errors– determine output link
• queueing– time waiting at output
link for transmission – depends on congestion
level of routerA
B
propagation
transmission
nodalprocessing queueing
Which delay corresponds to bandwidth?
![Page 9: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/9.jpg)
Delay in packet-switched networks
Transmission delay:• R=link bandwidth (bps)• L=packet length (bits)• time to send bits into link
= L/R
Propagation delay:• d = length of physical link• s = propagation speed in
medium (~2x108 m/sec)• propagation delay = d/s
A
B
propagation
transmission
nodalprocessing queueing
Note: s and R are very different quantities!
High-speed network?High-bandwidth network?
![Page 10: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/10.jpg)
Queueing delay (revisited)
• R=link bandwidth (bps)• L=packet length (bits)• a=average packet arrival
rate
traffic intensity = La/R
• La/R ~ 0: average queueing delay small• La/R -> 1: delays become large• La/R > 1: more “work” arriving than can be
serviced, average delay infinite!
![Page 11: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/11.jpg)
Internet structure: network of networks
• roughly hierarchical• national/international backbone provi
ders (NBPs) [tier 1]– e.g. BBN/GTE, Sprint, AT&T, IBM, UU
Net– interconnect (peer) with each other pr
ivately, or at public Network Access Point (NAPs)
• regional ISPs [tier 2]– connect into NBPs
• local ISP [tier 3], company– connect into regional ISPs
• a point-of-presence (POP) is an access point from one place to the rest of the Internet
NBP A
NBP B
NAP NAP
regional ISP
regional ISP
localISP
localISP
![Page 12: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/12.jpg)
National Backbone Providere.g. Sprint US backbone network
![Page 13: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/13.jpg)
Layered approach
• What is layering?– A technique to organize a network system into
a succession of logically distinct entities, such that the service provided by one entity is solely based on the service provided by the previous (lower level) entity
![Page 14: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/14.jpg)
Why layering?
• No layering: each new application has to be re-implemented for every network technology!
Telnet FTP NFS
Packetradio
Coaxial cable
Fiberoptic
Application
TransmissionMedia
HTTP
![Page 15: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/15.jpg)
Why Layering?
• Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies
Telnet FTP NFS
Packetradio
Coaxial cable
Fiberoptic
Application
TransmissionMedia
HTTP
Intermediate layer
![Page 16: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/16.jpg)
Layering
• Advantages– Modularity – protocols easier to manage and maintain– Abstract functionality: lower layers can be changed
without affecting the upper layers– Reuse – upper layers can reuse the functionality provided
by lower layers
• Disadvantages– Information hiding – inefficient implementations
![Page 17: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/17.jpg)
Key Design Decision
• How do you divide functionality across the layers?
![Page 18: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/18.jpg)
Layering: Hop-by-Hop vs. End-to-End
• Think twice before implementing a functionality that you believe that is useful to an application at a lower layer
• If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement
![Page 19: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/19.jpg)
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
![Page 20: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/20.jpg)
Discussion
• Solution 1 not complete– What happens if the sender or/and receiver
misbehave?
• The receiver has to do the check anyway!• Thus, full functionality can be entirely
implemented at application layer; no need for reliability from lower layers
• Is there any need to implement reliability at lower layers?
![Page 21: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/21.jpg)
Discussion
• Yes, but only to improve performance• Example:
– Assume a high error rate on communication network– Then, a reliable communication service at data link layer
might help
![Page 22: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/22.jpg)
Trade-offs
• Application has more information about the data and the semantic of the service it requires (e.g., can check only at the end of each data unit)
• A lower layer has more information about constraints in data transmission (e.g., packet size, error rate)
• Note: these trade-offs are a direct result of layering!
![Page 23: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/23.jpg)
Rule of Thumb
• Implementing a functionality at a lower level should have minimum performance impact on the application that do not use the functionality
![Page 24: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/24.jpg)
Internet & End-to-End Argument
• Provides one simple service: best effort datagram (packet) delivery
• Only one higher level service implemented at transport layer: reliable data delivery (TCP)– Performance enhancement; used by a large variety of applications
(Telnet, FTP, HTTP)– Does not impact other applications (can use UDP)
• Everything else implemented at application level
![Page 25: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/25.jpg)
Key Advantages
• The service can be implemented by a large variety of network technologies
• Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is – Robust– Scalable
![Page 26: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/26.jpg)
What About Other Services?
• Multicast?• Quality of Service (QoS)?
![Page 27: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/27.jpg)
Summary: Layering
• Key technique to implement communication protocols; provides– Modularity– Abstraction– Reuse
• Key design decision: what functionality to put in each layer?
![Page 28: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/28.jpg)
Summary: End-to-End Argument
• If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs– Add functionality in lower layers iff it is (1) used and improves perf
ormances of a large number of applications, and (2) does not hurt other applications
• Success story: Internet
![Page 29: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/29.jpg)
Summary
• Challenge of building a good (network) system: find the right balance between:
Reuse, implementation effort(apply layering concepts)
End-to-end argumentPerformance
No universal answer: the answer depends on the goals and assumptions!
![Page 30: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/30.jpg)
How Internet started?
![Page 31: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/31.jpg)
The Problem
• Before Internet– different packet-switching networks (e.g., ARPANET, ARPA
packet radio)– only nodes on the same physical/link layer network could
communicate– want to share room-size computers, storage to reduce
expense
![Page 32: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/32.jpg)
The Challenge
• Interconnect existing networks• … but, packet switching networks differ
widely– different services
• e.g., degree of reliability
– different interfaces • e.g., length of the packet that can be transmitted,
address format
– different protocols• e.g., routing protocols
![Page 33: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/33.jpg)
Possible solutions
• Reengineer and develop one global packet switching network standard– not economically feasible– not deployable
• Have every host implement the protocols of any network it wants to communicate with– Complexity/node = O(n)– O(n2) global complexity
![Page 34: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/34.jpg)
Solution
• Add an extra layer: inter-networking layer– hosts:
• understand one network protocol• understand one physical/link protocol
– gateways:• understand one network protocol• understand the physical/link protocols of the networks they
gateway
– Complexity to add a node/network: O(1) with respect to number of existing nodes
![Page 35: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/35.jpg)
Solution
Gateways
![Page 36: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/36.jpg)
Common Intermediate Representation
• Examples:– telnet, IP, strict HTML, I-mode cHTML
• Who ignored this:– US cell phone providers (pairwise roaming agreements)– IE HTML, Netscape HTML, etc.– WAP (WML same purpose as HTML, but not compatible)
• network value = O(n2), (Metcalfe's Law)• pairwise translation: cost = O(n2), utility = O(1)• CIR: cost = O(n), utility = O(n)
![Page 37: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/37.jpg)
Challenge 1: Different Address Formats
• Options:– Map one address format to another. Why not?– Provide one common format
• map lower level addresses to common format
• Format: – Initially: 8b network 16b host 24b total– Before Classless InterDomain Routing (CIDR):
• 7b/24b, 14b/16b, or 21b/8b 32b total– After CIDR: Arbitrary division 32b total– NAT: 32b + 16b simultaneously active– IPv6: 128b total
![Page 38: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/38.jpg)
Address Formats
• 256 networks? What were they thinking?• Why CIDR?• What happens if they run out before IPv6?• Why IPv6?• Why 128b for IPv6? 248=281 trillion.• Why not variable length addresses?
![Page 39: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/39.jpg)
Challenge 2: Different Packet Sizes
• Need to define maximum packet size• Options:
– Take the minimum of the maximum packets sizes over all networks
– Implement fragmentation/reassembly• Flexibility to adjust packet sizes as new technologies arrive• IP: fragment at routers, reassemble at host• Why not reassemble at routers?
– Still stuck with 1500B as de facto maximum
![Page 40: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/40.jpg)
Other Challenges
• Errors require end-to-end reliability– Thought to be rarely invoked, but necessary
• Different (routing) protocols coordinate these protocols
• Accounting– Did not envision script kiddies
• Quality of Service– Not addressed
![Page 41: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/41.jpg)
Transmission Control Program
• Original TCP/IP (Cerf & Kahn) – no separation between transport (TCP) and network (IP) layers– one common header (vestige?)– flow control, but not congestion control (why not?)– fragmentation handled by TCP
• Today’s TCP/IP – separate transport (TCP) and network (IP) layer (why?)– split the common header in: TCP and UDP headers– fragmentation reassembly done by IP – congestion control
![Page 42: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/42.jpg)
Devil’s Advocate
• Who cares about resource sharing?– 1974: cycles, storage, bandwidth expensive, people
cheap– 2002: resources cheap, people expensive– 1974: Share computer resources– 2002: Communicate with people, access documents, buy,
sell
• Does it still make sense to make processes the endpoint?
![Page 43: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/43.jpg)
Back to the big picture
![Page 44: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/44.jpg)
Goals (Clark’88)
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 services3. Must accommodate a variety of networks4. Allow distributed management5. Allow host attachment with a low level of effort6. Be cost effective7. Allow resource accountability
![Page 45: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/45.jpg)
1. Survivability
• continue to operate even in the presence of network failures (e.g., link and router failures)– failures (excepting network partition) should be
transparent to endpoints
• maintain state only at end-points (fate-sharing)– no need to replicate and restore router state– disadvantages?
• Internet: stateless network architecture– no per-flow state, still have state in address
allocation, DNS
![Page 46: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/46.jpg)
2. Types of Services
• Add UDP to TCP to better support other types of applications – e.g., “real-time” applications
• Probably main reason for separating TCP and IP• Provide datagram abstraction: lower common denominator
on which other services can be built – service differentiation considered (ToS header bits)– was not widely deployed (why?)
![Page 47: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/47.jpg)
Application Assumptions
• Who made them:– Telephone network: voice (web, video?)– Cable: broadcast (2-way?)– X.25: remote terminal access (file transfer?)– BBS: centralized meeting place (web, p2p?)– NAT: client/server model (p2p, IM, IP Telephony?)
• Who didn't: Internet– Caveat: best-effort, unicast, fixed location (real-time,
multicast, mobility?)
• Allows development of unforeseen applications:– Web, p2p, distributed gaming
![Page 48: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/48.jpg)
3. Variety of Networks
• Very successful– because the minimalist service; it requires from underlying network
only to deliver a packet with a “reasonable” probability of success
• …does not require:– reliability, in-order delivery, single delivery, QoS guarantees
• The mantra: IP over everything– Then: ARPANET, X.25, DARPA satellite network..– Now: ATM, SONET, WDM, PPP, USB, 802.11b, GSM, GPRS, DSL, c
able modems, power lines
![Page 49: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/49.jpg)
Internet Architecture
• Packet-switched datagram network
• IP is the glue • Hourglass architecture
– all hosts and routers run IP
• Common Intermediate Representation
IP
TCP UDP
ATM
Satellite
Ethernet
![Page 50: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/50.jpg)
Other Goals
• Allow distributed management– each network can be managed by a different
organization– different organizations need to interact only at
the boundaries– doesn’t work so well for routing, accounting
• Cost effective – sources of inefficiency
• header overhead• retransmissions• routing
– …but routers relatively simple to implement (especially software side)
![Page 51: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/51.jpg)
Other Goals (Cont)
• Low cost of attaching a new host– not a strong point higher than other architecture because the in
telligence is in hosts (e.g., telephone vs. computer)• Moore’s law made this moot point, both <$100
– bad implementations or malicious users can produce considerably harm (remember fate-sharing?)
• DDoS possibly biggest threat to Internet
• Accountability– very little so far
![Page 52: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/52.jpg)
What About the Future?
• Datagram not the best abstraction for:– resource management, accountability, QoS
• A new abstraction: flow?• Routers require to maintain per-flow state (what is the mai
n problem with this raised by Clark?)– state management
• Solution– soft-state: end-hosts responsible to maintain the state
![Page 53: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/53.jpg)
Summary: Minimalist Approach
• Dumb network– IP provide minimal functionalities to support connectivity– addressing, forwarding, routing
• Smart end system– transport layer or app does more sophisticated functionalities– flow control, error control, congestion control
• Advantages– accommodate heterogeneous technologies – support diverse applications (telnet, ftp, Web, X windows)– decentralized network administration
• Disadvantages– poor realtime performance– poor accountability
![Page 54: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/54.jpg)
Textbook Internet vs. real Internet
end-to-end (application only in 2 places)
middle boxes (proxies, ALGs, …)
permanent interface identifier (IP address)
time-varying (DHCP)
globally unique and routable
network address translation (NAT)
multitude of L2 protocols (ATM, ARCnet, Ethernet, FDDI, modems, …)
dominance of Ethernet, but also L2’s not designed for networks (1394 Firewire, Fibre Channel, …)
![Page 55: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/55.jpg)
Textbook Internet vs. real Internet
mostly trusted end users hackers, spammers, con artists, pornographers, …
small number of manufacturers, making expensive boxes
Linksys, Dlink, Netgear, …, available at Radio Shack
technical users, excited about new technology
grandma, frustrated if email doesn’t work
4 layers (link, network, transport, application)
layer splits
transparent network firewalls, L7 filters, “transparent proxies”
![Page 56: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/56.jpg)
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
The Internet Protocol Hourglass(Deering)
![Page 57: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/57.jpg)
Why the hourglass architecture?
• Why an internet layer?– make a bigger network– global addressing– virtualize network to isolate end-to-end
protocols from network details/changes• Why a single internet protocol?
– maximize interoperability– minimize number of service interfaces
• Why a narrow internet protocol?– assumes least common network functionality
to maximize number of usable networks
Deering, 1998
![Page 58: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/58.jpg)
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP + mcast
+ QoS +...
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Putting on Weight
• requires more functionality from underlying networks
![Page 59: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/59.jpg)
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP4 IP6
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Mid-Life Crisis
• doubles number of service interfaces
• requires changes above & below
• major interoper-ability issues
![Page 60: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/60.jpg)
Layer splitting
• Traditionally, L2 (link), L3 (network = IP), L4 (transport = TCP), L7 (applications)
• Layer 2: Ethernet PPPoE (DSL)• Layer 2.5: MPLS, L2TP• Layer 3: tunneling (e.g., GPRS)• Layer 4: UDP + RTP• Layer 7: HTTP + real application
![Page 61: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/61.jpg)
Internet acquires presentation layer
• All learn about OSI 7-layer model• OSI: ASN.1 as common rendering of application
data structures– used in LDAP and SNMP (and H.323)
• Internet never really had presentation layer– approximations: common encoding (TLV, RFC 822 styles)
• Now, XML as the design choice by default
![Page 62: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/62.jpg)
Internet acquires session layer
• Originally, meant for data sessions• Example (not explicit): ftp control connection• Now, separate data delivery from session setup
– address and application configuration– deal with mobility– E.g., RTSP, SIP and H.323
![Page 63: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/63.jpg)
Standards
• Mandatory vs. voluntary– Allowed to use vs. likely to sell– Example: health & safety standards UL listing for electrical appliances, fire codes
• Telecommunications and networking always focus of standardization– 1865: International Telegraph Union (ITU)– 1956: International Telephone and Telegraph Consultative Committee (CCITT)
• Five major organizations:– ITU for lower layers, multimedia collaboration– IEEE for LAN standards (802.x)– IETF for network, transport & some applications– W3C for web-related technology (XML, SOAP)– ISO for media content (MPEG)
![Page 64: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/64.jpg)
Who makes the rules? - ITU
• ITU = ITU-T (telecom standardization) + ITU-R (radio) + development– http://www.itu.int– 14 study groups– produce Recommendations:
• E: overall network operation, telephone service (E.164)• G: transmission system and media, digital systems and
networks (G.711)• H: audiovisual and multimedia systems (H.323)• I: integrated services digital network (I.210); includes ATM• V: data communications over the telephone network (V.24)• X: Data networks and open system communications• Y: Global information infrastructure and internet protocol
aspects
![Page 65: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/65.jpg)
ITU
• Initially, national delegations• Members: state, sector, associate
– Membership fees (> 10,500 SFr)
• Now, mostly industry groups doing work• Initially, mostly (international) telephone services• Now, transition from circuit-switched to packet-
switched universe & lower network layers (optical)• Documents cost SFr, but can get three freebies for
each email address
![Page 66: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/66.jpg)
IETF
• IETF (Internet Engineering Task Force)– see RFC 3233 (“Defining the IETF”)
• Formed 1986, but earlier predecessor organizations (1979-)• RFCs date back to 1969• Initially, largely research organizations and universities, now mostly
R&D labs of equipment vendors and ISPs• International, but 2/3 United States
– meetings every four months– about 300 companies participating in meetings
• but Cisco, Ericsson, Lucent, Nokia, etc. send large delegations
![Page 67: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/67.jpg)
IETF
• Supposed to be engineering, i.e., translation of well-understood technology standards
– make choices, ensure interoperability– reality: often not so well defined
• Most development work gets done in working groups (WGs)– specific task, then dissolved (but may last 10 years…)– typically, small clusters of authors, with large peanut gallery– open mailing list discussion for specific problems– interim meetings (1-2 days) and IETF meetings (few hours)– published as Internet Drafts (I-Ds)
• anybody can publish draft-somebody-my-new-protocol• also official working group documents (draft-ietf-wg-*)• versioned (e.g., draft-ietf-avt-rtp-10.txt)• automatically disappear (expire) after 6 months
![Page 68: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/68.jpg)
IETF process
• WG develops WG last call IETF last call approval (or not) by IESG publication as RFC
• IESG (Internet Engineering Steering Group) consists of area directors – they vote on proposals– areas = applications, general, Internet, operations and
management, routing, security, sub-IP, transport
• Also, Internet Architecture Board (IAB) – provides architectural guidance– approves new working groups– process appeals
![Page 69: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/69.jpg)
IETF activities
• general (3): ipr, nomcom, problem• applications (25): crisp, geopriv, impp, ldapbis, lemonade, opes, provreg, sim
ple, tn3270e, usefor, vpim, webdav, xmpp• internet (18) = IPv4, IPv6, DNS, DHCP: dhc, dnsext, ipoib, itrace, mip4, nemo,
pana, zeroconf• oam (22) = SNMP, RADIUS, DIAMETER: aaa, v6ops, netconf, …• routing (13): forces, ospf, ssm, udlr, …• security (18): idwg, ipsec, openpgp, sasl, smime, syslog, tls, xmldsig, …• subip (5) = “layer 2.5”: ccamp, ipo, mpls, tewg• transport (26): avt (RTP), dccp, enum, ieprep, iptel, megaco, mmusic (RTSP),
nsis, rohc, sip, sipping (SIP), spirits, tsvwg
![Page 70: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/70.jpg)
RFCs
• Originally, “Request for Comment”• now, mostly standards documents that are well settled• published RFCs never change• always ASCII (plain text), sometimes PostScript• anybody can submit RFC, but may be delayed by review (“end run avoi
dance”)• see April 1 RFCs (RFC 1149, 3251, 3252)• accessible at http://www.ietf.org/rfc/ and http://www.rfc-editor.org/
![Page 71: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/71.jpg)
IETF process issues
• Can take several years to publish a standard– see draft-ietf-problem-issue-statement
• Relies on authors and editors to keep moving– often, busy people with “day jobs” spurts three times a year
• Lots of opportunities for small groups to delay things• Original idea of RFC standards-track progression:
– Proposed Standard (PS) = kind of works– Draft Standard (DS) = solid, interoperability tested (2 interoperable implementation
s for each feature), but not necessarily widely used– Standard (S) = well tested, widely deployed
![Page 72: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/72.jpg)
IETF process issues
• Reality: very few protocols progress beyond PS– and some widely-used protocols are only I-Ds
• In addition: Informational, Best Current Practice (BCP), Experimental, Historic
• Early IETF: simple protocols, stand-alone– TCP, HTTP, DNS, BGP, …
• Now: systems of protocols, with security, management, configuration and scaling– lots of dependencies wait for others to do their job
![Page 73: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/73.jpg)
Other Internet standards organizations
• ISOC (Internet Society)– legal umbrella for IETF, development work
• IANA (Internet Assigned Numbers Authority)– assigns protocol constants
• NANOG (North American Network Operators Group) (http://www.nanog.org)– operational issues– holds nice workshop with measurement and “real world” papers
• RIPE, ARIN, APNIC– regional IP address registries dole out chunks of address
space to ISPs– routing table management
![Page 74: IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia](https://reader035.vdocuments.site/reader035/viewer/2022062407/56649e025503460f94aed421/html5/thumbnails/74.jpg)
ICANN
• Internet Corporation for Assigned Names and Numbers– manages IP address space (at top level)– DNS top-level domains (TLD)
• ccTLD (country codes): .us, .uk, .kr, …• gTLDs (generic): .com, .edu, .gov, .int, .mil, .net, and .org• uTLD (unsponsored): .biz, .info, .name, and .pro• sTLD (sponsored): .aero, .coop, and .museum
• actual domains handled by registrars