Slide 1

Slide 1 text

Design Philosophy in Networked Systems Justine Sherry, Carnegie Mellon University

Slide 2

Slide 2 text

So you’re building a widget. Super Widget 2000 FEATURES!!! API API Other Service Other Service

Slide 3

Slide 3 text

So you’re building a widget. Super Widget 2000 Other Service Other Other Service Other Other Other Service Add-on Extension Platform X Platform z

Slide 4

Slide 4 text

Design Philosophy: Principles for thinking about the outside world and the impact of your widget.

Slide 5

Slide 5 text

This is David Clark. Internet Philosopher

Slide 6

Slide 6 text

Three Papers “The Design Philosophy of the DARPA Internet Protocols”, Clark, D. “END-TO-END ARGUMENTS IN SYSTEM DESIGN”, Salzer, Reed and Clark. “Tussle in Cyberspace: Defining Tomorrow’s Internet”, Clark, Wrokowski, Sollins, and Braden. Recom m ended Reading

Slide 7

Slide 7 text

I met David Clark at a conference once. He told me he liked my talk. I fangirled only a little tiny bit.

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Layered Design: Background

Slide 10

Slide 10 text

Layers… Physical Link Network Transport Application

Slide 11

Slide 11 text

Physical Link Network Transport Application “How do I make bits out of electricity or light or sound or radio?”

Slide 12

Slide 12 text

Physical Link Network Transport Application How do I turn those bits in to messages?

Slide 13

Slide 13 text

Physical Link Network Transport Application How do I deliver the bits across the Internet?

Slide 14

Slide 14 text

Physical Link Network Transport Application How do I make sure none of the bits got lost, or corrupted? And that they show up in order?

Slide 15

Slide 15 text

Physical Link Network Transport Application How do I interpret the bits to do cool stuff?

Slide 16

Slide 16 text

Physical Link Network Transport Application Physical Link Network Transport Application hey zeeshan check out this sweet paper!

Slide 17

Slide 17 text

Physical Link Network Transport Application Physical Link Network Transport Application

Slide 18

Slide 18 text

Physical Link Network Transport Application Physical Link Network Transport Application

Slide 19

Slide 19 text

Physical Link Network Transport Application Physical Link Network Transport Application … 10101010 11110110 10000011 01010111

Slide 20

Slide 20 text

Physical Link Network Transport Application Physical Link Network Transport Application 1 2 3 label all the pieces so none go missing

Slide 21

Slide 21 text

Physical Link Network Transport Application Physical Link Network Transport Application 1 2 3 To: Z To: Z To: Z put an address on my envelopes/packets

Slide 22

Slide 22 text

Physical Link Network Transport Application Physical Link Network Transport Application 1 2 3 To: Z To: Z To: Z and send those packets down to bits

Slide 23

Slide 23 text

0101101110000101 Physical Link Network Transport Application Physical Link Network Transport Application

Slide 24

Slide 24 text

Physical Link Network Transport Application Physical Link Network Transport Application 1 2 3 To: Z To: Z To: Z

Slide 25

Slide 25 text

Physical Link Network Transport Application Physical Link Network Transport Application 1 2 3 To: Z To: Z To: Z Yep that’s me

Slide 26

Slide 26 text

Physical Link Network Transport Application Physical Link Network Transport Application 1 2 3 Did we get all the pieces?

Slide 27

Slide 27 text

Physical Link Network Transport Application Physical Link Network Transport Application … 10101010 11110110 10000011 01010111

Slide 28

Slide 28 text

Physical Link Network Transport Application Physical Link Network Transport Application

Slide 29

Slide 29 text

Physical Link Network Transport Application Physical Link Network Transport Application sweet paper, thx justine

Slide 30

Slide 30 text

Modular, Layered Systems • Components are implemented independently with APIs in between them. • Different layers may have multiple implementations (e.g. WiFi vs Wired Ethernet as your physical layer) • … and even different APIs and capabilities (e.g. TCP provides reliable, in-order delivery but UDP does not provide reliability or ordering. Both are transport protocols!) • To make the end-to-end system work, data passes through multiple layers.

