Basics: Intro; network connectivity


Today we start with a claim that will organize much of the course: the Internet is unreasonably fast, and unreasonably reliable, given what it does. A message you send from Hanover, NH to Sydney, Australia is chopped into pieces, handed to a machine you don't own, forwarded a dozen times by machines no single entity controls, carried under an ocean, reassembled at the far end, and answered — all in about a fifth of a second. Nothing about that arrangement is obviously going to work, but it does. The rest of the term is an answer to the question "how does it work?", and, once we understand how it works, "how can it be attacked, and how do we defend it?"

Slides from class

Files:

Additional information:

Agenda

These notes cover the networking material for Day 1: how fast is the network and why, what the Internet actually is as a physical and economic object, how packets move through it, and how an individual host gets connected in the first place. Course policies, grading, and logistics are on the About page and are not repeated here.

Notes

How fast should the network be?

Before measuring anything, it is worth deciding what is reasonable. Suppose you are in Hanover, NH and you fetch a web page from a server in Sydney, Australia. The quantity we care about is the round trip time (RTT): the time for a message to travel to a remote host and for the reply to come back.

Start with the hard physical limit. The great-circle distance from Hanover to Sydney is roughly 16,150 km, so the round trip covers about 32,300 km. Nothing carrying information travels faster than light in vacuum, 299,792.458 km/sec. So:

one way = 16,150 km / 299,792.458 km/sec × 1000 ms/sec ≈ 53.9 ms
RTT = 2 × 53.9 ms ≈ 107.7 ms

That 107.7 ms is a fantasy number in two ways. First, it assumes a perfectly straight path around the earth, with no stops, no processing, no queueing, and no detours around continents. Second, it assumes light in vacuum. Real long-haul links are optical fiber, and light in glass travels roughly 30% slower than in vacuum, which pushes the honest physical floor to something closer to 161 ms. Keep both numbers in mind: they tell you that no amount of engineering will ever get a Hanover–Sydney RTT below about a sixth of a second. Speed of light is not a bug to be optimized away; it is a design constraint that shapes everything from the network's behavior to where companies build data centers.

Now let's measure. An actual round trip from a machine on the Dartmouth network to an Australian government web server came back in about 197 ms. Compare that to the fiber floor of ~154 ms and think about everything that happened inside the gap:

All of that overhead — every router, every queue, every protocol handshake, every lookup — costs about 36 ms total. That is why I call the Internet unreasonably fast. The interesting question is not "why is the network slow?" but "how on earth is it this close to the speed of light?"

Traceroute, hops, and routers

How do we know there were about a dozen forwarding steps? Traceroute is a program that reports each hop along the path from a source to a destination, where a hop is one router that handled your traffic. Run against an Australian government site, traceroute shows roughly 13 hops: your local gateway, your ISP's regional infrastructure, one or more large transit providers, a submarine cable crossing, and finally the destination network. Each line of output typically shows the hop number, the router's address and name, and the measured RTT to that router. (Dartmouth blocks traceroute from campus, so the example in class was run from a hosted tool.)

A router is a device that stores an incoming packet and forwards it onward toward its destination. In diagrams throughout this course I'll draw a router as a circle with arrows coming in and going out. In real life it is a rack-mounted box, usually in a data center or a network closet, with network cables plugged into a bank of ports. The abstraction and the hardware are worth keeping separate in your head, because the interesting behavior — queueing, dropping, choosing an outbound link — belongs to the abstraction, while a lot of the practical security surface belongs to the hardware and the room it's sitting in.

traceroute output is also the first thing in this course that doubles as a reconnaissance tool. The path to a target tells you who its providers are, where it is hosted, and often what the internal naming conventions look like. That information is useful to a network operator diagnosing a problem, and equally useful to an attacker mapping a target. This dual-use pattern will recur constantly throughout this course.

Content Delivery Networks

Now let's run traceroute on a different Australian site — a large Australian news site, say — from the northeastern United States. The path never leaves the New York City area. The destination is nominally Australian, but your packets stop after a few hops, well short of the Pacific.

The reason is a Content Delivery Network (CDN). Companies such as Akamai, Cloudflare, Google, and Amazon operate large fleets of servers distributed around the world that hold cached copies of other organizations' content. When you request that news site, you are directed to a nearby cache rather than to the origin server in Sydney. Since the physical distance is a hundredth of what it was, so is the propagation delay.

