Sources and References

Primary textbook — James F. Kurose & Keith W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021. Supplementary — Larry Peterson & Bruce Davie, Computer Networks: A Systems Approach (open access at book.systemsapproach.org); Nick Feamster, Jennifer Rexford & Zegura, “The Road to SDN,” ACM Queue, 2013 (open access). RFCs — IETF RFC 2460 (IPv6), RFC 4271 (BGP-4), RFC 9000 (QUIC), RFC 8200 (IPv6 bis), RFC 8446 (TLS 1.3). All publicly available at tools.ietf.org.

Chapter 1: Internet Architecture and Review

1.1 The Internet as a System

The Internet is not a single network but a network of networks — an ecosystem of tens of thousands of individually operated Autonomous Systems (ASes) interconnected by a set of protocols that enforce interoperability without requiring central administration. Understanding this architecture is the foundation for every advanced topic in the course.

At the coarsest level, the Internet’s structure is hierarchical. Tier-1 providers (e.g., AT&T, NTT, Lumen) maintain global backbones and exchange traffic settlement-free through peering agreements. Tier-2 providers purchase transit from Tier-1 carriers but also peer with comparable networks to reduce cost. Stub ASes — corporate networks, universities, ISPs serving end users — sit at the edge and purchase transit rather than selling it. This economic structure shapes routing policy: an AS will generally not advertise a route learned from one provider to another provider (the no-valley and prefer-customer rules) to avoid becoming an unwilling transit point.

1.1.1 BGP and Inter-Domain Routing

The Border Gateway Protocol (BGP-4, RFC 4271) is the de-facto standard for exchanging routing information between ASes. Unlike interior routing protocols such as OSPF or IS-IS, which optimise for shortest path, BGP is a path-vector protocol that carries the full AS-level path to each prefix, enabling policy-based route selection.

A BGP speaker establishes a session (a TCP connection over port 179) with each neighbour and exchanges UPDATE messages. Each UPDATE either announces a new prefix reachability (with a set of path attributes) or withdraws a previously announced prefix. The most important path attributes are:

• AS_PATH: the ordered list of ASNs the announcement has traversed. Used to detect routing loops (a speaker rejects an update containing its own ASN) and as a coarse measure of path length.
• NEXT_HOP: the IP address of the border router that should be used as the next forwarding hop.
• LOCAL_PREF: a locally significant integer (higher is preferred) used within an AS to select among multiple external routes.
• MED (Multi-Exit Discriminator): a hint from one AS to a neighbouring AS about the preferred entry point when multiple links connect the two.
• COMMUNITY: a tag allowing ASes to signal routing policy across administrative boundaries.

BGP route selection follows a deterministic tie-breaking procedure: prefer the highest LOCAL_PREF, then the shortest AS_PATH, then the lowest MED, then eBGP over iBGP, then the closest (lowest IGP cost) NEXT_HOP, and finally the lowest router-ID as a tiebreaker.

1.1.2 Internet Exchange Points

Internet Exchange Points (IXPs) are physical facilities where multiple networks interconnect via a shared switching fabric, typically a layer-2 Ethernet switch. By exchanging traffic at an IXP instead of routing it through upstream providers, members reduce transit costs and improve latency. Major IXPs such as DE-CIX (Frankfurt), AMS-IX (Amsterdam), and LINX (London) handle multiple terabits per second of traffic. The proliferation of IXPs over the past two decades has flattened the Internet’s hierarchy, enabling direct peering between networks that were previously many hops apart.

1.2 IPv6: Design and Deployment

IPv4’s 32-bit address space — approximately 4.3 billion addresses — was effectively exhausted at the IANA level in 2011. IPv6 (RFC 8200, originally RFC 2460) provides a 128-bit address space, yielding \( 2^{128} \approx 3.4 \times 10^{38} \) addresses, a quantity large enough to assign a globally unique address to every grain of sand on Earth many times over.

1.2.1 IPv6 Header Format

The IPv6 fixed header is 40 bytes, compared to the variable-length IPv4 header of 20–60 bytes. The key fields are:

• Version (4 bits): always 6.
• Traffic Class (8 bits): carries the Differentiated Services Code Point (DSCP) and ECN bits, analogous to the IPv4 ToS/DSCP field.
• Flow Label (20 bits): a new field allowing sources to label packets belonging to a flow, enabling stateless per-flow treatment by routers.
• Payload Length (16 bits): the length of the payload including any extension headers.
• Next Header (8 bits): identifies the type of the next header — either an upper-layer protocol (TCP = 6, UDP = 17, ICMPv6 = 58) or an extension header.
• Hop Limit (8 bits): decremented by each router, replacing IPv4’s TTL.
• Source and Destination Addresses (128 bits each).

Fragmentation in IPv6 is performed only by the source, not by intermediate routers. When a source needs to fragment, it inserts a Fragment extension header. This design simplifies router forwarding and is one reason IPv6 routers can process packets faster than IPv4 routers on equivalent hardware.

1.2.2 IPv6 Addressing

IPv6 addresses are 128-bit values written in eight groups of four hexadecimal digits separated by colons, e.g., 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Two abbreviation rules apply: leading zeros within a group may be dropped, and a single contiguous run of all-zero groups may be replaced by :: (used at most once per address).

Address types in IPv6 include:

• Global Unicast Addresses (GUA): routable on the public Internet. Currently allocated from 2000::/3.
• Link-Local Addresses: fe80::/10, automatically configured on every interface, scoped to a single link, used for neighbour discovery and router solicitation.
• Unique Local Addresses (ULA): fc00::/7, analogous to RFC 1918 private space in IPv4.
• Multicast: ff00::/8. Broadcast does not exist in IPv6; it is replaced by specific multicast groups (e.g., all-routers ff02::2, all-nodes ff02::1).
• Anycast: a single address assigned to multiple interfaces; packets are routed to the topologically nearest interface.

Stateless Address Autoconfiguration (SLAAC) allows hosts to self-configure a GUA by combining the /64 prefix advertised by the router with an Interface Identifier derived from the MAC address (EUI-64) or generated randomly (RFC 7217 stable privacy addresses). DHCPv6 (stateful or stateless) is also available.

1.2.3 IPv6 Transition Mechanisms

Because IPv4 and IPv6 are not directly interoperable, the Internet has relied on a toolbox of transition mechanisms:

• Dual-stack: a host or router runs both IPv4 and IPv6 simultaneously, preferring IPv6 when available.
• Tunneling (6in4, 6to4, Teredo, ISATAP): IPv6 packets are encapsulated inside IPv4 packets to traverse IPv4-only infrastructure.
• NAT64 + DNS64: a NAT64 gateway translates between IPv6 and IPv4, allowing IPv6-only clients to reach IPv4 servers. DNS64 synthesises AAAA records for IPv4-only names by prepending a well-known prefix.

