Brief history of the Internet

1. CS144
An Introduc/on to Computer Networks
What the Internet is
4 Layer Model
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
CS144, Stanford University 1

2. The 4 Layer Internet Model
Applica/on
Transport
Network
Link
CS144, Stanford University 2

3. Peer layers communicate
A B
Applica/on Applica/on
Transport Transport
Network Network Network Network
Link Link Link Link
CS144, Stanford University 3

4. Encapsula/on
A
Applica/on
Transport
Network Network
Link Link
CS144, Stanford University 4

5. Peer layers communicate
B
Applica/on
Transport
Network Network
Link Link
CS144, Stanford University 5

6. A few last words…
CS144, Stanford University 6

7. Where do the different layers run?
Applica/on
Transport
Network
Link
CS144, Stanford University 7

8. Why is the Network Layer oPen
called “Layer 3”?
h-p Applica/on
Applica/on
ASCII Presenta/on
Session
Transport TCP
Transport
Network IP Network
Link
Ethernet
Link
Physical
The 4‐layer Internet model The 7‐layer OSI Model
CS144, Stanford University

9. <The End>
CS144, Stanford University 9

10. CS144
An Introduc/on to Computer Networks
What the Internet is
A very brief history of networking
and the Internet
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
CS144, Stanford University 1

11. Outline
Brief history of networking
Brief history of the Internet
CS144, Stanford University 2

12. Fire Beacons Flags
Carrier Pigeons Semaphore telegraphs Telephone
Heliographs: sun’s
Human Messengers Chappe (France)
rays & reflector
Horse Relays … Edelcrantz (Sweden) Internet
Telescopes
1,000 BC 0 1800 AD Today
CS144, Stanford University 3

13. The Telegraph
CS144, Stanford University 4

14. Four steps of inven/on
(2,000 BC) Systems to signal a small set of pre‐defined
messages, e.g. beacons.
(1600s) Systems to transmit arbitrary messages, e.g. by
encoding the alphabet.
(1700s) Numeric codes for common words and phrases.
“Compression”.
(1700s) Codes for control signals. “Protocols”.
CS144, Stanford University 5

15. Protocol Signals by 1800
1. Ini/aliza/on
2. Error control: erase, resend.
3. Rate control: “faster/slower”.
4. Flow control: stop/wait, selec/ve‐repeat.
CS144, Stanford University 6

16. Telephone networks in 1900
1. (1897) Alexander Graeme Bell made the first
telephone call
CS144, Stanford University 7

17. Outline
Brief history of Networking
Brief history of the Internet
CS144, Stanford University 8

18. Parallel beginnings
J.C.R. Licklider describes an Four nodes
Intergalac/c Network connec/ng interconnected
everyone on the globe. (UCLA, SRI, UCSB,
Utah)
RAND (Paul Baran)
Packet switching for
survivable networks.
DARPA (Roberts)
MIT (Kleinrock) First plans for
paper on packet “ARPANET”.
switching theory.
WAN connects two /me‐
NPL, UK (Davies) sharing computers First “IMPs” (BBN).
Packet network.
1960 1965 1966 1968
CS144, Stanford University 9

19. TCP/IP
deployed
NSFNET, etc.
New networks appear:
IBM SNA, ALOHAnet, Cisco and IETF
Cyclades (France). started
“Internehng” and TCP
born (DARPA), led by
Vint Cerf and Bob Kahn. 1st Web browser
200 hosts on 100,000 hosts
ARPAnet on Internet
1970 1980 1990
CS144, Stanford University 10

20. Useful References
1. The Early History of Data Networks
G. J. Holzmann, B. Pehrson, IEEE Press 1994.
2. The Design Philosophy of the
DARPA Internet Protocols.
D. Clark, ACM Sigcomm 1988
3. Brief History of the Internet
B. M. Leiner, V. Cerf, D. D. Clark et al.
hjp://www.internetsociety.org/internet/internet‐51/history‐internet/brief‐history‐internet
CS144, Stanford University 11

21. <The End>
CS144, Stanford University 12

22. Principle: Layering
CS144, Stanford University 1

23. File Transfer
• Data format
• Packetization
• Reliability, error checking
• Congestion and flow control
• Packet delivery and routing
• Link delivery
• Signal modulation and framing
CS144, Stanford University 2

