Network Resources — Network Fundamentals | OneNoughtOne

0/240

Computer NetworksNetwork Fundamentals

Network Fundamentals

LevelBeginner

Duration60 mins

TopicNetwork Fundamentals

5 / 5

Network Resources

The Resources Networks Provide

Networks are not merely conduits for moving bits—they are shared resource systems providing bandwidth, connectivity, storage, and computational capabilities to many simultaneous users. Understanding network resources—their nature, how they're shared, and how conflicts are resolved—is fundamental to network design, operation, and application development. When you stream a video while your neighbor downloads files while a business runs video conferences, the same network infrastructure serves all. How does this work? How are resources allocated? What happens when demand exceeds supply?

Learning Objectives

By the end of this page, you will: • Identify the key resources that networks provide • Understand bandwidth, capacity, and throughput distinctions • Explain resource sharing mechanisms and their trade-offs • Analyze Quality of Service (QoS) concepts and implementations • Apply resource concepts to network capacity planning and troubleshooting

Types of Network Resources

Networks provide and manage several distinct types of resources. Each resource type has unique characteristics, constraints, and management challenges.

Network Resource Types
Resource	Description	Measurement	Scarcity Impact
Bandwidth	Data transmission capacity of links	bps (bits per second)	Congestion, delays, dropped packets
Buffer Memory	Temporary storage in network devices	Bytes, packets	Packet loss when buffers overflow
Processing Power	CPU cycles in devices for packet processing	Packets per second, CPU %	Forwarding delays, device overload
Addresses	IP addresses, port numbers, MAC addresses	Count of available	Address exhaustion (IPv4), NAT required
Connectivity	Physical/logical paths between locations	Paths, uptime	Unreachability if paths fail
Time/Slots	Time-division access in shared media	Microseconds, slots	Collision, access delays (WiFi)

Bandwidth: The Primary Resource Bandwidth is typically the most visible and constrained network resource. It's important to distinguish related but different concepts: Bandwidth (Capacity): Theoretical maximum data rate of a link Determined by physical medium, encoding, equipment Example: A Gigabit Ethernet link has 1 Gbps bandwidth Throughput (Actual): Real data rate achieved in practice Always less than bandwidth due to overhead, congestion, errors Example: A 1 Gbps link might achieve 900 Mbps throughput for TCP Goodput (Application): Actual useful data rate at application level Excludes protocol overhead, retransmissions Example: 900 Mbps throughput with 10% overhead = 810 Mbps goodput The distinction matters: A user expects to download at link speed but actually receives goodput—potentially much less than the advertised bandwidth.

Factors Reducing Throughput Below Bandwidth

•Protocol Overhead — Headers consume bandwidth. TCP/IP adds 40+ bytes per packet; for small packets, overhead can be substantial.
•Congestion — Competing traffic reduces available capacity. Shared links rarely provide full bandwidth to one user.
•Latency — TCP throughput is bounded by bandwidth-delay product. High latency limits TCP performance regardless of bandwidth.
•Packet Loss — Lost packets require retransmission, consuming additional bandwidth and reducing effective throughput.
•Flow/Congestion Control — TCP intentionally limits sending rate to prevent overwhelming network.
•Half-Duplex — WiFi can only send OR receive, not both simultaneously, halving effective throughput for bidirectional transfer.

The Bandwidth-Delay Product

The Bandwidth-Delay Product (BDP) is the amount of data 'in flight' on a link: BDP = Bandwidth \times Round-Trip Time Example: 100 Mbps link with 50ms RTT: BDP = 100 Mbps \times 0.050s = 5 Mbits = 625 KB TCP windows must be at least this large to fully utilize the link. This is why high-bandwidth, high-latency links (transcontinental fiber) require special TCP tuning.

Resource Sharing Mechanisms

Networks are fundamentally shared resources . Unlike dedicated point-to-point connections, modern networks allow many users to share the same infrastructure. This sharing dramatically reduces cost but creates resource allocation challenges.

Circuit Switching

•Dedicated path for each communication
•Reserved resources throughout duration
•Guaranteed capacity once connected
•Inefficient when idle—resources wasted
•Example: Traditional telephone networks
•Analogy: Reserved highway lane

Packet Switching

•Shared paths among all users
•No reservation — on-demand allocation
•Statistical multiplexing improves efficiency
•Variable performance based on load
•Example: The Internet
•Analogy: Shared highway with traffic

Statistical Multiplexing: Packet switching exploits statistical multiplexing —the observation that not all users need resources simultaneously: A user browses web pages: Short bursts of traffic, long idle periods 100 users with 10 Mbps peak each might only need 100 Mbps shared (not 1000 Mbps) As user count grows, statistical averaging improves efficiency Example Calculation: Assume each user: Has 10 Mbps access Is actively transmitting 10% of the time Total capacity needed = Number of users \times 10 Mbps \times 0.1 = 1 Mbps average per user With 1000 users: Peak theoretically possible: 10,000 Mbps Average expected: 1,000 Mbps With 2,000 Mbps capacity, excellent service is likely This dramatic efficiency gain makes the shared Internet economically viable. Dedicated 10 Mbps per user would be prohibitively expensive. The Trade-Off: Statistical multiplexing provides efficiency but not guarantees. When many users are simultaneously active, congestion occurs. This is the fundamental nature of shared networks.

