Measuring Network Activity
- 6.1 About Ethernet
- 6.2 About Hubs, Switches, and Routers
- 6.3 About TCP/IP
- 6.4 About Packets
- 6.5 About Remote Procedure Calls (RPCs)
- 6.6 Slop
- 6.7 Observing Network Traffic
- 6.8 Sample RPC Message Definition
- 6.9 Sample Logging Design
- 6.10 Sample Client-Server System Using RPCs
- 6.11 Sample Server Program
- 6.12 Spinlocks
- 6.13 Sample Client Program
- 6.14 Measuring One Sample Client-Server RPC
- 6.15 Postprocessing RPC Logs
- 6.16 Observations
- 6.17 Summary
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
The fourth fundamental shared resource to measure is network activity—how long do real network transmissions take and what are their dynamics? In contrast to measurements of the internal dynamics of single operations in the previous chapters, we will look at multiple overlapping network requests. The environment for disk measurements (and for that matter CPU and memory measurements) is fairly simple, as shown in Figure 6.1. There is just the one program running on one CPU and accessing one disk with a single transfer at a time.
){kind=link}
Figure 6.1 Environment for disk measurements
But the environment for network measurements is substantially more complicated, as shown in Figure 6.2. There are multiple client programs sending request messages to several server programs, which in turn send responses. These are all running on several different computers with network connections in between. Common server programs include database software.
In general, the different computers of Figure 6.2 could be located anywhere in the world, but we will concentrate in this chapter on computers that are physically close to each other, such as all inside a single datacenter room. The network connections could be Ethernet, Infiniband, Fibre Channel, or other choices, but we will concentrate on Ethernet connections. Various network protocols could be used, such as virtual channels, User Datagram Protocol (UDP), or Transmission Control Protocol/Internet Protocol (TCP/IP) software. We will concentrate on TCP/IP links, a common choice within datacenters.
)
Figure 6.2 More complicated environment for network measurements
The request messages and their responses could be structured in various ways; we will concentrate on remote procedure call (RPC) messages. Each RPC request message specifies a server computer to perform some work, the particular method (i.e., function or procedure name) to be called, and copies of all the method arguments. Each response message specifies the client computer to receive the response and the response data itself. The request and response messages can vary widely in size, from about 100 bytes to tens of megabytes. RPCs are usually asynchronous, meaning that the caller need not wait for the RPC response, but can instead continue executing and issuing other RPC requests in parallel, eventually waiting for responses that come back in arbitrary order. It is the highly parallel execution of many small pieces of work that allows datacenter software to respond quickly. Unlike TCP and other network protocols, RPC message formats are not standardized. This book uses a simple made-up format, described in Section 6.8.
In a large datacenter of 20,000 computers, with each computer running many different programs, an individual computer may have 10,000 network connections open at once, exchanging RPCs over all of them. While Figure 6.2 shows multiple point-to-point connections between client CPUs and server CPUs, these are just conceptual. The physical network may have just a single Ethernet link between each computer and a network router, with all the RPC traffic shared across these links. These underlying physical links and their associated kernel software are the shared network resource that we measure in this chapter.
As discussed in Chapter 1, datacenter software consists of layers and layers of subsystems, many running in parallel and often on hundreds or thousands of different servers. All this activity is tied together with some form of network message passing or RPCs. In this chapter we will observe and measure some simple RPCs, and then in the next chapter we will measure multiple overlapping RPCs. There are several layers of software involved, including user code, the operating system, and the TCP (transmission control protocol) stack on the client computer and the same three on the server computer. We will use RPCs from one user-mode program to another and back, measuring the behavior and delays between sample servers.
6.1 About Ethernet
Ethernet is the standard networking technology worldwide and is heavily used in datacenters. The original Ethernet at Xerox PARC in 1973 used a single coaxial cable (one wire inside a tube of a second wire with insulation in between), so it was a shared medium. Individual Alto computers connected to the wire with a vampire tap that poked an insulated spike through the outer wire to touch the inner wire, plus a second connection to the outer wire, as shown in Figure 6.3. (The vampire taps were shown to be unreliable and were soon superseded.) Just as polite people do when talking in a group, a computer desiring to transmit would listen to the coax (carrier-sense) waiting until it was idle and then try to transmit. During transmission, it continued to listen to determine whether the bits it transmitted were on the wire or whether they were garbled because some other computer was also starting to transmit. When that happened, both would stop transmitting, each wait a random amount of time, and then try again. Any node connected to the shared coax can observe all the packets, not just those addressed to that node. This is useful for monitoring network performance and debugging network problems, but it raises security issues.
)
Figure 6.3 Metcalfe’s original Ethernet diagram, photographed by Boggs [Metcalfe 1976]
Today, Ethernet data is transmitted as packets of up to 1,518 bytes (jumbo packets can be bigger) with gaps [Wikipedia 2021n] in between and a checksum at the end, as in Figure 6.4. Network software turns longer messages into sequences of packets. Individual packets are delivered with high probability, but are not 100% guaranteed to arrive. In particular, switches and routers that are overloaded are free to drop packets at any time. Packets with bad checksums are also discarded.
)
Figure 6.4 Ethernet type II frame [Wikimedia 2020a]
Each Ethernet packet starts with the 48-bit destination Media Access Control (MAC) address, followed by the 48-bit source MAC address, followed by a 16-bit Ethertype field and then the rest of the packet. The last 24 bits of a MAC address is an assigned Organizationally Unique Identifier (OUI) [IEEE 2021].
The remainder of a packet typically has several headers for layers of different switching protocols and then finally some user data. We will be using the TCP/IPv4 protocol pair, with a 20-byte IPv4 header giving the 4-byte IP addresses of the source and destination machines and a 20-byte TCP header giving the 2-byte port numbers on those machines plus data sequence numbers (SEQ) and acknowledgment bits (ACK) for accomplishing in-order guaranteed delivery.
We are using IP version 4 (IPv4) in our examples, but all the 32-bit IP numbers in this protocol are now used up worldwide, so the newer IPv6 is also being used in datacenters. IPv6 has 128-bit IP addresses, and an entire IPv6 header is 40 bytes instead of 20.
The MAC address is a unique 48-bit identifier assigned to each network interface controller in the world. (The original 3 Mb/sec Ethernet used 8-bit addresses.) The Ethertype field specifies how to interpret the following data bytes. For TCP/IP traffic, the MAC header Ethertype specifies IPv4, followed by a 20-byte IPv4 header in the first few data bytes of Figure 6.4. The IP header in turn specifies that it is followed immediately by a TCP header, which specifies that it is followed immediately by some number N of user message data or payload bytes.
Note that network transmission rate is traditionally measured in bits per second while disk transfer rate is traditionally measured in bytes per second. Lower-case “Mb” is megabits while upper-case “MB” is megabytes. Marketing literature often confuses these, introducing factor-of-eight errors. Deliberately quoting disk transfers in Mb/sec is a cheap way to make your numbers 8x larger.