3. Layered Network stack
- Modularity
- Does not specify an implementation
- Instead, tells us how to organize functionality
- Encapsulation
- Interfaces define cross-layer interaction
- Layers only rely on those below them
- Flexibility
- Reuse of code across the network
- Module implementations may change
- Unfortunately, there are tradeoffs
- Interfaces hide information
- As we will see, may hurt performance…
3.1. OSI Model
Layer features
- Service
- What does this layer do?
- Interface(bit, Frame, Packet, Segment)
- How do you access this layer?
- Protocol
- How is this layer implemented?
Layer | Service | Interface | Protocol | Examples |
---|---|---|---|---|
Physical Layer | Move information between two systems connected by a physical link | Specifies how to send one bit | - Encoding scheme for one bit<br/>- Voltage levels <br/>- Timing of signals | coaxial cable, fiber optics, radio frequency transmitters |
Data Link Layer | - Data framing: boundaries between packets<br/>- Media access control (MAC)<br/> -Per-hop reliability and flow-control | Send one packet between two hosts connected to the same media | Physical addressing (e.g. MAC address) | Ethernet, Wifi, DOCSIS |
Network Layer | - Deliver packets across the network<br/>- Handle fragmentation/reassembly<br/>- Packet scheduling<br/> -Buffer management | Send one packet to a specific destination | - Define globally unique addresses<br/>- Maintain routing tables | Internet Protocol (IP), IPv6 |
Transport Layer | - Multiplexing/demultiplexing<br/>- Congestion control<br/>- Reliable, in-order delivery | Send message to a destination | - Port numbers<br/>- Reliability/error correction<br/>- Flow-control information | UDP, TCP |
Session Layer | - Access management<br/>- Synchronization | It depends… | - Token management<br/>- Insert checkpoints | none |
Presentation Layer | - Convert data between different representations<br/>- E.g. big endian to little endian<br/> -E.g. Ascii to Unicode | It depends… | - Define data formats<br/>- Apply transformation rules | none |
Application Layer | Whatever you want :) | Whatever you want :D | Whatever you want ;) | turn on your smartphone and look at the list of apps |
3.2. Network Stack in Practice
Host 1 Host 2
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Application | | Application |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Transport | Switch | Transport |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Network | | Network | | Network |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Data Link | | Data Link | | Data Link |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
3.3. Hourglass Model
- One Internet layer means all networks interoperate
- All applications function on all networks
- Room for development above and below IP
- But, changing IP is insanely hard
3.4. Distribute Functionality
The End-to-End Arguments in System Design
- Saltzer, Reed, and Clark
- The Sacred Text of the Internet
- Endlessly debated by researchers and engineers
3.4.1. basic observations
- Some applications have end-to-end requirements
- Security, reliability, etc.
- Implementing this stuff inside the network is hard
- Every step along the way must be fail-proof
- Different applications have different needs End hosts…
- Can’t depend on the network
- Can satisfy these requirements without network level support
In-network implementation some functions
- Doesn’t reduce host complexity
- Does increase network complexity
- Increased overhead for apps that don’t need functionality
- But, in-network performance may be better
But they choose end hosts or apps to implement these functions.
As a Conservative Interpretation, don’t implement a function at the lower levels of the system unless it can be completely implemented at this level (Peterson and Davie)Basically, unless you can completely remove the burden from end hosts, don’t bother
As a Radical Interpretation,
- Don’t implement anything in the network that can be implemented correctly by the hosts
- Make network layer absolutely minimal
- Ignore performance issues
As a Moderate Interpretation,
- Think twice before implementing functionality in the network
- If hosts can implement functionality correctly, implement it a lower layer only as a performance enhancement
- But do so only if it does not impose burden on applications that do not require that functionality…
- …and if it doesn’t cost too much $ to implement
Layering and E2E principals regularly violated by firewalls, transparent proxies, and NAT devices.
3.5. Takeaways
- Layering for network functions
- Helps manage diversity in computer networks
- Not optimal for everything, but simple and flexible
- Narrow waist ensures interoperability, enables innovation
- E2E argument (attempts) to keep IP layer simple
- Think carefully when adding functionality into the network