Merge branch 'master' of github.com:SystemsApproach/book

Author: drbruced12

applications/infrastructure.rst

@@ -253,8 +253,8 @@ TLD servers.
    (a.gtld-servers.net, A, 192.5.6.30)
    ...
 
-Moving our way down the hierarchy by one level, the server has records
-for domains like this:
+Moving our way down the hierarchy by one level, the ``a3.nstld.com`` server has records
+for ``.edu`` domains like this:
 
 ::
 

congestion/tcpcc.rst

@@ -269,7 +269,7 @@ following code fragment:
    }
 
 where ``state`` represents the state of a particular TCP connection and
-defines an upper bound on how large the congestion window is allowed to
+``TCP_MAXWIN`` defines an upper bound on how large the congestion window is allowed to
 grow.
 
 :numref:`Figure %s <fig-trace1>` traces how TCP’s ``CongestionWindow``

e2e/rtp.rst

@@ -151,7 +151,7 @@ perceptible and annoying.
 A final function that we might want to put into the protocol is some
 way of identifying senders that is more user-friendly than an IP
 address. As illustrated in :numref:`Figure %s <fig-zoom>`, audio and
-video conferencing applications can display strings such as on their
+video conferencing applications can display strings such as ``User <user@example.com>`` on their
 control panels, and thus the application protocol should support the
 association of such a string with a data stream.
 

foreword.rst

@@ -8,7 +8,7 @@ how long ago the foundations of the Internet were laid.
 
 In 1996, the NSFNET had just been decommissioned, and the commercial
 phase of the Internet was just beginning. The first search engine
-(Alta Vista—do you remember?) had just been demonstrated. Content
+(AltaVista—do you remember?) had just been demonstrated. Content
 delivery networks did not exist—Akamai was founded two years later
 in 1998, the same year Google was officially born. Cloud was only a
 distant haze on the horizon. And there was no such thing as

foundation/architecture.rst

@@ -136,7 +136,7 @@ Except at the hardware level, where peers directly communicate with each
 other over a physical medium, peer-to-peer communication is
 indirect—each protocol communicates with its peer by passing messages to
 some lower-level protocol, which in turn delivers the message to *its*
-peer. In addition, there are potentially more than one protocol at any
+peer. In addition, there may be more than one protocol at any
 given level, each providing a different communication service. We
 therefore represent the suite of protocols that make up a network system
 with a *protocol graph*. The nodes of the graph correspond to protocols,
@@ -424,9 +424,9 @@ layer is layer 3, and the link or subnet layer below IP is layer 2.
    specification of many of its protocols, such as TCP, UDP, IP,
    DNS, and BGP. But the Internet architecture also embraces many
    protocols defined by other organizations, including IEEE's
-   802.11 ethernet and Wi-Fi standards, W3C's HTTP/HTML web
-   specifications, 3GPP's 4G and 5G cellular networks standards,
-   and ITU-T's H.232 video encoding standards, to name a few.
+   802.3 Ethernet and 802.11 Wi-Fi standards, W3C's HTTP/HTML web
+   specifications, 3GPP's 4G and 5G cellular network standards,
+   and ITU-T's H.264 video encoding standard, to name a few.
 
    In addition to defining architectures and specifying protocols,
    there are yet other organizations that support the larger goal of
@@ -486,4 +486,3 @@ meetings:
    capabilities, and evolve rapidly. The narrow-waisted model is
    critical to the Internet’s ability to adapt to new user
    demands and changing technologies. :ref:`[Next] <key-pipe-full>`
-

foundation/performance.rst

@@ -310,16 +310,16 @@ that can be achieved over a network is given by the simple relationship
 
 .. centered:: Throughput = TransferSize / TransferTime
 
-where TransferTime includes not only the elements of one-way
+where ``TransferTime`` includes not only the elements of one-way latency
 identified earlier in this section, but also any additional time spent
 requesting or setting up the transfer. Generally, we represent this
 relationship as
 
 .. centered:: TransferTime = RTT + 1/Bandwidth x TransferSize
 
-We use in this calculation to account for a request message being sent
+We use ``RTT`` in this calculation to account for a request message being sent
 across the network and the data being sent back. For example, consider a
-situation where a user wants to fetch a 1-MB file across a 1-Gbps with a
+situation where a user wants to fetch a 1-MB file across a 1-Gbps link with a
 round-trip time of 100 ms. This includes both the transmit time for 1 MB
 (1 / 1 Gbps × 1 MB = 8 ms) and the 100-ms RTT, for a total transfer time
 of 108 ms. This means that the effective throughput will be

foundation/problem.rst

@@ -28,7 +28,7 @@ network is its generality. Computer networks are built primarily from
 general-purpose programmable hardware, and they are not optimized for a
 particular application like making phone calls or delivering television
 signals. Instead, they are able to carry many different types of data,
-and they support a wide, and ever growing, range of applications.
+and they support a wide, and ever-growing, range of applications.
 Today’s computer networks have pretty much taken over the functions
 previously performed by single-use networks. This chapter looks at some
 typical applications of computer networks and discusses the requirements
@@ -49,10 +49,10 @@ important to understand how they are operated or managed and how network
 applications are developed. Almost all of us now have computer networks
 in our homes, offices, and in some cases in our cars, so operating
 networks is no longer a matter only for a few specialists. And with the
-proliferation of smartphones, many more of this generation are
+proliferation of smartphones, many more people in this generation are
 developing networked applications than in the past. So we need to
 consider networks from these multiple perspectives: builders, operators,
-application developers.
+and application developers.
 
 To start us on the road toward understanding how to build, operate, and
 program a network, this chapter does four things. First, it explores the

foundation/software.rst

@@ -81,7 +81,7 @@ understanding the underlying ideas.)
           into a multi-billion dollar industry. Starting from the
           humble beginnings of the client/server paradigm and a
           handful of simple application programs like email, file
-          transfer, and remote login, everyone now has access to an
+          transfer, and remote login, everyone now has access to a
           never-ending supply of cloud applications from their
           smartphones.
 

foundation/trend.rst

@@ -17,7 +17,7 @@ Facebook, Google, Amazon, Microsoft, Apple, Netflix, Spotify), and of
 course, subscribers and customers (i.e., individuals, but also
 enterprises and businesses). The lines between these players are not
 always crisp, with many companies playing multiple roles. The most
-notable example of this are the large cloud providers, who (a) build
+notable examples are the large cloud providers, who (a) build
 their own networking equipment using commodity components, (b) deploy
 and operate their own networks, and (c) provide end-user services and
 applications on top of their networks.
@@ -36,7 +36,7 @@ changes with each new edition of the textbook over the years. Doing that
 on a timeline measured in years has historically been good enough, but
 anyone that has downloaded and used the latest smartphone app knows how
 glacially slow anything measured in years is by today’s standards.
-Designing for evolution has to be part of the decision making process.
+Designing for evolution has to be part of the decision-making process.
 
 On the second point, the companies that build networks are almost always
 the same ones that operate them. They are collectively known as *network

internetworking/routing.rst

@@ -1171,7 +1171,7 @@ common approach to setting metrics is to use a constant multiplied by
    time, so it’s important to deploy a simple solution sooner rather
    than later, and expect to improve it over time. Staying stuck in the
    design phase indefinitely is usually not a good plan. The second
-   is the well-know KISS principle: *Keep it Simple, Stupid.* When
+   is the well-known KISS principle: *Keep it Simple, Stupid.* When
    building a complex system, less is often more. Opportunities to
    invent sophisticated optimizations are plentiful, and it’s a tempting
    opportunity to pursue. While such optimizations sometimes have