msgid "" msgstr "" "Project-Id-Version: English (cnp3-ebook)\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2026-04-19 07:27+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: English \n" "Language: en\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n != 1;\n" "X-Generator: Weblate 5.14.3\n" #: ../../exercises/tcp-2.rst:8 #, read-only msgid "A closer look at TCP" msgstr "A closer look at TCP" #: ../../exercises/tcp-2.rst:10 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:14 #, read-only msgid "Injecting segments in the Linux TCP stack" msgstr "Injecting segments in the Linux TCP stack" #: ../../exercises/tcp-2.rst:16 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:18 #, read-only 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 "" "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]_." #: ../../exercises/tcp-2.rst:20 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:22 #, read-only msgid "packetdrill_ executes a system call and verifies its return value" msgstr "packetdrill_ executes a system call and verifies its return value" #: ../../exercises/tcp-2.rst:23 #, read-only msgid "" "packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux " "kernel as if it were received from the network" msgstr "" "packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux " "kernel as if it were received from the network" #: ../../exercises/tcp-2.rst:24 #, read-only msgid "" "packetdrill_ compares a packet transmitted by the instrumented Linux kernel " "with the packet that the script expects" msgstr "" "packetdrill_ compares a packet transmitted by the instrumented Linux kernel " "with the packet that the script expects" #: ../../exercises/tcp-2.rst:26 #, read-only msgid "" "For our first packetdrill_ script, we aim at reproducing the simple " "connection shown in the figure below." msgstr "" "For our first packetdrill_ script, we aim at reproducing the simple " "connection shown in the figure below." #: ../../exercises/tcp-2.rst:57 #, read-only msgid "" "Let us start with the execution of a system call. A simple example is shown " "below." msgstr "" "Let us start with the execution of a system call. A simple example is shown " "below." #: ../../exercises/tcp-2.rst:63 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:65 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:80 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:86 #, read-only 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 "" "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]_." #: ../../exercises/tcp-2.rst:88 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:95 #, read-only 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 "" "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 (``<...>``)." #: ../../exercises/tcp-2.rst:98 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:105 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:113 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:115 #, read-only msgid "" "packetdrill_ can also inject data that will be read by the stack as shown by " "the lines below." msgstr "" "packetdrill_ can also inject data that will be read by the stack as shown by " "the lines below." #: ../../exercises/tcp-2.rst:123 #, read-only 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 "" "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``." #: ../../exercises/tcp-2.rst:125 #, read-only msgid "" "We can now close the connection gracefully. Let us first issue inject a " "segment with the ``FIN`` flag set." msgstr "" "We can now close the connection gracefully. Let us first issue inject a " "segment with the ``FIN`` flag set." #: ../../exercises/tcp-2.rst:133 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:142 #, read-only msgid "" "The complete packetdrill_ script is available from :download:`/exercises/" "packetdrill_scripts/connect.pkt`." msgstr "" "The complete packetdrill_ script is available from :download:`/exercises/" "packetdrill_scripts/connect.pkt`." #: ../../exercises/tcp-2.rst:145 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:147 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:165 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:167 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:191 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:213 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:234 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:259 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:261 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:293 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:326 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:364 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:411 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:459 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:502 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:546 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:593 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:637 #, read-only msgid "Open questions" msgstr "Open questions" #: ../../exercises/tcp-2.rst:639 #, read-only msgid "" "Unless otherwise noted, we assume for the questions in this section that the " "following conditions hold." msgstr "" "Unless otherwise noted, we assume for the questions in this section that the " "following conditions hold." #: ../../exercises/tcp-2.rst:641 #, read-only msgid "the sender/receiver performs a single :manpage:`send(3)` of `x` bytes" msgstr "the sender/receiver performs a single :manpage:`send(3)` of `x` bytes" #: ../../exercises/tcp-2.rst:642 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:643 #, read-only 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 "" "the delay required to transmit a single TCP segment containing MSS bytes is " "small and set to 1 milliseconds, independently of the MSS size" #: ../../exercises/tcp-2.rst:644 #, read-only msgid "the transmission delay for a TCP acknowledgment is negligible" msgstr "the transmission delay for a TCP acknowledgment is negligible" #: ../../exercises/tcp-2.rst:645 #, read-only msgid "the initial value of the congestion window is one MSS-sized segment" msgstr "the initial value of the congestion window is one MSS-sized segment" #: ../../exercises/tcp-2.rst:646 #, read-only msgid "" "the value of the duplicate acknowledgment threshold is fixed and set to 3" msgstr "" "the value of the duplicate acknowledgment threshold is fixed and set to 3" #: ../../exercises/tcp-2.rst:647 #, read-only msgid "TCP always acknowledges each received segment" msgstr "TCP always acknowledges each received segment" #: ../../exercises/tcp-2.rst:649 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:684 #, read-only 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 "" "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) ?" #: ../../exercises/tcp-2.rst:686 #, read-only msgid "" "Can you explain why the congestion window is increased after the reception " "of the first acknowledgment ?" msgstr "" "Can you explain why the congestion window is increased after the reception " "of the first acknowledgment ?" #: ../../exercises/tcp-2.rst:688 #, read-only msgid "" "How long does it take for the sender to deliver 3 KBytes to the receiver ?" msgstr "" "How long does it take for the sender to deliver 3 KBytes to the receiver ?" #: ../../exercises/tcp-2.rst:691 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:715 #, read-only 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 "" "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 ?" #: ../../exercises/tcp-2.rst:738 #, read-only 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 "" "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`." #: ../../exercises/tcp-2.rst:740 #, read-only 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 "" "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 ?" #: ../../exercises/tcp-2.rst:775 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:832 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:834 #, read-only msgid "" "Same question, but assume now that the fourth segment delivered by the " "sender experienced congestion (but was not discarded)." msgstr "" "Same question, but assume now that the fourth segment delivered by the " "sender experienced congestion (but was not discarded)." #: ../../exercises/tcp-2.rst:837 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:871 #, read-only msgid "Footnotes" msgstr "Footnotes" #: ../../exercises/tcp-2.rst:876 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:883 #, read-only 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 "" "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" #: ../../exercises/tcp-2.rst:885 #, read-only 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 "" "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``" #: ../../exercises/tcp-2.rst:887 #, read-only 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 "" "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." #: ../../exercises/tcp-2.rst:889 #, read-only 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 "" "The variables that are included in TCP_INFO are defined in https://" "github.com/torvalds/linux/blob/master/include/uapi/linux/tcp.h" #: ../../exercises/tcp-2.rst:891 #, read-only msgid "" "These states are defined in https://github.com/torvalds/linux/blob/master/" "include/net/tcp_states.h" msgstr "" "These states are defined in https://github.com/torvalds/linux/blob/master/" "include/net/tcp_states.h"