Slide 31

Slide 31 text

Networks aren’t the only systems with layers.

Slide 32

Slide 32 text

Storage system layers…

Slide 33

Slide 33 text

Virtualization Layers

Slide 34

Slide 34 text

Today’s questions!

Slide 35

Slide 35 text

How does what I implement in my layer impact the outside world?

Slide 36

Slide 36 text

“Sure, I think about that when I design APIs!” Physical Link Network Transport Session Presentation Application

Slide 37

Slide 37 text

Physical Link Network Transport Session Presentation Application What about all the other layers?

Slide 38

Slide 38 text

Physical Link Network Transport Session Presentation Application What about the people on top?

Slide 39

Slide 39 text

Without further ado, paper #1:

Slide 40

Slide 40 text

J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984. End- to-end arguments in system design. ACM Trans. Comput. Syst. 2, 4 (November 1984), 277-288.

Slide 41

Slide 41 text

“Careful File Transfer” A B Network Program File System Network Program File System at various points along the way. The application program in this case is the file transfer program, part of which runs at host A and part at host B. In order to discuss the possible threats to the file's integrity in this transaction, let us assume that the following specific steps are involved: 1. At host A the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent. 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 42

Slide 42 text

“Careful File Transfer” A B Network Program File System Network Program File System at various points along the way. The application program in this case is the file transfer program, part of which runs at host A and part at host B. In order to discuss the possible threats to the file's integrity in this transaction, let us assume that the following specific steps are involved: 1. At host A the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent. 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 43

Slide 43 text

“Careful File Transfer” A B Network Program File System Network Program File System at various points along the way. The application program in this case is the file transfer program, part of which runs at host A and part at host B. In order to discuss the possible threats to the file's integrity in this transaction, let us assume that the following specific steps are involved: 1. At host A the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent. 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 44

Slide 44 text

“Careful File Transfer” A B Network Program File System Network Program File System 1. At host A the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent. 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 45

Slide 45 text

“Careful File Transfer” A B Network Program File System Network Program File System 1. At host A the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent. 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 46

Slide 46 text

“Careful File Transfer” A B Network Program File System Network Program File System file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 47

Slide 47 text

“Careful File Transfer” A B Network Program File System Network Program File System 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 48

Slide 48 text

“Careful File Transfer” A B Network Program File System Network Program File System 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 49

Slide 49 text

What if Zeeshan later reads the file and find it is corrupted? What could have gone wrong?

Slide 50

Slide 50 text

3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 51

Slide 51 text

part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 52

Slide 52 text

of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 53

Slide 53 text

a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 54

Slide 54 text

SALTZER ET AL. End-to-End Arguments in System Design 3 5. Either of the hosts may crash part way through the transaction after performing an unknown amount (perhaps all) of the transaction. How would a careful file transfer application then cope with this list of threats? One approach might be to reinforce each of the steps along the way using duplicate copies, timeout and retry, carefully located redundancy for error detection, crash recovery, etc. The goal would be to reduce the probability of each of the individual threats to an acceptably small value. Unfortunately, systematic countering of threat two requires writing correct programs, which task is quite difficult, and not all the programs that must be correct are written by the file transfer application programmer. If we assume further that all these threats are relatively low in probability – low enough that the system allows useful work to be accomplished – brute force countermeasures such as doing everything three times appear uneconomical.

Slide 55

Slide 55 text

How do we re-design our system to make sure the file doesn’t get corrupted?

Slide 56

Slide 56 text

B Network Program File System

Slide 57

Slide 57 text

B Network Program File System

Slide 58

Slide 58 text

B Network Program File System

Slide 59

Slide 59 text

The End-to-End Argument [If] the function in question can completely and correctly be implemented with the knowledge and help of the application standing at the endpoints of the communication system: [Then] providing that questioned function as a feature of the communication system [or lower layer] is not possible. [However], sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.

