Fix hyphenation and remove British spelling from dictionary

README.rst

@@ -6,7 +6,7 @@ About This Book
 ===============
 
 .. no badge when making Latex doc
-   
+
 .. image:: https://github.com/SystemsApproach/7E/actions/workflows/publish-docs.yml/badge.svg
    :align: left
    :alt: deployment status button

applications/email.rst

@@ -65,7 +65,7 @@ to start over with email using today's best practices, what would you
 do differently?  One likely answer is that you would define a RESTful
 API for email, and use HTTPS to both write messages to a mailbox and
 read messages from a mailbox. In fact, the same could be said for many
-applications that pre-date the web—their protocols are just
+applications that predate the web—their protocols are just
 purpose-built Request/Reply protocols. This is a topic we address in
 Chapter |Message|.
 

applications/web.rst

@@ -119,7 +119,7 @@ message has the general form
    <CRLF>
    MESSAGE_BODY <CRLF>
 
-where ``<CRLF>`` stands for carriage-return+line-feed. This is a
+where ``<CRLF>`` stands for carriage return + line feed. This is a
 pair of ASCII control characters often used to indicate the end of a
 line of text. The
 first line (``START_LINE``) indicates whether this is a request message

capacity.rst

@@ -55,7 +55,7 @@ traffic onto links and nodes in the first place. This network-wide
 decision-making process is known as *Traffic Engineering (TE)*, and it
 comes into play when per-node capacity is chronically under-provisioned
 due to long-term changes in the volume of traffic flowing between
-various nodes. TE was originally an off-line process, requiring
+various nodes. TE was originally an offline process, requiring
 administrator intervention, but it is increasingly being done as an
 automated (but coarse-grained) part of a network's overall approach to
 capacity management.

capacity/datacenter.rst

@@ -52,7 +52,7 @@ The commonly used set of per-hop behaviors includes:
   requirements, which will be met as long as the sender is well
   behaved.
 
-AF is further subdivided into four sub-classes, each of which has an
+AF is further subdivided into four subclasses, each of which has an
 associated *drop preference* (low, medium, high), for a total of 12
 possible AF-related values. Finally, there is an attempt to maintain
 backward compatibility with the priority (precedence) specified in the

capacity/traffic.rst

@@ -140,7 +140,7 @@ there is no choice but the long path. But a central algorithm that
 looked at all three flows at once and tried to place them optimally
 would end up with the much less wasteful set of paths shown on the
 bottom in the figure. While this is a contrived example,
-sub-optimal outcomes are unavoidable when there
+suboptimal outcomes are unavoidable when there
 is no central view of traffic.
 
 .. _fig-te-example:

congestion/variants.rst

@@ -57,7 +57,7 @@ rather than making the simple binary decision that congestion is
 present. It then scales the congestion window based on this
 estimate. The standard TCP algorithm still kicks in should a packet
 actually be lost. The approach is designed to keep queues short by
-reacting early to congestion while not over-reacting to the point that
+reacting early to congestion while not overreacting to the point that
 they run empty and sacrifice throughput.
 
 The key challenge in this approach is to estimate the fraction of bytes
@@ -117,7 +117,7 @@ as the congestion window is calculated as follows:
 
 To summarize, CE marking to indicate incipient congestion happens
 early and often, but the reaction to such marking is more measured
-than in standard TCP, to avoid the over-reaction that would lead to
+than in standard TCP, to avoid the overreaction that would lead to
 queues running empty.
 
 The paper that lays out all the arguments for DCTCP including a study
@@ -156,7 +156,7 @@ previous equilibrium state. This is a difficult choice because it
 depends on the duration of congestion, which is hard to predict. If
 the congestion is transient, the algorithm should remember its
 previous state so it can rapidly restore the old equilibrium without
-under-utilizing the network once the burst ends. If the congestion is
+underutilizing the network once the burst ends. If the congestion is
 sustained, for example due to the arrival of one or more new flows,
 the algorithm should forget its previous state so that it can rapidly
 find a new equilibrium.

dict.txt

@@ -1598,8 +1598,6 @@ Shuberg
 Sigcomm
 SIGCOMM's
 Sigelman
-signalled
-signalling
 SIGOPS
 siloed
 SIMs

introduction/architecture.rst

@@ -174,11 +174,11 @@ with "transport protocol" being a universal term.
 While it is possible to roughly map the other layers between the two
 architectures, understanding how and why they differ is more
 instructive. At the top end, the Internet does not partition
-application protocols into sub-layers, corresponding to the OSI's layers 5, 6,
+application protocols into sublayers, corresponding to the OSI's layers 5, 6,
 and 7.  This is because it treats applications as an orthogonal
 concern, with each app free to adopt whatever modularization makes
 sense. At the bottom, the Internet does not prescribe how the
-underlying networks are partitioned into sub-layers, corresponding to
+underlying networks are partitioned into sublayers, corresponding to
 the OSI's layers 1, 2, and 3. As at the application layer, the
 Internet architecture is agnostic as to how underlying network
 technologies are organized. Deciding what details to specify and what

message/rdma.rst

@@ -111,7 +111,7 @@ low-level, and so is typically not directly used by application
 programs. Such applications are generally written to a higher-level
 interface, of which there are several options. They include *Message
 Passing Interface (MPI)* , *Global Address Space Programming Interface