24. Layering
• Decompose communication into a set of smaller, well-defined components
• Components build on top of one another: they layer
• Each layer has a well-defined interface and clear responsibilities
▶ Routing layer does not worry about application
▶ Application layer does not worry about how signals represented
• Each layer can evolve independently
CS144, Stanford University 3

25. Layering
Transport
Network
Link
CS144, Stanford University 4

26. OSI Model
7. Application
6. Presentation
5. Session
4. Transport segments
3. Network packets
2. Link frames
1. Physical bits/bytes
CS144, Stanford University 5

27. Layering Principle
• Decompose communication into layers of abstraction
• Separation of concerns
• Each layer can evolve independently
CS144, Stanford University 6

28. Principle: Encapsulation

29. Layering
Application
Presentation
• Separation of concerns and responsibilities
Session • Allows each service to evolve independently
Transport • Examples:
Network ▶ Transport: inter-application communication
▶ Link: inter-host communication on a shared link
Link
Physical

30. Encapsulation
Application
Presentation • How layering manifests in data representation
• Layer N data is payload to layer N-1
Session
• Example:
Transport ▶ HTTP (web) application payload in
Network ▶ a TCP transport segment in
▶ an IP network packet in
Link ▶ an Ethernet link frame.
Physical
application data
Network
Transport
Link

31. Encapsulation Flexibility
• Encapsulation allows you to layer recursively
• Example: Virtual Private Network (VPN):
▶ HTTP (web) application payload in
▶ a TCP transport segment in
▶ an IP network packet in
▶ a secured TLS presentation message in
▶ a TCP transport segment in
▶ an IP network packet in
▶ an Ethernet link frame.

32. Encapsulation
Layer 7
Layer 6
• How layering manifests in data representation
Layer 5 • Encapsulated payloads
Layer 4 ▶ Help separation of concerns
Layer 3 ▶ Help enforce boundaries/layering
▶ Simplify layer implementations
Layer 2
Layer 1

33. An#Introduc+on#to#Computer#Networks#
Principle:*Packet*Switching*

34. What#is#packet#switching?#
Packet:#A#self=contained#unit#of#data#that#carries#
informa+on#necessary#for#it#to#reach#its#des+na+on.#
CS144,#Stanford#University#

35. Two#consequences#
1. No#per=flow#state#required.#
2. Efficient#sharing#of#links.#
CS144,#Stanford#University#

36. No#per=flow#state#required#
Packet#switches#don’t#need#state#for#each#flow#–#each#
packet#is#self=contained.#
No#per=flow#state#to#be#added/removed.#
No#per=flow#state#to#be#stored.#
No#per=flow#state#to#be#changed#upon#failure.#
CS144,#Stanford#University#

37. Efficient#sharing#of#links#
Data#traffic#is#bursty#
– If#we#reserved#a#frac+on#of#the#links#for#each#flow,#the#
links#would#be#used#inefficiently.#
– Packet#switching#allows#flows#to#use#all#available#link#
capacity.#
This#is#called#Sta$s$cal(Mul$plexing.#
CS144,#Stanford#University#

38. Principle: Names and Addresses
CS144, Stanford University 1

39. Name vs. Address
• Name: specifies what something is
▶ Office: Philip Levis’ office
▶ Host name: market.scs.stanford.edu
▶ Memory: list_ptr
• Address: specifies where something is
▶ Office: 412 Gates Hall, 353 Serra Mall, Stanford, CA 94305-9040 USA
▶ IP: 171.66.3.9
▶ Memory: 0x0040005080
• Telephone numbers: names or addresses?
• This is not a hard classification, just a conceptual model
CS144, Stanford University 2

40. Names
• Structure of names affects what you can reference (easily)
• Flat names
▶ Stock tickers (GOOG, MSFT), airport codes (NRT, YYZ)
▶ Services: http, ftp, https
▶ Skype IDs
• Tuple pairs
▶ Gender: Female; Name: Jennifer Widom; Position: Department Chair
• Hierarchical names
▶ maps.google.com
▶ Nick McKeown, Professor of Electrical Engineering and Computer Science,
Stanford University
CS144, Stanford University 3

