1. COT 5611 Operating Systems Design Principles Spring 2014
Dan C. Marinescu
Office: HEC 304
Office hours: M-Wd 3:30 – 5:30 PM

2. Lecture 9 Reading assignment: Chapter 7 from the on-line text
Last time:
Consensus protocols
Modeling concurrency – Petri Nets
11/9/2018
Lecture 9

3. Today Design principles for computer and communication systems
Interesting Properties of Networks
Isochronous and Asynchronous Multiplexing
Packet Forwarding; Delay
Queuing models for delay determination
Buffer Overflow and Discarded Packets
Duplicate Packets and Duplicate Suppression
Damaged Packets and Broken Links
Reordered Delivery
Summary of Interesting Properties and the Best-Effort Contract
11/9/2018
Lecture 9

4. General design principles
Adopt sweeping simplifications: So you can see what you are doing.
Avoid excessive generality: If it is good for everything, it is good for nothing.
Avoid rarely used components: Deterioration and corruption accumulate unnoticed—until the next use.
Be explicit: Get all of the assumptions out on the table.
Decouple modules with indirection: Indirection supports replaceability.
Design for iteration: You won't get it right the first time, so make it easy to change.
End-to-end argument: The application knows best.
Escalating complexity principle: Adding a feature increases complexity out of proportion.
Incommensurate scaling rule: Changing a parameter by a factor of ten requires a new design.
Keep digging principle: Complex systems fail for complex reasons.
11/9/2018
Lecture 9

5. General design principles
Law of diminishing returns: The more one improves some measure of goodness, the more effort the next improvement will require.
Open design principle: Let anyone comment on the design; you need all the help you can get.
Principle of least astonishment: People are part of the system. Choose interfaces that match the user’s experience, expectations, and mental models.
Robustness principle: Be tolerant of inputs, strict on outputs.
Safety margin principle: Keep track of the distance to the edge of the cliff or you may fall over the edge.
Unyielding foundations rule: It is easier to change a module than to change the modularity.
11/9/2018
Lecture 9

6. Area-specific design principles
Atomicity - golden rule of atomicity: Never modify the only copy!
Coordination - one-writer principle: If each variable has only one writer, coordination is simpler.
Durability - the durability mantra: Multiple copies, widely separated and independently administered.
Security - minimize secrets: Because they probably won’t remain secret for long.
Security - complete mediation: Check every operation for authenticity, integrity, and authorization.
Security- fail-safe defaults: Most users won’t change them, so set defaults to do something safe.
Security- least privilege principle: Don’t store lunch in the safe with the jewels.
Security - economy of mechanism: The less there is, the more likely you will get it right.
Security - minimize common mechanism: Shared mechanisms provide unwanted communication paths.
11/9/2018
Lecture 9

7. Design hints Exploit brute force.
Instead of reducing latency, hide it.
Optimize for the common case.
Separate mechanism from policy.
11/9/2018
Lecture 9

8. The design of communication networks
Critical considerations
fundamental physical properties,
the mechanics of sharing, and
a wide range of parameter values
Fundamental physical properties
The speed of light is finite – no way to avoid the propagation delay
Communication media have limited capacity/bandwidth.
Communication environments are hostile – noise, errors, lost information, etc.
Sharing arises for two distinct reasons
Any-to-any connection: the number of paths required grows with the square of the number of communicating entities
Reducing communication costs
11/9/2018
Lecture 9

9. Sharing: links and switches
Channel sharing
Multiplexing
Isochronous multiplexing – scheduled access
TDM
FDM
Asynchronous multiplexing
Random Multiple Access
Other communication system components such as switches are shared
11/9/2018
Lecture 9

10. Data flow on an isochronous channel/link
Isochronous  equally spaced.
Time division multiplexing
Requires the establishment of a connection
The channel has limited capacity  capacity-limiting scheme
11/9/2018
Lecture 9

11. Store and forward network
11/9/2018
Lecture 9