Chapter 2: Application Layer and Content-Centric Networks

2.1 DNS Architecture

The Domain Name System (DNS) is a globally distributed, hierarchical, and loosely-consistent database that maps human-readable domain names to IP addresses and other resource records. The hierarchy consists of the root zone (managed by ICANN/IANA), top-level domains (TLDs such as .com, .net, .ca), and second-level and lower domains administered by their respective owners.

DNS resolution is iterative or recursive. In iterative resolution, the client’s recursive resolver (often provided by the ISP or a public resolver like 8.8.8.8 or 1.1.1.1) queries the root servers, then the TLD servers, then the authoritative name servers, assembling the final answer. In recursive resolution, the resolver passes the entire resolution burden to another server. Caching at each step, governed by the record’s Time-To-Live (TTL) field, dramatically reduces the query load on authoritative servers.

2.1.1 DNS Security (DNSSEC)

DNSSEC adds origin authentication and data integrity to DNS through a chain of cryptographic signatures. Each zone signs its resource records with a Zone Signing Key (ZSK); the ZSK’s public key is itself signed by a Key Signing Key (KSK), and the KSK is vouched for by the parent zone, creating a chain of trust rooted at the IANA root key-signing key. DNSSEC does not provide confidentiality — queries and responses are still in plaintext — which motivates DNS-over-HTTPS (DoH, RFC 8484) and DNS-over-TLS (DoT, RFC 7858).

2.2 HTTP/2 and HTTP/3

HTTP/1.1, despite its longevity, suffers from head-of-line (HOL) blocking at the application layer: within a single TCP connection, responses must be delivered in request order, so a slow response blocks subsequent ones. HTTP/2 addresses this through multiplexing: multiple logical streams are interleaved within a single TCP connection, each identified by a stream ID. Frames from different streams can be interleaved arbitrarily, so a stalled stream does not block others.

HTTP/2 also introduces header compression via HPACK (RFC 7541), which maintains a dynamic table of previously seen header fields and encodes new fields as deltas, dramatically reducing header overhead. Server push allows the server to proactively send resources the client is likely to need without waiting for an explicit request.

However, HTTP/2 still runs over TCP, which has its own HOL blocking at the transport layer: packet loss anywhere in the TCP byte stream stalls all multiplexed streams until the lost segment is retransmitted. HTTP/3 (RFC 9114) solves this by running over QUIC (RFC 9000) instead of TCP, providing independent per-stream reliability at the transport layer.

2.3 Content Delivery Networks

A Content Delivery Network (CDN) is a geographically distributed set of proxy servers (called edge servers or PoPs — Points of Presence) that cache and serve content on behalf of an origin server. CDNs exploit the principle of content locality: by placing a copy of popular content close to users, both latency and backbone bandwidth consumption are reduced.

2.3.1 CDN Request Routing

CDNs must steer each client request to the optimal edge server. The two dominant mechanisms are:

DNS-based load balancing: the CDN’s authoritative name server returns a different IP address for the same hostname depending on the client’s apparent location (inferred from the recursive resolver’s IP address) and the current load on edge servers. The short TTL (often 30 seconds) ensures that clients are redirected to new servers as conditions change. Akamai pioneered this approach in the late 1990s.

Anycast routing: the same IP prefix is originated from multiple PoPs via BGP. BGP’s shortest-path logic naturally steers clients to the topologically nearest PoP. Anycast is used by all major DNS providers (including the root DNS servers) and by CDNs serving DDoS mitigation services.

2.3.2 CDN Cache Hierarchy and Replacement

CDN PoPs typically maintain a tiered cache hierarchy: a small, fast L1 cache in RAM and a larger L2 cache on SSD or HDD. Cache replacement is governed by policies such as LRU (Least Recently Used), LFU (Least Frequently Used), or the more sophisticated LIRS (Low Inter-reference Recency Set) algorithm. Content popularity distributions are heavy-tailed (Zipf-like), meaning a small fraction of objects accounts for the vast majority of requests — this is precisely what makes caching effective.

2.3.3 Peer-to-Peer Protocols and Data Centers

Peer-to-peer (P2P) protocols distribute both storage and bandwidth across participating end-hosts, eliminating the need for centralised servers. BitTorrent divides a file into pieces and exchanges them among peers using a tit-for-tat incentive mechanism that rewards uploaders with download bandwidth. Distributed Hash Tables (DHTs), used in systems like Kademlia (employed by BitTorrent’s DHT tracker), provide a decentralised key-value lookup in \( O(\log N) \) hops over a network of \( N \) peers.

Modern Internet companies operate massive data centres — facilities housing tens of thousands to hundreds of thousands of servers in close proximity connected by high-speed, low-latency switching fabric. The network architecture inside a data centre is discussed in depth in Chapter 4.

Chapter 3: Software-Defined Networking

3.1 Motivation and Architecture

Traditional network devices couple the control plane — the logic that decides where packets should go — with the data plane — the hardware that actually forwards packets at line rate. This coupling has historically meant that changing network behaviour requires upgrading proprietary hardware or firmware, a slow and expensive process. Software-Defined Networking (SDN) decouples the control plane from the data plane, centralising routing logic in a software controller that communicates with dumb but fast forwarding elements (switches) via an open protocol.

The southbound interface between the controller and the data plane is the most visible innovation. OpenFlow (standardised by the Open Networking Foundation, ONF) was the first widely deployed southbound protocol and remains the conceptual reference model for SDN.

3.1.1 OpenFlow

In an OpenFlow switch, the forwarding decision is based on flow tables. Each flow table entry contains:

• Match fields: values to compare against packet header fields (Ethernet src/dst, IP src/dst, TCP/UDP ports, VLAN tags, MPLS labels, and more). OpenFlow 1.3 extended the match space to over 40 fields.
• Priority: when multiple entries match, the highest-priority entry wins.
• Instructions/Actions: what to do with matching packets — output on a port, modify a header field, push/pop a VLAN or MPLS label, send to the controller, drop, or forward to the next table.
• Counters: packet and byte counts per entry, used for traffic measurement.
• Timeout: idle and hard timeouts after which the entry is removed.

When a packet arrives at an OpenFlow switch and no flow table entry matches, the switch sends a Packet-In message to the controller via the secure OpenFlow channel (TCP or TLS). The controller processes the packet, determines the appropriate action, and sends back a Flow-Mod message installing a new flow table entry so that subsequent packets in the same flow are handled without controller involvement (reactive flow setup). For proactive setup, the controller pre-installs flow entries before any traffic arrives.

