cnp3-ebook/exercises/tcp-2 — French @ Weblate: To understand the operation of the TCP congestion control, it …

Zen

Translation

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.

French

Needs editing

Skip

	English	French	Actions
	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`.
	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`.
	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`.
	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`.
	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`.
	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`.
	Open questions
	Unless otherwise noted, we assume for the questions in this section that the following conditions hold.
	the sender/receiver performs a single :manpage:`send(3)` of `x` bytes
	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 delay required to transmit a single TCP segment containing MSS bytes is small and set to 1 milliseconds, independently of the MSS size
	the transmission delay for a TCP acknowledgment is negligible
	the initial value of the congestion window is one MSS-sized segment
	the value of the duplicate acknowledgment threshold is fixed and set to 3
	TCP always acknowledges each received segment
	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.
	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 congestion window is increased after the reception of the first acknowledgment ?
	How long does it take for the sender to deliver 3 KBytes to the receiver ?
	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 the first one, but consider that the MSS on the sender is set to 500 bytes. How does this modification affect the entire delay ?
	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`.
	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 ?
	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.
	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.
	Same question, but assume now that the fourth segment delivered by the sender experienced congestion (but was not discarded).
	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.
	Footnotes	Notes de pied de page
	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.
	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
	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``

Loading…

None

Source string added

English 0 characters edited

4 years ago

Browse all string changes

Glossary

English	French
No related strings found in the glossary.

30636 String information

Source string location

../../exercises/tcp-2.rst:649

String age

4 years ago

Last updated

a month ago

Source string age

4 years ago

Translation file

locale/fr/LC_MESSAGES/exercises/tcp-2.po, string 52

Shortcut	Action
`?`	Open available keyboard shortcuts.
`Alt` + `Home`	Navigate to the first translation in the current search.
`Alt` + `End`	Navigate to the last translation in the current search.
`Alt` + `PageUp` or `Ctrl` + `↑` or `Alt` + `↑` or `Cmd` + `↑` or	Navigate to the previous translation in the current search.
`Alt` + `PageDown` or `Ctrl` + `↓` or `Alt` + `↓` or `Cmd` + `↓` or	Navigate to the next translation in the current search.
`Ctrl` + `Enter` or `Cmd` + `Enter`	Submit current form; this works the same as pressing Save and continue while editing translation.
`Ctrl` + `Shift` + `Enter` or `Cmd` + `Shift` +`Enter`	Unmark translation as Needing edit and submit it.
`Alt` + `Enter` or `Option` + `Enter`	Submit the string as a suggestion; this works the same as pressing Suggest while editing translation.
`Ctrl` + `E` or `Cmd` + `E`	Focus on translation editor.
`Ctrl` + `U` or `Cmd` + `U`	Focus on comment editor.
`Ctrl` + `M` or `Cmd` + `M`	Shows Automatic suggestions tab.
`Ctrl` + `1` to `Ctrl` + `9` or `Cmd` + `1` to `Cmd` + `9`	Copies placeable of a given number from source string.
`Ctrl` + `M` followed by `1` to `9` or `Cmd` + `M` followed by `1` to `9`	Copy the machine translation of a given number to current translation.
`Ctrl` + `I` followed by `1` to `9` or `Cmd` + `I` followed by `1` to `9`	Ignore one item in the list of failing checks.
`Ctrl` + `J` or `Cmd` + `J`	Shows the Nearby strings tab.
`Ctrl` + `S` or `Cmd` + `S`	Focus on search field.
`Ctrl` + `O` or `Cmd` + `O`	Copy the source string.
`Ctrl` + `Y` or `Cmd` + `Y`	Toggle the Needs editing checkbox.
`→`	Browse the next translation string.
`←`	Browse the previous translation string.