12. Asynchronously multiplexed link
Computer generated traffic is bursty  isochronous communication is not good
On an asynchronous link, a frame can be of any convenient length, and can be carried at any time that the link is not being used for another frame.
11/9/2018
Lecture 9

13. Communication Continuous versus bursty
The old phone network versus data networks
Human versus computer communication
Connection-oriented versus connectionless communication
Packet-forwarding networks
Routing problem
Delays
11/9/2018
Lecture 9

14. 11/9/2018
Lecture 9

15. Packet forwarding (store and forward) networks
11/9/2018
Lecture 9

16. Problems in packet forwarding networks
Delay
Propagation delay
Transmission delay
Processing delay
Queuing delay
Resources are finite and a worst case design is not feasible  heavy tail distributions of resource needs
Buffer overflow and discarded packets
Adaptive rate modulated by information regarding network congestion
Timers and packet retransmission
Duplicate packets
11/9/2018
Lecture 9

17. Delays and waiting time when a resource is shared
Queuing theory describes systems where you have a shared resource – a server - and customers and both the arrival of the customers and the time it takes to service them are random variables with a certain distribution.
There are two stochastic processes involved:
Arrival
Service
11/9/2018
Lecture 9

18. Customer arrival
The arrival process describes the pattern of the customers arrive  characterized by its probability distribution function e.g., a uniform, exponential.
The distribution can described by one or more parameters such as the average value of the random variables subject to that distribution, e.g., the arrival rate denoted as 𝛌¸ or the the inter-arrival time (the average time between two consecutive customer arrivals), 1/ 𝛌.
For example, if customers arrive in average at two minutes intervals the arrival rate is 1/2 customers/minute and the inter-arrival time is 2 minutes.
11/9/2018
Lecture 9

19. Customer service
The service process  describes how customers are served.
The service processes is characterized by its probability distribution function e.g., a uniform, exponential, hyper exponential.
The distribution can described by
the service rate 𝛍 or
the service time (the average time between two consecutive customer departures from the system) 1/ 𝛍
For example, if the service rate is 𝛍 = 10 customers per hour, then the service time is 1/ 𝛍 = 60minutes/10 = 5 minutes.
11/9/2018
Lecture 9

20. The pattern of customer behavior
The customer arrives in the system and joins a waiting queue. The time spent waiting is called waiting time and it is denoted as W.
When its turn arrives the customer enters service and the service time is 1/𝛍
When the service is terminated the customer leaves the system. The time spent the customer is called the time in system T = W + 1/𝛍.
N is the total number of customers in system, one is in service and (N-1) are waiting in the queue.
11/9/2018
Lecture 9

21. Birth and death process
pi the probability to be in state i; ∑pi = 1
Equilibrium equation for a birth-death process
pk 𝛌 = pk+1 𝛍
Utilization ρ = 𝛌/ 𝛍 ≤1
pi = ρi (1- ρ)
E[N] = ∑ i pi= (1- ρ) ∑ i ρi = (1- ρ)[ρ/ (1- ρ)2 ] = ρ/(1- ρ)
Little’s law: E[N]=𝛌E[T ]  E[T]= (1/ 𝛌) [ρ/(1- ρ)]= (1/ 𝛍)[1/(1- ρ)] ]
11/9/2018
Lecture 9

22. Queuing delays versus utilization
11/9/2018
Lecture 9

23. Recovery of lost packets
11/9/2018
Lecture 9

24. Duplicate requests
11/9/2018
Lecture 9

25. Delays and recovery lead to duplicate response
11/9/2018
Lecture 9

26. 11/9/2018
Lecture 9

27. Example of layered design
11/9/2018
Lecture 9

28. Data link layer
11/9/2018
Lecture 9

29. Network layer
11/9/2018
Lecture 9

30. End-to-end (transport) layer
11/9/2018
Lecture 9

31. How many layers should a network model have?
OSI –has 7 layers
Internet is based on a model including
Application
Transport
Network
Data Link
Physical Layer
Applications are very diverse and it makes no sense for a lower layer to implement functions required by higher layers.
The end-to-end argument  application knows best
11/9/2018
Lecture 9