Oversubscription

Network providers oversubscribe —they sell more capacity than they physically have, betting on statistical multiplexing. An ISP selling '100 Mbps' to 1000 customers doesn't have 100 Gbps of upstream capacity—they might have 10 Gbps, assuming most users are idle most of the time. This usually works. But during peak hours or unusual events (everyone working from home during a pandemic), oversubscription leads to congestion. Understanding this explains why 'my Internet is slow in the evening.'

Congestion: When Demand Exceeds Supply

Congestion occurs when network demand exceeds available capacity. It's the inevitable consequence of shared resources and is one of the most significant challenges in network design and operation.

Symptoms of Congestion

•Increased Latency — Packets wait in queues, adding delay. A 5ms link becomes 500ms at congestion.
•Packet Loss — When buffers overflow, incoming packets are dropped. TCP retransmits, UDP loses data.
•Reduced Throughput — Even though link is 'full,' actual goodput drops due to retransmissions and overhead.
•Jitter — Variable delays cause inconsistent packet arrival. Disruptive for real-time applications.
•Timeout Failures — Applications expecting quick responses may fail entirely.
•Congestion Collapse — In extreme cases, throughput approaches zero as the network spends all capacity on failed transmissions.

Congestion Control Mechanisms: TCP Congestion Control: TCP actively adjusts sending rate to avoid congestion: Slow Start — Begin slowly, double window each RTT until loss Congestion Avoidance — After reaching threshold, increase linearly Congestion Detection — Packet loss or increased RTT signals congestion Rate Reduction — Halve window on congestion, restart growth Algorithms: TCP Reno — Classic, widely deployed, conservative TCP Cubic — Default on Linux, better for high-BDP networks TCP BBR — Google's algorithm, estimates bandwidth/RTT, more aggressive Network-Based Control: Random Early Detection (RED) — Routers proactively drop packets before buffers fill, signaling senders to slow Explicit Congestion Notification (ECN) — Routers mark packets to signal congestion without dropping Traffic Shaping — Devices enforce rate limits, smoothing bursts

congestion-visualization
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
"""
Simplified TCP Congestion Control Simulation
Demonstrates slow start and congestion avoidance
"""
 
class SimpleTCPCongestionControl:
    def __init__(self):
        self.cwnd = 1  # Congestion window (MSS units)
        self.ssthresh = 64  # Slow start threshold
        self.phase = "slow_start"
        self.history = []
    
    def on_ack_received(self):
        """Called when ACK is received (successful transmission)"""
        if self.phase == "slow_start":
            # Exponential growth: double window
            self.cwnd += 1  # For each ACK, increase by 1 MSS
            if self.cwnd >= self.ssthresh:
                self.phase = "congestion_avoidance"
        else:
            # Linear growth: increase by 1/cwnd per ACK
            # Net effect: +1 MSS per RTT
            self.cwnd += 1 / self.cwnd
        
        self.history.append(('ack', self.cwnd, self.phase))
    
    def on_packet_loss(self):
        """Called when packet loss is detected"""
        # Multiplicative decrease
        self.ssthresh = max(self.cwnd / 2, 2)
        self.cwnd = 1  # Restart slow start (TCP Tahoe style)
        self.phase = "slow_start"
        self.history.append(('loss', self.cwnd, self.phase))
 
# Simulate 20 successful transmissions, then a loss
cc = SimpleTCPCongestionControl()
 
print("Simulation: 20 ACKs, then loss, then 10 more ACKs")
print("-" * 50)
 
for i in range(20):
    cc.on_ack_received()
    print(f"ACK {i+1}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")
 