3.1.2 SDN Controllers

A variety of open-source SDN controllers have been developed:

• NOX/POX: early Python-based controllers used primarily for research.
• Floodlight: Java-based, modular architecture with a REST northbound API.
• OpenDaylight (ODL): a large-scale, multi-protocol Java framework hosted by the Linux Foundation, supporting OpenFlow, NETCONF/YANG, and BGP.
• ONOS (Open Network Operating System): designed for carrier-grade deployments with high availability, distributed state, and support for intent-based networking.
• Ryu: a lightweight Python controller popular in academic settings.

A critical design question is controller placement: where in the network should the (logically centralised but physically distributed) controller instances reside to minimise the average control-plane latency? This is an NP-hard optimisation problem for general network topologies but admits good heuristics.

3.1.3 Network Programmability with P4

OpenFlow exposes a fixed, protocol-specific match-action pipeline. P4 (Programming Protocol-Independent Packet Processors) goes further: it is a domain-specific language (DSL) that allows operators to define the packet processing pipeline of a switch, specifying which header fields to parse, which match-action tables to create, and how to compose them. A P4 program is compiled to a target-specific binary (FPGA, SmartNIC, or software switch like BMv2).

P4’s key abstractions are:

• Headers and parsers: a parser is a finite state machine that extracts header fields from raw bytes.
• Match-action tables: analogous to OpenFlow flow tables but fully programmable in terms of which fields are matched and what actions are possible.
• Control flow: imperative code that sequences tables and conditional logic.
• Deparsers: reconstruct the packet byte stream from (possibly modified) header fields.

P4 enables capabilities impossible in fixed-pipeline switches, including in-band network telemetry (INT), custom tunnel encapsulations, and stateful per-flow tracking at terabit-per-second line rates.

3.2 Intent-Based Networking

Intent-based networking (IBN) raises the abstraction level further: rather than specifying low-level flow rules, network operators express high-level intents — “host A should be able to reach server S with at most 10 ms latency and 99.9% availability” — and the IBN system translates, validates, and deploys the corresponding low-level configuration. The intent lifecycle consists of four phases: translation (intent to policy), activation (policy to device configuration), assurance (continuous monitoring against the intent), and remediation (corrective action when the network deviates from the intent).

Chapter 4: Data Center Networking

4.1 Data Center Topology

The networking inside a data centre must support any-to-any communication among tens of thousands of servers at near line-rate bandwidth while tolerating hardware failures. Traditional three-tier architectures (access — aggregation — core) create bandwidth bottlenecks at the aggregation layer. Modern data centres use Clos topologies, which are non-blocking multi-path fabrics originally designed for telephone switching.

For a \( k = 48 \) fat-tree (48-port 10 GbE switches):

4.1.1 Equal-Cost Multipath (ECMP)

Fat-tree topologies expose multiple equal-cost paths between any pair of hosts. ECMP distributes flows across these paths using a hash of the packet’s 5-tuple (source IP, destination IP, source port, destination port, protocol). Because hashing is deterministic within a flow, packet reordering within a TCP connection is avoided. However, ECMP’s hash-based assignment can cause flow collisions — multiple large (“elephant”) flows mapped to the same path while other paths are underutilised.

4.1.2 RDMA and RoCE

High-performance computing applications (distributed machine learning, in-memory databases, financial trading) demand sub-microsecond latency and near-zero CPU overhead for network I/O. Remote Direct Memory Access (RDMA) allows one host to directly read or write the memory of another without involving the remote CPU. Over Ethernet, RDMA is implemented via RoCE (RDMA over Converged Ethernet), which encapsulates the InfiniBand transport in UDP/Ethernet frames.

RoCE is extremely sensitive to packet loss because the RDMA transport’s Go-Back-N retransmission scheme causes a single dropped packet to trigger retransmission of all subsequent packets in the window. This makes lossless fabric operation essential for RoCE deployments.

4.1.3 DCQCN Congestion Control

Datacenter Quantised Congestion Notification (DCQCN) is the congestion control algorithm developed by Microsoft and deployed in Azure for RoCE traffic. It combines two mechanisms:

1. ECN marking at switches: when a queue depth exceeds a threshold, switches set the ECN Congestion Experienced (CE) codepoint in packet headers.
2. Rate-based control at the sender: upon receiving a Congestion Notification Packet (CNP) from the receiver (which is triggered by CE-marked packets), the sender reduces its transmission rate by a multiplicative factor \( \alpha \); the rate is then gradually increased back toward the link rate.

The DCQCN rate update equations are:

A timer-based rate increase mechanism restores bandwidth: the rate is first increased by a fixed byte count increment (fast recovery) and then by a fraction of the headroom to the link rate (hyper-increase).

Chapter 5: Network Security

5.1 Cryptographic Foundations

Network security rests on a small set of cryptographic primitives whose security properties are well understood. For ECE 416, the key concepts are:

• Symmetric encryption (e.g., AES-GCM): the same key is used for encryption and decryption. Extremely fast (hardware AES-NI support), but key distribution is the challenge.
• Asymmetric (public-key) encryption (e.g., RSA, ECDH): a public key is used to encrypt (or verify a signature) and the corresponding private key decrypts (or creates a signature). Solves key distribution but is orders of magnitude slower than symmetric encryption.
• Cryptographic hash functions (e.g., SHA-256, SHA-3): one-way functions mapping arbitrary input to a fixed-length digest. Used for integrity verification, digital signatures, and MAC construction.
• Message Authentication Codes (MACs): keyed hash functions providing both integrity and authentication.
• Digital signatures: a private key is used to sign a digest; anyone with the public key can verify the signature. Provides non-repudiation.
• Diffie-Hellman key exchange: allows two parties to establish a shared secret over an untrusted channel without prior key exchange.

5.2 TLS 1.3

Transport Layer Security (TLS) 1.3, standardised in RFC 8446 (2018), is the protocol that secures virtually all sensitive Internet traffic — HTTPS, SMTPS, IMAPS, and VPN tunnels. TLS 1.3 made sweeping improvements over TLS 1.2:

