Exit Zen
37
../../exercises/tcp-2.rst:364
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`.
0/2110 · 211
38
../../exercises/tcp-2.rst:411
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`.
0/6170 · 617
39
../../exercises/tcp-2.rst:459
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`.
0/2610 · 261
40
../../exercises/tcp-2.rst:502
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`.
0/5610 · 561
41
../../exercises/tcp-2.rst:546
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`.
0/3880 · 388
42
../../exercises/tcp-2.rst:593
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`.
0/2600 · 260
43
../../exercises/tcp-2.rst:637
English
Open questions
0/140 · 14
44
../../exercises/tcp-2.rst:639
English
Unless otherwise noted, we assume for the questions in this section that the following conditions hold.
0/1030 · 103
45
../../exercises/tcp-2.rst:641
English
the sender/receiver performs a single :manpage:`send(3)` of `x` bytes
0/690 · 69
46
../../exercises/tcp-2.rst:642
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.
0/2270 · 227
47
../../exercises/tcp-2.rst:643
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
0/1380 · 138
48
../../exercises/tcp-2.rst:644
English
the transmission delay for a TCP acknowledgment is negligible
0/610 · 61
49
../../exercises/tcp-2.rst:645
English
the initial value of the congestion window is one MSS-sized segment
0/670 · 67
50
../../exercises/tcp-2.rst:646
English
the value of the duplicate acknowledgment threshold is fixed and set to 3
0/730 · 73
51
../../exercises/tcp-2.rst:647
English
TCP always acknowledges each received segment
0/450 · 45
52
../../exercises/tcp-2.rst:649
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.
0/4900 · 490
53
../../exercises/tcp-2.rst:684
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) ?
0/1730 · 173
54
../../exercises/tcp-2.rst:686
English
Can you explain why the congestion window is increased after the reception of the first acknowledgment ?
0/1040 · 104
55
../../exercises/tcp-2.rst:688
English
How long does it take for the sender to deliver 3 KBytes to the receiver ?
0/740 · 74
56
../../exercises/tcp-2.rst:691
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.
0/2450 · 245