41. Addresses
• Structure of addresses affects what you can reference (easily)
• Flat addresses
▶ Memory (0x040004400)
▶ Port numbers (80, 21, 443)
• Tuple pairs
▶ x=32, y=100, z=88
▶ latitude=45.211W, longitude=48.111N
• Hierarchical addresses
▶ Memory segments (0x1000 in segment 0)
▶ 412 Gates Hall, 353 Serra Mall, Stanford, CA, 94131 USA
CS144, Stanford University 4

42. Downloading a File
• How does one refer to the file?
• Address: http://csl.stanford.edu/~pal/pubs.html
▶ Refers to what host the file is on
▶ Refers to where on the host’s file system the file is
• Name: take a hash of pubs.html: 0x27de2b6939d7fb4b0573dbd6dbe2c740
▶ Request the file (using a different protocol than http) with hash
▶ If file changes, hash changes
▶ Says nothing about where the file is
CS144, Stanford University 5

43. Internet Names and Addresses
• Internet addresses: 32-bit IPv4, 128-bit IPv6 addresses
• Internet names: domain name system (DNS), www.stanford.edu
• Many more names and addresses at higher layers
▶ Service names (http) and ports (80)
▶ SIP identifiers (pal@a.com) and email addresses (pal@a.com)
• Internet Corporation for Assigned Names and Numbers (ICANN)
▶ Internet Assigned Numbers Authority (IANA)
CS144, Stanford University 6

44. Two Examples
• http://csl.stanford.edu/~pal vs. http://171.64.73.43/~pal
• A user moving between networks
CS144, Stanford University 7

45. Principle
• Whether you name or address something has deep implications to how
your network and or protocol can be used.
• The structure and design of those names and addresses also have deep
implications.
CS144, Stanford University 8

46. The End-to-End Principle
CS144, Stanford University 1

47. Application View of the World
CS144, Stanford University 2

48. Why Doesn’t the Network Help?
• Compress data?
• Reformat/translate/improve requests?
• Serve cached data?
• Add security?
• Migrate connections across the network?
• Or one of any of a huge number of other things?
CS144, Stanford University 3

49. The End-To-End Principle
The function in question can completely and correctly
be implemented only with the knowledge and help of
the application standing at the end points of the
communication system. Therefore, providing that
questioned function as a feature of the communication
system itself is not possible. (Sometimes an incomplete
version of the function provided by the communication
system may be useful as a performance enhancement.)
We call this line of reasoning. . . “the end-to-end
argument.”
- Saltzer, Reed, and Clark,
End-to-end Arguments in System Design, 1984
CS144, Stanford University 4

50. Example: File Transfer
CS144, Stanford University 5

51. Example: Link Reliability
CS144, Stanford University 6

52. “Strong” End to End
The network’s job is to transmit datagrams as
efficiently and flexibly as possible. Everything
else should be done at the fringes. . .
– [RFC 1958]
CS144, Stanford University 7

53. Net Neutrality
“Allowing broadband carriers to control what people see and do online
would fundamentally undermine the principles that have made the
Internet such a success.”
- Vinton Cerf in testimony before Congress February 7, 2006
"I am totally opposed to mandating that nothing interesting can happen
inside the net."
- Bob Kahn, speaking at the Computer History Museum, January 9, 2007
CS144, Stanford University 8

54. Finite State Machines
Protocol Specification
CS144, Stanford University 1

55. Finite State Machines
State State
1 2
State
3
CS144, Stanford University 2

56. Finite State Machines
event causing state transition
actions taken on state transition
State State
1 2
State
3
CS144, Stanford University 3

57. Finite State Machines
event causing state transition
actions taken on state transition
State State
1 2
event
action
State
3
CS144, Stanford University 4

58. FSM Example: HTTP Request
CS144, Stanford University 5

59. FSM Example: TCP Connection
CS144, Stanford University 6 http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Tcp_state_diagram_fixed.svg/

60. The Internet
(why you should take this course)
CS144, Stanford University 1

61. Societal Change
• Economics: Black Friday, Cyber Monday, E-Fairness legislation
• Dating: okcupid, match.com
• Knowledge: Google books, eBooks, wikipedia
• Communication: IM,VoIP, video telephony
CS144, Stanford University 2

62. Political Change
• Arab spring: SMS, Twitter, U.S. State Department
• Diplomacy: Wikileaks
• Occupy movement: Twitter, Facebook
• By force: Stuxnet worm
CS144, Stanford University 3