• Forward secrecy is mandatory: all key exchange in TLS 1.3 uses ephemeral Diffie-Hellman (ECDHE), so compromise of the server’s long-term private key does not expose past session traffic.
• Handshake latency reduced to 1-RTT: the client sends its key share in the first flight (ClientHello), and the server can immediately respond with its key share and the encrypted handshake data (EncryptedExtensions, Certificate, CertificateVerify, Finished). The application data can follow immediately. A 0-RTT mode allows session resumption with no additional round trip, at the cost of susceptibility to replay attacks.
• Cipher suite simplification: legacy and weak algorithm combinations (RC4, 3DES, export-grade ciphers, RSA key transport) were removed. Only five cipher suites are defined, all using AEAD (Authenticated Encryption with Associated Data).
• Encrypted handshake: in TLS 1.2 the Certificate message was in plaintext, leaking the server identity. TLS 1.3 encrypts everything after the ServerHello, protecting the server certificate from passive observers.

5.3 Application-Layer Security

5.3.1 Email Security (SMTP, POP, IMAP)

Email security is addressed at multiple layers. At the message layer:

• SPF (Sender Policy Framework): a DNS TXT record published by the domain owner lists the IP addresses authorised to send email on behalf of the domain. Receiving MTAs verify the envelope sender against this list.
• DKIM (DomainKeys Identified Mail): the sending mail server signs selected message headers and the body with a private key; the public key is published as a DNS TXT record. The signature travels with the message and survives forwarding.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): a policy published in DNS that specifies what receiving servers should do with messages that fail SPF or DKIM alignment, and requests aggregate and forensic reports.

5.3.2 DDoS Attacks and Mitigation

Distributed Denial-of-Service (DDoS) attacks aim to exhaust a target’s resources — bandwidth, CPU, connection tables — by flooding it with traffic from many sources. Volumetric attacks (UDP floods, DNS amplification, NTP amplification) exploit amplification: a small spoofed request triggers a large response directed at the victim. The amplification factor for DNS can be as high as 70×; for NTP monlist queries, historically above 500×.

Mitigation strategies operate at multiple timescales:

• Ingress filtering (BCP38): networks drop packets whose source addresses are not routable from the interface on which they arrived. This prevents source-address spoofing but requires widespread deployment to be effective.
• Scrubbing centres: traffic is redirected (via BGP or DNS) to a scrubbing centre where it is filtered before being forwarded to the origin.
• Anycast diffusion: the target prefix is anycast-announced from many PoPs, distributing the attack traffic across the provider’s global infrastructure.
• Rate limiting and CAPTCHAs: applied at the application layer to filter bot traffic.

5.3.3 BGP Hijacking

BGP hijacking occurs when a malicious or misconfigured AS announces a more-specific (longer-prefix) or equally-specific prefix belonging to another AS. Because BGP prefers more-specific routes, even a small rogue AS can attract traffic meant for the legitimate prefix owner. Notable incidents include the Pakistan Telecom hijacking of YouTube’s prefix in 2008 and the China Telecom incidents of 2010 and 2018.

Defences include:

• RPKI (Resource Public Key Infrastructure): a database of Route Origin Authorisations (ROAs), each cryptographically signed and specifying which AS is authorised to originate a given prefix with up to a specified maximum prefix length. Routers performing Route Origin Validation (ROV) reject routes that violate a ROA.
• BGPsec: a full path-validation extension that signs each BGP hop, preventing path forgery in addition to origin forgery. Deployment has been slow due to complexity and performance overhead.
• MANRS (Mutually Agreed Norms for Routing Security): an industry initiative encouraging ASes to implement filtering, anti-spoofing, and ROA publication.

5.4 Network-Layer Security: IPsec

IPsec operates at the IP layer and provides confidentiality, integrity, and authentication for IP packets. It is used in VPNs (both site-to-site and remote-access). The two primary protocols are:

• AH (Authentication Header): provides integrity and authentication but no confidentiality. Because it authenticates the outer IP header, it is incompatible with NAT.
• ESP (Encapsulating Security Payload): provides confidentiality, integrity, and authentication. Compatible with NAT when used in UDP-encapsulated form (NAT traversal, RFC 3948).

IPsec operates in transport mode (protecting only the payload, leaving the original IP header) or tunnel mode (encapsulating the entire original IP packet inside a new IP packet — the basis of VPN tunnels). The Internet Key Exchange (IKEv2) protocol establishes Security Associations (SAs) using Diffie-Hellman and authenticates peers via certificates or pre-shared keys.

5.5 Firewalls

A firewall enforces an access control policy between network segments by inspecting and filtering traffic. Types include:

• Packet filters: stateless, match on 5-tuple fields. Fast but cannot track connection state.
• Stateful inspection firewalls: maintain a connection table tracking established TCP and UDP flows. New connections matching policy are admitted and the state is tracked; packets that don’t match an established state or allowed new connection are dropped.
• Application-layer gateways (ALGs) / proxy firewalls: terminate and reinitiate connections, performing deep inspection of application protocols.
• Next-Generation Firewalls (NGFWs): combine stateful inspection with IDS/IPS, SSL inspection, application identification, and user-identity awareness.

Chapter 6: Link Layer — VLANs and MPLS

6.1 Virtual LANs

A Virtual LAN (VLAN) partitions a single physical switched network into multiple logical broadcast domains. Without VLANs, every device on a switch is in the same broadcast domain and receives all broadcast traffic. VLANs confine broadcast traffic to members of the same VLAN, improving security, performance, and administrative manageability.

IEEE 802.1Q defines VLAN tagging: a 4-byte tag inserted between the source MAC address and the EtherType field of an Ethernet frame. The tag carries a 12-bit VLAN Identifier (VID) (values 1–4094, with 0 and 4095 reserved) and a 3-bit Priority Code Point (PCP) used for 802.1p QoS marking.

Switch ports are configured as:

• Access ports: carry untagged frames from end devices; the switch adds a tag internally.
• Trunk ports: carry frames from multiple VLANs, tagged with their respective VIDs. Used for inter-switch and switch-to-router (router-on-a-stick) links.

Inter-VLAN routing requires either a router with subinterfaces (one per VLAN) or a Layer-3 switch with Switched Virtual Interfaces (SVIs).

6.2 Multiprotocol Label Switching

Multiprotocol Label Switching (MPLS) is a forwarding paradigm that makes forwarding decisions based on a short fixed-length label rather than a full IP destination prefix lookup. MPLS labels are inserted between the Layer 2 header and the IP header (the “shim header”), carrying a 20-bit label value, a 3-bit Traffic Class (TC) field, an S (bottom-of-stack) bit, and an 8-bit TTL.

At the ingress Label Edge Router (LER), an IP packet is classified and assigned a label. Label Switch Routers (LSRs) in the MPLS domain forward packets based solely on the label, swapping it for the next label in the path (Label-Switched Path, LSP). The egress LER removes the label and forwards the plain IP packet.

MPLS enables several important features:

