95
2/15/2011 Harvard Bits 1

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

  • View
    217

  • Download
    1

Embed Size (px)

Citation preview

2/15/2011 Harvard Bits 1

2/15/2011 Harvard Bits 2

US Telegraph “Network” in 1856

2/15/2011 Harvard Bits 3

2/15/2011 Harvard Bits 4

• Size of switch grows as square of number of telephones

• Impractical to centralize switching as number of telephones grows

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/2011 Harvard Bits 5

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/2011 Harvard Bits 6

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/2011 Harvard Bits 7

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/2011 Harvard Bits 8

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/2011 Harvard Bits 9

2/15/2011 Harvard Bits 10

2/15/2011 Harvard Bits 11Client Computers

Web Server

www.harvard.edu

e-mail Server

pop.fas.harvard.edu

e-mail Server

smtp.fas.harvard.edu

download uploadTHE INTERNET

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/2011 Harvard Bits 12

Routing Table

Routers are relatively dumb and rely on intelligence at the edge to compensate

2/15/2011 Harvard Bits 13

• 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

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/2011 Harvard Bits 14

2/15/2011 Harvard Bits 15

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/2011 Harvard Bits 16

ICANN = Internet Corporation for Assigned Names and Numbers

A US nonprofit … but it’s a long story.

2/15/2011 Harvard Bits 17

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/2011 Harvard Bits 18

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/2011 Harvard Bits 19

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 20

1 2 3 4

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 21

1

2 3 4

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 22

12

3 4

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 23

123

4

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 24

1234

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 25

1234

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 26

1234

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 27

1

234

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 28

1 2

34

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 29

1 2 3

4

Smallish packets also make better use of the network since later packets can leave before earlier packets arrive

2/15/2011 Harvard Bits 30

1 2 3 4

Store and Forward delays would add up if entire message had to be buffered at every router

2/15/2011 Harvard Bits 31

1 2 3 4

Store and Forward delays would add up if entire message had to be buffered at every router

2/15/2011 Harvard Bits 32

1 2 3 4

Store and Forward delays would add up if entire message had to be buffered at every router

2/15/2011 Harvard Bits 33

1 2 3 4

Store and Forward delays would add up if entire message had to be buffered at every router

2/15/2011 Harvard Bits 34

1 2 3 4

Store and Forward delays would add up if entire message had to be buffered at every router

2/15/2011 Harvard Bits 35

1 2 3 4

Store and Forward delays would add up if entire message had to be buffered at every router

2/15/2011 Harvard Bits 36

1 2 3 4

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/2011 Harvard Bits 37

2/15/2011 Harvard Bits 38

2/15/2011 Harvard Bits 39

1 2

2/15/2011 Harvard Bits 40

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 41

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 42

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 43

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 44

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 45

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 46

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 47

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 48

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 49

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 50

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 51

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 52

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 53

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 54

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 55

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 56

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 57

1 2

“3-Way Handshaking”

2/15/2011 Harvard Bits 58

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

2/15/2011 Harvard Bits 59

11 2

2/15/2011 Harvard Bits 60

11 2

2/15/2011 Harvard Bits 61

1 2 12

2/15/2011 Harvard Bits 62

11 2 2

2/15/2011 Harvard Bits 63

1 2 12

2/15/2011 Harvard Bits 64

11 2 2

2/15/2011 Harvard Bits 65

ACK1

1 2 12

2/15/2011 Harvard Bits 66

ACK1

1 2 12

2/15/2011 Harvard Bits 67

ACK1

1 2 1 2

ACK2

2/15/2011 Harvard Bits 68

ACK1

11 2

ACK2

2/15/2011 Harvard Bits 69

ACK1

1 2 1

ACK2

2

2/15/2011 Harvard Bits 70

12 2

ACK2

2/15/2011 Harvard Bits 71

2 21

ACK2

2/15/2011 Harvard Bits 72

2 21

ACK2

2/15/2011 Harvard Bits 73

1 2

2/15/2011 Harvard Bits 74

1 2

2/15/2011 Harvard Bits 75

11 2

2/15/2011 Harvard Bits 76

11 2

2/15/2011 Harvard Bits 77

11 2 2

2/15/2011 Harvard Bits 78

1 2 2

2/15/2011 Harvard Bits 79

1 2 2

2/15/2011 Harvard Bits 80

1 2 2

2/15/2011 Harvard Bits 81

1 2 2

2/15/2011 Harvard Bits 82

1 2 2

2/15/2011 Harvard Bits 83

1 2 12

TIMEOUT

Used for real-time applications (e.g. streaming audio and video) where timing is essential but perfect delivery is not

2/15/2011 Harvard Bits 84

2/15/2011 Harvard Bits 85

2 3 1

2/15/2011 Harvard Bits 86

3 2 1

2/15/2011 Harvard Bits 87

3 12

2/15/2011 Harvard Bits 88

3 12

2/15/2011 Harvard Bits 89

3 1

2/15/2011 Harvard Bits 90

3 1

2/15/2011 Harvard Bits 91

3 1

2/15/2011 Harvard Bits 92

3 1

2/15/2011 Harvard Bits 93

31

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/2011 Harvard Bits 94

2/15/2011 Harvard Bits 95

Hig

her

Lev

el P

roto

cols

Low

er L

evel

P

roto

cols