Module 1
Computer Networks and the Internet
a. What Is the Internet?
There are a couple of ways to answer this question. First, we can describe the nuts
and bolts of the Internet, that is, the basic hardware and software components that make
up the Internet. Second, we can describe the Internet in terms of a networking
infrastructure that provides services to distributed applications.
The Internet is a computer network that interconnects billions of computing
devices throughout the world. Not too long ago, these computing devices were primarily
traditional desktop computers, Linux workstations, and so-called servers that store and
transmit information such as Web pages and e-mail messages. Increasingly, however,
users connect to the Internet with smartphones and tablets—today, close to half of the
world’s population are active mobile Internet users with the percentage expected to
increase to 75% by 2025 [Statista 2019]. Furthermore, nontraditional Internet “things”
such as TVs, gaming consoles, thermostats, home security systems, home appliances,
watches, eye glasses, cars, traffic control systems, and more are being connected to the
Internet. Indeed, the term computer network is beginning to sound a bit dated, given the
many nontraditional devices that are being hooked up to the Internet. In Internet jargon,
all of these devices are called hosts or end systems. By some estimates, there were about
18 billion devices connected to the Internet in 2017, and the number will reach 28.5
billion by 2022 [Cisco VNI 2020].
End systems are connected together by a network of communication links and
packet switches. We’ll see in Section 1.2 that there are many types of communication
links, which are made up of different types of physical media, including coaxial cable,
copper wire, optical fiber, and radio spectrum. Different links can transmit data at
different rates, with the transmission rate of a link measured in bits/second. When one
end system has data to send to another end system, the sending end system segments the
data and adds header bytes to each segment. The resulting packages of information,
known as packets in the jargon of computer networks, are then sent through the network
to the destination end system, where they are reassembled into the original data.
A packet switch takes a packet arriving on one of its incoming communication
links and forwards that packet on one of its outgoing communication links. Packet
switches come in many shapes and flavors, but the two most prominent types in today’s
Internet are routers and link-layer switches. Both types of switches forward packets
toward their ultimate destinations. Link-layer switches are typically used in access
networks, while routers are typically used in the network core. The sequence of
communication links and packet switches traversed by a packet from the sending end
system to the receiving end system is known as a route or path through the network.
Cisco predicts annual global IP traffic will reach nearly five zettabytes (1021 bytes) by
2022 [Cisco VNI 2020].
Packet-switched networks (which transport packets) are in many ways similar to
transportation networks of highways, roads, and intersections (which transport vehicles).
Consider, for example, a factory that needs to move a large amount of cargo to some
destination warehouse located thousands of kilometers away. At the factory, the cargo is
segmented and loaded into a fleet of trucks. Each of the trucks then independently travels
through the network of highways, roads, and intersections to the destination warehouse.
At the destination warehouse, the cargo is unloaded and grouped with the rest of the
cargo arriving from the same shipment. Thus, in many ways, packets are analogous to
trucks, communication links are analogous to highways and roads, packet switches are
analogous to intersections, and end systems are analogous to buildings. Just as a truck
takes a path through the transportation network, a packet takes a path through a computer
network.
End systems access the Internet through Internet Service Providers (ISPs),
including residential ISPs such as local cable or telephone companies; corporate ISPs;
university ISPs; ISPs that provide WiFi access in airports, hotels, coffee shops, and other
public places; and cellular data ISPs, providing mobile access to our smartphones and
other devices. Each ISP is in itself a network of packet switches and communication
links. ISPs provide a variety of types of network access to the end systems, including
residential broadband access such as cable modem or DSL, high-speed local area network
access, and mobile wireless access. ISPs also provide Internet access to content
providers, connecting servers directly to the Internet. The Internet is all about connecting
end systems to each other, so theISPs that provide access to end systems must also be
interconnected. These lowertier ISPs are thus interconnected through national and
international upper-tier ISPs and these upper-tier ISPs are connected directly to each
other. An upper-tier ISP consists of high-speed routers interconnected with high-speed
fiber-optic links. Each ISP network, whether upper-tier or lower-tier, is managed
independently, runs the IP protocol (see below), and conforms to certain naming and
address conventions.
End systems, packet switches, and other pieces of the Internet run protocols that
control the sending and receiving of information within the Internet. The Transmission
Control Protocol (TCP) and the Internet Protocol (IP) are two of the most important
protocols in the Internet. The IP protocol specifies the format of the packets that are sent
and received among routers and end systems. The Internet’s principal protocols are
collectively known as TCP/IP. We’ll begin looking into protocols in this introductory.
But that’s just a start—much of this book is concerned with networking protocols!
Given the importance of protocols to the Internet, it’s important that everyone
agree on what each and every protocol does, so that people can create systems and
products that interoperate. This is where standards come into play. Internet standards are
developed by the Internet Engineering Task Force (IETF) [IETF 2020]. The IETF
standards documents are called requests for comments (RFCs). RFCs started out as
general requests for comments (hence the name) to resolve network and protocol design
problems that faced the precursor to the Internet [Allman 2011]. RFCs tend to be quite
technical and detailed. They define protocols such as TCP, IP, HTTP (for the Web), and
SMTP (for e-mail). There are currently nearly 9000 RFCs. Other bodies also specify
standards for network components, most notably for network links. The IEEE 802 LAN
Standards Committee [IEEE 802 2020], for example, specifies the Ethernet and wireless
WiFi standards.
Our discussion above has identified many of the pieces that make up the Internet.
But we can also describe the Internet from an entirely different angle—namely, as an
infrastructure that provides services to applications. In addition to traditional applications
such as e-mail and Web surfing, Internet applications include mobile smartphone and
tablet applications, including Internet messaging, mapping with real-time road-traffic
information, music streaming movie and television streaming, online social media, video
conferencing, multi-person games, and location-based recommendation systems. The
applications are said to be distributed applications, since they involve multiple end
systems that exchange data with each other. Importantly, Internet applications run on end
systems—they do not run in the packet switches in the network core. Although packet
switches facilitate the exchange of data among end systems, they are not concerned with
the application that is the source or sink of data.
Let’s explore a little more what we mean by an infrastructure that provides
services to applications. To this end, suppose you have an exciting new idea for a
distributed Internet application, one that may greatly benefit humanity or one that may
simply make you rich and famous. How might you go about transforming this idea into
an actual Internet application? Because applications run on end systems, you are going to
need to write programs that run on the end systems. You might, for example, write your
programs in Java, C, or Python. Now, because you are developing a distributed Internet
application, the programs running on the different end systems will need to send data to
each other. And here we get to a central issue—one that leads to the alternative way of
describing the Internet as a platform for applications. How does one program running on
one end system instruct the Internet to deliver data to another program running on another
end system?
End systems attached to the Internet provide a socket interface that specifies how
a program running on one end system asks the Internet infrastructure to deliver data to a
specific destination program running on another end system. This Internet socket
interface is a set of rules that the sending program must follow so that the Internet can
deliver the data to the destination program. We’ll discuss the Internet socket interface in
detail. For now, let’s draw upon a simple analogy, one that we will frequently use in this
book. Suppose Alice wants to send a letter to Bob using the postal service. Alice, of
course, can’t just write the letter (the data) and drop the letter out her window. Instead,
the postal service requires that Alice put the letter in an envelope; write Bob’s full name,
address, and zip code in the center of the envelope; seal the envelope; put a stamp in the
upperright-hand corner of the envelope; and finally, drop the envelope into an official
postal service mailbox. Thus, the postal service has its own “postal service interface,” or
set of rules, that Alice must follow to have the postal service deliver her letter to Bob. In
a similar manner, the Internet has a socket interface that the program sending data must
follow to have the Internet deliver the data to the program that will receive the data.
The postal service, of course, provides more than one service to its customers. It
provides express delivery, reception confirmation, ordinary use, and many more services.
In a similar manner, the Internet provides multiple services to its applications. When you
develop an Internet application, you too must choose one of the Internet’s services for
your application.
We have just given two descriptions of the Internet; one in terms of its hardware
and software components, the other in terms of an infrastructure for providing services to
distributed applications. But perhaps you are still confused as to what the Internet is.
What are packet switching and TCP/IP? What are routers? What kinds of communication
links are present in the Internet? What is a distributed application? How can a thermostat
or body scale be attached to the Internet? If you feel a bit overwhelmed by all of this
now, don’t worry—the purpose of this book is to introduce you to both the nuts and bolts
of the Internet and the principles that govern how and why it works.
Now that we’ve got a bit of a feel for what the Internet is, let’s consider another
important buzzword in computer networking: protocol. What is a protocol? What does a
protocol do?
It is probably easiest to understand the notion of a computer network protocol by
first considering some human analogies, since we humans execute protocols all of the
time. Consider what you do when you want to ask someone for the time of day. A typical
exchange. Human protocol (or good manners, atleast) dictates that one first offer a
greeting to initiate communication with someone else. The typical response to a “Hi” is a
returned “Hi” message. Implicitly, one then takes a cordial “Hi” response as an indication
that one can proceed and ask for the time of day. A different response to the initial “Hi”
(such as “Don’t bother me!” or “I don’t speak English,” or some unprintable reply) might
indicate an unwillingness or inability to communicate. In this case, the human protocol
would be not to ask for the time of day. Sometimes one gets no response at all to a
question, in which case one typically gives up asking that person for the time. Note that
in our human protocol, there are specific messages we send, and specific actions we take
in response to the received reply messages or other events (such as no reply within some
given amount of time). Clearly, transmitted and received messages, and actions taken
when these messages are sent or received or other events occur, play a central role in a
human protocol. If people run different protocols (for example, if one person has manners
but the other does not, or if one understands the concept of time and the other does not)
the protocols do not interoperate and no useful work can be accomplished. The same is
true in networking—it takes two (or more) communicating entities running the same
protocol in order to accomplish a task.
Let’s consider a second human analogy. Suppose you’re in a college class (a
computer networking class, for example!). The teacher is droning on about protocols and
you’re confused. The teacher stops to ask, “Are there any questions?” (a message that is
transmitted to, and received by, all students who are not sleeping). You raise your hand
(transmitting an implicit message to the teacher). Your teacher acknowledges you with a
smile, saying “Yes . . .” (a transmitted message encouraging you to ask your question—
teachers love to be asked questions), and you then ask your question (that is, transmit
your message to your teacher). Your teacher hears your question (receives your question
message) and answers (transmits a reply to you). Once again, we see that the transmission
and receipt of messages, and a set of conventional actions taken when these messages are
sent and received, are at the heart of this question-and-answer protocol.
A network protocol is similar to a human protocol, except that the entities
exchanging messages and taking actions are hardware or software components of some
device (for example, computer, smartphone, tablet, router, or other network-capable
device). All activity in the Internet that involves two or more communicating remote
entities is governed by a protocol. For example, hardware-implemented protocols in two
physically connected computers control the flow of bits on the “wire” between the two
network interface cards; congestion-control protocols in end systems control the rate at
which packets are transmitted between sender and receiver; protocols in routers
determine a packet’s path from source to destination. Protocols are runningeverywhere in
the Internet, and consequently much of this book is about computer network protocols.
As an example of a computer network protocol with which you are probably
familiar, consider what happens when you make a request to a Web server, that is, when
you type the URL of a Web page into your Web browser. The scenario is illustrated in
the right half. First, your computer will send a connection request message to the Web
server and wait for a reply. The Web server will eventually receive your connection
request message and return a connection reply message. Knowing that it is now OK to
request the Web document, your computer then sends the name of the Web page it wants
to fetch from that Web server in a GET message. Finally, the Web server returns the Web
page (file) to your computer.
The Internet, and computer networks in general, make extensive use of protocols.
Different protocols are used to accomplish different communication tasks. As you read
through this book, you will learn that some protocols are simple and straightforward,
while others are complex and intellectually deep. Mastering the field of computer
networking is equivalent to understanding the what, why, and how of networking
protocols.
b. The Network Edge
In the previous section, we presented a high-level overview of the Internet and
networking protocols. We are now going to delve a bit more deeply into the components
of the Internet. We begin in this section at the edge of the network and look at the
components with which we are most familiar—namely, the computers, smartphones and
other devices that we use on a daily basis. In the next section, we’ll move from the
network edge to the network core and examine switching and routing in computer
networks.
Recall from the previous section that in computer networking jargon, the
computers and other devices connected to the Internet are often referred to as end
systems. They are referred to as end systems because they sit at the edge of the Internet.
The Internet’s end systems include desktop computers(e.g., desktop PCs, Macs, and
Linux boxes), servers (e.g., Web and e-mail servers), and mobile devices (e.g., laptops,
smartphones, and tablets). Furthermore, an increasing number of non-traditional “things”
are being attached to the Internet as end systems (see the Case History feature).
End systems are also referred to as hosts because they host (that is, run)
application programs such as a Web browser program, a Web server program, an e-
mailclient program, or an e-mail server program. Throughout this book we will use the
terms hosts and end systems interchangeably; that is, host = end system. Hosts are
sometimes further divided into two categories: clients and servers. Informally, clients
tend to be desktops, laptops, smartphones, and so on, whereas servers tend to be more
powerful machines that store and distribute Web pages, stream video, relay e-mail, and so
on. Today, most of the servers from which we receive search results, e-mail, Web pages,
videos and mobile app content reside in large data centers. For example, as of 2020,
Google has 19 data centers on four continents, collectively containing several million
servers includes two such data centers, and the Case History sidebar describes data
centers in more detail.
Having considered the applications and end systems at the “edge of the network,”
let’s next consider the access network—the network that physically connects an end
system to the first router (also known as the “edge router”) on a path from the end system
to any other distant end system several types of access networks with thick, shaded lines
and the settings (home, enterprise, and wide-area mobile wireless) in which they are used.
As of 2020, more than 80% of the households in Europe and the USA have
Internet access [Statista 2019]. Given this widespread use of home access networks let’s
begin our overview of access networks by considering how homes connect to the
Internet.
Today, the two most prevalent types of broadband residential access are digital
subscriber line (DSL) and cable. A residence typically obtains DSL Internet access from
the same local telephone company (telco) that provides its wired local phone access.
Thus, when DSL is used, a customer’s telco is also its ISP each customer’s DSL modem
uses the existing telephone line exchange data with a digital subscriber line access
multiplexer (DSLAM) located in the telco’s local central office (CO). The home’s DSL
modem takes digital data and translates it to high-frequency tones for transmission over
telephone wires to the CO; the analog signals from many such houses are translated back
into digital format at the DSLAM.
The DSL standards define multiple transmission rates, including downstream
transmission rates of 24 Mbs and 52 Mbs, and upstream rates of 3.5 Mbps and 16 Mbps;
the newest standard provides for aggregate upstream plus downstream rates of 1 Gbps
[ITU 2014]. Because the downstream and upstream rates are different, the access is said
to be asymmetric. The actual downstream and upstream transmission rates achieved may
be less than the rates noted above, as the DSL provider may purposefully limit a
residential rate when tiered service (different rates, available at different prices) are
offered. The maximum rate is also limited by the distance between the home and the CO,
the gauge of the twisted-pair line and the degree of electrical interference. Engineers have
expressly designed DSL for short distances between the home and the CO; generally, if
the residence is not located within 5 to 10 miles of the CO, the residence must resort to an
alternative form of Internet access.
While DSL makes use of the telco’s existing local telephone infrastructure, cable
Internet access makes use of the cable television company’s existing cable television
infrastructure. A residence obtains cable Internet access from the same company that
provides its cable television. Fiber optics connect the cable head end to neighborhood-
level junctions, from which traditional coaxial cable is then used to reach individual
houses and apartments. Each neighborhood junction typically supports 500 to 5,000
homes. Because both fiber and coaxial cable are employed in this system, it is often
referred to as hybrid fiber coax (HFC).
Cable internet access requires special modems, called cable modems. As with a
DSL modem, the cable modem is typically an external device and connects to the home
PC through an Ethernet port. At the cable head end, the cable modem termination system
(CMTS) serves a similar function as the DSL network’s DSLAM— turning the analog
signal sent from the cable modems in many downstream homes back into digital format.
Cable modems divide the HFC network into two channels, a downstream and an
upstream channel. As with DSL, access is typically asymmetric, with the downstream
channel typically allocated a higher transmission rate than the upstream channel. The
DOCSIS 2.0 and 3.0 standards define downstream bitrates of 40 Mbps and 1.2 Gbps, and
upstream rates of 30 Mbps and 100 Mbps, respectively. As in the case of DSL networks,
the maximum achievable rate may not be realized due to lower contracted data rates or
media impairments.
One important characteristic of cable Internet access is that it is a shared
broadcast medium. In particular, every packet sent by the head end travels downstream
on every link to every home and every packet sent by a home travels on the upstream
channel to the head end. For this reason, if several users are simultaneously downloading
a video file on the downstream channel, the actual rate at which each user receives its
video file will be significantly lower than the aggregate cable downstream rate. On the
other hand, if there are only a few active users and they are all Web surfing, then each of
the users may actually receive Web pages at the full cable downstream rate, because the
users will rarely request a Web page at exactly the same time. Because the upstream
channel is also shared, a distributed multiple access protocol is needed to coordinate
transmissions and avoid collisions.
Although DSL and cable networks currently represent the majority of residential
broadband access in the United States, an up-and-coming technology that provides even
higher speeds is fiber to the home (FTTH) [Fiber Broadband 2020]. As the name
suggests, the FTTH concept is simple—provide an optical fiber path from the CO directly
to the home. FTTH can potentially provide Internet access rates in the gigabits per second
range.
There are several competing technologies for optical distribution from the CO to
the homes. The simplest optical distribution network is called direct fiber, with one fiber
leaving the CO for each home. More commonly, each fiber leaving the central office is
actually shared by many homes; it is not until the fiber gets relatively close to the homes
that it is split into individual customer-specific fibers. There are two competing optical-
distribution network architectures that performthis splitting: active optical networks
(AONs) and passive optical networks (PONs). AON is essentially switched Ethernet.
Here, we briefly discuss PON, which is used in Verizon’s FiOS service shows
FTTH using the PON distribution architecture. Each home has an optical network
terminator (ONT), which is connected by dedicated optical fiber to a neighborhood
splitter. The splitter combines a number of homes (typically less than 100) onto a single,
shared optical fiber, which connects to an optical line terminator (OLT) in the telco’s CO.
The OLT, providing conversion between optical and electrical signals, connects to the
Internet via a telco router. At home, users connect a home router (typically a wireless
router) to the ONT and access the Internet via this home router. In the PON architecture,
all packets sent from OLT to the splitter are replicated at the splitter (similar to a cable
head end).
In addition to DSL, Cable, and FTTH, 5G fixed wireless is beginning to be
deployed. 5G fixed wireless not only promises high-speed residential access, but will do
so without installing costly and failure-prone cabling from the telco’s CO to the home.
With 5G fixed wireless, using beam-forming technology, data is sent wirelessly from a
provider’s base station to the a modem in the home. A WiFi wireless router is connected
to the modem (possibly bundled together), similar to how a WiFi wireless router is
connected to a cable or DSL modem. 5G cellular networks.
On corporate and university campuses, and increasingly in home settings, a local
area network (LAN) is used to connect an end system to the edge router. Although there
are many types of LAN technologies, Ethernet is by far the most prevalent access
technology in corporate, university, and home networks. Ethernet users use twisted-pair
copper wire to connect to an Ethernet switch. The Ethernet switch, or a network of such
interconnected switches, is then in turn connected into the larger Internet. With Ethernet
access, users typically have 100 Mbps to tens of Gbps access to the Ethernet switch,
whereas servers may have 1 Gbps 10 Gbps access.
Increasingly, however, people are accessing the Internet wirelessly from laptops,
smartphones, tablets, and other “things”. In a wireless LAN setting, wireless users
transmit/receive packets to/from an access point that is connected into the enterprise’s
network (most likely using wired Ethernet), which in turn is connected to the wired
Internet. A wireless LAN user must typically be within a few tens of meters of the access
point. Wireless LAN access based on IEEE 802.11 technology, more colloquially known
as WiFi, is now just about everywhere—universities, business offices, cafes, airports,
homes, and even in airplanes.
Even though Ethernet and WiFi access networks were initially deployed in
enterprise (corporate, university) settings, they are also common components of home
networks. Many homes combine broadband residential access (that is, cable modems or
DSL) with these inexpensive wireless LAN technologies to create powerful home
networks shows a typical home network. This home network consists of a roaming
laptop, multiple Internet-connected home appliances, as well as a wired PC; a base
station (the wireless access point), which communicates with the wireless PC and other
wireless devices in the home; and a home router that connects the wireless access point,
and any other wired home devices, to the Internet. This network allows household
members to have broadband access to the Internet with one member roaming from the
kitchen to the backyard to the bedrooms.
Mobile devices such as iPhones and Android devices are being used to message,
share photos in social networks, make mobile payments, watch movies, stream music,
and much more while on the run. These devices employ the same wireless infrastructure
used for cellular telephony to send/receive packets through a base station that is operated
by the cellular network provider. Unlike WiFi, a user need only be within a few tens of
kilometers (as opposed to a few tens of meters) of the base station.
Telecommunications companies have made enormous investments in so-called
fourth-generation (4G) wireless, which provides real-world download speeds of up to 60
Mbps. But even higher-speed wide-area access technologies—a fifth-generation (5G) of
wide-area wireless networks—are already being deployed. We’ll cover the basic
principles of wireless networks and mobility, as well as WiFi, 4G and 5G technologies
(and more!)
In the previous subsection, we gave an overview of some of the most important
network access technologies in the Internet. As we described these technologies, we also
indicated the physical media used. For example, we said that HFC uses a combination of
fiber cable and coaxial cable. We said that DSL and Ethernet use copper wire. And we
said that mobile access networks use the radio spectrum. In this subsection, we provide a
brief overview of these and other transmission media that are commonly used in the
Internet.
In order to define what is meant by a physical medium, let us reflect on the brief
life of a bit. Consider a bit traveling from one end system, through a series of links and
routers, to another end system. This poor bit gets kicked around and transmitted many,
many times! The source end system first transmits thebit, and shortly thereafter the first
router in the series receives the bit; the first router then transmits the bit, and shortly
thereafter the second router receives the bit; and so on. Thus our bit, when traveling from
source to destination, passes through a series of transmitter-receiver pairs. For each
transmitter-receiver pair, the bit is sent by propagating electromagnetic waves or optical
pulses across a physical medium. The physical medium can take many shapes and forms
and does not have to be of the same type for each transmitter-receiver pair along the path.
Examples of physical media include twisted-pair copper wire, coaxial cable, multimode
fiber-optic cable, terrestrial radio spectrum, and satellite radio spectrum. Physical media
fall into two categories: guided media and unguided media. With guided media, the
waves are guided along a solid medium, such as a fiber-optic cable, a twisted-pair copper
wire, or a coaxial cable. With unguided media, the waves propagate in the atmosphere
and in outer space, such as in a wireless LAN or a digital satellite channel.
But before we get into the characteristics of the various media types, let us say a
few words about their costs. The actual cost of the physical link (copper wire, fiberoptic
cable, and so on) is often relatively minor compared with other networking costs. In
particular, the labor cost associated with the installation of the physical link can be orders
of magnitude higher than the cost of the material. For this reason, many builders install
twisted pair, optical fiber, and coaxial cable in every room in a building. Even if only one
medium is initially used, there is a good chance that another medium could be used in the
near future, and so money is saved by not having to lay additional wires in the future.
The least expensive and most commonly used guided transmission medium is
twisted-pair copper wire. For over a hundred years it has been used by telephone
networks. In fact, more than 99 percent of the wired connections from the telephone
handset to the local telephone switch use twisted-pair copper wire. Most of us have seen
twisted pair in our homes (or those of our parents or grandparents!) and work
environments. Twisted pair consists of two insulated copper wires, each about 1 mm
thick, arranged in a regular spiral pattern. The wires are twisted together to reduce the
electrical interference from similar pairs close by. Typically, a number of pairs are
bundled together in a cable by wrapping the pairs in a protective shield. A wire pair
constitutes a single communication link. Unshielded twisted pair (UTP) is commonly
used for computer networks within a building, that is, for LANs. Data rates for LANs
using twisted pair today range from 10 Mbps to 10 Gbps. The data rates that can be
achieved depend on the thickness of the wire and the distance between transmitter and
receiver.
When fiber-optic technology emerged in the 1980s, many people disparaged
twisted pair because of its relatively low bit rates. Some people even feltthat fiber-optic
technology would completely replace twisted pair. But twisted pair did not give up so
easily. Modern twisted-pair technology, such as category 6a cable, can achieve data rates
of 10 Gbps for distances up to a hundred meters. In the end, twisted pair has emerged as
the dominant solution for high-speed LAN networking.
As discussed earlier, twisted pair is also commonly used for residential Internet
access. We saw that dial-up modem technology enables access at rates of up to 56 kbps
over twisted pair. We also saw that DSL (digital subscriber line) technology has enabled
residential users to access the Internet at tens of Mbps over twisted pair (when users live
close to the ISP’s central office).
c. The Network Core
In a network application, end systems exchange messages with each other.
Messages can contain anything the application designer wants. Messages may perform a
control function (for example, the “Hi” messages in our handshaking example or can
contain data, such as an e-mail message, a JPEG image, or an MP3 audio file. To send a
message from a source end system to a destination end system, the source breaks long
messages into smaller chunks of data known as packets. Between source and destination,
each packet travels through communication links and packet switches (for which there
are two predominant types, routers and link-layer switches). Packets are transmitted over
each communication link at a rate equal to the full transmission rate of the link. So, if a
source end system or a packet switch is sending a packet of L bits over a link with
transmission rate R bits/sec, then the time to transmit the packet is L/R seconds.
Most packet switches use store-and-forward transmission at the inputs to the
links. Store-and-forward transmission means that the packet switch must receive the
entire packet before it can begin to transmit the first bit of the packet onto the outbound
link. To explore store-and-forward transmission in more detail, consider a simple
network consisting of two end systems connected by a single router. A router will
typically have many incident links, since its job is to switch an incoming packet onto an
outgoing link; in this simple example, the router has the rather simple task of transferring
a packet from one (input) link to the only other attached link. In this example, the source
has three packets, each consisting of L bits, to send to the destination. At the snapshot of
time, the source has transmitted some of packet 1, and the front of packet 1 has already
arrived at the router. Because the router employs store-and-forwarding, at this instant of
time, the router cannot transmit the bits it has received; instead it must first buffer (i.e.,
“store”) the packet’s bits. Only after the router has received all of the packet’s bits can it
begin to transmit (i.e., “forward”) the packet onto the outbound link.
To gain some insight into store-and-forward transmission, let’s now calculate the
amount of time that elapses from when the source begins to send the packet until the
destination has received the entire packet. (Here we will ignore propagation delay—the
time it takes for the bits to travel across the wire at near the speed of light—which will be
discussed in Section 1.4.) The source begins to transmit at time 0; at time L/R seconds,
the source has transmitted the entire packet, and the entire packet has been received and
stored at the router (since there is no propagation delay). At time L/R seconds, since the
router has just received the entire packet, it can begin to transmit the packet onto the
outbound link towards the destination; at time 2L/R, the router has transmitted the entire
packet, and the entire packet has been received by the destination. Thus, the total delay is
2L/R.
If the switch instead forwarded bits as soon as they arrive (without first receiving
the entire packet), then the total delay would be L/R since bits are not held up at the
router. But, as we will discuss in Section 1.4, routers need to receive, store, and process
the entire packet before forwarding.
Now let’s calculate the amount of time that elapses from when the source begins
to send the first packet until the destination has received all three packets. As before, at
time L/R, the router begins to forward the first packet. But also at time L/R the source
will begin to send the second packet, since it has just finished sending the entire first
packet. Thus, at time 2L/R, the destination has received the first packet and the router has
received the second packet. Similarly, at time 3L/R, the destination has received the first
two packets and the router has received the third packet. Finally, at time 4L/R the
destination has received all three packets!
Each packet switch has multiple links attached to it. For each attached link, the
packet switch has an output buffer (also called an output queue), which stores packets
that the router is about to send into that link. The output buffers play a key role in packet
switching. If an arriving packet needs to be transmitted onto a link but finds the link busy
with the transmission of another packet, the arriving packet must wait in the output
buffer. Thus, in addition to the store-and-forward delays, packets suffer output buffer
queuing delays. These delays are variable and depend on thelevel of congestion in the
network. Since the amount of buffer space is finite, an arriving packet may find that the
buffer is completely full with other packets waiting for transmission. In this case, packet
loss will occur—either the arriving packet or one of the already-queued packets will be
dropped.
The width of a slab represents the number of bits in the packet. In this figure, all
packets have the same width and hence the same length. Suppose Hosts A and B are
sending packets to Host E. Hosts A and B first send their packets along 100 Mbps
Ethernet links to the first router. The router then directs these packets to the 15 Mbps
link. If, during a short interval of time, the arrival rate of packets to the router (when
converted to bits per second) exceeds 15 Mbps, congestion will occur at the router as
packets queue in the link’s output buffer before being transmitted onto the link. For
example, if Host A and B each send a burst of five packets back-to-back at the same time,
then most of these packets will spend some time waiting in the queue. The situation is, in
fact, entirely analogous to many common-day situations—for example, when we wait in
line for a bank teller or wait in front of a tollbooth.
Earlier, we said that a router takes a packet arriving on one of its attached
communication links and forwards that packet onto another one of its attached
communication links. But how does the router determine which link it shouldforward the
packet onto? Packet forwarding is actually done in different ways in different types of
computer networks. Here, we briefly describe how it is done in the Internet.
In the Internet, every end system has an address called an IP address. When a
source end system wants to send a packet to a destination end system, the source includes
the destination’s IP address in the packet’s header. As with postal addresses, this address
has a hierarchical structure. When a packet arrives at a router in the network, the router
examines a portion of the packet’s destination address and forwards the packet to an
adjacent router. More specifically, each router has a forwarding table that maps
destination addresses (or portions of the destination addresses) to that router’s outbound
links. When a packet arrives at a router, the router examines the address and searches its
forwarding table, using this destination address, to find the appropriate outbound link.
The router then directs the packet to this outbound link.
The end-to-end routing process is analogous to a car driver who does not use
maps but instead prefers to ask for directions. For example, suppose Joe is driving from
Philadelphia to 156 Lakeside Drive in Orlando, Florida. Joe first drives to his
neighborhood gas station and asks how to get to 156 Lakeside Drive in Orlando, Florida.
The gas station attendant extracts the Florida portion of the address and tells Joe that he
needs to get onto the interstate highway I-95 South, which has an entrance just next to the
gas station. He also tells Joe that once he enters Florida, he should ask someone else
there. Joe then takes I-95 South until he gets to Jacksonville, Florida, at which point he
asks another gas station attendant for directions. The attendant extracts the Orlando
portion of the address and tells Joe that he should continue on I-95 to Daytona Beach and
then ask someone else. In Daytona Beach, another gas station attendant also extracts the
Orlando portion of the address and tells Joe that he should take I-4 directly to Orlando.
Joe takes I-4 and gets off at the Orlando exit. Joe goes to another gas station attendant,
and this time the attendant extracts the Lakeside Drive portion of the address and tells Joe
the road he must follow to get to Lakeside Drive. Once Joe reaches Lakeside Drive, he
asks a kid on a bicycle how to get to his destination. The kid extracts the 156 portion of
the address and points to the house. Joe finally reaches his ultimate destination. In the
above analogy, the gas station attendants and kids on bicycles are analogous to routers.
We just learned that a router uses a packet’s destination address to index a
forwarding table and determine the appropriate outbound link. But this statement begs yet
another question: How do forwarding tables get set? Are they configured by hand in each
and every router, or does the Internet use a more automated procedure? This issue will be
studied. But to whet your appetite here, we’ll note now that the Internet has a number of
special routing protocols that are used to automatically set the forwarding tables. A
routing protocol may, for example, determine the shortest path from each router to each
destination and use the shortest path results to configure the forwarding tables in the
routers.
d. Delay, Loss, and Throughput in Packet-Switched Networks
Recall that a packet starts in a host (the source), passes through a series of routers,
and ends its journey in another host (the destination). As a packet travels from one node
(host or router) to the subsequent node (host or router) along this path, the packet suffers
from several types of delays at each node along the path. The most important of these
delays are the nodal processing delay, queuing delay, transmission delay, and propagation
delay; together, these delays accumulate to give a total nodal delay. The performance of
many Internet applications—such as search, Web browsing, e-mail, maps, instant
messaging, and voice-over-IP—are greatly affected by network delays. In order to
acquire a deep understanding of packet switching and computer networks, we must
understand the nature and importance of these delays.
As part of its end-to-end route between source and destination, a packet is sent
from the upstream node through router A to router B. Our goal is to characterize the
nodal delay at router A. Note that router A has an outbound link leading to router B. This
link is preceded by a queue (also known as a buffer). When the packet arrives at router A
from the upstream node, router A examines the packet’s header to determine the
appropriate outbound link for the packet and then directs the packet to this link. In this
example, the outbound link for the packet is the one that leads to router B. A packet can
be transmitted on a link only if there is no other packet currently being transmitted on the
link and if there are no other packets preceding it in the queue; if the link iscurrently busy
or if there are other packets already queued for the link, the newly arriving packet will
then join the queue.
The time required to examine the packet’s header and determine where to direct
the packet is part of the processing delay. The processing delay can also include other
factors, such as the time needed to check for bit-level errors in the packet that occurred in
transmitting the packet’s bits from the upstream node to router A. Processing delays in
high-speed routers are typically on the order of microseconds or less. After this nodal
processing, the router directs the packet to the queue that precedes the link to router B.
At the queue, the packet experiences a queuing delay as it waits to be transmitted
onto the link. The length of the queuing delay of a specific packet will depend on the
number of earlier-arriving packets that are queued and waiting for transmission onto the
link. If the queue is empty and no other packet is currently being transmitted, then our
packet’s queuing delay will be zero. On the other hand, if the traffic is heavy and many
other packets are also waiting to be transmitted, the queuing delay will be long. We will
see shortly that the number of packets that an arriving packet might expect to find is a
function of the intensity and nature of the traffic arriving at the queue. Queuing delays
can be on the order of microseconds to milliseconds in practice.
Assuming that packets are transmitted in a first-come-first-served manner, as is
common in packet-switched networks, our packet can be transmitted only after all the
packets that have arrived before it have been transmitted. Denote the length of the packet
by L bits, and denote the transmission rate of the link from router A to router B by R
bits/sec. For example, for a 10 Mbps Ethernet link, the rate is R = 10 Mbps; for a 100
Mbps Ethernet link, the rate is R = 100 Mbps. The transmission delay is L/R. This is the
amount of time required to push (that is, transmit) all of the packet’s bits into the link.
Transmission delays are typically on the order of microseconds to milliseconds in
practice.
Newcomers to the field of computer networking sometimes have difficulty
understanding the difference between transmission delay and propagation delay. The
difference is subtle but important. The transmission delay is the amount of time required
for the router to push out the packet; it is a function of the packet’s length and the
transmission rate of the link, but has nothing to do with the distance between the two
routers. The propagation delay, on the other hand, is the time it takes a bit to propagate
from one router to the next; it is a function of the distance between the two routers, but
has nothing to do with the packet’s length or the transmission rate of the link.
An analogy might clarify the notions of transmission and propagation delay.
Consider a highway that has a tollbooth every 100 kilometers. You can think of the
highway segments between tollbooths as links and the tollbooths as routers. Suppose that
cars travel (that is, propagate) on the highway at a rate of 100 km/hour (that is, when a
car leaves a tollbooth, it instantaneously accelerates to 100 km/hour and maintains that
speed between tollbooths). Suppose next that 10 cars, traveling together as a caravan,
follow each other in a fixed order. You can think of each car as a bit and the caravan as a
packet.
Also suppose that eachtollbooth services (that is, transmits) a car at a rate of one
car per 12 seconds, and that it is late at night so that the caravan’s cars are the only cars
on the highway. Finally, suppose that whenever the first car of the caravan arrives at a
tollbooth, it waits at the entrance until the other nine cars have arrived and lined up
behind it. (Thus, the entire caravan must be stored at the tollbooth before it can begin to
be forwarded.) The time required for the tollbooth to push the entire caravan onto the
highway is (10 cars)/(5 cars/minute) = 2 minutes. This time is analogous to the
transmission delay in a router. The time required for a car to travel from the exit of one
tollbooth to the next tollbooth is 100 km/(100 km/hour) = 1 hour. This time is analogous
to propagation delay. Therefore, the time from when the caravan is stored in front of a
tollbooth until the caravan is stored in front of the next tollbooth is the sum of
transmission delay and propagation delay—in this example, 62 minutes.
Let’s explore this analogy a bit more. What would happen if the tollbooth service
time for a caravan were greater than the time for a car to travel between tollbooths? For
example, suppose now that the cars travel at the rate of 1,000 km/hour and the tollbooth
services cars at the rate of one car per minute. Then the traveling delay between two
tollbooths is 6 minutes and the time to serve a caravan is 10 minutes. In this case, the first
few cars in the caravan will arrive at the second tollbooth before the last cars in the
caravan leave the first tollbooth. This situation also arises in packet-switched networks—
the first bits in a packet can arrive at a router while many of the remaining bits in the
packet are still waiting to be transmitted by the preceding router.
If a picture speaks a thousand words, then an animation must speak a million
words. The Web site for this textbook provides an interactive animation that nicely
illustrates and contrasts transmission delay and propagation delay. The reader is highly
encouraged to visit that animation. [Smith 2009] also provides a very readable discussion
of propagation, queueing, and transmission delays.
e. Protocol Layers and Their Service Models
Before attempting to organize our thoughts on Internet architecture, let’s look for
a human analogy. Actually, we deal with complex systems all the time in our everyday
life. Imagine if someone asked you to describe, for example, the airline system. How
would you find the structure to describe this complex system that has ticketing agents,
baggage checkers, gate personnel, pilots, airplanes, air traffic control, and a worldwide
system for routing airplanes? One way to describe this system might be to describe the
series of actions you take (or others take for you) when you fly on an airline. You
purchase your ticket, check your bags, go to the gate, and eventually get loaded onto the
plane. The plane takes off and is routed to its destination. After your plane lands, you
deplane at the gate and claim your bags. If the trip was bad, you complain about the flight
to the ticket agent (getting nothing for your effort).
Already, we can see some analogies here with computer networking: You are
being shipped from source to destination by the airline; a packet is shipped from source
host to destination host in the Internet. But this is not quite the analogy we are after. We
are looking for some, we note that there is a ticketing function at each end; there is also a
baggage function for already-ticketed passengers, and a gate function for already-ticketed
and already-baggage-checked passengers. For passengers who have made it through the
gate (that is, passengers who are already ticketed, baggage-checked, and through the
gate), there is a takeoff and landing function, and while in flight, there is an airplane
routing function.
Note that each layer, combined with the layers below it, implements some
functionality, some service. At the ticketing layer and below, airline-counter-to-airline-
counter transfer of a person is accomplished. At the baggage layer and below, baggage-
check-to-baggage-claim transfer of a person and bags is accomplished. Note that the
baggage layer provides this service only to an already-ticketed person. At the gate layer,
departure-gate-to-arrival-gate transfer of a person and bags is accomplished. At the
takeoff/landing layer, runway-to-runway transfer of people and their bags is
accomplished. Each layer provides its service by (1) performing certain actions within
that layer (for example, at the gate layer, loading and unloading people from an airplane)
and by (2) using the services of the layer directly below it (for example, in the gate layer,
using the runway-to-runway passenger transfer service of the takeoff/landing layer).
A layered architecture allows us to discuss a well-defined, specific part of a large
and complex system. This simplification itself is of considerable value by providing
modularity, making it much easier to change the implementation of the service provided
by the layer. As long as the layer provides the same service to the layer above it, and uses
the same services from the layer below it, the remainder of the system remains
unchanged when a layer’s implementation is changed. (Note that changing the
implementation of a service is very different from changing the service itself!) For
example, if the gate functions were changed (for instance, to have people board and
disembark by height), the remainder of the airline system would remain unchanged since
the gate layer still provides the same function (loading and unloading people); it simply
implements that function in a different manner after the change. For large and complex
systems that are constantly being updated, the ability to change the implementation of a
service without affecting other components of the system is another important advantage
of layering.
But enough about airlines. Let’s now turn our attention to network protocols. To
provide structure to the design of network protocols, network designers organize
protocols—and the network hardware and software that implement the protocols— in
layers. Each protocol belongs to one of the layers, just as each function in the airline
architecture belonged to a layer. We are again interested in the services that a layer offers
to the layer above—the so-called service model of a layer. Just as in the case of our
airline example, each layer provides its service by (1) performing certain actions within
that layer and by (2) using the services of the layer directly below it. For example, the
services provided by layer n may include reliable delivery of messages from one edge of
the network to the other. This might be implemented by using an unreliable edge-to-edge
message delivery service of layer n - 1, and adding layer n functionality to detect and
retransmit lost messages.
A protocol layer can be implemented in software, in hardware, or in a
combination of the two. Application-layer protocols—such as HTTP and SMTP—are
almost always implemented in software in the end systems; so are transport-layer
protocols. Because the physical layer and data link layers are responsible for handling
communication over a specific link, they are typically implemented in a network
interface card (for example, Ethernet or WiFi interface cards) associated with a given
link. The network layer is often a mixed implementation of hardware and software. Also
note that just as the functions in the layered airline architecture were distributed among
the various airports and flight control centers that make up the system, so too is a layer n
protocol distributed among the end systems, packet switches, and other components that
make up the network. That is, there’s often a piece of a layer n protocol in each of these
network components.
Protocol layering has conceptual and structural advantages [RFC 3439]. As we
have seen, layering provides a structured way to discuss system components. Modularity
makes it easier to update system components. We mention, however, that some
researchers and networking engineers are vehemently opposed to layering [Wakeman
1992]. One potential drawback of layering is that one layer may duplicate lower-layer
functionality. For example, many protocol stacks provide error recovery on both a per-
link basis and an end-to-end basis. A second potential drawback is that functionality at
one layer may need information (for example, a timestamp value) that is present only in
another layer; this violates the goal of separation of layers.
When taken together, the protocols of the various layers are called the protocol
stack. The Internet protocol stack consists of five layers: the physical, link, network,
transport, and application layers. If you examine the Table of Contents, you will see that
we have roughly organized this book using the layers of the Internet protocol stack. We
take a top-down approach, first covering the application layer and then proceeding
downward.
f. Networks Under Attack
The Internet has become mission critical for many institutions today, including
large and small companies, universities, and government agencies. Many individuals also
rely on the Internet for many of their professional, social, and personal activities. Billions
of “things,” including wearables and home devices, are currently being connected to the
Internet. But behind all this utility and excitement, there is a dark side, a side where “bad
guys” attempt to wreak havoc in our daily lives by damaging our Internet-connected
computers, violating our privacy, and rendering inoperable the Internet services on which
we depend.
The field of network security is about how the bad guys can attack computer
networks and about how we, soon-to-be experts in computer networking, can defend
networks against those attacks, or better yet, design new architectures that are immune to
such attacks in the first place. Given the frequency and variety of existing attacks as well
as the threat of new and more destructive future attacks, network security has become a
central topic in the field of computer networking. One of the features of this textbook is
that it brings network security issues to the forefront.
Since we don’t yet have expertise in computer networking and Internet protocols,
we’ll begin here by surveying some of today’s more prevalent security related problems.
This will whet our appetite for more substantial discussions in the upcoming. So we
begin here by simply asking, what can go wrong? How are computer networks
vulnerable? What are some of the more prevalent types of attacks today?
We attach devices to the Internet because we want to receive/send data from/to
the Internet. This includes all kinds of good stuff, including Instagram posts,
Internetsearch results, streaming music, video conference calls, streaming movies, and so
on. But, unfortunately, along with all that good stuff comes malicious stuff— collectively
known as malware—that can also enter and infect our devices. Once malware infects our
device it can do all kinds of devious things, including deleting our files and installing
spyware that collects our private information, such as social security numbers, passwords,
and keystrokes, and then sends this (over the Internet, of course!) back to the bad guys.
Our compromised host may also be enrolled in a network of thousands of similarly
compromised devices, collectively known as a botnet, which the bad guys control and
leverage for spam e-mail distribution or distributed denial-of-service attacks (soon to be
discussed) against targeted hosts.
Much of the malware out there today is self-replicating: once it infects one host,
from that host it seeks entry into other hosts over the Internet, and from the newly
infected hosts, it seeks entry into yet more hosts. In this manner, self-replicating malware
can spread exponentially fast.
Another broad class of security threats are known as denial-of-service (DoS)
attacks. As the name suggests, a DoS attack renders a network, host, or other piece of
infrastructure unusable by legitimate users. Web servers, e-mail servers, DNS servers,
and institutional networks can all be subject to DoS attacks. The site Digital Attack Map
allows use to visualize the top daily DoS attacks worldwide [DAM 2020].
Let’s now explore the bandwidth-flooding attack in more detail. Recalling our
delay and loss analysis discussion in Section 1.4.2, it’s evident that if the server has an
access rate of R bps, then the attacker will need to send traffic at a rate of approximately
R bps to cause damage. If R is very large, a single attack source may not be able to
generate enough traffic to harm the server. Furthermore, if allthe traffic emanates from a
single source, an upstream router may be able to detect the attack and block all traffic
from that source before the traffic gets near the server. In a distributed DoS (DDoS)
attack, the attacker controls multiple sources and has each source blast traffic at the
target. With this approach, the aggregate traffic rate across all the controlled sources
needs to be approximately R to cripple the service. DDoS attacks leveraging botnets with
thousands of comprised hosts are a common occurrence today [DAM 2020]. DDos
attacks are much harder to detect and defend against than a DoS attack from a single host.
It is surprisingly easy (you will have the knowledge to do so shortly as you
proceed through this text!) to create a packet with an arbitrary source address, packet
content, and destination address and then transmit this hand-crafted packet into the
Internet, which will dutifully forward the packet to its destination. Imagine the
unsuspecting receiver (say an Internet router) who receives such a packet, takes the
(false) source address as being truthful, and then performs some command embedded in
the packet’s contents (say modifies its forwarding table). The ability to inject packets into
the Internet with a false source address is known as IP spoofing, and is but one of many
ways in which one user can masquerade as another user.
In closing this section, it’s worth considering how the Internet got to be such an
insecure place in the first place. The answer, in essence, is that the Internet was originally
designed to be that way, based on the model of “a group of mutually trusting users
attached to a transparent network” [Blumenthal 2001]—a model in which (by definition)
there is no need for security. Many aspects of the original Internet architecture deeply
reflect this notion of mutual trust. For example, the ability for one user to send a packet to
any other user is the default rather than a requested/ granted capability, and user identity
is taken at declared face value, rather than being authenticated by default.
But today’s Internet certainly does not involve “mutually trusting users.”
Nonetheless, today’s users still need to communicate when they don’t necessarily trust
each other, may wish to communicate anonymously, may communicate indirectly
through third parties and may distrust the hardware, software, and even the air through
which they communicate. We now have many security-related challenges before us as we
progress through this book: We should seek defenses against sniffing, end-point
masquerading, man-in-the-middle attacks, DDoS attacks, malware, and more. We should
keep in mind that communication among mutually trusted users is the excep
