# SOME DESCRIPTIVE TITLE. # Copyright (C) 2019 Olivier Bonaventure # This file is distributed under the same license as the Computer networking : Principles, Protocols and Practice package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Computer networking : Principles, Protocols and Practice 3\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2021-05-17 09:55+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../../exercises/tcp-2.rst:8 msgid "A closer look at TCP" msgstr "" #: ../../exercises/tcp-2.rst:10 msgid "In this series of exercises, you will explore in more details the operation of TCP and its congestion control scheme. TCP is a very important protocol in today's Internet since most applications use it to exchange data. We first look at TCP in more details by injecting segments in the Linux TCP stack and analyze how the stack reacts. Then we study the TCP congestion control scheme." msgstr "" #: ../../exercises/tcp-2.rst:14 msgid "Injecting segments in the Linux TCP stack" msgstr "" #: ../../exercises/tcp-2.rst:16 msgid "Packet capture tools like tcpdump_ and Wireshark_ are very useful to observe the segments that transport protocols exchange. TCP is a complex protocol that has evolved a lot since its first specification :rfc:`793`. TCP includes a large number of heuristics that influence the reaction of a TCP implementation to various types of events. A TCP implementation interacts with the application through the ``socket`` API." msgstr "" #: ../../exercises/tcp-2.rst:18 msgid "packetdrill_ is a TCP test suite that was designed to develop unit tests to verify the correct operation of a TCP implementation. A more detailed description of packetdrill_ may be found in [CCB+2013]_. packetdrill_ uses a syntax which is a mix between the C language and the tcpdump_ syntax. To understand the operation of packetdrill_, we first discuss several examples. The TCP implementation in the Linux kernel supports all the recent TCP extensions to improve its performance. For pedagogical reasons, we disable [#fsysctl]_ most of these extensions to use a simple TCP stack. packetdrill_ can be easily installed on recent Linux kernels [#finstall]_." msgstr "" #: ../../exercises/tcp-2.rst:20 msgid "Let us start with a very simple example that uses packetdrill_ to open a TCP connection on a server running on the Linux kernel. A packetdrill_ script is a sequence of lines that are executed one after the other. There are three main types of lines in a packetdrill_ script." msgstr "" #: ../../exercises/tcp-2.rst:22 msgid "packetdrill_ executes a system call and verifies its return value" msgstr "" #: ../../exercises/tcp-2.rst:23 msgid "packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux kernel as if it were received from the network" msgstr "" #: ../../exercises/tcp-2.rst:24 msgid "packetdrill_ compares a packet transmitted by the instrumented Linux kernel with the packet that the script expects" msgstr "" #: ../../exercises/tcp-2.rst:26 msgid "For our first packetdrill_ script, we aim at reproducing the simple connection shown in the figure below." msgstr "" #: ../../exercises/tcp-2.rst:57 msgid "Let us start with the execution of a system call. A simple example is shown below." msgstr "" #: ../../exercises/tcp-2.rst:63 msgid "The ``0`` indicates that the system call must be issued immediately. packetdrill_ then executes the system call and verifies that it returns ``3```. If yes, the processing continues. Otherwise the script stops and indicates an error." msgstr "" #: ../../exercises/tcp-2.rst:65 msgid "For this first example, we program packetdrill_ to inject the segments that a client would send. The first step is thus to prepare a :manpage:`socket` that can be used to accept this connection. This socket can be created by using the four system calls below." msgstr "" #: ../../exercises/tcp-2.rst:80 msgid "At this point, the socket is ready to accept incoming TCP connections. packetdrill_ needs to inject a TCP segment in the instrumented Linux stack. This can be done with the line below." msgstr "" #: ../../exercises/tcp-2.rst:86 msgid "Each line of a packetdrill_ script starts with a `timing` parameter that indicates at what time the event specified on this line should happen. packetdrill_ supports absolute and relative timings. An absolute timing is simply a number that indicates the delay in seconds between the start of the script and the event. A relative timing is indicated by using ``+`` followed by a number. This number is then the delay in seconds between the previous event and the current line. Additional information may be found in [CCB+2013]_." msgstr "" #: ../../exercises/tcp-2.rst:88 msgid "The description of TCP packets in packetdrill_ uses a syntax that is very close to the tcpdump_ one. The ``+0`` timing indicates that the line is executed immediately after the previous event. The ``<`` sign indicates that packetdrill_ injects a TCP segment and the ``S`` character indicates that the ``SYN`` flag must be set. Like tcpdump_, packetdrill_ uses sequence numbers that are relative to initial sequence number. The three numbers that follow are the sequence number of the first byte of the payload of the segment (``0``), the sequence number of the last byte of the payload of the segment (``0`` after the semi-column) and the length of the payload (``0`` between brackets) of the ``SYN`` segment. This segment does not contain a valid acknowledgment but advertises a window of 1000 bytes. All ``SYN`` segments must also include the ``MSS`` option. In this case, we set the MSS to 1000 bytes. The next line of the packetdrill_ script verifies the reply sent by the instrumented Linux kernel." msgstr "" #: ../../exercises/tcp-2.rst:95 msgid "This TCP segment is sent immediately by the stack. The ``SYN`` flag is set and the dot next to the ``S`` character indicates that the ACK flag is also set. The SYN+ACK segment does not contain any data but its acknowledgment number is set to 1 (relative to the initial sequence number). For outgoing packets, packetdrill_ does not verify the value of the advertised window. In this line, it also accepts any TCP options (``<...>``)." msgstr "" #: ../../exercises/tcp-2.rst:98 msgid "The third segment of the three-way handshake is sent by packetdrill_ after a delay of 0.1 seconds. The connection is now established and the accept system call will succeed." msgstr "" #: ../../exercises/tcp-2.rst:105 msgid "The :manpage:`accept` system call returns a new file descriptor, in this case value ``4``. At this point, packetdrill_ can write data on the socket or inject packets." msgstr "" #: ../../exercises/tcp-2.rst:113 msgid "packetdrill_ writes 10 bytes of data through the :manpage:`write` system call. The stack immediately sends these 10 bytes inside a segment whose ``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` and ends at sequence number ``10``. packetdrill_ replies by injecting an acknowledgment for the entire data after 100 milliseconds." msgstr "" #: ../../exercises/tcp-2.rst:115 msgid "packetdrill_ can also inject data that will be read by the stack as shown by the lines below." msgstr "" #: ../../exercises/tcp-2.rst:123 msgid "In the example above, packetdrill_ injects a segment containing two bytes. This segment is acknowledged and after that the :manpage:`read` system call succeeds and reads the available data with a buffer of 1000 bytes. It returns the amount of read bytes, i.e. ``2``." msgstr "" #: ../../exercises/tcp-2.rst:125 msgid "We can now close the connection gracefully. Let us first issue inject a segment with the ``FIN`` flag set." msgstr "" #: ../../exercises/tcp-2.rst:133 msgid "packetdrill_ injects the ``FIN`` segment and the instrumented kernel returns an acknowledgment. If packetdrill_ issues the :manpage:`close` system call, the kernel will send a ``FIN`` segment to terminate the connection. packetdrill_ injects an acknowledgment to confirm the end of the connection." msgstr "" #: ../../exercises/tcp-2.rst:142 msgid "The complete packetdrill_ script is available from :download:`/exercises/packetdrill_scripts/connect.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:145 msgid "Another interesting features of packetdrill_ is that it is possible to inspect the state maintained by the Linux kernel for the underlying connection using the ``TCP_INFO`` socket option. This makes it possible to retrieve the value of some variables of the TCP control block." msgstr "" #: ../../exercises/tcp-2.rst:147 msgid "Let us first explore how a TCP connection can be established. In the previous script, we have injected the segments that a client would send to a server. We can also use the Linux stack as a client and inject the segments that a server would return. Such a client process would first create its :manpage:`socket`` and then issue the :manpage:`connect` system call. At this point, the stack sends a ``SYN`` segment. To simplify the scripts, we have configured the stack to use a ``MSS`` of 1000 bytes and disabled the TCP extensions (the details of this configuration may be found at the beginning of the script). The server replies with a ``SYN+ACK`` and the stack sends acknowledges it to finish the three-way-handshake." msgstr "" #: ../../exercises/tcp-2.rst:165 msgid "The ``tcpi_state`` variable used in this script is returned by ``TCP_INFO`` [#ftcpinfo]_. It tracks the state of the TCP connection according to TCP's finite state machine [#fstates]_. This script is available from :download:`/exercises/packetdrill_scripts/client.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:167 msgid "Another example is the simultaneous establishment of a TCP connection. The TCP stack sends a ``SYN`` and receives a ``SYN`` in response instead of a ``SYN+ACK``. It then acknowledges the received ``SYN`` and retransmits its own ``SYN``. The connection becomes established upon reception of the fourth segment. This script is available from :download:`/exercises/packetdrill_scripts/dual.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:191 msgid "Another usage of packetdrill_ is to explore how a TCP connection ends. The scripts below show how a TCP stack closes a TCP connection. The first example shows a local host that connects to a remote host and then closes the connection. The remote host acknowledges the ``FIN`` and later closes its direction of data transfer. This script is available from :download:`/exercises/packetdrill_scripts/local-close.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:213 msgid "As for the establishment of a connection, it is also possible for the two communicating hosts to close the connection at the same time. This is shown in the example below where the remote host sends its own ``FIN`` when acknowledging the first one. This script is available from :download:`/exercises/packetdrill_scripts/local-close2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:234 msgid "A third scenario for the termination of a TCP connection is that the remote hosts sends its ``FIN`` first. This script is available from :download:`/exercises/packetdrill_scripts/remote-close.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:259 msgid "Another very interesting utilization of packetdrill_ is to explore how a TCP stack reacts to acknowledgments that would correspond to lost or reordered segments. For this analysis, we configure a very large initial congestion window to ensure that the connection does not start with a slow-start." msgstr "" #: ../../exercises/tcp-2.rst:261 msgid "Let us first use packetdrill_ to explore the evolution of the TCP retransmission timeout. The value of this timeout is set based on the measured round-trip-time and its variance. When the retransmission timer expires, TCP doubles the retransmission timer. This exponential backoff mechanism is important to ensure that TCP slowdowns during very severe congestion periods. We use the ``tcpi_rto`` variable from ``TCP_INFO`` to track the evolution of the retransmission timer. This script is available from :download:`/exercises/packetdrill_scripts/rto.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:293 msgid "We can use a similar code to demonstrate that the TCP stack performs a fast retransmit after having received three duplicate acknowledgments. This script is available from :download:`/exercises/packetdrill_scripts/frr.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:326 msgid "A TCP stack uses both the fast retransmit technique and retransmission timers. A retransmission timer can fire after a fast retransmit when several segments are lost. The example below shows a loss of two consecutive segments. This script is available from :download:`/exercises/packetdrill_scripts/frr-rto.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:364 msgid "More complex scenarios can be written. The script below demonstrates how the TCP stack behaves when three segments are lost. This script is available from :download:`/exercises/packetdrill_scripts/frr-rto2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:411 msgid "The examples above have demonstrated how TCP retransmits lost segments. However, they did not consider the interactions with the congestion control scheme since the use a large initial congestion window. We now set the initial congestion window to two MSS-sized segments and use the ``tcpi_snd_cwnd`` and ``tcpi_snd_ssthresh`` variables from ``TCP_INFO`` to explore the evolution of the TCP congestion control scheme. Our first script looks at the evolution of the congestion window during a slow-start when there are no losses. This script is available from :download:`/exercises/packetdrill_scripts/slow-start.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:459 msgid "Some TCP clients use delayed acknowledgments and send a TCP acknowledgment after after second in-sequence segment. This behavior is illustrated in the script below. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-delayed.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:502 msgid "We can now explore how TCP's retransmission techniques interact with the congestion control scheme. The Linux TCP code that combines these two techniques contains several heuristics to improve their performance. We start with a transfer of 8KBytes where the penultimate segment is not received by the remote host. In this case, TCP does not receive enough acknowledgments to trigger the fast retransmit and it must wait for the expiration of the retransmission timer. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-rto2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:546 msgid "Another interesting scenario is when the loss happens early in the data transfer. This is shown in the script below where the second segment is lost. We observe that by triggering transmissions of unacknowledged data, the :rfc:`3042` rule speeds up the recovery since a fast retransmit happens. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-frr2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:593 msgid "Our last scenario is when the first segment sent is lost. In this case, two round-trip-times are required to retransmit the missing segment and recover from the loss. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-frr3.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:637 msgid "Open questions" msgstr "" #: ../../exercises/tcp-2.rst:639 msgid "Unless otherwise noted, we assume for the questions in this section that the following conditions hold." msgstr "" #: ../../exercises/tcp-2.rst:641 msgid "the sender/receiver performs a single :manpage:`send(3)` of `x` bytes" msgstr "" #: ../../exercises/tcp-2.rst:642 msgid "the round-trip-time is fixed and does not change during the lifetime of the TCP connection. We assume a fixed value of 100 milliseconds for the round-trip-time and a fixed value of 200 milliseconds for the retransmission timer." msgstr "" #: ../../exercises/tcp-2.rst:643 msgid "the delay required to transmit a single TCP segment containing MSS bytes is small and set to 1 milliseconds, independently of the MSS size" msgstr "" #: ../../exercises/tcp-2.rst:644 msgid "the transmission delay for a TCP acknowledgment is negligible" msgstr "" #: ../../exercises/tcp-2.rst:645 msgid "the initial value of the congestion window is one MSS-sized segment" msgstr "" #: ../../exercises/tcp-2.rst:646 msgid "the value of the duplicate acknowledgment threshold is fixed and set to 3" msgstr "" #: ../../exercises/tcp-2.rst:647 msgid "TCP always acknowledges each received segment" msgstr "" #: ../../exercises/tcp-2.rst:649 msgid "To understand the operation of the TCP congestion control, it is often useful to write time-sequence diagrams for different scenarios. The example below shows the operation of the TCP congestion control scheme in a very simple scenario. The initial congestion window (``cwnd``) is set to 1000 bytes and the receive window (``rwin``) advertised by the receiver (supposed constant for the entire connection) is set to 2000 bytes. The slow-start threshold (``ssthresh``) is set to 64000 bytes." msgstr "" #: ../../exercises/tcp-2.rst:684 msgid "Can you explain why the sender only sends one segment first and then two successive segments (the delay between the two segments on the figure is due to graphical reasons) ?" msgstr "" #: ../../exercises/tcp-2.rst:686 msgid "Can you explain why the congestion window is increased after the reception of the first acknowledgment ?" msgstr "" #: ../../exercises/tcp-2.rst:688 msgid "How long does it take for the sender to deliver 3 KBytes to the receiver ?" msgstr "" #: ../../exercises/tcp-2.rst:691 msgid "Same question as above but now with a small variation. Recent TCP implementations use a large initial value for the congestion window. Draw the time-sequence diagram that corresponds to an initial value of 10000 bytes for this congestion window." msgstr "" #: ../../exercises/tcp-2.rst:715 msgid "Same question as the first one, but consider that the MSS on the sender is set to 500 bytes. How does this modification affect the entire delay ?" msgstr "" #: ../../exercises/tcp-2.rst:738 msgid "Assuming that there are no losses and that there is no congestion in the network. If the sender writes `x` bytes on a newly established TCP connection, derive a formula that computes the minimum time required to deliver all these `x` bytes to the receiver. For the derivation of this formula, assume that `x` is a multiple of the maximum segment size and that the receive window and the slow-start threshold are larger than `x`." msgstr "" #: ../../exercises/tcp-2.rst:740 msgid "In question 1, we assumed that the receiver acknowledged every segment received from the sender. In practice, many deployed TCP implementations use delayed acknowledgments. Assuming a delayed acknowledgment timer of 50 milliseconds, modify the time-sequence diagram below to reflect the impact of these delayed acknowledgment. Does their usage decreases or increased the transmission delay ?" msgstr "" #: ../../exercises/tcp-2.rst:775 msgid "Let us now explore the impact of congestion on the slow-start and congestion avoidance mechanisms. Consider the scenario below. For graphical reasons, it is not possible anymore to show information about the segments on the graph, but you can easily infer them." msgstr "" #: ../../exercises/tcp-2.rst:832 msgid "Redraw the same figure assuming that the second segment that was delivered by the sender in the figure experienced congestion. In a network that uses Explicit Congestion Notification, this segment would be marked by routers and the receiver would return the congestion mark in the corresponding acknowledgment." msgstr "" #: ../../exercises/tcp-2.rst:834 msgid "Same question, but assume now that the fourth segment delivered by the sender experienced congestion (but was not discarded)." msgstr "" #: ../../exercises/tcp-2.rst:837 msgid "A TCP connection has been active for some time and has reached a congestion window of 4000 bytes. Four segments are sent, but the second (shown in red in the figure) is corrupted. Complete the time-sequence diagram." msgstr "" #: ../../exercises/tcp-2.rst:871 msgid "Footnotes" msgstr "" #: ../../exercises/tcp-2.rst:876 msgid "On Linux, most of the parameters to tune the TCP stack are accessible via :manpage:`sysctl`. These parameters are briefly described in https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt and in the :manpage:`tcp` manpage. Each script sets some of these configuration variables." msgstr "" #: ../../exercises/tcp-2.rst:883 msgid "packetdrill_ requires root privileges since it inject raw IP packets. The easiest way to install it is to use a virtualbox image with a Linux kernel 4.x or 5.x. You can clone its git repository from https://github.com/google/packetdrill and follow the instructions in https://github.com/google/packetdrill/tree/master/gtests/net/packetdrill. The packetdrill_ scripts used in this section are available from https://github.com/cnp3/ebook/tree/master/exercises/packetdrill_scripts" msgstr "" #: ../../exercises/tcp-2.rst:885 msgid "By default, packetdrill_ uses port 8080 when creating TCP segments. You can thus capture the packets injected by packetdrill_ and the responses from the stack by using ``tcpdump -i any -n port 8080``" msgstr "" #: ../../exercises/tcp-2.rst:887 msgid "The `Push` flag is one of the TCP flags defined in :rfc:`793`. TCP stacks usually set this flag when transmitting a segment that empties the send buffer. This is the reason why we observe this push flag in our example." msgstr "" #: ../../exercises/tcp-2.rst:889 msgid "The variables that are included in TCP_INFO are defined in https://github.com/torvalds/linux/blob/master/include/uapi/linux/tcp.h" msgstr "" #: ../../exercises/tcp-2.rst:891 msgid "These states are defined in https://github.com/torvalds/linux/blob/master/include/net/tcp_states.h" msgstr ""