-(GPI)*, and *Open Fabrics Interface (OFI)*, all of which pre-date the
+(GPI)*, and *Open Fabrics Interface (OFI)*, all of which predate the
 last decade's pivot towards AI workloads. More recently, *NCCL*
 (pronounced "nickel") has become the dominant API for AI software
 running on GPUs. NCCL was created by NVIDIA (it is an acronym for

message/roce.rst

@@ -135,7 +135,7 @@ Notification (ECN) mechanism described in Chapter |Capacity|. This is
 appealing for cloud providers because their datacenters already
 leverage ECN in support of TCP congestion control.  The two mechanisms
 work in concert, with ECN pacing the source host as a first response
-to congestion, and PFC serving as a fall-back.
+to congestion, and PFC serving as a fallback.
 
 Note that this is all still an active area of research, with the
 following papers giving some insight into the issues being studied.

naming/dns.rst

@@ -347,7 +347,7 @@ request/reply paradigm and have built-in security thanks to TLS.
 There are, in fact, proposals to do exactly that. They are known as
 "DNS over HTTPS" (DoH) and "DNS over QUIC" (DoQ), respectively, as
 defined in RFCs 8484 and 9250. Instead, like all applications that
-pre-date HTTP, DNS has a bespoke request/reply protocol and it runs
+predate HTTP, DNS has a bespoke request/reply protocol and it runs
 over UDP (see RFC 1035). This approach has several security risks,
 some of which DoH and DoQ address. We discuss those risks, and
 introduce other defenses, in a companion book.

operations/config.rst

@@ -56,7 +56,7 @@ straightforward. In any case, our focus is on the variable dictionary.
 You can learn more about the basics of SNMP and the MIB from RFCs 1157
 and 1213, respectively, and if you want to follow the history of
 incremental refinements, there is a long list of follow-on RFCs. But
-all of this work is based on an approach that pre-dates the
+all of this work is based on an approach that predates the
 availability of modern modeling languages, of which YANG has become
 the widely-accepted solution. YANG stands for *Yet Another Next
 Generation*, a name chosen to poke fun at how often a do-over proves

preface.rst

@@ -78,7 +78,7 @@ students about the details of every RFC published in the last 30
 years. It would be unhelpful to try. This is what we mean by
 giving a sense of perspective. Within that massive space of design
 possibilities and protocols, there are certain topics that stand out
-because they have out-sized importance in how networks operate, or that
+because they have outsized importance in how networks operate, or that
 teach a particular design principle.
 
 One way we approach the magnitude of the task is to focus on the

secure.rst

@@ -58,7 +58,7 @@ a general-purpose set of mechanisms to provide a secure byte-stream
 abstraction to any higher-layer protocol that needed it.
 
 In providing a secure channel, it is commonly required to authenticate
-end-points, to protect the integrity of traffic against modification,
+endpoints, to protect the integrity of traffic against modification,
 and to ensure traffic confidentiality. These capabilities are as
 useful for remote procedure calls (a topic we cover in the next
 chapter) as they are for web traffic.

shared/cellular.rst

@@ -468,7 +468,7 @@ the corresponding queue during each scheduling interval. The fragments
 are reassembled back into complete packets at the receiver, before
 being passed up to the device (for downstream traffic) or on to the
 Mobile Core (for upstream traffic). Finally, note that one possible
-decision the scheduler might make is to "hand-off" the user to another
+decision the scheduler might make is to "hand off" the user to another
 base station, as outlined in Section |Shared|.4.2. In this way, a collection
 of base stations effectively collaborates to allocate spectrum across a
 set of radio cells.

shared/spectrum.rst

@@ -167,7 +167,7 @@ building block. It is this building block, and the ways it can be
 Before getting into the details, there is one other bit of context to
 set.  At a high level, some range of spectrum bandwidth is set aside
 for wireless communication, whether it's licensed or unlicensed. We
-often use a short-hand to refer to that band; e.g., "Wi-Fi at 5-GHz"
+often use a shorthand to refer to that band; e.g., "Wi-Fi at 5-GHz"
 or "5G at 6-GHz". In actuality, we're talking about a specific range;
 for example, Wi-Fi uses 5.150-GHz to 5.850-GHz. Within such a band, it
 is common to then subdivide the full range into discrete *channels*,

stream/design.rst

@@ -69,7 +69,7 @@ The fourth issue is a familiar one: how to scale the system. While
 most of us have been on large video conferences that seem to work
 well, the solution normally depends on some high-capacity cloud
 service to send the video out to the participants. The problem of how
-to distribute real-time media to large audiences—imagine a world-wide
+to distribute real-time media to large audiences—imagine a worldwide
 audience watching the World Cup—is gaining renewed attention and we
 conclude the chapter by looking at an approach which aims to be as
 scalable as today's delivery of entertainment video using DASH.

technology/circuits.rst

@@ -9,7 +9,7 @@ This book squarely focuses on packet-switched networks, in which
 complete packets are transmitted from one node to another, and any
 switch along an end-to-end path from source to destination
 stores and forwards packets.  There is another general approach to
-building networks, known as *circuit switching*, that pre-dates packet
+building networks, known as *circuit switching*, that predates packet
 switching. It has always been an integral part of the telephony
 network. In fact, as we pointed out in the introduction to this
 chapter, the original ARPANET was an experiment to demonstrate the