print("
*** PACKET LOSS DETECTED ***
")
cc.on_packet_loss()
print(f"After loss: cwnd = {cc.cwnd:.2f}, ssthresh = {cc.ssthresh:.2f}")
print()
 
for i in range(10):
    cc.on_ack_received()
    print(f"ACK {i+21}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")

Fairness in Congestion Control

TCP congestion control is designed to be fair —multiple flows sharing a bottleneck should each get approximately equal share. However, 'fair' is nuanced: • UDP doesn't respond to congestion—it can starve TCP flows • Some TCP variants are more aggressive than others • Short flows never exit slow start, getting less than long flows • Flows with different RTTs get different shares (RTT-unfairness) Despite imperfections, TCP's congestion control has kept the Internet stable for decades.

Quality of Service (QoS)

Quality of Service (QoS) refers to mechanisms that provide differentiated treatment to different types of traffic. Instead of treating all packets equally (best-effort), QoS enables prioritization based on application needs.

QoS Parameters

•Bandwidth — Guaranteed or maximum data rate for a traffic class
•Latency — Maximum acceptable delay from source to destination
•Jitter — Maximum variation in latency between packets
•Packet Loss — Maximum acceptable percentage of dropped packets
•Availability — Percentage of time service is operational

QoS Requirements by Application Type
Application	Bandwidth	Latency	Jitter	Loss Tolerance
VoIP	Low (100 Kbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Conference	Medium (2-10 Mbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Streaming	High (5-25 Mbps)	Moderate (buffering)	Moderate	Very Low
Online Gaming	Low-Medium	Critical (<50ms)	Critical	Medium
Web Browsing	Variable	Noticeable (but tolerate)	Not critical	Must retry
File Transfer	As available	Not critical	Not critical	Zero (TCP ensures)
Email	Low	Minutes acceptable	Not applicable	Zero (TCP)

QoS Mechanisms: Traffic Classification: Identify traffic type by port, protocol, source, deep packet inspection Mark packets with priority (DSCP field in IP header, 802.1p in Ethernet) Classes: EF (Expedited Forwarding), AF (Assured Forwarding), BE (Best Effort) Traffic Shaping: Enforce rate limits per class Smooth bursts to prevent congestion Token bucket: Allow bursts up to bucket size, then rate-limit Queuing Disciplines: FIFO — First-in-first-out, no differentiation Priority Queuing — High-priority always before low (starvation risk) Weighted Fair Queuing (WFQ) — Proportional bandwidth allocation Class-Based WFQ — WFQ with defined classes and weights Admission Control: Reject new flows if accepting would degrade existing service quality Common in VoIP systems: limit concurrent calls based on bandwidth

QoS End-to-End Challenge

QoS only works when enforced everywhere along the path . Your enterprise can prioritize VoIP, but once traffic leaves your network to the ISP, those markings may be ignored or re-marked. The public Internet is largely best-effort—which is why real-time applications use adaptive techniques (buffering, quality switching) rather than relying on QoS guarantees.

Address Space as a Resource

IP addresses are a finite resource—perhaps the most constrained in modern networking. The IPv4 address space exhaustion and the transition to IPv6 represent one of the largest infrastructure changes in Internet history.

IPv4 vs IPv6 Address Space
Characteristic	IPv4	IPv6
Address Size	32 bits	128 bits
Total Addresses	~4.3 billion	~340 undecillion (3.4×10³⁸)
Format	Dotted decimal (192.168.1.1)	Hexadecimal (2001:db8::1)
Status	Exhausted globally	Vast availability
Private Addresses	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16	fc00::/7 (ULA)
Broadcast	Supported	Replaced by multicast

The IPv4 Exhaustion Crisis: The Internet's architects in the 1970s allocated 32-bit addresses, believing 4.3 billion addresses would be plenty. They were wrong: Timeline: 1981: IPv4 formalized 1990s: Rapid Internet growth consumes addresses 2011: IANA exhausts its pool 2015-2019: Regional registries exhaust pools Today: IPv4 addresses are traded; some worth $50+ each Mitigation Strategies: Network Address Translation (NAT): Multiple devices share one public IP Private-to-public address mapping Extends IPv4 lifetime significantly Drawbacks: Breaks end-to-end principle, complicates protocols Classless Inter-Domain Routing (CIDR): Variable-length subnet masks More efficient address allocation Replaced wasteful classful addressing IPv6 Deployment: Long-term solution Adoption growing but slow (>40% of Google traffic now IPv6) Dual-stack deployment common during transition

Why IPv6 Adoption is Slow

Despite being standardized in 1998, IPv6 adoption took decades because: • IPv6 is not backward compatible—requires parallel infrastructure • NAT 'solved' the immediate problem, reducing urgency • Costs of dual-stack outweigh benefits for many organizations • No compelling features for users—speed/security arguments weak Adoption accelerated when mobile operators (needing massive address space) and large content providers (Google, Facebook) deployed IPv6, creating critical mass.

Network Services as Resources

Beyond raw connectivity, networks provide services that are themselves shared resources. These services have capacity limits and require management.

Network Services as Resources

•DNS Resolution Capacity — DNS servers have query limits. Under DDoS attack, DNS can become the bottleneck preventing all name resolution.
•DHCP Address Pools — Limited pool of dynamic addresses. Exhausted pools prevent new device connections.
•NAT Translation Tables — Each NAT device has finite memory for translation entries. High connection counts can exhaust tables.
•Firewall State Tables — Stateful firewalls track connections. Connection flooding attacks exhaust state, blocking legitimate traffic.
•VPN Tunnel Capacity — VPN concentrators have concurrent tunnel limits. Exceeded during mass remote-work events.
•Load Balancer Capacity — Connection handling, SSL termination have limits. Over-capacity means failed requests.

Service Resource Planning: Network service capacity planning requires understanding: Baseline Load: What's normal traffic? Peak times? How many concurrent users/connections? Growth Projections: How is usage increasing? Planned new applications? Headroom: How much spare capacity for unexpected spikes? Typical target: 70% utilization at peak Failure Modes: What happens when capacity is exceeded? Graceful degradation vs. total failure? Scaling Strategy: Vertical (bigger device) vs. horizontal (more devices) Lead time for procurement/deployment

The Cloud Scaling Illusion

Cloud services create an illusion of infinite resources—'just spin up more instances.' In reality: • Cloud regions have physical capacity limits • Quotas limit individual account usage • Scaling takes time (seconds to minutes) • Costs grow with usage (potentially dramatically) Even in the cloud, capacity planning remains essential. The model changes from 'buy equipment' to 'manage costs and quotas.'

Monitoring and Managing Resources

Effective resource management requires visibility. Network monitoring provides data for capacity planning, troubleshooting, and optimization.

Network Monitoring Approaches
Method	What It Measures	Tools	Use Case
SNMP Polling	Device counters (bytes, errors, CPU)	Cacti, Nagios, PRTG	Capacity trends, health dashboards
Flow Analysis	Traffic patterns (source, dest, protocol)	NetFlow, sFlow, ntopng	Who's using bandwidth? What protocols?
Packet Capture	Full packet contents	Wireshark, tcpdump	Deep troubleshooting, forensics
Synthetic Probing	Simulated transactions	Smokeping, ThousandEyes	Application experience, SLA verification
Log Analysis	Event records from devices	ELK stack, Splunk	Security, troubleshooting, audit
APM	Application-level metrics	New Relic, Datadog, Dynatrace	End-user experience, service dependencies

Key Metrics to Monitor: Bandwidth/Utilization: Interface traffic in/out (bps) Utilization percentage Trend over time Latency: Round-trip time to key destinations Jitter (latency variation) Path latency decomposition Errors: Interface errors (CRC, collisions, drops) Protocol errors (TCP retransmissions) Device errors (CPU overload, memory usage) Availability: Service uptime percentage Mean time between failures (MTBF) Mean time to recovery (MTTR) Session Counts: Active connections Connection rate (new connections/second) NAT table utilization

bandwidth-monitor
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
"""
Simple bandwidth utilization calculation from SNMP counters
Demonstrates fundamental network monitoring concepts
"""
 
from datetime import datetime
from dataclasses import dataclass
 
@dataclass
class InterfaceCounters:
    """SNMP counter values at a point in time"""
    timestamp: datetime
    if_in_octets: int  # Bytes received
    if_out_octets: int  # Bytes transmitted
    interface_speed: int  # Interface speed in bps
 
def calculate_utilization(prev: InterfaceCounters, 
                          curr: InterfaceCounters) -> dict:
    """
    Calculate bandwidth utilization between two measurement points
    """
    time_delta = (curr.timestamp - prev.timestamp).total_seconds()
    
    if time_delta <= 0:
        raise ValueError("Time delta must be positive")
    
    # Calculate bits transferred (counter difference × 8)
    in_bits = (curr.if_in_octets - prev.if_in_octets) * 8
    out_bits = (curr.if_out_octets - prev.if_out_octets) * 8
    
    # Calculate rates (bits per second)
    in_bps = in_bits / time_delta
    out_bps = out_bits / time_delta
    
    # Calculate utilization percentage
    in_util = (in_bps / curr.interface_speed) * 100
    out_util = (out_bps / curr.interface_speed) * 100
    
    return {
        'interval_seconds': time_delta,
        'in_bps': in_bps,
        'out_bps': out_bps,
        'in_mbps': in_bps / 1_000_000,
        'out_mbps': out_bps / 1_000_000,
        'in_utilization_pct': in_util,
        'out_utilization_pct': out_util
    }
 
# Example: 1 Gbps interface, 5-minute polling interval
interface_speed = 1_000_000_000  # 1 Gbps
 
sample_1 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 0, 0),
    if_in_octets=1_000_000_000,
    if_out_octets=500_000_000,
    interface_speed=interface_speed
)
 
sample_2 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 5, 0),  # 5 minutes later
    if_in_octets=1_450_000_000,  # 450 MB received
    if_out_octets=650_000_000,   # 150 MB sent
    interface_speed=interface_speed
)
 
