CS 382: Network-Centric Computing

Network Design Principles

Dr. Zafar Ayyub Qazi

Spring 2023

ACK: Slides use some material from Scott Shenker (UC Berkeley)
 My Office Hours
l Tuesdays, 3-4pm

l Students who have shown up so far

l Ahmad Kashif Jabbar
l Ahmed Hassan Ghumman

l All of you must drop by my office at least once during the semester

2
Internet is an extremely complicated system

3
 Internet is an extremely complicated system
car navigator
Routing Reliable data transfer
link
phone company
smartphone
Windows PC switch
university

Congestion
control
cable company Name to address
mappings 4
4
How do we organize the Internet
functionality and architecture?

5
 Recap: Network Modularity Decisions
l How to break system into modules?
l Classic decomposition into tasks

l Where are modules implemented?

l Hosts?
l Routers?
l Both?

l Where is state stored?

l Hosts?
l Routers? 6

l Both?
 Recap: Leads to three design principles
l How to break system into modules?
l Layering

l Where are modules implemented?

l End-to-End Principle

l Where is state stored?

l Fate-Sharing

7
 Recap: Leads to three design principles
l How to break system into modules?
l Layering

l Where are modules implemented?

l End-to-End Principle

l Where is state stored?

l Fate-Sharing

8
Layering
 Tasks in Networking
l What does it take to send packets from source to destination?

l Simplistic decomposition:
l Task 1: send along a single wire

l Task 2: stitch these together to send the packet to the destination

l This gives an idea of what I mean by decomposition

l Next slide presents a much more detailed version

10
 Breakdown into Tasks
l Bits on wire
l Deliver packets across an individual link
l Deliver packets across nodes to the destination
l Potentially across different networks
l Deliver packets reliably, to correct application program
l Do something with the data

11
 Resulting Modules (Layers)
l Bits on wire (Physical)
l Deliver packets across an individual link (Datalink)
l Deliver packets across nodes to the destination (Network)
l Deliver packets reliably, to correct application program (Transport)
l Do something with the data (Application)

12
 Resulting Modules (Layers)
l Bits on wire (Physical)
l Deliver packets across local network (Datalink)
l Local addresses
l Deliver packets across different networks (Network)
l Global addresses
l Deliver packets reliably, to correct application program (Transport)
l Do something with the data (Application)

13
 Five Layers (top-down)
l Application: Providing network support for apps
l Transport (L4): (Reliable) end-to-end delivery
l Network (L3): Global best-effort delivery
l Datalink (L2): Local best-effort delivery
l Physical: Bits on wire

l Interactions between these components?

l Do all components talk to each other?
l Or are the components limited in their interactions?
l Answer: they are strictly layered!
14
 Strictly Layered Dependencies
Applications
…built on…
Reliable (or unreliable) transport
…built on…
Best-effort global packet delivery
…built on…
Best-effort local packet delivery
…built on…
Physical transfer of bits
 Three Observations
l Each layer:
l Depends on layer below
l Supports layer above
l Independent of others

l Multiple versions in layer

l Interfaces differ somewhat
l Components pick which
lower-level protocol to use

l But only one IP layer

l Unifying protocol 16
 Layering Crucial to Internet’s Success
l Innovation at most levels
l Applications (lots)
l Transport (few)
l Datalink (few)
l Physical (lots)

l Innovation proceeded largely in parallel

l Payoff of modularity!

l Pursued by very different communities

l Like systems and chip designs

17
 Three Internet Design Principles
l How to break system into modules?
l Layering

l Where are modules implemented?

l End-to-End Principle

l Where is state stored?

l Fate-Sharing

18
The End-to-End Principle
 Placing Network Functionality
l Influential paper: “End-to-End Arguments in System Design” by
Saltzer, Reed, and Clark (‘84)

l Proposed the End-to-End principle

20
 End-End Principle
l Suggests that “specific application-level functions usually cannot,
and preferably should not, be built into the lower levels of the
system – the core of the network”

l Reasoning
l Some functionality can only be correctly implemented at the end-system
l E.g., even if we implement reliability inside the network, the end-systems will still have to
implement it to ensure end-end reliable data transfer
l The functionality may not be needed by all applications
l E.g., not all applications need reliable data transfer (like voice)
l Improves generalizability
l The complexity of the network can be reduced 21
 Example: Reliable File Transfer
Host A Host B

Appl. Appl.

Step 1 Step 2 Step 3

• Solution 1: make each step reliable, and string them together to

make reliable end-to-end process
• Requires network to also handle reliability
• Solution 2: allow steps to be unreliable, but do end-to-end check
and try again if necessary
22
 Discussion
l Which solution would you prefer? And why?

23
 Reliability inside the network
l Lets examine when you might implement reliability inside the
network

24
25
 Reliability inside the network
l Lets examine when you might implement reliability inside the network

l If packets on individual links fail 10% of the time, and are traversing 10
links, then End-End (E2E) loss rate is 65%
l Probability of successful E2E delivery = (1-0.1)10 = 0.35
l E2E loss rate = 1- (1-0.1)10 = 0.65 or 65%

l Implementing two retransmissions on links

l Link loss rate reduced to (0.1*0.1*0.1) = 0.001
l Local reliability reduces the losses visible to end-systems
l Probability of successful E2E delivery = (1-0.001)10 = 0.99
l E2E loss rate = 1 – (1-0.001)10 = 0.01 or 1%
26
 Summary
l Where to implement functionality is complicated
l No right or wrong answer

l Depends on the design goals

l Generalizability
l Performance optimization
l Complexity

27
Questions?

28