• Traffic engineering (MPLS-TE): LSPs can be explicitly routed through the network (bypassing IGP shortest paths) using RSVP-TE or OSPF-TE signalling, allowing operators to load-balance across multiple paths and provision bandwidth guarantees.
• VPNs (MPLS-BGP VPNs, RFC 4364): each customer VPN is identified by a VPN Routing and Forwarding (VRF) instance at the PE router. BGP distributes VPN routes with an additional Route Distinguisher (RD) field to make overlapping customer address spaces unique in the BGP table.
• Fast reroute: pre-computed backup LSPs allow traffic to be rerouted in 50 ms or less upon detecting a link or node failure, meeting carrier-grade availability requirements.

Chapter 7: Wireless and Mobile Networks

7.1 Wi-Fi — IEEE 802.11

Wi-Fi is the dominant wireless LAN technology. The 802.11 family has evolved from 802.11b (11 Mbps, 2.4 GHz, 1999) through 802.11a/g (54 Mbps), 802.11n (600 Mbps, MIMO), 802.11ac (3.5 Gbps, MU-MIMO in 5 GHz), to 802.11ax (Wi-Fi 6, 9.6 Gbps, OFDMA, BSS Colouring) and 802.11be (Wi-Fi 7, 46 Gbps, multi-link operation).

7.1.1 CSMA/CA

Unlike Ethernet’s CSMA/CD (Collision Detection), Wi-Fi uses CSMA/CA (Collision Avoidance) because half-duplex radio operation makes collision detection impractical. The MAC procedure is:

1. If the channel is idle for DIFS (Distributed Interframe Space), transmit immediately.
2. If the channel is busy, wait until it becomes idle, then backoff for a random number of slots uniformly chosen from [0, CW − 1], where CW is the current contention window.
3. After each successful transmission, CW is reset to CWmin (typically 16 slots). After each collision or timeout, CW is doubled (up to CWmax, typically 1024 slots) — Binary Exponential Backoff (BEB).
4. For unicast frames, the receiver sends an ACK after SIFS (Short IFS) to confirm receipt. If no ACK is received within the ACK timeout, the sender assumes a collision and retransmits after re-backoff.

The optional RTS/CTS handshake (Request To Send / Clear To Send) mitigates the hidden terminal problem — where two stations that cannot hear each other both transmit to the same AP, causing a collision.

7.1.2 Wi-Fi Security

WPA2 (IEEE 802.11i): uses AES-CCMP for frame encryption and TKIP (deprecated) as a fallback. In personal (PSK) mode, the Pre-Shared Key and the SSID seed a 4-way handshake that derives per-session Pairwise Transient Keys (PTKs). In enterprise mode, 802.1X authentication with RADIUS is used, providing per-user credentials and per-session key derivation.

WPA3: addresses WPA2’s vulnerability to offline dictionary attacks on PSK by using SAE (Simultaneous Authentication of Equals, a Dragonfly handshake), which provides forward secrecy even if the PSK is later compromised. WPA3-Enterprise mandates 192-bit security suites.

PMKID attack: a passive attack (no need to capture the 4-way handshake) where the PMKID, derivable from a single beacon/association packet, is used to perform offline brute-force on the PSK.

7.2 4G LTE Architecture

Long-Term Evolution (LTE), standardised by 3GPP, is the dominant 4G radio access technology. The LTE architecture separates the Evolved Packet Core (EPC) from the Evolved UTRAN (E-UTRAN) radio access network.

Key EPC entities:

• eNodeB (eNB): the base station that handles radio resource management, scheduling, and header compression.
• MME (Mobility Management Entity): handles control-plane functions — authentication, session management, handover signalling, and NAS (Non-Access Stratum) protocol.
• S-GW (Serving Gateway): the user-plane anchor in the EPC, forwarding data packets between the eNB and the P-GW.
• P-GW (PDN Gateway): the interface to external packet data networks (Internet, IMS). Performs IP address assignment (using DHCPv4/v6 or SLAAC), policy enforcement, and charging.
• HSS (Home Subscriber Server): a database storing subscriber information, authentication vectors, and subscription profiles.

7.2.1 LTE Tunnelling and Mobility

User data in LTE is carried in GTP-U (GPRS Tunnelling Protocol — User Plane) tunnels. When a device moves from one cell to another (X2 handover), the source eNB and target eNB exchange context via the X2 interface, and a temporary tunnel carries in-flight packets to the target. After handover, the S-GW updates its tunnel endpoint to point to the new eNB. This transparent mobility — the device’s IP address does not change — is a key differentiator of cellular versus Wi-Fi mobility.

7.3 5G NR Architecture

5G New Radio (NR) extends LTE with three usage scenarios defined by IMT-2020:

• eMBB (enhanced Mobile Broadband): peak downlink rates of 20 Gbps, sub-1 ms air-interface latency.
• URLLC (Ultra-Reliable Low-Latency Communications): 99.9999% reliability with end-to-end latency ≤ 1 ms, targeting industrial automation and connected vehicles.
• mMTC (massive Machine-Type Communications): connection density of \( 10^6 \) devices/km\(^2\), targeting IoT deployments.

7.3.1 5G Core (5GC) and Service-Based Architecture

5GC adopts a Service-Based Architecture (SBA): instead of point-to-point interfaces between fixed network functions, each NF exposes a service via HTTP/2-based APIs registered in the Network Repository Function (NRF). Core NFs include the AMF (Access and Mobility Management Function), SMF (Session Management Function), UPF (User Plane Function), AUSF (Authentication Server Function), UDM (Unified Data Management), and PCF (Policy Control Function).

The separation of control plane (AMF, SMF) from user plane (UPF) is a key SDN-like design choice that enables User Plane Function placement close to the edge, supporting multi-access edge computing (MEC) with sub-10-ms end-to-end latency.

7.3.2 Network Slicing

Network slicing allows a single physical 5G infrastructure to be partitioned into multiple logically independent networks, each customised for a particular use case. A slice is defined by a slice/service type (SST) and a slice differentiator (SD); together they form the S-NSSAI (Single Network Slice Selection Assistance Information). The RAN, transport, and core are all sliced simultaneously: in the RAN, radio resources are partitioned; in the core, dedicated NF instances or shared NFs with per-slice policies serve each slice. This enables a mobile operator to simultaneously serve a consumer broadband slice, a URLLC slice for a factory, and an mMTC slice for utility metering over a single physical network.

Chapter 8: Quality of Service

8.1 Why QoS?

