2. cnp3-ebook
3. protocols/congestion
4. English
5. Zen

37 ../../protocols/congestion.rst:199
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As the losses are equally spaced, the congestion window always starts at some value (:math:`\frac{W}{2}`), and is incremented by one MSS every round-trip-time until it reaches twice this value (`W`). At this point, a segment is retransmitted and the cycle starts again. If the congestion window is measured in MSS-sized segments, a cycle lasts :math:`\frac{W}{2}` round-trip-times. The bandwidth of the TCP connection is the number of bytes that have been transmitted during a given period of time. During a cycle, the number of segments that are sent on the TCP connection is equal to the area of the yellow trapeze in the figure. Its area is thus : 650/10000 · 650
38 ../../protocols/congestion.rst:201
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`area=(\frac{W}{2})^2 + \frac{1}{2} \times (\frac{W}{2})^2 = \frac{3 \times W^2}{8}` 90/10000 · 90
39 ../../protocols/congestion.rst:203
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, given the regular losses that we consider, the number of segments that are sent between two losses (i.e. during a cycle) is by definition equal to :math:`\frac{1}{p}`. Thus, :math:`W=\sqrt{\frac{8}{3 \times p}}=\frac{k}{\sqrt{p}}`. The throughput (in bytes per second) of the TCP connection is equal to the number of segments transmitted divided by the duration of the cycle : 385/10000 · 385
40 ../../protocols/congestion.rst:205
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`Throughput=\frac{area \times MSS}{time} = \frac{ \frac{3 \times W^2}{8}}{\frac{W}{2} \times rtt}` or, after having eliminated `W`, :math:`Throughput=\sqrt{\frac{3}{2}} \times \frac{MSS}{rtt \times \sqrt{p}}` 214/10000 · 214
41 ../../protocols/congestion.rst:209
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — More detailed models and the analysis of simulations have shown that a first order model of the TCP throughput when losses occur was :math:`Throughput \approx \frac{k \times MSS}{rtt \times \sqrt{p}}`. This is an important result which shows that : 248/10000 · 248
42 ../../protocols/congestion.rst:211
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connections with a small round-trip-time can achieve a higher throughput than TCP connections having a longer round-trip-time when losses occur. This implies that the TCP congestion control scheme is not completely fair since it favors the connections that have the shorter round-trip-times. 295/10000 · 295
43 ../../protocols/congestion.rst:212
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connections that use a large MSS can achieve a higher throughput that the TCP connections that use a shorter MSS. This creates another source of unfairness between TCP connections. However, it should be noted that today most hosts are using almost the same MSS, roughly 1460 bytes. 285/10000 · 285
44 ../../protocols/congestion.rst:214
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In general, the maximum throughput that can be achieved by a TCP connection depends on its maximum window size and the round-trip-time if there are no losses. If there are losses, it depends on the MSS, the round-trip-time and the loss ratio. 242/10000 · 242
45 ../../protocols/congestion.rst:216
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`Throughput<\min(\frac{window}{rtt},\frac{k \times MSS}{rtt \times \sqrt{p}})` 84/10000 · 84
46 ../../protocols/congestion.rst:219
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The TCP congestion control zoo 30/10000 · 30
47 ../../protocols/congestion.rst:221
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first TCP congestion control scheme was proposed by `Van Jacobson`_ in [Jacobson1988]_. In addition to writing the scientific paper, `Van Jacobson`_ also implemented the slow-start and congestion avoidance schemes in release 4.3 `Tahoe` of the BSD Unix distributed by the University of Berkeley. Later, he improved the congestion control by adding the fast retransmit and the fast recovery mechanisms in the `Reno` release of 4.3 BSD Unix. Since then, many researchers have proposed, simulated and implemented modifications to the TCP congestion control scheme. Some of these modifications are still used today, e.g. : 622/10000 · 622
48 ../../protocols/congestion.rst:223
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `NewReno` (:rfc:`3782`), which was proposed as an improvement of the fast recovery mechanism in the `Reno` implementation. 122/10000 · 122
49 ../../protocols/congestion.rst:224
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `TCP Vegas`, which uses changes in the round-trip-time to estimate congestion in order to avoid it [BOP1994]_. This is one of the examples of the delay-based congestion control algorithms. A Vegas sender continuously measures the evolution of the round-trip-time and slows down when the round-trip-time increases significantly. This enables Vegas to prevent congestion when used alone. Unfortunately, if Vegas senders compete with more aggressive TCP congestion control schemes that only react to losses, Vegas senders may have difficulties to user their fair share of the available bandwidth. 593/10000 · 593
50 ../../protocols/congestion.rst:225
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `CUBIC`, which was designed for high bandwidth links and is the default congestion control scheme in Linux since the Linux 2.6.19 kernel [HRX2008]_. It is now used by several operating systems and is becoming the default congestion control scheme :rfc:`8312`. A key difference between CUBIC and the TCP congestion control scheme described in this chapter is that CUBIC is much more aggressive when probing the network. Instead of relying on additive increase after a fast recovery, a CUBIC sender adjusts its congestion by using a cubic function. Thanks to this function, the congestion windows grows faster. This is particularly important in high-bandwidth delay networks. 673/10000 · 673
51 ../../protocols/congestion.rst:226
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `BBR`, which is being developed by Google researchers and is included in recent Linux kernels [CCG+2016]_. BBR periodically estimates the available bandwidth and the round-trip-times. To adapt to changes in network conditions, BBR regularly tries to send at 1.25 times the current bandwidth. This enables BBR senders to probe the network, but can also cause large amount of losses. Recent scientific articles indicate that BBR is unfair to other congestion control schemes in specific conditions [WMSS2019]_. 508/10000 · 508
52 ../../protocols/congestion.rst:229
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A wide range of congestion control schemes have been proposed in the scientific literature and several of them have been widely deployed. A detailed comparison of these congestion control schemes is outside the scope of this chapter. A recent survey paper describing many of the implemented TCP congestion control schemes may be found in [TKU2019]_. 349/10000 · 349
53 ../../protocols/congestion.rst:235
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
54 ../../protocols/congestion.rst:236
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this pseudo-code, we assume that TCP uses unlimited sequence and acknowledgment numbers. Furthermore, we do not detail how the `cwnd` is adjusted after the retransmission of the lost segment by fast retransmit. Additional details may be found in :rfc:`5681`. 261/10000 · 261
55 ../../protocols/congestion.rst:238
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In enterprise networks or datacenters, the situation is different since a single company typically controls all the sources and all the routers. In such networks it is possible to ensure that all hosts and routers have been upgraded before turning on ECN on the routers. 270/10000 · 270
56 ../../protocols/congestion.rst:240
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With the ECT bit, the deployment issue with ECN is solved provided that all sources cooperate. If some sources do not support ECN but still set the ECT bit in the packets that they sent, they will have an unfair advantage over the sources that correctly react to packet markings. Several solutions have been proposed to deal with this problem :rfc:`3540`, but they are outside the scope of this book. 400/10000 · 400