result = calculate_utilization(sample_1, sample_2)
 
print("Interface Utilization Report")
print("=" * 40)
print(f"Interval: {result['interval_seconds']:.0f} seconds")
print(f"Inbound:  {result['in_mbps']:.2f} Mbps ({result['in_utilization_pct']:.1f}%)")
print(f"Outbound: {result['out_mbps']:.2f} Mbps ({result['out_utilization_pct']:.1f}%)")

Alerting Strategy

Don't just monitor—alert on actionable conditions: • Utilization >80% — Warning; may hit capacity • Utilization >90% — Critical; likely causing issues • Sudden drops — Possible failure • Error rates increasing — Hardware or cable issues • Latency increases — Congestion or path changes Avoid alert fatigue: Too many false positives cause real alerts to be ignored.

Computer NetworksNetwork Fundamentals

Network Fundamentals

LevelBeginner

Duration60 mins

TopicNetwork Fundamentals

5 / 5

Network Resources

The Resources Networks Provide

Networks are not merely conduits for moving bits—they are shared resource systems providing bandwidth, connectivity, storage, and computational capabilities to many simultaneous users. Understanding network resources—their nature, how they're shared, and how conflicts are resolved—is fundamental to network design, operation, and application development. When you stream a video while your neighbor downloads files while a business runs video conferences, the same network infrastructure serves all. How does this work? How are resources allocated? What happens when demand exceeds supply?

