1. 2/15/2011Harvard Bits1

2. 2/15/2011Harvard Bits2 US Telegraph “Network” in 1856

3. 2/15/2011Harvard Bits3

4. 2/15/2011Harvard Bits4 Size of switch grows as square of number of telephones Impractical to centralize switching as number of telephones grows

5.  Historically a telephone call is completed by setting switches so there is a continuous electric circuit from telephone to telephone  Pros: Dedicated line means uninterrupted service once circuit is completed 2/15/2011Harvard Bits5

6.  Number of calls limited by size and number of switches  Long telephone lines are “seized” by the call even if no one is talking, one party hangs up, etc.  Hard to utilize alternative routes if a switch along the principal path is overloaded 2/15/2011Harvard Bits6

7.  Alternative, used by the Internet  Break message into data packets of 1-2KB  Address the packets to their destination and serial number them so they can be reassembled at the other end  Let network figure out how to deliver them  Different packets of same message may take different routes 2/15/2011Harvard Bits7

8.  Extremely efficient use of network lines - whenever a link is not transporting a packet it is available for completely unrelated messages  Size of switch depends on actual data traffic, not on the number of simultaneous communications that might be happening 2/15/2011Harvard Bits8

9.  No performance guarantees possible, so hard to be sure real-time communications will work  Routing algorithms are not obvious, though if they can be made adaptive, the network could heal itself in case of localized catastrophes  Seems to require more intelligence at the edge of the network, while circuit switching requires intelligence in the core and can tolerate dumb devices at the edge 2/15/2011Harvard Bits9

10. 2/15/2011Harvard Bits10

11. 2/15/2011Harvard Bits11 Client Computers Web Server www.harvard.edu e-mail Server pop.fas.harvard.edu e-mail Server smtp.fas.harvard.edu downloadupload THE INTERNET

12.  Router in network core receives incoming packets and stores them in “buffer” (temporary storage)  Routes packets on outgoing links  May throw packets away if buffer is full 2/15/2011Harvard Bits12 Routing Table

13.  Routers are relatively dumb and rely on intelligence at the edge to compensate 2/15/2011Harvard Bits13 Packetize Add serial #s Add fingerprint Add destination address Insert into network BEST EFFORT Reassemble packets (Maybe) report missing packets (Maybe) report damaged packets Deliver to application Client application: email, web browser, iTunes Server application

14.  IPv4: 32 bits written as 4 decimal numerals less than 256, e.g. 141.211.125.22 (UMich)  4 billion not enough  IPv6: 128 bits written as 8 blocks of 4 hex digits each, e.g. AF43:23BC:CAA1:0045:A5B2:90AC:FFEE:8080  At edge, translate URLs --> IP addresses, e.g. umich.edu --> 141.211.125.22  Authoritative sites for address translation = “Domain Name Server” (DNS)  In the network core, IP addresses are used to route packets using routing tables 2/15/2011Harvard Bits14

15. 2/15/2011Harvard Bits15

16.  We treat IP addresses as Non-Personal Information  We reserve the right to share Non-Personal Information with affiliates and other third parties. 2/15/2011Harvard Bits16

17.  ICANN = Internet Corporation for Assigned Names and Numbers  A US nonprofit … but it’s a long story. 2/15/2011Harvard Bits17

18.  Routers do not know what the bits in the packets represent  Do not know if they are email, streaming video, html web pages  Do not know if they are encrypted or unencrypted  You can invent your own new service adhering to IP standards  Gain Internet’s best-effort service  and possibility of undelivered packets 2/15/2011Harvard Bits18

19.  Packet size (1.5 KB max) a compromise  Small enough that they can be “handled” quickly and with relatively low odds of being damaged  Large enough that packaging does not outweigh the contents or “payload” 2/15/2011Harvard Bits19

20.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits20 1234

21.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits21 1 234

22.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits22 12 34

23.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits23 123 4

24.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits24 1234

25.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits25 1234

26.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits26 1234

27.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits27 1 234

28.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits28 12 34

29.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits29 123 4

30.  Smallish packets also make better use of the network since later packets can leave before earlier packets arrive 2/15/2011Harvard Bits30 1234

31.  Store and Forward delays would add up if entire message had to be buffered at every router 2/15/2011Harvard Bits31 1234

32.  Store and Forward delays would add up if entire message had to be buffered at every router 2/15/2011Harvard Bits32 1234

33.  Store and Forward delays would add up if entire message had to be buffered at every router 2/15/2011Harvard Bits33 1234

34.  Store and Forward delays would add up if entire message had to be buffered at every router 2/15/2011Harvard Bits34 1234

35.  Store and Forward delays would add up if entire message had to be buffered at every router 2/15/2011Harvard Bits35 1234