Slide 60

Slide 60 text

Let’s say we had a perfectly reliable network A B Network Program File System Network Program File System

Slide 61

Slide 61 text

5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. Would that solve our reliability problem? 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. SALTZER ET AL. End-to-End Arguments in System Design 3 5. Either of the hosts may crash part way through the transaction after performing an unknown amount (perhaps all) of the transaction. How would a careful file transfer application then cope with this list of threats? One approach might be to reinforce each of the steps along the way using duplicate copies, timeout and retry, 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 62

Slide 62 text

5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. Would that solve our reliability problem? 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. SALTZER ET AL. End-to-End Arguments in System Design 3 5. Either of the hosts may crash part way through the transaction after performing an unknown amount (perhaps all) of the transaction. How would a careful file transfer application then cope with this list of threats? One approach might be to reinforce each of the steps along the way using duplicate copies, timeout and retry, 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 63

Slide 63 text

Well, that wasn’t very helpful…

Slide 64

Slide 64 text

A B Network Program File System Network Program File System “End to End Check and Retry”

Slide 65

Slide 65 text

“End to End Check and Retry” A B Network Program File System Network Program File System Read file and its checksum from disk. Verify file + checksum. Send File AND Checksum.

Slide 66

Slide 66 text

A B Network Program File System Network Program File System “End to End Check and Retry”

Slide 67

Slide 67 text

A B Network Program File System Network Program File System “End to End Check and Retry”

Slide 68

Slide 68 text

“Careful File Transfer” A B Network Program File System Network Program File System file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 69

Slide 69 text

A B Network Program File System Network Program File System “End to End Check and Retry”

Slide 70

Slide 70 text

A B Network Program File System Network Program File System “End to End Check and Retry” Write file and checksum to disk. Then read back and double-check that checksum + file verify.

Slide 71

Slide 71 text

A B Network Program File System Network Program File System “End to End Check and Retry” If Checksum doesn’t match? Just ask Justine to re-send. (ie, try all over again!)

Slide 72

Slide 72 text

5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. Would that solve our reliability problem? 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once. SALTZER ET AL. End-to-End Arguments in System Design 3 5. Either of the hosts may crash part way through the transaction after performing an unknown amount (perhaps all) of the transaction. How would a careful file transfer application then cope with this list of threats? One approach might be to reinforce each of the steps along the way using duplicate copies, timeout and retry, 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once.

Slide 73

Slide 73 text

Lesson: If you can do it at the “higher” layer, don’t bother implementing it at a lower layer. Don’t waste your time! Avoid causing confusion.

Slide 74

Slide 74 text

Other places to apply E2E in Networks • Encryption • First-in-first-out ordering • Duplicate message surpression • Multi-message transactions

Slide 75

Slide 75 text

The End-to-End Argument [If] the function in question can completely and correctly be implemented with the knowledge and help of the application standing at the endpoints of the communication system: [Then] providing that questioned function as a feature of the communication system [or lower layer] is not possible. [However], sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement. One Exception!

Slide 76

Slide 76 text

A B Network Program File System Program File System What if 90% of my loss really was happening at the network layer? Network As a performance optimization, you might want to implement it in the lower layer anyway (redundantly).

Slide 77

Slide 77 text

A B Network Program File System Network Program File System “End to End Check and Retry” + A Reliable Network

Slide 78

Slide 78 text

Anyone have any other examples where this plays out?

Slide 79

Slide 79 text

Why the heck is this the classic article networking grad students argue about?

Slide 80

Slide 80 text

The “Strong” End-to-End Argument

Slide 81

Slide 81 text

It’s not just a waste of time to put non-essential functionality at lower layers: it’s actually harmful.

Slide 82

Slide 82 text

A B Network Program File System Network Program File System “End to End Check and Retry” + A Reliable Network Slightly less bandwidth More latency

Slide 83

Slide 83 text

Some applications may be constrained by the new functionality.

Slide 84

Slide 84 text