Learning Objectives

By the end of this page, you will: • Identify the key resources that networks provide • Understand bandwidth, capacity, and throughput distinctions • Explain resource sharing mechanisms and their trade-offs • Analyze Quality of Service (QoS) concepts and implementations • Apply resource concepts to network capacity planning and troubleshooting

Types of Network Resources

Networks provide and manage several distinct types of resources. Each resource type has unique characteristics, constraints, and management challenges.

Network Resource Types
Resource	Description	Measurement	Scarcity Impact
Bandwidth	Data transmission capacity of links	bps (bits per second)	Congestion, delays, dropped packets
Buffer Memory	Temporary storage in network devices	Bytes, packets	Packet loss when buffers overflow
Processing Power	CPU cycles in devices for packet processing	Packets per second, CPU %	Forwarding delays, device overload
Addresses	IP addresses, port numbers, MAC addresses	Count of available	Address exhaustion (IPv4), NAT required
Connectivity	Physical/logical paths between locations	Paths, uptime	Unreachability if paths fail
Time/Slots	Time-division access in shared media	Microseconds, slots	Collision, access delays (WiFi)

Bandwidth: The Primary Resource Bandwidth is typically the most visible and constrained network resource. It's important to distinguish related but different concepts: Bandwidth (Capacity): Theoretical maximum data rate of a link Determined by physical medium, encoding, equipment Example: A Gigabit Ethernet link has 1 Gbps bandwidth Throughput (Actual): Real data rate achieved in practice Always less than bandwidth due to overhead, congestion, errors Example: A 1 Gbps link might achieve 900 Mbps throughput for TCP Goodput (Application): Actual useful data rate at application level Excludes protocol overhead, retransmissions Example: 900 Mbps throughput with 10% overhead = 810 Mbps goodput The distinction matters: A user expects to download at link speed but actually receives goodput—potentially much less than the advertised bandwidth.

Factors Reducing Throughput Below Bandwidth

•Protocol Overhead — Headers consume bandwidth. TCP/IP adds 40+ bytes per packet; for small packets, overhead can be substantial.
•Congestion — Competing traffic reduces available capacity. Shared links rarely provide full bandwidth to one user.
•Latency — TCP throughput is bounded by bandwidth-delay product. High latency limits TCP performance regardless of bandwidth.
•Packet Loss — Lost packets require retransmission, consuming additional bandwidth and reducing effective throughput.
•Flow/Congestion Control — TCP intentionally limits sending rate to prevent overwhelming network.
•Half-Duplex — WiFi can only send OR receive, not both simultaneously, halving effective throughput for bidirectional transfer.

The Bandwidth-Delay Product

The Bandwidth-Delay Product (BDP) is the amount of data 'in flight' on a link: BDP = Bandwidth \times Round-Trip Time Example: 100 Mbps link with 50ms RTT: BDP = 100 Mbps \times 0.050s = 5 Mbits = 625 KB TCP windows must be at least this large to fully utilize the link. This is why high-bandwidth, high-latency links (transcontinental fiber) require special TCP tuning.

Resource Sharing Mechanisms

Networks are fundamentally shared resources . Unlike dedicated point-to-point connections, modern networks allow many users to share the same infrastructure. This sharing dramatically reduces cost but creates resource allocation challenges.

Circuit Switching

•Dedicated path for each communication
•Reserved resources throughout duration
•Guaranteed capacity once connected
•Inefficient when idle—resources wasted
•Example: Traditional telephone networks
•Analogy: Reserved highway lane

Packet Switching

•Shared paths among all users
•No reservation — on-demand allocation
•Statistical multiplexing improves efficiency
•Variable performance based on load
•Example: The Internet
•Analogy: Shared highway with traffic

Statistical Multiplexing: Packet switching exploits statistical multiplexing —the observation that not all users need resources simultaneously: A user browses web pages: Short bursts of traffic, long idle periods 100 users with 10 Mbps peak each might only need 100 Mbps shared (not 1000 Mbps) As user count grows, statistical averaging improves efficiency Example Calculation: Assume each user: Has 10 Mbps access Is actively transmitting 10% of the time Total capacity needed = Number of users \times 10 Mbps \times 0.1 = 1 Mbps average per user With 1000 users: Peak theoretically possible: 10,000 Mbps Average expected: 1,000 Mbps With 2,000 Mbps capacity, excellent service is likely This dramatic efficiency gain makes the shared Internet economically viable. Dedicated 10 Mbps per user would be prohibitively expensive. The Trade-Off: Statistical multiplexing provides efficiency but not guarantees. When many users are simultaneously active, congestion occurs. This is the fundamental nature of shared networks.

Oversubscription