63. Economic Change
• #24: Sergey Brin and Larry Page (tied)
• #26: Jeff Bezos
• #35: Mark Zuckerberg
(data from Forbes top billionaires list, April 16 2012)
CS144, Stanford University 4

64. Second Industrial Revolution
Degrees conferred in 2008 and projected job openings/year 2008-2018
http://csl.stanford.edu/~pal/ed
CS144, Stanford University 5

65. Roles in the Revolution
CS144, Stanford University 6

66. This Course
• How computer networks work: principles, design, and implementation
• Use these principles to understand the current Internet
• How to apply these principles to help build the future Internet
• How forces shape the Internet: technological, economic, social, political
CS144, Stanford University 7

67. CS144
An Introduc/on to Computer Networks
Conges'on
AIMD with a single flow
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
1

68. AIMD
Addi/ve Increase, Mul/plica/ve Decrease
1
If packet received OK: W ← W +
W
W
If a packet is dropped: W ←
2
cwnd
Drops
halved
t
CS144, Stanford University 2

69. Animation
Animation at:
http://guido.appenzeller.net/anims/
CS144, Stanford University 3

70. Single Flow Dynamics
4
CS144, Stanford University 4

71. Sending rate for a single flow
Round‐trip /me
Round‐trip /me
Window Size Window Size Window Size
A
B ACK ACK ACK ACK ACK
(1) R x RTT > Window size, W (2) R x RTT = Window size, W
CS144, Stanford University 5

72. Sending rate for single flow
Window size RTT
t
Router buffer
Link rate > C Link rate = C
A B
CS144, Stanford University 6

73. How big should the buffer be?
Buffer size, B = RTT × C Buffer size, B < RTT × C
CS144, Stanford University 7

74. Observa/ons for single flow
1. Window expands/contracts according to AIMD.
2. …to probe how many bytes the pipe can hold.
3. The sawtooth is the stable operating point.
4. The sending rate is constant.
5. …if we have sufficient buffers (RTT x C).
CS144, Stanford University 8

75. <end>
CS144, Stanford University 9

76. CS144
An Introduc/on to Computer Networks
Conges'on
AIMD with mul-ple flows
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
1

77. Router buffer
Link rate > C Link rate = C
A B
CS144, Stanford University 2

78. One flow vs mul/ple flows
One flow W(t)
R= = constant Buffer occupancy
Window size RTT(t)
and RTT
t
Mul'ple flows
Buffer occupancy
Buffer
Occupancy and RTT
t
W(t)
R= ∝W(t)
(Zoom in) RTT One of the flows
cwnd
t
CS144, Stanford University 3

79. Simple geometric intuition
Drops
cwnd
A
1 t
3 2
Packet drop rate, p = 1 / A, where A = Wmax
8
A 3 1 RTT
Throughput, R = =
! Wmax $ 2 RTT p
# & RTT
" 2 %
4

80. Interpre/ng the rate equa/on
3 1
R=
2 RTT p
1. RTT → 0 ⇒ R → ∞ ?
2. p → 0 ⇒ R → ∞ ?
CS144, Stanford University 5

81. Observa/ons for mul/ple flows
1. Window expands/contracts according to AIMD.
2. …to probe how many bytes the pipe can hold.
3. Bottleneck will contain packets from many flows.
4. The sending rate varies with window size.
5. AIMD is very sensitive to loss rate.
6. AIMD penalizes flows with long RTTs.
CS144, Stanford University 6

82. <end>
CS144, Stanford University 7

83. Congestion Control II
RTT Estimation, self-clocking
CS144, Stanford University 1

84. Three Improvements
• Congestion window
• Timeout estimation
• Self-clocking
CS144, Stanford University 2

85. Timeouts
• Round trip time estimation is critical for timeouts
▶ Too short: waste capacity with restransmissions, trigger slow start
▶ Too long: waste capacity with idle time
• Challenge: RTT is highly dynamic
• Challenge: RTT can vary significantly with load
CS144, Stanford University 3

86. Pre-Tahoe Timeouts
• r is RTT estimate, initialize to something reasonable
• m, RTT measurement from most recently acked data packet
• Exponentially weighted moving average: r = αr + (1-α)m
• Timeout = βr, β=2
• What’s the problem?
CS144, Stanford University 4