Best-effort IP networks treat all packets equally — there is no mechanism to prioritise voice over bulk file transfer, or to guarantee bandwidth for a video conference. As networks carry an increasing mix of latency-sensitive (VoIP, interactive video, gaming), delay-tolerant (bulk data transfer, backups), and best-effort (web browsing) traffic, QoS mechanisms have become essential.

Three broad QoS models exist:

1. IntServ (Integrated Services): per-flow resource reservation using RSVP signalling. Each application signals its bandwidth and delay requirements, and routers allocate dedicated resources. Provides hard guarantees but scales poorly — maintaining per-flow state at core routers is infeasible for the global Internet.

2. DiffServ (Differentiated Services): aggregate-level QoS using the 6-bit DSCP field in the IP header. Traffic is classified and marked at the edge; interior routers apply per-hop behaviours (PHBs) based on the DSCP value. The two main PHBs are Expedited Forwarding (EF) (low latency, low jitter, for premium traffic) and Assured Forwarding (AF) (four classes × three drop precedences = 12 codepoints for elastic traffic with differentiated drop probabilities).

3. Best-effort with traffic shaping: token bucket and leaky bucket algorithms at ingress points shape bursty traffic into conformant streams, preventing a single flow from monopolising shared resources.

8.2 Scheduling Algorithms

Queuing and scheduling are the central tools for implementing QoS in a router or switch.

FIFO with tail-drop: the simplest policy — serve packets in arrival order, drop new arrivals when the queue is full. Provides no differentiation and can lead to global synchronisation of TCP flows.

Priority Queuing (PQ): maintain separate queues per traffic class; always serve the highest non-empty queue. Provides strict priority but can starve lower-priority classes under heavy load.

Weighted Fair Queuing (WFQ): generalises round-robin by assigning weights \( w_i \) to each queue \( i \), ensuring that queue \( i \) receives at least a fraction \( w_i / \sum_j w_j \) of the bandwidth. WFQ approximates max-min fair allocation and provides bounded per-flow delay.

Deficit Round Robin (DRR): a practical approximation to WFQ that handles variable-length packets without per-packet timestamp sorting. Each queue is assigned a deficit counter; at each round, the counter is incremented by the queue’s quantum, and packets are dequeued until the counter goes negative (carried over to the next round). DRR runs in \( O(1) \) per packet, making it practical at high speeds.

8.3 Active Queue Management: RED and ECN

Tail-drop queues react to congestion only after overflow, causing TCP flows to synchronise their congestion window reductions. Random Early Detection (RED) drops packets with a probability that increases linearly as the average queue length grows from a minimum threshold \( \text{min}_{th} \) to a maximum threshold \( \text{max}_{th} \):

The average queue length \( \bar{q} \) is computed via EWMA: \( \bar{q} \leftarrow (1-w_q)\bar{q} + w_q q \), where \( q \) is the instantaneous queue length and \( w_q \approx 0.002 \) is a small weight.

ECN (Explicit Congestion Notification, RFC 3168) extends RED by marking rather than dropping packets: when congestion is detected, the router sets the CE (Congestion Experienced) bits in the IP header. The receiver echoes this back to the sender via the ECE (ECN Echo) bit in the TCP header, and the sender reduces its congestion window. ECN avoids the goodput reduction associated with drops and is particularly beneficial for short flows, which may carry only a handful of packets and cannot afford any retransmissions.

Chapter 9: Advanced Transport Protocols

9.1 TCP Congestion Control Review

TCP’s classical congestion control (RFC 5681) combines slow start, congestion avoidance, fast retransmit, and fast recovery. In congestion avoidance, the congestion window \( \text{cwnd} \) grows by approximately one MSS per RTT (additive increase), and is halved on detecting a loss event (multiplicative decrease) — the AIMD (Additive Increase, Multiplicative Decrease) algorithm. This provably converges to fairness among competing flows sharing a bottleneck link.

9.2 BBR Congestion Control

Bottleneck Bandwidth and Round-trip propagation time (BBR), developed at Google and deployed in Linux 4.9, takes a fundamentally different approach. Instead of reacting to loss events, BBR models the network path as a pipe with two parameters: the bottleneck bandwidth (BtlBw) and the round-trip propagation time (RTprop). BBR continuously estimates both parameters and adjusts the sending rate and cwnd to keep the network operating at the optimal point — filling the pipe but not the queue.

BBR cycles through four states:

1. STARTUP: exponentially probe bandwidth until no more gain is achievable.
2. DRAIN: drain any queue built during startup by temporarily reducing rate below BtlBw.
3. PROBE_BW: cruise at BtlBw, periodically probing for higher bandwidth by briefly sending faster (pacing_gain = 1.25) and then slower (pacing_gain = 0.75).
4. PROBE_RTT: periodically drain the queue to obtain a fresh RTprop estimate.

BBR is implemented as a pacing algorithm: packets are sent at a controlled rate rather than in bursts, achieving lower latency and higher throughput, especially over paths with shallow buffers.

9.3 QUIC

QUIC (Quick UDP Internet Connections), now standardised as RFC 9000, is a general-purpose transport protocol developed by Google and adopted as the foundation for HTTP/3. QUIC runs over UDP, allowing deployment without OS kernel changes and enabling innovation at the application layer. Key properties:

• Connection establishment: QUIC combines the cryptographic handshake with the transport handshake. A new connection requires 1 RTT (or 0-RTT for resumed connections using a stored server configuration) before application data flows, compared to TCP+TLS 1.3’s 1 RTT (plus the TCP 3-way handshake, adding at least 1 RTT) for data to begin.
• Stream multiplexing with independent reliability: each QUIC stream has independent reliability semantics. Loss of a packet on one stream does not stall other streams, eliminating TCP’s HOL blocking at the transport layer.
• Connection migration: a QUIC connection is identified by a Connection ID rather than the 4-tuple (src IP, src port, dst IP, dst port). When a mobile device switches networks (e.g., from Wi-Fi to cellular), the Connection ID remains the same and the connection continues without interruption.
• Integrated TLS 1.3: QUIC uses TLS 1.3 exclusively for handshake and key derivation; TLS record boundaries are eliminated and QUIC provides its own encryption of packet payloads.
• Improved loss recovery: QUIC uses monotonically increasing packet numbers (never retransmitting with the same number), eliminating the TCP retransmission ambiguity problem that makes accurate RTT estimation difficult.

9.4 Multipath TCP

Multipath TCP (MPTCP, RFC 8684) allows a single TCP connection to simultaneously use multiple network paths (e.g., Wi-Fi and cellular on a smartphone). MPTCP establishes multiple subflows, each a standard TCP connection on a different path. Data is split across subflows and reassembled at the receiver using a sequence number space that spans all subflows. MPTCP’s coupled congestion control algorithm (Linked Increases) ensures that a multipath flow does not take more bandwidth from any bottleneck than a single-path flow would, while still exploiting uncongested paths.