Network providers oversubscribe —they sell more capacity than they physically have, betting on statistical multiplexing. An ISP selling '100 Mbps' to 1000 customers doesn't have 100 Gbps of upstream capacity—they might have 10 Gbps, assuming most users are idle most of the time. This usually works. But during peak hours or unusual events (everyone working from home during a pandemic), oversubscription leads to congestion. Understanding this explains why 'my Internet is slow in the evening.'

Congestion: When Demand Exceeds Supply

Congestion occurs when network demand exceeds available capacity. It's the inevitable consequence of shared resources and is one of the most significant challenges in network design and operation.

Symptoms of Congestion

•Increased Latency — Packets wait in queues, adding delay. A 5ms link becomes 500ms at congestion.
•Packet Loss — When buffers overflow, incoming packets are dropped. TCP retransmits, UDP loses data.
•Reduced Throughput — Even though link is 'full,' actual goodput drops due to retransmissions and overhead.
•Jitter — Variable delays cause inconsistent packet arrival. Disruptive for real-time applications.
•Timeout Failures — Applications expecting quick responses may fail entirely.
•Congestion Collapse — In extreme cases, throughput approaches zero as the network spends all capacity on failed transmissions.

Congestion Control Mechanisms: TCP Congestion Control: TCP actively adjusts sending rate to avoid congestion: Slow Start — Begin slowly, double window each RTT until loss Congestion Avoidance — After reaching threshold, increase linearly Congestion Detection — Packet loss or increased RTT signals congestion Rate Reduction — Halve window on congestion, restart growth Algorithms: TCP Reno — Classic, widely deployed, conservative TCP Cubic — Default on Linux, better for high-BDP networks TCP BBR — Google's algorithm, estimates bandwidth/RTT, more aggressive Network-Based Control: Random Early Detection (RED) — Routers proactively drop packets before buffers fill, signaling senders to slow Explicit Congestion Notification (ECN) — Routers mark packets to signal congestion without dropping Traffic Shaping — Devices enforce rate limits, smoothing bursts

congestion-visualization
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
"""
Simplified TCP Congestion Control Simulation
Demonstrates slow start and congestion avoidance
"""
 
class SimpleTCPCongestionControl:
    def __init__(self):
        self.cwnd = 1  # Congestion window (MSS units)
        self.ssthresh = 64  # Slow start threshold
        self.phase = "slow_start"
        self.history = []
    
    def on_ack_received(self):
        """Called when ACK is received (successful transmission)"""
        if self.phase == "slow_start":
            # Exponential growth: double window
            self.cwnd += 1  # For each ACK, increase by 1 MSS
            if self.cwnd >= self.ssthresh:
                self.phase = "congestion_avoidance"
        else:
            # Linear growth: increase by 1/cwnd per ACK
            # Net effect: +1 MSS per RTT
            self.cwnd += 1 / self.cwnd
        
        self.history.append(('ack', self.cwnd, self.phase))
    
    def on_packet_loss(self):
        """Called when packet loss is detected"""
        # Multiplicative decrease
        self.ssthresh = max(self.cwnd / 2, 2)
        self.cwnd = 1  # Restart slow start (TCP Tahoe style)
        self.phase = "slow_start"
        self.history.append(('loss', self.cwnd, self.phase))
 
# Simulate 20 successful transmissions, then a loss
cc = SimpleTCPCongestionControl()
 
print("Simulation: 20 ACKs, then loss, then 10 more ACKs")
print("-" * 50)
 
for i in range(20):
    cc.on_ack_received()
    print(f"ACK {i+1}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")
 