87. TCP Tahoe Timeouts
• r is RTT estimate, initialize to something reasonable
• g is the EWMA gain (e.g., 0.25)
• m is the RTT measurement from most recently acked data packet
• Error in the estimate e = m-r
• r = r + g⋅e
• Measure variance v = v + g(|e| - v)
• Timeout = r + βv (β=4)
• Exponentially increase timeout in case of tremendous congestion
CS144, Stanford University 5

88. RTT Estimation Improvement
Pre-Tahoe Tahoe
CS144, Stanford University 6

89. Three Improvements
• Congestion window
• Timeout estimation
• Self-clocking
CS144, Stanford University 7

90. Self-Clocking
• In case of a bottleneck link, sender receives acks properly spaced in time
sender receiver
CS144, Stanford University 8

91. Self-Clocking Principle
• Only put data in when data has left
▶ Want to prevent congestion -- too much data in network
• Send new data in response to acknowledgments
• Send acknowledgments aggressively -- important signal
CS144, Stanford University 9

92. TCP Tahoe
• 1987-8:Van Jacobson fixes TCP, publishes seminal TCP paper (Tahoe)
▶ Congestion window, slow start
▶ Timeout considers variance
▶ Self-clocking
• TCP Tahoe solved TCP’s congestion control problem
▶ Spawned a huge area of research in TCP variants
▶ Next lecture will talk about Reno and NewReno
▶ Reading: “Congestion Avoidance and Control,” Van Jacobson and Karels.
CS144, Stanford University 10

93. Congestion Control III
Performance improvements: TCP Reno, TCP NewReno
CS144, Stanford University 1

94. TCP Tahoe
• On timeout or triple duplicate ack (implies lost packet)
▶ Set threshold to congestion window/2
▶ Set congestion window to 1
▶ Enter slow start state
CS144, Stanford University 2

95. TCP Tahoe Review
window
size
time
CS144, Stanford University 3

96. TCP Reno
• Same as Tahoe on timeout
• On triple duplicate ack
▶ Set threshold to congestion window/2
▶ Set congestion window to congestion window/2 (fast recovery)
▶ Retransmit missing segment (fast retransmit)
▶ Stay in congestion avoidance state
CS144, Stanford University 4

97. TCP Reno
window
size
time
CS144, Stanford University 5

98. TCP Reno Example
receiver
sender
Time
CS144, Stanford University 6

99. TCP NewReno
• Same as Tahoe/Reno on timeout
• During fast recovery
▶ Keep track of last unacknowledged packet when entering fast recovery
▶ On every duplicate ack, inflate congestion window by maximum segment size
▶ When last packet acknowledged, return to congestion avoidance state, set cwnd
back to value set when entering fast recovery
▶ Start sending out new packets while fast retransmit is in flight
CS144, Stanford University 7

100. TCP NewReno Behavior
Time
CS144, Stanford University 8

101. Congestion Control
• One of the hardest problems in robust networked systems
• Basic approach: additive increase, multiplicative decrease
• Tricks to keep pipe full, improve throughput
▶ Fast retransmit (don’t wait for timeout to send lost data)
▶ Congestion window inflation (don’t wait an RTT before sending more data)
CS144, Stanford University 9

102. Congestion Control IV
Why AIMD
CS144, Stanford University 1

103. Congestion Control
• Service Provider: maximize link utilization
• User: I get my fair share
• Want network to converge to a state where everyone gets 1/N
• Avoid congestion collapse
CS144, Stanford University 2

104. Congestion Window Size
San Francisco Boston
Optimal congestion window size is the bandwidth-delay product
CS144, Stanford University 3

105. Chiu Jain Plot
Flow B rate (bps)
Flow A rate (bps)
CS144, Stanford University 4

106. Chiu Jain Plot
Fair
A=B
Flow B rate (bps)
Flow A rate (bps)
CS144, Stanford University 5

107. Chiu Jain Plot
Fair
A=B
Flow B rate (bps)
Efficient
A+B=C
Flow A rate (bps)
CS144, Stanford University 6

108. Chiu Jain Plot
Fair
A=B
Flow B rate (bps)
overload
Efficient
underload A+B=C
Flow A rate (bps)
CS144, Stanford University 7

109. Chiu Jain Plot
Fair
A=B
Flow B rate (bps)
overload
Efficient
underload A+B=C
Flow A rate (bps)
CS144, Stanford University 8