Chapter 10: Network Measurement and Performance

10.1 Passive Measurement: NetFlow and sFlow

Understanding what traffic is flowing in a network — and where it is going — is essential for capacity planning, anomaly detection, and security monitoring.

NetFlow (originally Cisco, standardised as IPFIX in RFC 7011): routers and switches export flow records to a collector. A flow is defined by the 5-tuple; additional fields include byte count, packet count, start and end timestamps, and TCP flags. Because NetFlow requires the device to maintain per-flow state, it is resource-intensive and is typically sampled (e.g., 1-in-N packet sampling) to reduce overhead.

sFlow (RFC 3176): a random packet sampling scheme in which 1 in N packets (configurable, typically 1-in-512 or 1-in-1000) is forwarded in full to a collector. sFlow also supports counter sampling (periodic snapshots of interface counters). Because no per-flow state is maintained, sFlow scales to very high line rates with minimal hardware overhead. The trade-off is statistical estimation error, which decreases as \( 1/\sqrt{N_{\text{samples}}} \).

10.2 Active Measurement

Active measurement injects probe traffic to measure path properties. Key tools:

• Ping (ICMP Echo): measures round-trip time (RTT) and packet loss rate.
• Traceroute: exploits the IP TTL field to discover the sequence of routers along a path. Each probe is sent with increasing TTL; each router that decrements TTL to zero returns an ICMP Time Exceeded message, revealing the router’s address and the RTT to that hop.
• iPerf / iperf3: measures achievable throughput between two hosts.
• OWAMP / TWAMP: measure one-way delay and delay variation (jitter) with NTP/PTP synchronised clocks.

10.3 Network Tomography

Network tomography infers internal network parameters (link delays, link loss rates, topology) from end-to-end measurements that can only observe path aggregates. This is useful when internal network state is not directly observable (e.g., inferring link delays across an ISP from measurements made at customer endpoints).

For delay tomography, if the additive path delay \( d_p \) equals the sum of link delays along path \( p \):

then a system of such equations (one per measured path) can be inverted to recover individual link delays \( d_\ell \), provided the system is overdetermined and the paths are linearly independent in the link-path incidence matrix. In practice, statistical estimation (e.g., maximum likelihood or Bayesian methods) is used because measurements are noisy.

Chapter 11: Internet of Things

11.1 IoT Architecture and Constraints

The Internet of Things encompasses the networking of billions of constrained devices — sensors, actuators, meters, vehicles, wearables — that differ fundamentally from conventional hosts in their resource profile: limited CPU (8–32 MHz microcontrollers), small RAM (kilobytes to tens of kilobytes), limited storage, and operation from coin-cell batteries requiring multi-year lifetimes. These constraints motivate a distinct protocol stack different from the Internet’s standard TCP/IP suite.

The IETF’s 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) working group developed adaptations that allow IPv6 to run over IEEE 802.15.4 (ZigBee) radio links with 127-byte maximum frame sizes, achieved through header compression (IPHC) that reduces the 40-byte IPv6 header to as few as 2 bytes, and fragmentation/reassembly for IPv6’s 1280-byte minimum MTU.

11.2 Application Protocols

11.2.1 MQTT

