71 strings / 2733 words

Translation Source string Target string
cnp3-ebook/exercises/tcp-2 — English
A closer look at TCP
A closer look at TCP
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
Injecting segments in the Linux TCP stack
Injecting segments in the Linux TCP stack
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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]_.
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]_.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
packetdrill_ executes a system call and verifies its return value
packetdrill_ executes a system call and verifies its return value
cnp3-ebook/exercises/tcp-2 — English
packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux kernel as if it were received from the network
packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux kernel as if it were received from the network
cnp3-ebook/exercises/tcp-2 — English
packetdrill_ compares a packet transmitted by the instrumented Linux kernel with the packet that the script expects
packetdrill_ compares a packet transmitted by the instrumented Linux kernel with the packet that the script expects
cnp3-ebook/exercises/tcp-2 — English
For our first packetdrill_ script, we aim at reproducing the simple connection shown in the figure below.
For our first packetdrill_ script, we aim at reproducing the simple connection shown in the figure below.
cnp3-ebook/exercises/tcp-2 — English
Let us start with the execution of a system call. A simple example is shown below.
Let us start with the execution of a system call. A simple example is shown below.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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]_.
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]_.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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 (``<...>``).
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 (``<...>``).
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
packetdrill_ can also inject data that will be read by the stack as shown by the lines below.
packetdrill_ can also inject data that will be read by the stack as shown by the lines below.
cnp3-ebook/exercises/tcp-2 — English
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``.
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``.
cnp3-ebook/exercises/tcp-2 — English
We can now close the connection gracefully. Let us first issue inject a segment with the ``FIN`` flag set.
We can now close the connection gracefully. Let us first issue inject a segment with the ``FIN`` flag set.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
The complete packetdrill_ script is available from :download:`/exercises/packetdrill_scripts/connect.pkt`.
The complete packetdrill_ script is available from :download:`/exercises/packetdrill_scripts/connect.pkt`.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
Open questions
Open questions
cnp3-ebook/exercises/tcp-2 — English
Unless otherwise noted, we assume for the questions in this section that the following conditions hold.
Unless otherwise noted, we assume for the questions in this section that the following conditions hold.
cnp3-ebook/exercises/tcp-2 — English
the sender/receiver performs a single :manpage:`send(3)` of `x` bytes
the sender/receiver performs a single :manpage:`send(3)` of `x` bytes
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
the delay required to transmit a single TCP segment containing MSS bytes is small and set to 1 milliseconds, independently of the MSS size
the delay required to transmit a single TCP segment containing MSS bytes is small and set to 1 milliseconds, independently of the MSS size
cnp3-ebook/exercises/tcp-2 — English
the transmission delay for a TCP acknowledgment is negligible
the transmission delay for a TCP acknowledgment is negligible
cnp3-ebook/exercises/tcp-2 — English
the initial value of the congestion window is one MSS-sized segment
the initial value of the congestion window is one MSS-sized segment
cnp3-ebook/exercises/tcp-2 — English
the value of the duplicate acknowledgment threshold is fixed and set to 3
the value of the duplicate acknowledgment threshold is fixed and set to 3
cnp3-ebook/exercises/tcp-2 — English
TCP always acknowledges each received segment
TCP always acknowledges each received segment
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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) ?
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) ?
cnp3-ebook/exercises/tcp-2 — English
Can you explain why the congestion window is increased after the reception of the first acknowledgment ?
Can you explain why the congestion window is increased after the reception of the first acknowledgment ?
cnp3-ebook/exercises/tcp-2 — English
How long does it take for the sender to deliver 3 KBytes to the receiver ?
How long does it take for the sender to deliver 3 KBytes to the receiver ?
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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 ?
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 ?
cnp3-ebook/exercises/tcp-2 — English
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`.
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`.
cnp3-ebook/exercises/tcp-2 — English
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 ?
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 ?
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
Same question, but assume now that the fourth segment delivered by the sender experienced congestion (but was not discarded).
Same question, but assume now that the fourth segment delivered by the sender experienced congestion (but was not discarded).
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — French
Footnotes
Notes de pied de page
cnp3-ebook/exercises/tcp-2 — English
Footnotes
Footnotes
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
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
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
cnp3-ebook/exercises/tcp-2 — English
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``
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``
cnp3-ebook/exercises/tcp-2 — English
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.
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.
cnp3-ebook/exercises/tcp-2 — English
The variables that are included in TCP_INFO are defined in https://github.com/torvalds/linux/blob/master/include/uapi/linux/tcp.h
The variables that are included in TCP_INFO are defined in https://github.com/torvalds/linux/blob/master/include/uapi/linux/tcp.h
cnp3-ebook/exercises/tcp-2 — English
These states are defined in https://github.com/torvalds/linux/blob/master/include/net/tcp_states.h
These states are defined in https://github.com/torvalds/linux/blob/master/include/net/tcp_states.h