110. Chiu Jain Plot
Fair
t2 A=B
t4
Flow B rate (bps)
t1 t6
t3
t5
overload
Efficient
underload A+B=C
Flow A rate (bps)
CS144, Stanford University 9

111. CS144
An Introduc/on to Computer Networks
What the Internet is
4 Layer Model
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
CS144, Stanford University 1

112. The 4 Layer Internet Model
Applica/on
Transport
Network
Link
CS144, Stanford University 2

113. Peer layers communicate
A B
Applica/on Applica/on
Transport Transport
Network Network Network Network
Link Link Link Link
CS144, Stanford University 3

114. Encapsula/on
A
Applica/on
Transport
Network Network
Link Link
CS144, Stanford University 4

115. Peer layers communicate
B
Applica/on
Transport
Network Network
Link Link
CS144, Stanford University 5

116. A few last words…
CS144, Stanford University 6

117. Where do the different layers run?
Applica/on
Transport
Network
Link
CS144, Stanford University 7

118. Why is the Network Layer oPen
called “Layer 3”?
h-p Applica/on
Applica/on
ASCII Presenta/on
Session
Transport TCP
Transport
Network IP Network
Link
Ethernet
Link
Physical
The 4‐layer Internet model The 7‐layer OSI Model
CS144, Stanford University

119. <The End>
CS144, Stanford University 9

120. CS144
An Introduc/on to Computer Networks
What the Internet is
The IP Service
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
CS144, Stanford University 1

121. The Internet Protocol (IP)
Applica/on
Transport
TCP Data Hdr
TCP Segment
Network IP Data Hdr
IP Datagram
Link
CS144, Stanford University 2

122. The IP Service Model
Property Behavior
Datagram Individually routed packets.
Hop‐by‐hop rou/ng.
Unreliable Packets might be dropped.
Best effort …but only if necessary.
Connec4onless No per‐flow state.
Packets might be mis‐sequenced.
CS144, Stanford University 3

123. The IP Service Model (Details)
• Tries to prevent packets looping forever.
• Will fragment packets if they are too long.
• Uses a checksum to reduce chances of delivering
to wrong des/na/on.
• Allows for new versions of IP
– Currently IPv4 with 32 bit addresses
– And IPv6 with 128 bit addresses
• Allows for new op/ons to be added to header.
CS144, Stanford University 4

124. IPv4 Datagram
Bit 0 Bit 31
Header Type of
Version
Length Service Total Packet Length
Packet ID Flags Fragment Offset
Time to Live
“TTL” Protocol ID Checksum
Source IP Address
Des/na/on IP Address
(OPTIONS)
(PAD)
Data
CS144, Stanford University 5

