diff --git a/README.rst b/README.rst index c59d5b9..48292c3 100644 --- a/README.rst +++ b/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 diff --git a/applications/email.rst b/applications/email.rst index c742ec9..f9ec213 100644 --- a/applications/email.rst +++ b/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|. diff --git a/applications/web.rst b/applications/web.rst index 2fb36a0..a376af7 100644 --- a/applications/web.rst +++ b/applications/web.rst @@ -119,7 +119,7 @@ message has the general form MESSAGE_BODY -where ```` stands for carriage-return+line-feed. This is a +where ```` 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 diff --git a/capacity.rst b/capacity.rst index 70dfefb..b7137ec 100644 --- a/capacity.rst +++ b/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. diff --git a/capacity/datacenter.rst b/capacity/datacenter.rst index 50c0542..1336c36 100644 --- a/capacity/datacenter.rst +++ b/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 diff --git a/capacity/traffic.rst b/capacity/traffic.rst index ab1cea4..35e85d6 100644 --- a/capacity/traffic.rst +++ b/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: diff --git a/congestion/variants.rst b/congestion/variants.rst index bf17b9c..63be521 100644 --- a/congestion/variants.rst +++ b/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. diff --git a/dict.txt b/dict.txt index ad881f8..7e4ae69 100644 --- a/dict.txt +++ b/dict.txt @@ -1598,8 +1598,6 @@ Shuberg Sigcomm SIGCOMM's Sigelman -signalled -signalling SIGOPS siloed SIMs diff --git a/introduction/architecture.rst b/introduction/architecture.rst index 2a7715f..f07bbc7 100644 --- a/introduction/architecture.rst +++ b/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 diff --git a/message/rdma.rst b/message/rdma.rst index c6cf3d1..78ea8ba 100644 --- a/message/rdma.rst +++ b/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 diff --git a/message/roce.rst b/message/roce.rst index 1adde8f..aa1301d 100644 --- a/message/roce.rst +++ b/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. diff --git a/naming/dns.rst b/naming/dns.rst index b63af30..cb42daf 100644 --- a/naming/dns.rst +++ b/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. diff --git a/operations/config.rst b/operations/config.rst index 8f6799b..8f8db4f 100644 --- a/operations/config.rst +++ b/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 diff --git a/preface.rst b/preface.rst index 7654efb..69d98ff 100644 --- a/preface.rst +++ b/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 diff --git a/secure.rst b/secure.rst index 8528def..7ebda32 100644 --- a/secure.rst +++ b/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. diff --git a/shared/cellular.rst b/shared/cellular.rst index f1ea7a6..07eb6d9 100644 --- a/shared/cellular.rst +++ b/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. diff --git a/shared/spectrum.rst b/shared/spectrum.rst index 0d611e6..3c430a5 100644 --- a/shared/spectrum.rst +++ b/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*, diff --git a/stream/design.rst b/stream/design.rst index e2fd7d4..6e8b179 100644 --- a/stream/design.rst +++ b/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. diff --git a/technology/circuits.rst b/technology/circuits.rst index 96198b4..2e21f6f 100644 --- a/technology/circuits.rst +++ b/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