-are computed from both hardcoded values and :ref:`latency and bandwidth factors<cfg=network/latency-factor>`.
-
-Once the instantaneous speeds are computed, the simulation kernel determines what is the earliest terminating action
-from their respective speeds and remaining amounts of work. The simulated time is then updated along with the values
-in the LMM. As some actions have nothing left to do, the corresponding activities thus terminate, which in turn
-unblocks the corresponding actors that can further execute.
-
-Most of the SimGrid models build upon the LMM solver, that they adapt and configure for their respective usage. **CM02** is the simplest
-LMM model as it does not introduce any correction factors. This model should be used if you prefer understandable results over
-realistic ones. **LV08** (the default model) uses constant factors that are intended to capture common effects such as
-slow-start, or the fact that TCP headers reduce the *effective* bandwidth. **SMPI** use more advanced factors that also capture
-the MPI-specific effects such as the eager vs. rendez-vous communication mode. You can :ref:`pick another
-model<options_model_select>` on the command line, and these models can be :ref:`further configured<options_model>`.
-
-**L07** is rather distinct because it uses another objective function called *bottleneck*. This is because this model is
-intended to be used for parallel tasks that are actions mixing flops and bytes while the Max-Min objective function requires
-that all variables are expressed using the same unit. This is also why in reality, we have one LMM system per resource kind in
-the simulation, but the idea remains similar.
+are computed from both hard-coded values and :ref:`latency and bandwidth factors<cfg=network/latency-factor>` (more
+details on network performance modeling are given in the next section).
+
+Once the instantaneous speeds are computed for all acttions, the simulation kernel computes the earliest terminating action
+given their respective speeds and remaining amounts of work. The simulated time is then updated along with remaning
+amounts of work. At this point, some actions have no remaining work and are removed from the LMM. The corresponding activities thus terminate, which in turn
+unblocks the corresponding actors that can then continue executing.
+
+Most of the SimGrid models build upon the LMM solver, which they adapt and configure in various ways. For CPU
+and disk activities, the LMM-based models are respectively named **Cas01** and **S19**. The existing network models are
+described in the next section.
+
+.. _models_TCP:
+
+The TCP models
+**************
+
+SimGrid provides several network performance models that compute the time taken by each communication in isolation.
+**CM02** is the simplest one. It captures TCP windowing effects, but does not introduce any correction factors. This
+model should be used if you prefer human-understandable results over realistic ones. **LV08** (the default model) uses
+constant factors that are intended to capture common effects such as slow-start, the fact that TCP headers reduce the
+*effective* bandwidth, or TCP's ACK messages. **SMPI** uses more advanced factors that also capture the MPI-specific
+effects such as the switch between the eager vs. rendez-vous communication modes. You can :ref:`choose the
+model <options_model_select>` on via command-line arguments, and each model can be :ref:`further configured <options_model>`.
+
+The LMM solver is then used as described above to compute the effect of contention on the communication time when using TCP.
+For the sake of realism, the sharing on saturated links is not necessarily a fair sharing
+(unless when ``weight-S=0``, in which case the following mechanism is disabled).
+Instead, flows receive an amount of bandwidth inversely proportional to their round trip time. This is modeled
+in the LMM as a priority that depends on the :ref:`weight-S <cfg=network/weight-S>` parameter. More precisely, this
+priority is computed for each flow as :math:`\displaystyle\sum_{l\in links}\left(Lat(l)+\frac{weightS}{Bandwidth(l)}\right)`, i.e., as the sum of the
+latencies of all links traversed by the communication, plus the sum of `weight-S` over the bandwidth of each link along
+the path. This dependency on the link bandwidths is for the model to account for the TCP protocol's reactivity.
+
+Regardless of the TCP model in used, the latency is paid beforehand. It is as if the communication only starts after a
+small delay that corresponds to the end-to-end latency. During that time, the communication has no impact on the links (i.e., the other
+communications are not slowed down, because there is no contention yet).
+
+As an alternative to the above LMM-based models, it is possible to use the :ref:`ns-3 simulator as a network model <models_ns3>`. ns-3 performs
+a mushc more detailed, packet-level simulation
+than the above models. As a result is is much slower but will produce more accurate results.
+Both simulators have time complexity that is linear in the size of their input, but ns-3 has a much larger input in case of large communications
+because it considers individual network packets.
+However, the above SimGrid models must be carefully :ref:`calibrated <models_calibration>` if
+achieve very high accuracy is needed, while ns-3 is less demanding in this regard.
+
+.. _understanding_cm02:
+
+CM02
+====
+
+This is a simple model of TCP performance, where the sender stops sending packets when its TCP window is full. If the
+acknowledgment packets are returned in time to the sender, the TCP window has no impact on the performance, which is then
+only limited by link bandwidths. Otherwise, late acknowledgments will reduce the data transfer rate.
+
+SimGrid models this mechanism as follows: :math:`real\_BW = min(physical\_BW, \frac{TCP\_GAMMA}{2\times latency})` The used
+bandwidth is either the physical bandwidth that is configured in the platform, or a value that represents a bandwidth
+limit due to late acknowledgments. This value is the maximal TCP window size (noted TCP Gamma in SimGrid) divided by the
+round-trip time (i.e. twice the one-way latency). The default value of TCP Gamma is 4194304. This value can be changed with
+the :ref:`network/TCP-gamma <cfg=network/TCP-gamma>` configuration item.
+
+If you want to disable this mechanism altogether (e.g.,to model UDP or memory operations), you should set TCP-gamma
+to 0. Otherwise, the time it takes to send 10 Gib of data over a 10 Gib/s link that is otherwise unused is computed as
+:math:`latency + \frac{size}{bandwidth}`, but the bandwidth in the denominator may be the physical
+one (10Gb/s) or the one induced by the TCP window, depending on the latency:
+
+ - If the link latency is 0, the communication, expectedly, takes one second.
+ - If the link latency is 0.00001s, :math:`\frac{gamma}{2\times lat}=209,715,200,000 \approx 209Gib/s` which is larger than the
+ physical bandwidth. So the physical bandwidth is used (the link is fully utilized) and the communication takes 1.00001s
+ - If the link latency is 0.001s, :math:`\frac{gamma}{2\times lat}=2,097,152,000 \approx 2Gib/s`, which is smaller than the
+ physical bandwidth. The communication thus fails to fully utilize the link and takes about 4.77s.
+ - With a link latency of 0.1s, :math:`gamma/2\times lat \approx 21Mb/s`, so the communication takes about 476.84 + 0.1 seconds!
+ - More cases are tested and their validity checked by the test ``teshsuite/models/cm02-tcpgamma/cm02-tcpgamma.tesh`` in our test suite.
+
+For more details, please refer to "A Network Model for Simulation of Grid Application" by Henri Casanova and Loris
+Marchal (published in 2002, hence the model name).