Firewalls and Intrusion Detection Good server Evil Server

Slide 85

Slide 85 text

Firewalls and Intrusion Detection I need to protect my users! Web traffic, email IRC, strange port numbers

Slide 86

Slide 86 text

Firewalls and Intrusion Detection I need to protect my users! Only allow web and email!

Slide 87

Slide 87 text

Firewalls and Intrusion Detection I need to protect my users! But what if I have a cool new app?

Slide 88

Slide 88 text

HTTP for Everything? “Many firewalls and intrusion detection systems only accept HTTP. So, we should build everything using HTTP now.”

Slide 89

Slide 89 text

Cache + TCP Optimization

Slide 90

Slide 90 text

Cache + TCP Optimization

Slide 91

Slide 91 text

Cache + TCP Optimization

Slide 92

Slide 92 text

Cache + TCP Optimization

Slide 93

Slide 93 text

Cache + TCP Optimization What the heck half the packets are missing?!?!?!

Slide 94

Slide 94 text

Can we extend existing protocols? “We tried to extend TCP to support multipath, but devices in the network kept rejecting our connections because they looked weird.”

Slide 95

Slide 95 text

Quick pause (People often have complaints to share about this problem!)

Slide 96

Slide 96 text

End to End Argument: Recap • Basic argument: If you can implement functionality correctly and completely at endpoints, do it there and not at a lower layer. • It saves on redundant work in the system, and avoids confusion later. Exceptions okay for performance optimizations. • Strong argument: Avoid putting unneeded functionality at lower layers of your system altogether because it’s harmful! • Extra functionality at low layers constrains how applications are designed at higher layers.

Slide 97

Slide 97 text

Who decides what optimizations/ constraints are okay to deploy and what constraints aren’t?

Slide 98

Slide 98 text

…bringing us to Paper #2.

Slide 99

Slide 99 text

David D. Clark, John Wroclawski, Karen R. Sollins, and Robert Braden. 2005. Tussle in cyberspace: defining tomorrow's internet. IEEE/ACM Trans. Netw. 13, 3 (June 2005), 462-475.

Slide 100

Slide 100 text

“The Internet is not a single happy family of people dedicated to universal packet carriage.”

Slide 101

Slide 101 text

People want to talk in private. Government wants to wiretap their conversations.

Slide 102

Slide 102 text

Conservative governments put their users behind firewalls. Users install VPNs to tunnel through firewalls.

Slide 103

Slide 103 text

ISPs give users a single IP address and support “just one host”. Users install address translators to support multiple hosts.

Slide 104

Slide 104 text

Tussle: “the ongoing contention among parties with conflicting interests.”

Slide 105

Slide 105 text

“Different parties adapt a mix of mechanisms to achieve their conflicting goals, and others respond by adapting the mechanisms to push back.”

Slide 106

Slide 106 text

A recent example…

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

Actor Model of Tussle Designer User User System Design Constrain Constrain Adapt Workaround Redesign Redesign can both extend or restrict workaround.

Slide 112

Slide 112 text

“There is an open question … to whether the tussle will be driven out of the actor network, the actors will be forced into alignment, or whether this dynamic semi-stable system of today will persist.”

Slide 113

Slide 113 text

How do we design for tussle?

Slide 114

Slide 114 text

Design to stay out of the tussle. Design to influence the tussle.

Slide 115

Slide 115 text

“Design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome.”

Slide 116

Slide 116 text

Two Design Principles to Achieve This • Modularize the design along tussle boundaries, so that one tussle does not spill over and distort unrelated issues. • Design for choice, to permit the different players to express their preferences.

Slide 117

Slide 117 text

Modular Design: Make the tussle battle someone else’s problem

Slide 118

Slide 118 text

Modular Design: Bad Example

Slide 119

Slide 119 text

Problem: DNS represents both “service ID” and “trademark” I’m just trying to design a globally- addressable system and now I’m supposed to be an Intellectual Property expert?

Slide 120

Slide 120 text