MQTT (Message Queuing Telemetry Transport, ISO/IEC 20922) is a publish-subscribe protocol designed for constrained devices and unreliable networks. A broker decouples publishers from subscribers: publishers post messages to named topics (hierarchical, e.g., home/kitchen/temperature); subscribers register interest in topics using wildcard patterns (# matches any subtopic). The broker routes messages to matching subscribers. MQTT runs over TCP and provides three Quality-of-Service levels:

• QoS 0 (At most once): fire-and-forget, no acknowledgement.
• QoS 1 (At least once): acknowledged delivery, possible duplicates.
• QoS 2 (Exactly once): four-way handshake ensuring exactly one delivery.

The protocol overhead is extremely low: the fixed header is 2 bytes. MQTT over TLS (port 8883) provides security; MQTT over WebSockets (port 443) allows browser clients.

11.2.2 CoAP

CoAP (Constrained Application Protocol, RFC 7252) is a RESTful application protocol for constrained environments, analogous to HTTP but designed to run over UDP. CoAP supports GET, POST, PUT, and DELETE methods and 2-digit response codes (analogous to HTTP status codes). Reliability is provided optionally via Confirmable (CON) messages that require an ACK; Non-Confirmable (NON) messages are fire-and-forget. CoAP also supports Observe (RFC 7641), which allows a client to register for server-sent notifications on a resource, avoiding polling. The observe model is particularly efficient for sensor data streams.

CoAP is designed for integration with HTTP via simple proxying: a CoAP-to-HTTP proxy translates between the two protocols, allowing IoT devices to interact with web services without implementing a full HTTP stack.

11.2.3 LoRaWAN and LPWAN

LoRaWAN (Long Range Wide Area Network) is a media access control protocol layered on top of the LoRa physical layer (a spread-spectrum modulation technique based on chirp spread spectrum). LoRaWAN achieves ranges of 2–15 km in urban environments and up to 45 km line-of-sight, at the cost of very low data rates (250 bps – 50 kbps) and limited duty cycles. These properties make LoRaWAN suitable for applications such as smart metering, agriculture monitoring, and asset tracking.

LoRaWAN’s star topology routes all device transmissions through gateways (which forward raw packets to a network server over IP) rather than mesh routing, simplifying device MAC software. The network server performs join-server functions, deduplicates packets received from multiple gateways, and forwards application payloads to the application server.

ZigBee (IEEE 802.15.4 with ZigBee application layer) complements LoRaWAN: it operates at higher data rates (250 kbps), shorter range (10–100 m), and supports mesh topologies, making it suited for home automation and building management where many short-range devices form a dense network.

11.3 IoT Security Challenges

IoT devices present a dramatically expanded attack surface. Common vulnerabilities include default or weak credentials (the Mirai botnet compromised hundreds of thousands of cameras and routers with default passwords), unencrypted firmware updates (allowing over-the-air replacement with malicious firmware), and lack of memory protection enabling buffer overflow exploits. The resource constraints that prevent deploying full TLS stacks motivate lightweight alternatives such as DTLS (Datagram TLS, RFC 6347) for UDP-based protocols and OSCORE (Object Security for Constrained RESTful Environments, RFC 8613) for end-to-end security at the CoAP application layer.

Chapter 12: Multimedia Networking

12.1 Real-Time Multimedia Protocols

12.1.1 RTP and RTCP

The Real-time Transport Protocol (RTP, RFC 3550) provides the framing for real-time audio and video streams. RTP does not guarantee delivery or ordering — it runs over UDP — but it provides per-packet sequence numbers, timestamps, and source identification (SSRC). Receivers use the sequence numbers to detect loss and reordering, and the timestamps to reconstruct the original timing of the stream (driving the jitter buffer).

The RTP Control Protocol (RTCP) runs alongside RTP and carries QoS feedback. Sender Reports (SRs) carry NTP-synchronised timestamps (for inter-stream lip synchronisation) and sending statistics. Receiver Reports (RRs) carry fraction lost, cumulative lost, highest sequence received, and jitter estimates. RTCP bandwidth is limited to 5% of the media session bandwidth.

12.1.2 SIP

The Session Initiation Protocol (SIP, RFC 3261) is a text-based signalling protocol for establishing, modifying, and terminating multimedia sessions over IP. SIP borrows its message syntax and header structure from HTTP. The key message types (methods) are INVITE, ACK, BYE, CANCEL, REGISTER, and OPTIONS. SIP uses a trapezoidal architecture in which User Agents (UAs) communicate via SIP proxy servers and registrars. The actual media negotiation is carried in SDP (Session Description Protocol) bodies.

12.2 Adaptive Streaming

Modern video delivery over HTTP (DASH — Dynamic Adaptive Streaming over HTTP) encodes video at multiple quality levels and segments the stream into short chunks (typically 2–10 seconds). The client’s ABR (Adaptive Bitrate) algorithm continuously selects the quality level that best matches the current estimated throughput, keeping the playback buffer filled while avoiding rebuffering events. DASH places the adaptation logic entirely at the client, requiring no server-side state beyond a standard HTTP file server — a key deployment advantage.

Chapter 13: Network Layer Deep Dive — ICMP and Routing

13.1 ICMPv6

In IPv6, ICMPv6 (RFC 4443) assumes a far more central role than ICMP played in IPv4. In addition to error reporting (Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem), ICMPv6 includes the Neighbor Discovery Protocol (NDP) messages:

• Router Solicitation (RS, type 133): sent by hosts to discover routers.
• Router Advertisement (RA, type 134): sent by routers periodically and in response to RS, advertising the network prefix, default gateway, and MTU.
• Neighbor Solicitation (NS, type 135): equivalent to ARP Request, used to resolve IPv6 addresses to MAC addresses.
• Neighbor Advertisement (NA, type 136): response to NS, providing the MAC address.
• Redirect (type 137): informs a host of a better first-hop router.

NDP uses link-local multicast to avoid flooding: NS messages are sent to the Solicited-Node multicast address ff02::1:ff00:0/104 derived from the last 24 bits of the target address, so only a small fraction of hosts (typically one) need to process each NS.

Secure NDP (SEND, RFC 3971) uses Cryptographically Generated Addresses (CGAs) and RSA signatures on NDP messages to prevent spoofing and man-in-the-middle attacks, addressing a significant security weakness of ARP in IPv4.

13.2 Interior Routing Protocols

OSPF (Open Shortest Path First): a link-state protocol in which each router floods Link State Advertisements (LSAs) describing its directly connected links and their costs throughout the AS. Each router builds an identical link-state database and runs Dijkstra’s algorithm to compute shortest paths. OSPF supports hierarchical design through areas: the backbone area (area 0) connects to all other areas via Area Border Routers (ABRs), limiting LSA flooding scope and reducing database size.

IS-IS (Intermediate System to Intermediate System): a link-state protocol very similar to OSPF but uses its own PDU format rather than IP datagrams, making it suitable for multi-protocol environments. IS-IS is preferred by many large ISPs (including most tier-1 carriers) for its flexibility and rapid convergence.

Chapter 14: Research Projects and Advanced Topics

14.1 Project Methodology in Advanced Networking

ECE 416 culminates in a research project in which student teams select an advanced networking topic, survey the literature, conduct a technical investigation, and produce both a white paper and a presentation video. The project reflects the course’s emphasis on independent technical inquiry, which mirrors the research process in industry and academia.

A strong white paper for an advanced networking topic typically addresses:

1. Problem motivation: why does the problem matter? What are the limitations of existing approaches?
2. System/protocol design: the key architectural decisions and their rationale.
3. Performance analysis: analytical models, simulation results, or measurement data characterising the solution’s behaviour.
4. Security and operational considerations: threat model, failure modes, deployment challenges.
5. Open problems: what remains unsolved and why?

14.2 Network Neutrality and Internet Governance

Network neutrality is the principle that ISPs should treat all Internet traffic equally, without discrimination based on source, destination, application, or content. The policy debate turns on a set of technical and economic questions with engineering content:

• Traffic differentiation: deep packet inspection (DPI) enables ISPs to identify application types and apply differential QoS or throttling. At 100 Gbps line rates, DPI requires dedicated ASIC hardware.
• Zero-rating: exempting certain applications from data caps creates economic incentives that may distort competition among content providers.
• Last-mile monopoly: the concentration of broadband market power in many markets means end users may have limited recourse against discriminatory practices.

The debate is also a lens on the broader question of who controls the Internet’s evolution — a question spanning technical standards bodies (IETF, IEEE, 3GPP), government regulators (FCC in the US, BEREC in Europe), infrastructure operators, and civil society.

Sources and References

Primary textbook — James F. Kurose & Keith W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021. The definitive undergraduate reference covering all layers from application to physical; ECE 416 extends beyond the standard undergraduate treatment in SDN, 5G, and security.

Open-access supplementary texts — Larry Peterson & Bruce Davie, Computer Networks: A Systems Approach, 6th ed. (open at book.systemsapproach.org). Excellent treatment of SDN, programmable networks, and data centre networking. Nick Feamster, Jennifer Rexford & Zegura, “The Road to SDN: An Intellectual History of Programmable Networks,” ACM Queue 11(12), 2013 (open access).

IETF RFCs — RFC 8200 (IPv6), RFC 4271 (BGP-4), RFC 3550 (RTP/RTCP), RFC 3261 (SIP), RFC 9000 (QUIC), RFC 8446 (TLS 1.3), RFC 7252 (CoAP), RFC 3176 (sFlow), RFC 7011 (IPFIX/NetFlow v10). All publicly available at tools.ietf.org.

P4 language — The P4 Language Consortium, P4\(_{16}\) Language Specification (open at p4.org).

5G standards — 3GPP TS 23.501 (5G System Architecture), TS 38.300 (NR Overall Description). Publicly available at 3gpp.org.