125. The Hourglass Model of IP
h`p smtp ssh …
TCP UDP …
IP
Ethernet WiFi DSL …
CS144, Stanford University 6

126. Summary
We use IP every /me we send and receive
Internet packets.
It provides a deliberately simple service:
– Datagram
– Unreliable
– Best‐effort
– Connec/onless
CS144, Stanford University 7

127. <The End>
CS144, Stanford University 8

128. CS144
An Introduc/on to Computer Networks
Rou$ng
Mul$cast Rou$ng
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
CS144, Stanford University 1

129. Mul/cast
A B C D
R1 R2 R4 R6
R7
R5
R3 R8
E X
2

130. Mul/cast
A B C D
R1 R2 R4 R6
R7
R5
R3 R8
E X
3

131. Mul/cast
Techniques and Principles
- Reverse Path Broadcast (RPB) and Pruning
- One versus mul/ple trees
Prac/ce
- IGMP – group management
- DVMRP – the first mul/cast rou/ng protocol
- PIM – protocol independent mul/cast
CS144, Stanford University 4

132. Flooding
CS144, Stanford University 5

133. Reverse Path Broadcast (RPB)
aka Reverse Path Forwarding (RPF)
A B C D
R1 R2 R4 R6
R7
R5
R3 R8
E X
CS144, Stanford University 6

134. RPB + Pruning
1. Packets delivered loop‐free to every end host.
2. Routers with no interested hosts send prune
messages towards source.
3. Resul/ng tree is the minimum cost spanning tree
from source to the set of interested hosts.
CS144, Stanford University 7

135. One tree versus several trees?
A B C D
R1 R2 R4 R6
R7
R5
R3 R8
E X
8

136. Mul/cast
Techniques and Principles
- Reverse Path Broadcast (RPB) and Pruning
- One versus mul/ple trees
Prac/ce
- Mul/cast addresses
- IGMP – group management
- DVMRP – the first mul/cast rou/ng protocol
- PIM – protocol independent mul/cast
CS144, Stanford University 9

137. Addresses and joining a group
IPv4: Class D addresses are set aside for mul/cast.
IGMP* (Internet group management protocol)
- Between host and directly aaached router.
- Hosts ask to receive packets belonging to a par/cular
mul/cast group.
- Routers periodically poll hosts to ask which groups
they want.
- If no reply, membership /mes out (sod‐state).
*RFC 3376
CS144, Stanford University 10

138. Mul/cast rou/ng in the Internet
DVMRP
- Distance Vector Mul/cast Rou/ng Protocol (RFC 1075)
- First Internet rou/ng protocol
- Uses RPB + Prune
PIM
- Protocol Independent Mul/cast
- Two modes: dense mode, sparse mode
- Dense mode (RFC 3973): Similar to DVMRP
- Sparse mode (RFC 4601): Builds rendezvous points
through which packets join small set of spanning trees.
11

139. Mul/cast in prac/ce
Mul/cast used less than originally expected
- Most communica/on is individualized
(e.g. /me shiding)
- Early implementa/ons were inefficient
- Today, used for some IP TV and fast dissemina/on
- Some applica/on‐layer mul/cast rou/ng used
Some interes/ng ques/ons
- How to make mul/cast reliable?
- How to implement flow‐control?
- How to support different rates for different end users?
- How to secure a mul/cast conversa/on?
12

140. CS144
An Introduc/on to Computer Networks
Rou$ng
Spanning Tree Protocol
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
CS144, Stanford University 1

141. Outline
Ethernet “routes” packets too.
We know how addresses are learned, but how are
loops prevented?
Ethernet switches build a spanning tree over which
packets are forwarded.
2

142. Ethernet Switch
1. Examine the header of each arriving frame.
2. If the Ethernet DA is in the forwarding table, forward the
frame to the correct output port(s).
3. If the Ethernet DA is not in the table, broadcast the
frame to all ports (except the one through which the
frame arrived).
4. Entries in the table are learned by examining the
Ethernet SA of arriving packets.
3

143. Learning could lead to loops
CS144, Stanford University 4

144. Preven/ng loops
Spanning Tree Protocol
The topology of switches is a graph.
The Spanning Tree Protocol finds a a subgraph that
spans all the ver/ces without loops.
- Spanning: all switches are included.
- Tree: no loops.
The distributed protocol decides:
1. Which switch is the Root of the tree, and
2. Which ports are allowed to forward packets along the tree.
5

145. Example Spanning Tree
S9 S8
S3
S5
S7
S2
S1
S6 S4
1: Pick a single root.
2: Only forward packets on ports on the shortest hop‐count to root.
6

146. Resul/ng Spanning Tree
S1
S2 S4 S5 S6 S7
S3 S8 S9
7

147. How it works
1. Periodically, all switches broadcast a “Bridge Protocol Data Unit” (BPDU)
(ID of sender, ID of root, distance from sender to root).
2. Ini/ally, every switch claims to be Root: sets distance field to 0.
3. Every switch broadcasts un/l it hears a be^er message:
- A root with a smaller ID
- A root with equal ID, but with shorter distance
- Ties broken by smaller ID of sender.
4. If a switch hears a be^er message, retransmit message (add 1 to distance).
Root port: The port on a switch that is closest to the Root.
Designated port: The port neighbors agree to use to reach the Root.
All other ports are blocked from forwarding (but s/ll send/receive BPDUs).
Eventually:
- Only the root originates configura/on messages (others retransmit them).
- Locally, switch only forwards on ports.
8

148. A brief history
1985: STP proposed; IEEE standard in 1990.
S/ll very widely used
2004: STP replaced by RSTP which converges faster.
S/ll, RSTP uses the network inefficiently.
2012: A new standard for Ethernet switches was
introduced Shortest‐Path Bridging (SPB, or
802.1aq). It is a link‐state protocol like OSPF.
CS144, Stanford University 9

149. Reading an RFC
CS144, Stanford University 1

150. History (RFC 2555)
• RFC 1: “Host Software”
▶ “Mindful that our group was informal, junior and unchartered, I wanted to
emphasize these notes were the beginning of a dialog and not an assertion of
control.”
• Standardization of format
▶ Structure, intellectual property rights, terminology (RFC 2119)
▶ Security, IANA
• Kinds of RFCs: proposed standard, standards-track, informational,
experimental, best current practice (BCP)
CS144, Stanford University 2

151. RFC Process (simplified)
• Start with a draft: draft-levis-roll-trickle-00
• Revisions: draft-levis-roll-trickle-XX
• Accepted by working group: draft-ietf-roll-trickle-00
• Revisions: draft-ietf-roll-trickle-XX
• Accepted by working group chair for publication
• Working group, IETF last call
• IESG review
• Approved as an RFC
CS144, Stanford University 3

152. Terminology
• MUST, REQUIRED, SHALL: absolute requirement.
• SHOULD, RECOMMENDED: “mean that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before choosing a
different course.”
• MAY, OPTIONAL: “mean that an item is truly optional.”
CS144, Stanford University 4

153. Example: RFC5681
CS144, Stanford University 5

154. CS144
An Introduc/on to Computer Networks
Physical Links
CSMA/CD and Ethernet
Nick McKeown
Professor of Electrical Engineering
and Computer Science, Stanford University
1

155. The Link Layer
A B
Applica/on Applica/on
Transport Transport
Network Network Network Network
Link Link Link Link
2

156. Why is Ethernet oIen
referred to as “Layer 2”?
h0p Applica/on
Applica/on
ASCII Presenta/on
Session
Transport TCP
Transport
Network IP Network
Link
Ethernet
Link
Physical
The 4‐layer Internet model The 7‐layer OSI Model
CS144, Stanford University 3

157. The origins of Ethernet
CS144, Stanford University 4

158. Sharing a “medium”
- Ethernet is an example of mul/ple hosts sharing
a common cable (“medium”).
- To share the medium, we need to decide who
gets to send, and when.
- There is a general class of “Medium Access
Control Protocols”, or MAC Protocols.
- We will take a look at some examples.
CS144, Stanford University 5

159. Random
Examples of MAC Protocols
Packet‐Switched Radio Network
Simple
Aloha
Carrier Sense Mul/ple Access/Collision Detec/on
Ethernet (IEEE 802.3)
DeterminisFc
Complex
Token Passing
Token Ring (IEEE 802.5)
CS144, Stanford University 6

160. Goals of MAC Protocols
Medium Access Control protocols arbitrate access to a
common shared channel among a popula/on of users
1. High u/liza/on of the shared channel
2. Fair among end hosts
3. Simple and low cost to implement
4. Robust to errors; fault tolerant
CS144, Stanford University 7

161. Aloha Network (1968)
Kauai
Molokai
Oahu
Maui
Hawaii
CS144, Stanford University 8

162. Aloha
Frequency 0 Frequency 1
Original Aloha MAC protocol
1. If you have data to send, transmit it.
2. If your transmission “collides” with another, retry later.
CS144, Stanford University 9

163. Aloha Protocol
- Aloha protocol is very simple
- (Quite) robust against failure of a host.
- The protocol is distributed among the hosts.
- Under low‐load, we can expect the delay to be small.
- Under high‐load, a lot of /me “wasted” sending packets that
collide.
Improving performance:
1. Listen for ac/vity (“carrier sense”) before sending a packet.
2. Detect collisions quickly and stop transmigng.
3. AIer collision, pick random wai/ng /me based on the load.
CS144, Stanford University 10

164. CSMA/CD Protocol
All hosts transmit & receive on one channel
Packets are of variable size.
When a host has a packet to transmit:
1. Carrier Sense: Check the line is quiet before transmigng.
2. Collision Detec/on: Detect collision as soon as possible. If a collision is
detected, stop transmigng; wait a random /me, then return to step 1.
binary exponen7al backoff
CS144, Stanford University 11

165. CSMA/CD opera/on
A B C D
CS144, Stanford University 12

166. CSMA/CD Packet size requirement
A B C D
L/c
CS144, Stanford University 13

167. <end>
CS144, Stanford University 14

168. Wireless Networking
CS144, Stanford University 1

169. Access Point Networks
CS144, Stanford University 2