Notice what this does to the mental model you may have arrived with. "Going to an Australian website" does not necessarily mean sending packets to Australia. The name of a service, the company that owns it, and the physical location of the machine that answers you are three different things. CDNs are the first hint that the Internet's speed comes as much from clever placement of data as from fast links, and we will return to them when we cover network architecture.

New possibilities, new challenges

It is not just laptops and phones on the network. Estimates put roughly 19.8 billion devices on the Internet in 2025, with something like 29 billion projected by 2030, collectively exchanging on the order of 400 quintillion (4 × 1020) bytes per day. Much of that growth is the Internet of Things (IoT): pacemakers, refrigerators, thermostats, smart speakers, picture frames, security cameras, fitness trackers, mattresses, toasters, cars. If it has a power supply, someone has put computational capabilities and a radio in it.

Connecting things creates genuinely new capabilities. Consider implantable medical devices (IMDs) such as pacemakers. An implanted device cannot be plugged in to be reconfigured; surgery to reach it is dangerous; and yet the device genuinely needs to be reprogrammed as the patient's condition changes and as software is improved. Wireless communication between the implant and an external programmer solves a real problem that has no good wired solution. That is a good idea, and it saves lives.

Now consider the same design from an attacker's point of view. Imagine you are, years from now, a very important person — important enough to have acquired enemies, and stressed enough to have acquired a pacemaker. You're on stage giving a speech. Someone in the audience presses a button on a transmitter. If the pacemaker accepts commands without verifying who sent them, the adversary's command could be a command to shock the heart, or simply to run the battery down. The attacker walks out anonymously. Things don't end well for you.