print("
*** PACKET LOSS DETECTED ***
")
cc.on_packet_loss()
print(f"After loss: cwnd = {cc.cwnd:.2f}, ssthresh = {cc.ssthresh:.2f}")
print()
 
for i in range(10):
    cc.on_ack_received()
    print(f"ACK {i+21}: cwnd = {cc.cwnd:.2f}, phase = {cc.phase}")

Fairness in Congestion Control

TCP congestion control is designed to be fair —multiple flows sharing a bottleneck should each get approximately equal share. However, 'fair' is nuanced: • UDP doesn't respond to congestion—it can starve TCP flows • Some TCP variants are more aggressive than others • Short flows never exit slow start, getting less than long flows • Flows with different RTTs get different shares (RTT-unfairness) Despite imperfections, TCP's congestion control has kept the Internet stable for decades.

Quality of Service (QoS)

Quality of Service (QoS) refers to mechanisms that provide differentiated treatment to different types of traffic. Instead of treating all packets equally (best-effort), QoS enables prioritization based on application needs.

QoS Parameters

•Bandwidth — Guaranteed or maximum data rate for a traffic class
•Latency — Maximum acceptable delay from source to destination
•Jitter — Maximum variation in latency between packets
•Packet Loss — Maximum acceptable percentage of dropped packets
•Availability — Percentage of time service is operational

QoS Requirements by Application Type
Application	Bandwidth	Latency	Jitter	Loss Tolerance
VoIP	Low (100 Kbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Conference	Medium (2-10 Mbps)	Critical (<150ms)	Critical (<30ms)	Low (<1%)
Video Streaming	High (5-25 Mbps)	Moderate (buffering)	Moderate	Very Low
Online Gaming	Low-Medium	Critical (<50ms)	Critical	Medium
Web Browsing	Variable	Noticeable (but tolerate)	Not critical	Must retry
File Transfer	As available	Not critical	Not critical	Zero (TCP ensures)
Email	Low	Minutes acceptable	Not applicable	Zero (TCP)

QoS Mechanisms: Traffic Classification: Identify traffic type by port, protocol, source, deep packet inspection Mark packets with priority (DSCP field in IP header, 802.1p in Ethernet) Classes: EF (Expedited Forwarding), AF (Assured Forwarding), BE (Best Effort) Traffic Shaping: Enforce rate limits per class Smooth bursts to prevent congestion Token bucket: Allow bursts up to bucket size, then rate-limit Queuing Disciplines: FIFO — First-in-first-out, no differentiation Priority Queuing — High-priority always before low (starvation risk) Weighted Fair Queuing (WFQ) — Proportional bandwidth allocation Class-Based WFQ — WFQ with defined classes and weights Admission Control: Reject new flows if accepting would degrade existing service quality Common in VoIP systems: limit concurrent calls based on bandwidth

QoS End-to-End Challenge

QoS only works when enforced everywhere along the path . Your enterprise can prioritize VoIP, but once traffic leaves your network to the ISP, those markings may be ignored or re-marked. The public Internet is largely best-effort—which is why real-time applications use adaptive techniques (buffering, quality switching) rather than relying on QoS guarantees.

Address Space as a Resource

IP addresses are a finite resource—perhaps the most constrained in modern networking. The IPv4 address space exhaustion and the transition to IPv6 represent one of the largest infrastructure changes in Internet history.

IPv4 vs IPv6 Address Space
Characteristic	IPv4	IPv6
Address Size	32 bits	128 bits
Total Addresses	~4.3 billion	~340 undecillion (3.4×10³⁸)
Format	Dotted decimal (192.168.1.1)	Hexadecimal (2001:db8::1)
Status	Exhausted globally	Vast availability
Private Addresses	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16	fc00::/7 (ULA)
Broadcast	Supported	Replaced by multicast

The IPv4 Exhaustion Crisis: The Internet's architects in the 1970s allocated 32-bit addresses, believing 4.3 billion addresses would be plenty. They were wrong: Timeline: 1981: IPv4 formalized 1990s: Rapid Internet growth consumes addresses 2011: IANA exhausts its pool 2015-2019: Regional registries exhaust pools Today: IPv4 addresses are traded; some worth $50+ each Mitigation Strategies: Network Address Translation (NAT): Multiple devices share one public IP Private-to-public address mapping Extends IPv4 lifetime significantly Drawbacks: Breaks end-to-end principle, complicates protocols Classless Inter-Domain Routing (CIDR): Variable-length subnet masks More efficient address allocation Replaced wasteful classful addressing IPv6 Deployment: Long-term solution Adoption growing but slow (>40% of Google traffic now IPv6) Dual-stack deployment common during transition

Why IPv6 Adoption is Slow

Despite being standardized in 1998, IPv6 adoption took decades because: • IPv6 is not backward compatible—requires parallel infrastructure • NAT 'solved' the immediate problem, reducing urgency • Costs of dual-stack outweigh benefits for many organizations • No compelling features for users—speed/security arguments weak Adoption accelerated when mobile operators (needing massive address space) and large content providers (Google, Facebook) deployed IPv6, creating critical mass.

Network Services as Resources

Beyond raw connectivity, networks provide services that are themselves shared resources. These services have capacity limits and require management.

Network Services as Resources

•DNS Resolution Capacity — DNS servers have query limits. Under DDoS attack, DNS can become the bottleneck preventing all name resolution.
•DHCP Address Pools — Limited pool of dynamic addresses. Exhausted pools prevent new device connections.
•NAT Translation Tables — Each NAT device has finite memory for translation entries. High connection counts can exhaust tables.
•Firewall State Tables — Stateful firewalls track connections. Connection flooding attacks exhaust state, blocking legitimate traffic.
•VPN Tunnel Capacity — VPN concentrators have concurrent tunnel limits. Exceeded during mass remote-work events.
•Load Balancer Capacity — Connection handling, SSL termination have limits. Over-capacity means failed requests.

Service Resource Planning: Network service capacity planning requires understanding: Baseline Load: What's normal traffic? Peak times? How many concurrent users/connections? Growth Projections: How is usage increasing? Planned new applications? Headroom: How much spare capacity for unexpected spikes? Typical target: 70% utilization at peak Failure Modes: What happens when capacity is exceeded? Graceful degradation vs. total failure? Scaling Strategy: Vertical (bigger device) vs. horizontal (more devices) Lead time for procurement/deployment

The Cloud Scaling Illusion

Cloud services create an illusion of infinite resources—'just spin up more instances.' In reality: • Cloud regions have physical capacity limits • Quotas limit individual account usage • Scaling takes time (seconds to minutes) • Costs grow with usage (potentially dramatically) Even in the cloud, capacity planning remains essential. The model changes from 'buy equipment' to 'manage costs and quotas.'

Monitoring and Managing Resources

Effective resource management requires visibility. Network monitoring provides data for capacity planning, troubleshooting, and optimization.

Network Monitoring Approaches
Method	What It Measures	Tools	Use Case
SNMP Polling	Device counters (bytes, errors, CPU)	Cacti, Nagios, PRTG	Capacity trends, health dashboards
Flow Analysis	Traffic patterns (source, dest, protocol)	NetFlow, sFlow, ntopng	Who's using bandwidth? What protocols?
Packet Capture	Full packet contents	Wireshark, tcpdump	Deep troubleshooting, forensics
Synthetic Probing	Simulated transactions	Smokeping, ThousandEyes	Application experience, SLA verification
Log Analysis	Event records from devices	ELK stack, Splunk	Security, troubleshooting, audit
APM	Application-level metrics	New Relic, Datadog, Dynatrace	End-user experience, service dependencies

Key Metrics to Monitor: Bandwidth/Utilization: Interface traffic in/out (bps) Utilization percentage Trend over time Latency: Round-trip time to key destinations Jitter (latency variation) Path latency decomposition Errors: Interface errors (CRC, collisions, drops) Protocol errors (TCP retransmissions) Device errors (CPU overload, memory usage) Availability: Service uptime percentage Mean time between failures (MTBF) Mean time to recovery (MTTR) Session Counts: Active connections Connection rate (new connections/second) NAT table utilization

bandwidth-monitor
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
"""
Simple bandwidth utilization calculation from SNMP counters
Demonstrates fundamental network monitoring concepts
"""
 
from datetime import datetime
from dataclasses import dataclass
 
@dataclass
class InterfaceCounters:
    """SNMP counter values at a point in time"""
    timestamp: datetime
    if_in_octets: int  # Bytes received
    if_out_octets: int  # Bytes transmitted
    interface_speed: int  # Interface speed in bps
 
def calculate_utilization(prev: InterfaceCounters, 
                          curr: InterfaceCounters) -> dict:
    """
    Calculate bandwidth utilization between two measurement points
    """
    time_delta = (curr.timestamp - prev.timestamp).total_seconds()
    
    if time_delta <= 0:
        raise ValueError("Time delta must be positive")
    
    # Calculate bits transferred (counter difference × 8)
    in_bits = (curr.if_in_octets - prev.if_in_octets) * 8
    out_bits = (curr.if_out_octets - prev.if_out_octets) * 8
    
    # Calculate rates (bits per second)
    in_bps = in_bits / time_delta
    out_bps = out_bits / time_delta
    
    # Calculate utilization percentage
    in_util = (in_bps / curr.interface_speed) * 100
    out_util = (out_bps / curr.interface_speed) * 100
    
    return {
        'interval_seconds': time_delta,
        'in_bps': in_bps,
        'out_bps': out_bps,
        'in_mbps': in_bps / 1_000_000,
        'out_mbps': out_bps / 1_000_000,
        'in_utilization_pct': in_util,
        'out_utilization_pct': out_util
    }
 
# Example: 1 Gbps interface, 5-minute polling interval
interface_speed = 1_000_000_000  # 1 Gbps
 
sample_1 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 0, 0),
    if_in_octets=1_000_000_000,
    if_out_octets=500_000_000,
    interface_speed=interface_speed
)
 