36.  Store and Forward delays would add up if entire message had to be buffered at every router 2/15/2011Harvard Bits36 1234

37.  Creates logical connection between two machines on the edge of the network  Connected machines seem to have a circuit connecting them even though they do not tie up the network  Provide reliable, perfect transport of messages, even though IP may drop packets  Regulates the rate at which packets are inserted into the network 2/15/2011Harvard Bits37

38. 2/15/2011Harvard Bits38

39. 2/15/2011Harvard Bits39 1 2

40. 2/15/2011Harvard Bits40 1 2 + “3-Way Handshaking”

41. 2/15/2011Harvard Bits41 1 2 + “3-Way Handshaking”

42. 2/15/2011Harvard Bits42 1 2 + “3-Way Handshaking”

43. 2/15/2011Harvard Bits43 1 2 + “3-Way Handshaking”

44. 2/15/2011Harvard Bits44 1 2 + “3-Way Handshaking”

45. 2/15/2011Harvard Bits45 1 2 + “3-Way Handshaking”

46. 2/15/2011Harvard Bits46 1 2 * “3-Way Handshaking”

47. 2/15/2011Harvard Bits47 1 2 * “3-Way Handshaking”

48. 2/15/2011Harvard Bits48 1 2 * “3-Way Handshaking”

49. 2/15/2011Harvard Bits49 1 2 * “3-Way Handshaking”

50. 2/15/2011Harvard Bits50 1 2 * “3-Way Handshaking”

51. 2/15/2011Harvard Bits51 1 2 * “3-Way Handshaking”

52. 2/15/2011Harvard Bits52 1 2 * “3-Way Handshaking”

53. 2/15/2011Harvard Bits53 1 2 * “3-Way Handshaking”

54. 2/15/2011Harvard Bits54 1 2 * “3-Way Handshaking”

55. 2/15/2011Harvard Bits55 1 2 * “3-Way Handshaking”

56. 2/15/2011Harvard Bits56 1 2 * “3-Way Handshaking”

57. 2/15/2011Harvard Bits57 1 2 * “3-Way Handshaking”

58. 2/15/2011Harvard Bits58 1 2 “Virtual Circuit” now established between two hosts though the routers in between are not aware of it and the same path need not be followed by all packets

59. 2/15/2011Harvard Bits59 11 2

60. 2/15/2011Harvard Bits60 11 2

61. 2/15/2011Harvard Bits61 1 212

62. 2/15/2011Harvard Bits62 11 22

63. 2/15/2011Harvard Bits63 1 212

64. 2/15/2011Harvard Bits64 11 22

65. 2/15/2011Harvard Bits65 ACK1 1 2 1 2

66. 2/15/2011Harvard Bits66 ACK1 1 2 1 2

67. 2/15/2011Harvard Bits67 ACK1 1 2 12 ACK2

68. 2/15/2011Harvard Bits68 ACK1 1 1 2 ACK2

69. 2/15/2011Harvard Bits69 ACK1 1 2 1 ACK2 2

70. 2/15/2011Harvard Bits70 1 2 2 ACK2

71. 2/15/2011Harvard Bits71 2 21 ACK2

72. 2/15/2011Harvard Bits72 2 21 ACK2

73. 2/15/2011Harvard Bits73 12

74. 2/15/2011Harvard Bits74 12

75. 2/15/2011Harvard Bits75 11 2

76. 2/15/2011Harvard Bits76 11 2

77. 2/15/2011Harvard Bits77 11 22

78. 2/15/2011Harvard Bits78 1 22

79. 2/15/2011Harvard Bits79 1 22

80. 2/15/2011Harvard Bits80 1 22

81. 2/15/2011Harvard Bits81 1 22

82. 2/15/2011Harvard Bits82 1 22

83. 2/15/2011Harvard Bits83 1 21 2 TIMEOUT

84.  Used for real-time applications (e.g. streaming audio and video) where timing is essential but perfect delivery is not 2/15/2011Harvard Bits84

85. 2/15/2011Harvard Bits85 2 31

86. 2/15/2011Harvard Bits86 321

87. 2/15/2011Harvard Bits87 312

88. 2/15/2011Harvard Bits88 312

89. 2/15/2011Harvard Bits89 31

90. 2/15/2011Harvard Bits90 31

91. 2/15/2011Harvard Bits91 3 1

92. 2/15/2011Harvard Bits92 3 1

93. 2/15/2011Harvard Bits93 31

94.  Both TCP (guaranteed delivery) and UDP (fast delivery, no guarantees) use the lower-level Internet Protocol in the “link layer”  But TCP and UDP know nothing about links, routing, etc. All that knowledge is embedded in IP 2/15/2011Harvard Bits94

95. 2/15/2011Harvard Bits95 Higher Level Protocols Lower Level Protocols