English French Actions
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 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 and follow the instructions in The packetdrill_ scripts used in this section are available from
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``
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 variables that are included in TCP_INFO are defined in
These states are defined in

Showing only subset of the strings as there were too many matches.

Component Translation Difference to current string
This translation Propagated Translated cnp3-ebook/exercises/tcp-2
The following strings have the same context and source.
Propagated Translated cnp3-ebook/exercises/sockets
Propagated Translated cnp3-ebook/exercises/transport
Propagated Translated cnp3-ebook/principles/naming
Propagated Translated cnp3-ebook/principles/network
Propagated Translated cnp3-ebook/principles/referencemodels
Propagated Translated cnp3-ebook/protocols/dns
Propagated Translated cnp3-ebook/principles/security
Propagated Translated cnp3-ebook/exercises/dns
Propagated Translated cnp3-ebook/exercises/email
Propagated Translated cnp3-ebook/exercises/http
Propagated Translated cnp3-ebook/exercises/tcp
Propagated Translated cnp3-ebook/exercises/tls
Propagated Empty cnp3-ebook/protocols/bgp
Propagated Empty cnp3-ebook/protocols/congestion
Propagated Empty cnp3-ebook/protocols/dnssec
Propagated Empty cnp3-ebook/protocols/email
Propagated Empty cnp3-ebook/protocols/ethernet
Propagated Empty cnp3-ebook/protocols/http
Propagated Empty cnp3-ebook/protocols/http2


User avatar gegoa

New translation

cnp3-ebook / exercises/tcp-2French

a year ago
User avatar None

New source string

cnp3-ebook / exercises/tcp-2French

New source string a year ago
Browse all component changes

Things to check


This string has more than one translation in this project or is untranslated in some components.



English French
No related strings found in the glossary.

String information

Source string location
String age
a year ago
Source string age
a year ago
Translation file
locale/fr/LC_MESSAGES/exercises/tcp-2.po, string 64