-There is obviously many valuation of :math:`x_1 \ldots{} x_n` that respect such as set of constraints. SimGrid usually computes
-the instantaneous speeds according to a Max-Mix objective function, that maximizing the minimum over all :math:`x_i`. The
-coefficients associated to each variable in the inequalities are used to model some performance effects, such as the fact that
-TCP tend to favor communications with small RTTs. These coefficients computed from both hardcoded values and from the
-:ref:`latency and bandwidth factors<cfg=network/latency-factor>`.
-
-Once the instantaneous speeds are computed, the simulation kernel computes the earliest terminating action from their speeds and
-remaining work. The simulated time is then updated along with the values in the LMM. The corresponding activities terminate,
-unblocking the corresponding actors that can further execute.
-
-Most of the SimGrid models build upon the LMM solver, that they adapt and configure for a given 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.
+There are obviously many valuations of :math:`\varrho_1, \ldots{}, \varrho_n` that respect such as set of constraints.
+SimGrid usually computes the instantaneous speeds according to a Max-Min objective function, that is maximizing the
+minimum over all :math:`\varrho_i`. The coefficients associated to each variable in the inequalities are used to model
+some performance effects, such as the fact that TCP tends to favor communications with small RTTs. These coefficients
+are computed from both hard-coded values and :ref:`latency and bandwidth factors<cfg=network/latency-factor>` (more
+details on network performance modeling is given in the next section).
+
+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. 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.
+
+The TCP models
+**************
+
+SimGrid provides several network performance models which 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 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 command line, and these models 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 that is
+computed by the TCP model. For sake of realism, the sharing on saturated links is not necessarily a fair sharing.
+Instead, flows receive an amount of bandwidth inversely proportional to their round trip time.
+
+Regardless of the used TCP model, the latency is paid beforehand. It is as if the communication only starts after a
+little delay corresponding to the latency. During that time, the communication has no impact on the links (the other
+communications are not slowed down, because there is no contention yet).
+
+In addition to these LMM-based models, you can use the :ref:`ns-3 simulator as a network model <models_ns3>`. It is much
+more detailed than the pure SimGrid models and thus slower, but it is easier to get more accurate results. Concerning
+the speed, both simulators are linear in the size of their input, but ns-3 has a much larger input in case of large
+steady communications. On the other hand, the SimGrid models must be carefully :ref:`calibrated <models_calibration>` if
+accuracy is really important to your study, while ns-3 models are less demanding with that regard.
+
+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 that then is
+only limited by the link bandwidth. Otherwise, late acknowledgments will reduce the bandwidth.
+
+SimGrid models this mechanism as follows: :math:`realBW = min(physicalBW, \frac{TCP_GAMMA}{2\times latency})` The used
+bandwidth is either the physical bandwidth that is configured in the platform, or a value representing the bandwidth
+limit due to late acknowledgments. This value is the maximal TCP window size (noted TCP Gamma in SimGrid) over the
+round-trip time (i.e. twice the one-way latency). The default value of TCP Gamma is 4194304. This can be changed with
+the :ref:`network/TCP-gamma <cfg=network/TCP-gamma>` configuration item.
+
+Let's compute the time it takes to send 10 Gb of data over a 10 Gb/s link that is otherwise unused. This is always given
+by :math:`latency + size / bandwidth`, but the bandwidth to use 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, it obviously takes one second.
+ - If the link latency is 0.00001s, :math:`gamma/2\times lat=209,715,200,000 \approx 209Gb/s` which is larger than the
+ physical bandwidth. So the physical bandwidth is used (you fully use the link) and the communication takes 1.00001s
+ - If the link latency is 0.001s, :math:`gamma/2\times lat=2,097,152,000 \approx 2Gb/s`, which is smalled than the
+ physical bandwidth. The communication thus fails to fully use the link, and takes 5.12s.
+ - With a link latency of 0.1s, :math:`gamma/2\times lat \approx 21Mb/s`, so the communication takes 512 seconds!
+
+For more details, please refer to "A Network Model for Simulation of Grid Application" by Henri Casanova and Loris
+Marchal (published in 2002, thus the model name).