sample_2 = InterfaceCounters(
    timestamp=datetime(2024, 1, 15, 10, 5, 0),  # 5 minutes later
    if_in_octets=1_450_000_000,  # 450 MB received
    if_out_octets=650_000_000,   # 150 MB sent
    interface_speed=interface_speed
)
 
result = calculate_utilization(sample_1, sample_2)
 
print("Interface Utilization Report")
print("=" * 40)
print(f"Interval: {result['interval_seconds']:.0f} seconds")
print(f"Inbound:  {result['in_mbps']:.2f} Mbps ({result['in_utilization_pct']:.1f}%)")
print(f"Outbound: {result['out_mbps']:.2f} Mbps ({result['out_utilization_pct']:.1f}%)")

Alerting Strategy

Don't just monitor—alert on actionable conditions: • Utilization >80% — Warning; may hit capacity • Utilization >90% — Critical; likely causing issues • Sudden drops — Possible failure • Error rates increasing — Hardware or cable issues • Latency increases — Congestion or path changes Avoid alert fatigue: Too many false positives cause real alerts to be ignored.

Network Resources

The Resources Networks Provide

Types of Network Resources

Resource Sharing Mechanisms

Congestion: When Demand Exceeds Supply

Quality of Service (QoS)

Address Space as a Resource

Network Services as Resources

Monitoring and Managing Resources

There’s more to understand.

Network Resources

The Resources Networks Provide

Types of Network Resources

Resource Sharing Mechanisms

Congestion: When Demand Exceeds Supply

Quality of Service (QoS)

Address Space as a Resource

Network Services as Resources

Monitoring and Managing Resources

There’s more to understand.