Modular Design: Better Example It’s not my job to know what is or isn’t high priority: you tell me.

Slide 121

Slide 121 text

Design for Choice: let the user decide

Slide 122

Slide 122 text

That time the EU made MSFT design for choice.

Slide 123

Slide 123 text

We’re used to thinking about design for choice • TLS supports multiple crypto algorithms, depending on who you trust :-) • We have many different email providers. • We have many different operating systems.

Slide 124

Slide 124 text

What’s the difference between modular design and designing for choice? Modular Design: A global decision that constrains *everyone* must be made. Don’t make your system specific to any particular decision — let local government, enterprise, community decide what is right for them. Design for Choice: Decision is does not need to be the same for everyone. Make sure your system supports lots of choices side by side — every individual user gets to decide for themselves.

Slide 125

Slide 125 text

Places where tussle plays out • Some ISPs ban users from hosting web servers and block port 80. User solution? Run traffic over some other port. • Residential broadband access: will we have choice between providers? • Trust: I want to communicate with you, but you don’t want to communicate with me.

Slide 126

Slide 126 text

Can anyone think of other examples of systems designed for choice, or designed modularly?

Slide 127

Slide 127 text

ing about tussle must view it as a multi-round process, and second, that as mechanism is drawn into an ongoing tussle, it may be used in unexpected ways, and require redesign to survive in this new role. There is no such thing as value-neutral design. What choices designers include or exclude, what interfaces are defined or not, what protocols are open or proprietary, can have a profound influence on the shape of the Internet, the motivations of the players, and the potential for distor- tion of the architecture. Don’t assume that you design the answer. You are designing a playing field, not the outcome. 3. TUSSLE SPACES In this section we discuss some specific aspects of the In- pr sl dr be to to ch pr se ic in ad al sp (D is

Slide 128

Slide 128 text

[Editorial Note] Paper’s bias: Openness, choice, and tussle are good.

Slide 129

Slide 129 text

A lot of pressure to end/restrict choice. • App stores create “walled gardens” of whose apps will be permitted and whose won’t. • Protocol standardization efforts influenced to restrict strong cryptography… preventing privacy. • Firewalls, IDSes, Filters blocking protecting — and censoring, filtering out competition, or downgrading — traffic. • Typically: corporations and governments who want to control what’s going on.

Slide 130

Slide 130 text

Design to stay out of the tussle. Design to influence the tussle. In that everyone (rich, poor, citizen, government) else gets a say in how it plays out.

Slide 131

Slide 131 text

“Evolution and enhancement of existing, mature applications is inevitable.”

Slide 132

Slide 132 text

“Keeping the net open and transparent for new applications is the most important goal.”

Slide 133

Slide 133 text

“The most we can do to protect maturing applications is to bias the tussle.”

Slide 134

Slide 134 text

mic drop. Internet Philosopher

Slide 135

Slide 135 text

Back to you and your widget.

Slide 136

Slide 136 text

Now armed with some design principles • End-to-End design: implement complex functionality at high layers of your system. • Designing for choice: when multiple options about a tussle point are possible, allow users to select what’s best. • Modularity: when a choice has to be made about a tussle point, don’t bake the answer in to your system.

Slide 137

Slide 137 text

Recommended Reading “The Design Philosophy of the DARPA Internet Protocols”, Clark, D. SIGCOMM 1988 “HTTP as the Narrow Waist of the Future Internet.” Lucian Popa, Ali Ghodsi, and Ion Stoica. HotNets 2010. “Is it still possible to extend TCP?” Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark Handley, and Hideyuki Tokuda. Internet Measurement Conference, 2011. “The Evolution The Evolution of Layered Protocol Stacks Leads to an Hourglass-Shaped Architecture.” S. Akhshabi, C. Dovrolis. ACM SIGCOMM 2011.

Slide 138

Slide 138 text

Are you giving your users choice, or adding constraints? Super Widget 2000 FEATURES!!! API API Other Service Other Service Me: @justinesherry / [email protected]