This is not hypothetical in its essentials: early pacemaker generations did not authenticate the commands they accepted. (Dick Cheney's device was famously modified to disable wireless access while he was Vice President.) The general problem has since been addressed in the industry, but the lesson generalizes far past medical devices: do not trust a message just because it arrived. Anything that can be received, can received from an adversary. Once we understand how the network moves data, a large part of this course is devoted to authentication, confidentiality, and integrity — that is, to deciding when a message deserves to be trusted.

We will also study unintended networks: communication channels that exist whether or not anyone designed them. A laser microphone is a good example. Point a laser at a window pane from outside a building; sound inside the room vibrates the glass; those vibrations modulate the reflected laser beam; a photodetector receives the reflected modulated laser light and recovers the audio. Nobody installed a network, and yet the window is a communication medium carrying the conversation out of the room. Once you start looking for side channels like this — in power draw, in RF emissions, in timing, in Wi-Fi signal distortion — you find them everywhere, and defending against them requires thinking about the physical layer, not just the protocol stack. (Countermeasures for the laser microphone are worth thinking about before class: double-pane windows, curtains, deliberately vibrating the glass, planting trees to block line of sight.)

The scale of collected data raises its own concerns, which are usually summarized as the "five V's" of big data: volume (how much must be stored, and whether you scale vertically by getting a bigger machine or horizontally by getting more machines), velocity (how fast it must be processed, often as a stream rather than a batch), variety (structured data that fits a predefined model vs. unstructured data that doesn't), veracity (whether the data can be trusted), and value (whether anything useful can be extracted, often by correlating one dataset with another). That last point is where the privacy problems live: individually harmless datasets frequently become identifying when joined together.

What is the Internet, anyway?

The standard one-line answer is that the Internet is a network of networks. That phrasing is doing real work, so let's unpack it into three parts.

The network edge. At the edge are hosts: devices that run network applications and exchange data with each other. We usually divide hosts into clients (laptops, phones, tablets, IoT gadgets — things that initiate requests) and servers (often powerful machines in data centers — things that answer them). The distinction is about role in a conversation, not about hardware; your laptop can act as a server, and a powerful machine in data center can act as a client. Note also that routers and switches are not hosts in this vocabulary: hosts are the endpoints, the sources and sinks of data.

Access networks. A host has to get to the Internet somehow. Access networks provide that first connection, over wired links (Ethernet, fiber) or wireless links (Wi-Fi, cellular, LoRa for low-power long-range IoT). Access is normally sold to you by an Internet Service Provider (ISP), for a fee. There are, worldwide, on the order of hundreds of thousands of ISPs.

The network core. The Internet's core is a mesh of interconnected routers that carries traffic between access networks. This is where "network of networks" becomes literal: the core is not one organization's equipment but many independently owned networks that have agreed to carry each other's traffic.

Holding all of this together are protocols — agreed-upon rules for the format and ordering of messages and the actions taken on their receipt. The Internet Protocol (IP) and the Transmission Control Protocol (TCP) are the famous ones. What makes the Internet an Internet rather than a heap of unrelated networks is precisely that everyone has agreed on a common set of protocols, even when they agree on nothing else — not hardware, not business model, not jurisdiction, not who to trust.

Structure of the network core: ISPs, IXPs, and peering

Here is a design problem worth working through, because the answer explains the shape of the real Internet. Given many thousands of access ISPs, how should they be connected so that any host can reach any other host?

Attempt 1: connect every access ISP directly to every other one. This works, and it is immediately hopeless. Connecting N networks pairwise requires O(N2) links. With hundreds of thousands of access networks, that is tens of billions of physical connections, many of them intercontinental, most of them almost always idle. It doesn't scale.

Attempt 2: one global ISP in the middle. Connect each access ISP to a single global transit provider, which charges the access ISPs for connectivity. Now we need only O(N) links, and the economics are clear: whoever runs the global ISP gets paid by everyone. The trouble is that the global ISP must have a router physically near every access ISP on earth — every city, every country, every island. No single organization has ever had that reach, and building it would be extraordinarily costly.

Attempt 3: several global ISPs. If being the global ISP is profitable, competitors will appear. So instead of one provider we get several large ones — call them ISP A, ISP B, ISP C. But now the network is fragmented: a customer of A cannot reach a customer of B, which defeats the entire purpose. Competition is inevitable and fragmentation is unacceptable, so the providers must interconnect with each other.

What actually happened. The large providers connect to one another at Internet Exchange Points (IXPs): physical facilities, often in major cities, where many networks meet and exchange traffic. The links they establish there are peering links, and the arrangement is often settlement-free — each side carries the other's traffic without payment, on the theory that both benefit. There are roughly a dozen top-tier providers with global or near-global reach (Lumen, AT&T, NTT, Telia, Tata, GTT, and similar), conventionally called Tier-1 ISPs. Tier-1 networks are distinctive in that they can reach the entire Internet through peering alone; they don't buy transit from anyone.

Beneath them sit regional ISPs, which extend the Tier-1 providers' reach into particular countries or areas and sell transit to access ISPs, and above/alongside them sit content provider networks. Companies like Google, Microsoft, Meta, and Akamai have built their own private global backbones connecting their data centers, partly to control performance and cost, and partly to place CDN caches inside or adjacent to access networks so content sits a few milliseconds from users.

So the answer to "how are thousands of access ISPs connected?" is: hierarchically, commercially, and messily. Roughly a dozen Tier-1 providers, hundreds of thousands of lower-tier ISPs, regional providers filling gaps, content providers running their own networks, and IXPs stitching them together. Coverage is uneven — some networks span continents and oceans, others cover one metropolitan area. There is no central authority and no master map. The structure you see is the accumulated result of engineering constraints and business negotiations, which is why so much of Internet routing (BGP, later in the term) is really about expressing policy rather than finding shortest paths.

Packet switching: store and forward, queueing, and loss

Your message does not travel across that structure as a single unit. It is broken into pieces called packets, and each packet is forwarded independently. Two packets from the same message may take entirely different routes. Some may be delayed; some may be lost outright. At the destination, the pieces are reassembled — and, importantly, they may arrive out of order, so "reassembled" involves real work. This design is called packet switching.

Why would packets get delayed or lost? Answering that requires looking at what a router actually does with a packet.

Store and forward. A router receives an entire packet before it begins transmitting that packet onto the next link. If a packet is L bits and the outbound link runs at R bits per second, pushing the packet onto the link takes L/R seconds — the transmission delay. For example, with L = 10 Kb and R = 100 Mbps:

transmission delay = 10,000 bits / 100,000,000 bits/sec = 0.0001 sec = 0.1 ms per hop

That is small, but it is paid at every hop, and it is only one of several delay components. Propagation delay (distance divided by signal speed, which is what produced the 161 ms floor above), processing delay, and queueing delay all add on top.

Queueing. Routers have multiple input links and multiple output links, and those links generally do not run at the same speed. Suppose hosts A and B are sending toward hosts D and E through a router whose input link runs at 100 Mb/s but whose relevant output link runs at only 1.5 Mb/s. Packets arrive faster than they can be sent out, so the router holds them in a buffer — a queue — waiting for the output link. Queueing occurs whenever work arrives faster than it can be serviced, which is the same phenomenon as a line at a coffee shop, and it obeys the same intuitions: as the arrival rate approaches the service rate, the wait grows sharply.

Loss. Buffers are finite. If the arrival rate exceeds the output link's transmission rate for long enough, the buffer fills, and a router with a full buffer has no choice but to drop packets. Packet loss is not primarily a symptom of broken equipment; it is the normal, expected consequence of congestion in a network that shares links among many senders. This is why we need protocols that detect loss, retransmit, and slow senders down — reliable data transfer and congestion control, both of which get substantial attention later in the course.

Circuit switching, and how it compares

Packet switching is not the only option, and historically it wasn't the first choice. In circuit switching, end-to-end resources are allocated to and reserved for a "call" between source and destination before any data flows. Picture each link as carrying, say, four circuits; setting up a call claims one circuit on each link along the path — perhaps the second circuit on one link and the first on the next. Those resources belong to that call for its duration, shared with no one.

The consequence is guaranteed, circuit-like performance: a constant rate, with no queueing and no congestion loss. The cost is that a reserved circuit sits idle whenever the call isn't actively sending, and that capacity cannot be used by anyone else. Traditional telephone networks were built this way, which makes sense for voice, where a conversation sends more or less continuously for its whole duration.

Circuits are typically divided up in one of two ways. Frequency Division Multiplexing (FDM) splits the available frequency range into narrow bands and gives each call its own band; the call transmits continuously at the maximum rate of that narrow band. Time Division Multiplexing (TDM) instead divides time into slots and lets each call transmit only during its assigned slots, using the full frequency range while it does. Four users on an FDM link occupy four stacked frequency strips across all time; four users on a TDM link occupy the whole band during every fourth slot.

So why did the Internet choose packets? Because computer traffic is bursty: a host has a lot to send, then nothing for a while, then a lot again. Reserving a circuit for a bursty sender wastes most of the reserved capacity. Packet switching lets many bursty senders share the same links, so it supports far more users on the same infrastructure, and it needs no call setup, which makes it simpler and faster to start using. The price is exactly what we saw above: without reservations, congestion is possible, packets can be delayed and lost, and we are obliged to build protocols for reliable transfer and congestion control on top.

That leaves a natural question, which will occupy us on and off all term: how do you get circuit-like guarantees out of a packet-switched network? The honest short answer is that it's complicated. We'll look at several techniques that try to make packet switching behave as circuit-like as possible.

Forwarding vs. routing

Two core functions of the network are often confused with each other, so it is worth separating them now (the Internet does both).

Forwarding is a local action. When a packet arrives, the router reads a value from the packet's header, looks it up in a local forwarding table, and moves the packet to the appropriate output link. The table is just a mapping from header values to output links: header value 0100 goes out link 3, 0101 out link 2, 0111 out link 2, 1001 out link 1. A packet arriving with 0111 in its header goes out link 2. Nothing about this decision requires knowing anything about the rest of the world; it happens per packet, at line rate, in hardware.

Routing is a global action. It is the process of determining the paths packets will take across the network — which is to say, it is the process of computing the contents of all those forwarding tables. Routing runs as an algorithm among routers exchanging information with each other: OSPF within a single organization's network, BGP between the autonomous networks that make up the Internet.

The short version: routing decides the paths; forwarding walks a packet one step along them. When you hear "the routing algorithm determines the forwarding table," that sentence is the whole relationship.

How hosts connect: NICs, MAC addresses, and IP addresses

Zoom all the way back in to a single device. A given host often has several ways to reach other computers, and may use more than one at once:

Each of those connections is controlled by a Network Interface Card (NIC). Desktops, servers, and networking gear typically have wired NICs; a phone or tablet has no choice but to be wireless. A laptop usually has both. Modern wireless NICs have multiple antennas, which enables beamforming — shaping the transmitted radio energy so that it is directed toward a particular receiver rather than radiated uniformly.

Every NIC has a unique 48-bit Media Access Control (MAC) address, written as six hex octets, e.g. 5C:E9:1E:AA:BB:CC. A MAC address is burned into the interface and normally does not change. Two identical devices — two of the same model of phone — have different MAC addresses, so the address identifies that specific interface. We will later call this Layer 2 addressing.

The first three octets of a MAC address are the Organizationally Unique Identifier (OUI), assigned by the IEEE to the manufacturer; 5C:E9:1E belongs to Apple. Wireshark and various web tools will look up an OUI and tell you who made the interface. This is handy for network troubleshooting, and it is also a small intelligence leak: the first half of an address you overhear may tell you what kind of device you is transmitting.

Once a device is connected to a network it also gets an IP address, e.g. 123.123.123.123. Unlike a MAC address, an IP address depends on where the device is attached, and changes when the device moves to a different network. We will later call this Layer 3 addressing. Two addressing schemes with different scopes and different lifetimes is not redundancy — it's the mechanism that lets a globally routed network sit on top of many local ones, and reconciling the two is what ARP does (next class).

A question to sit with before class: if every device carries a unique, unchanging MAC address, and wireless devices announce themselves over the air as they move around, what are the privacy and security consequences? Who could learn what about you, and from how far away? (Modern phones do something about this, and we'll discuss what and why.)

LANs: hubs, switches, routers, and access points

Devices are grouped into Local Area Networks (LANs): networks connecting computers and devices within a limited geographic area such as a home, a floor of an office building, or a school. LANs are characterized by small geographic extent, high data rates, Ethernet or Wi-Fi as the usual technology, and private ownership and management.

Four kinds of device tie a LAN together. They are easy to conflate, and telling them apart is largely a matter of asking what address does this thing use to make decisions?

Hubs (Layer 1)

A hub is the most basic connecting device. Its behavior is simple: whatever arrives on one port is broadcast out every other port, regardless of who it was addressed to. Suppose host BB:BB:... wants to send to host AA:AA:.... The message arrives at the hub carrying the destination MAC address in its header, and the hub repeats it to every connected device. Each device inspects the destination MAC: AA:AA:... sees its own address and processes the message, while CC:CC:... sees an address that isn't its and discards it.

Two things follow. First, this is wasteful: every transmission consumes capacity on every port, and simultaneous transmissions collide. Hubs operate at the physical layer (Layer 1) and are simple and cheap, but they are inefficient enough that they've largely disappeared, surviving mainly in very small or old setups, or where someone needed to fan one connection out into several ports. Second — and this matters for the rest of the course — on a hub, every device sees every packet. Discarding a packet not addressed to you is a politeness, not a security boundary. A host can simply choose not to discard it. That behavior is promiscuous-mode packet sniffing, and it is why hubs are a security disaster and why they show up so often in lab exercises.

Switches (Layer 2)

A switch is the modern replacement and is considerably more intelligent. It examines the destination MAC address of each incoming frame and forwards it out only the one port where that address lives. When BB:BB:... sends to AA:AA:..., the switch delivers the frame only to AA:AA:... and nowhere else; CC:CC:... never sees it (unlike a hub where CC:CC:... would see it).

Switches operate at the data link layer (Layer 2), and are more complex than hubs but less complex than routers. Because each port becomes its own collision domain, different pairs of devices can communicate simultaneously without interfering, so throughput improves dramatically. Switches have largely replaced hubs and are what you find in essentially every modern home and office LAN. Note also the security improvement: a host on a switched network does not passively see its neighbors' traffic. (Which naturally raises the question of whether an attacker can convince a switch to send them that traffic anyway. They often can — hold that thought until we reach ARP spoofing in Lab 1.)

Routers (Layer 3)

A router connects networks to each other — your home LAN to the Internet, or one campus LAN to another. It operates at the network layer (Layer 3) and forwards packets based on IP addresses rather than MAC addresses. Picture two enterprise LANs, one using addresses like 111.0.0.2, 111.0.0.3, 111.0.0.4 and the other using 222.0.1.2, 222.0.1.3, 222.0.1.4, each LAN built from switches, with a router joining the two and connecting both onward to the Internet.

Routers are more complex than either hubs or switches, and typically provide services beyond forwarding: Network Address Translation (NAT), which lets many devices on a local network share a single public IP address; firewalling; and DHCP (Dynamic Host Configuration Protocol), which is how devices on a LAN normally get their IP addresses in the first place. DHCP is coming up soon.

Wireless access points (Layer 2/3)

A Wireless Access Point (AP) connects devices over radio instead of cable, usually within a building or campus, and commonly also acts as a router giving those devices Internet access. APs operate at Layers 2 and 3, buy you mobility and trivial installation, but cost you exposure to radio interference.

They also cost you the property that made switches attractive. An AP broadcasts over the air, so any device within radio range can hear the transmission — making an AP, in this specific respect, much more like a hub than like a switch. Wireless security therefore has to be achieved by cryptography rather than by physical isolation, because you cannot stop the signal at the property line.

From LANs to WANs

LANs handle local connectivity. To span larger distances, multiple LANs are joined into a Wide Area Network (WAN). WANs are what connect organizations that exist in more than one place: a business with branch offices, a university with multiple campuses, a government agency with regional offices. They enable communication, data sharing, and access to centralized resources across those sites.

The Internet is the world's largest WAN. Which means the structure we spent the middle of this page on — access networks, regional ISPs, Tier-1 providers, IXPs — and the structure we just covered — NICs, switches, routers, APs — are the same story told at two different scales.

Following one cable out of the building

It's worth walking the whole path once, concretely, from a wall jack to the Internet. The following traces my office in ECSC. It is illustrative — I don't know exactly how Dartmouth's cables actually run, this is my reconstruction — but the pattern is standard in commercial buildings and it will let you build an accurate mental picture.

  1. The wall jack. My office has a network jack in the wall. I plug a patch cable from my computer's NIC into the jack, and I have connectivity.
  2. The cable in the wall. Behind the jack, a cable runs through the wall and ceiling to a room elsewhere on the floor called an Intermediate Distribution Facility (IDF) — also known as the computer room, telephone room, or network closet, depending on who you ask and how old the building is. Cables from every office on the floor converge there.
  3. The patch panel. In the IDF, my office's cable terminates on the back of a patch panel: a rack-mounted row of jacks (normally 24 or 48 of them), each one wired to a specific location in the building. The panel's job is to turn permanent in-wall wiring into something a technician can rearrange with a short cable.
  4. Patch cables to the switch. Short patch cables run from the front of the patch panel to ports on a switch in the same rack. So the physical chain is: my NIC → wall jack → in-wall cable → back of patch panel → front of patch panel → switch port. A large floor will have several patch panels and several switches.
  5. The rack. IDF equipment lives in a rack, which holds patch panels, switches, routers, servers, and a Uninterruptible Power Supplies (UPS; batteries). Racks are measured in rack units, where 1U = 1.75 inches; a full rack is 42U. Switches, routers, and servers are commonly 1U (a "pizza box"), 2U, or 4U. Two pieces of practical advice: put the lightweight patch panel near the top, and put heavy equipment like the UPS at the bottom. (Why? Think about the center of gravity of a 6-foot cabinet, and about what happens to your back.)
  6. Up the hierarchy. IDFs connect onward to a Main Distribution Facility (MDF) or a data center, where many racks are aggregated.
  7. LANs and a router. The switches in the CS department's IDFs are connected together into a LAN. Thayer's switches, in their own IDFs, form a separate LAN. A router joins the CS LAN and the Thayer LAN to each other and to the Internet — exactly the two-LAN picture from the router section above, with real buildings in place of the abstract clouds.

Every abstraction in this course sits on top of that chain. When we later say "the packet is forwarded to the next hop," there is a specific patch cable, in a specific closet, that the bits physically traverse. When we discuss physical security, that closet's door is part of the threat model.

Exercises

To do before/around the next class:

Terms

Not a comprehensive reference — the textbook has much more — but these are the terms from Day 1 that will keep coming back.

round trip time (RTT)
The time for a message to travel to a remote host and for a reply to return. Bounded below by propagation delay, which is bounded below by the speed of light in the transmission medium (about 30% slower in fiber than in vacuum).
hop
One router along the path from source to destination. traceroute reports the hops on a path.
host
An end device that runs network applications: a client (laptop, phone, IoT device) or a server (typically in a data center). Routers and switches are not hosts.
protocol
An agreed set of rules governing the format and order of messages exchanged between entities, and the actions taken on transmission and receipt. IP and TCP are the canonical examples.
ISP (Internet Service Provider)
An organization that provides Internet access, normally for a fee. Access ISPs connect hosts; regional ISPs aggregate access ISPs; Tier-1 ISPs have global reach and can reach the whole Internet through peering alone.
IXP (Internet Exchange Point)
A physical facility where many networks interconnect to exchange traffic, avoiding the need for direct links between every pair of networks.
peering link
A direct interconnection between two networks for exchanging traffic, often settlement-free (neither party pays the other).
CDN (Content Delivery Network)
A distributed fleet of servers holding cached copies of content near users, reducing distance and therefore latency. Google, Microsoft, Akamai, Cloudflare, and Amazon run large ones.
packet
A piece of a message, forwarded independently through the network. Different packets from one message may take different routes, arrive out of order, be delayed, or be lost.
packet switching
Forwarding independent packets hop by hop with no advance reservation of resources. Efficient for bursty traffic and requires no call setup, but admits congestion, delay, and loss.
store and forward
A router receives an entire packet before beginning to transmit it on the next link.
transmission delay
L/R seconds to push an L-bit packet onto a link of rate R bps. E.g. 10 Kbits over 100 Mbps takes 0.1 ms.
queueing / buffering
Packets wait in a router's buffer when they arrive faster than the output link can serve them. Queueing occurs whenever work arrives faster than it can be serviced.
packet loss
Packets dropped when a router's buffer fills. A normal consequence of congestion, not necessarily of malfunction.
circuit switching
End-to-end resources are reserved for a call before data flows, giving guaranteed performance but leaving reserved capacity idle when unused. Used in traditional telephone networks.
FDM / TDM
Frequency Division Multiplexing gives each call its own narrow frequency band for all time; Time Division Multiplexing gives each call the full band during its assigned time slots.
forwarding
A local, per-packet action: look up a header value in the local forwarding table and move the packet to the corresponding output link.
routing
A global action: determine the paths packets take, i.e. compute the forwarding tables. Implemented by routing algorithms such as OSPF (within a network) and BGP (between networks).
NIC (Network Interface Card)
The hardware controlling one connection to a network, wired or wireless. A host may have several.
MAC address
A 48-bit identifier unique to a NIC, e.g. 5C:E9:1E:AA:BB:CC. Normally fixed for the life of the interface. Layer 2.
OUI (Organizationally Unique Identifier)
The first three octets of a MAC address, assigned by the IEEE, identifying the NIC's manufacturer.
IP address
An address such as 123.123.123.123 identifying a host's attachment point to a network. Changes as the device moves between networks. Layer 3.
LAN (Local Area Network)
A privately owned network covering a limited area (home, floor, building), typically Ethernet or Wi-Fi, with high data rates.
WAN (Wide Area Network)
A network joining LANs across large distances. The Internet is the largest one.
hub
A Layer 1 device that broadcasts incoming data out every port. Simple, cheap, inefficient, and lets every attached device see all traffic. Largely obsolete.
switch
A Layer 2 device that forwards frames only out the port where the destination MAC address lives, creating multiple collision domains and allowing simultaneous conversations.
router
A Layer 3 device that connects networks and forwards packets based on IP addresses. Often also provides NAT, firewalling, and DHCP.
access point (AP)
A device connecting hosts wirelessly, often also routing to the Internet. Because it broadcasts over the air, every device in radio range can hear it — hub-like in that respect.
NAT (Network Address Translation)
Letting multiple devices on a local network share one public IP address.
DHCP (Dynamic Host Configuration Protocol)
The protocol by which a device is assigned an IP address (and related configuration) on joining a network.
IDF / MDF
Intermediate Distribution Facility: the floor- or area-level network closet where building cabling terminates on patch panels and connects to switches. Main Distribution Facility: the building- or campus-level aggregation point that IDFs feed into.
patch panel
A rack-mounted array of jacks; permanent in-wall cables terminate on the back, short patch cables run from the front to switch ports.
rack unit (U)
1.75 inches of vertical rack space. A full rack is 42U; typical switches and servers are 1U, 2U, or 4U.
IoT (Internet of Things)
Networked devices other than conventional computers — medical implants, appliances, cameras, wearables. Expands what's possible and expands the attack surface.

Credit: Most information on this page is from Computer Networking: A Top-Down Approach, 9th edition by Kurose and Ross.
This page was generated by Claude from in-class slides.