2. cnp3-ebook
3. English
4. Zen

141 ../../protocols/wifi.rst:22
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.11 6/10000 · 6
141 ../../protocols/tcp.rst:424
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Then, when other rtt measurements are collected, `srtt` and `rttvar` are updated as follows : 93/10000 · 93
141 ../../bibliography.rst:350
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Turkovic, B., Kuipers, F., Uhlig, S., `Fifty Shades of Congestion Control: A Performance and Interactions Evaluation <https://arxiv.org/abs/1903.03852>`_ CoRR abs/1903.03852 (2019) 180/10000 · 180
141 ../../principles/sharing.rst:857
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us consider that host `A` uses a window of three segments. It thus sends three back-to-back segments at `10 Mbps` and then waits for an acknowledgment. Host `A` stops sending segments when its window is full. These segments reach the buffers of router `R1`. The first segment stored in this buffer is sent by router `R1` at a rate of `2 Mbps` to the destination host. Upon reception of this segment, the destination sends an acknowledgment. This acknowledgment allows host `A` to transmit a new segment. This segment is stored in the buffers of router `R1` while it is transmitting the second segment that was sent by host `A`... Thus, after the transmission of the first window of segments, the reliable transport protocol sends one data segment after the reception of each acknowledgment returned by the destination. In practice, the acknowledgments sent by the destination serve as a kind of `clock` that allows the sending host to adapt its transmission rate to the rate at which segments are received by the destination. This `self-clocking` is the first mechanism that allows a window-based reliable transport protocol to adapt to heterogeneous networks [Jacobson1988]_. It depends on the availability of buffers to store the segments that have been sent by the sender but have not yet been transmitted to the destination. 1332/10000 · 1332
142 ../../glossary.rst:135
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — RIP 3/10000 · 3
142 ../../principles/dv.rst:126
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — At this point, all routers can reach all other routers in the network thanks to the routing tables shown in the figure below. 125/10000 · 125
142 ../../principles/reliability.rst:480
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Decoded bit 11/10000 · 11
142 ../../principles/transport.rst:832
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The receiver may adjust its advertised receive window based on its current memory consumption, but also to limit the bandwidth used by the sender. In practice, the receive buffer can also shrink as the application may not able to process the received data quickly enough. In this case, the receive buffer may be completely full and the advertised receive window may shrink to `0`. When the sender receives an acknowledgment with a receive window set to `0`, it is blocked until it receives an acknowledgment with a positive receive window. Unfortunately, as shown in the figure below, the loss of this acknowledgment could cause a deadlock as the sender waits for an acknowledgment while the receiver is waiting for a data segment. 731/10000 · 731
142 ../../principles/sharing.rst:859
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, transport protocols are not only used in this environment. In the global Internet, a large number of hosts send segments to a large number of receivers. For example, let us consider the network depicted below which is similar to the one discussed in [Jacobson1988]_ and :rfc:`896`. In this network, we assume that the buffers of the router are infinite to ensure that no packet is lost. 395/10000 · 395
142 ../../protocols/bgp.rst:492
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BGP data is often collected by establishing BGP sessions between Unix hosts running a BGP daemon and BGP routers in different ASes. The Unix hosts stores all BGP messages received and regular dumps of its BGP routing table. See http://www.routeviews.org, http://www.ripe.net/ris, http://bgp.potaroo.net or http://irl.cs.ucla.edu/topology/. 339/10000 · 339
142 ../../protocols/email.rst:256
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — u 1/10000 · 1
142 ../../protocols/ipv6.rst:447
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below provides an example of a fragmented IPv6 packet containing a UDP segment. The `Next Header` type reserved for the IPv6 fragmentation option is 44. 163/10000 · 163
142 ../../protocols/wifi.rst:22 • ../../protocols/wifi.rst:24 • ../../protocols/wifi.rst:25
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 2.4 GHz 7/10000 · 7
142 ../../protocols/tcp.rst:426
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`rttvar=(1-\beta) \times rttvar + \beta \times |srtt - rtt|` 66/10000 · 66
142 ../../bibliography.rst:352
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Thomborson, C., `The V.42bis Standard for Data-Compressing Modems <http://www.computer.org/portal/web/csdl/doi/10.1109/40.166712>`_, IEEE Micro, September/October 1992 (vol. 12 no. 5), pp. 41-53 194/10000 · 194
143 ../../glossary.rst:137
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Routing Information Protocol. An intradomain routing protocol based on distance vectors that is sometimes used in enterprise networks. RIP is defined in :rfc:`2453`. 165/10000 · 165
143 ../../principles/dv.rst:203
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with link and router failures, routers use the timestamp stored in their routing table. As all routers send their distance vector every `N` seconds, the timestamp of each route should be regularly refreshed. Thus no route should have a timestamp older than `N` seconds, unless the route is not reachable anymore. In practice, to cope with the possible loss of a distance vector due to transmission errors, routers check the timestamp of the routes stored in their routing table every `N` seconds and remove the routes that are older than :math:`3 \times N` seconds. 573/10000 · 573
143 ../../principles/reliability.rst:492
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Other more powerful error correction codes have been proposed and are used in some applications. The `Hamming Code <https://en.wikipedia.org/wiki/Hamming_code>`_ is a clever combination of parity bits that provides error detection and correction capabilities. 259/10000 · 259
143 ../../principles/transport.rst:838
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Risk of deadlock with dynamic windows 37/10000 · 37
143 ../../principles/sharing.rst:903
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If many senders are attached to the left part of the network above, they all send a window full of segments. These segments are stored in the buffers of the router before being transmitted towards their destination. If there are many senders on the left part of the network, the occupancy of the buffers quickly grows. A consequence of the buffer occupancy is that the round-trip-time, measured by the transport protocol, between the sender and the receiver increases. Consider a network where 10,000 bits segments are sent. When the buffer is empty, such a segment requires 1 millisecond to be transmitted on the `10 Mbps` link and 5 milliseconds to be the transmitted on the `2 Mbps` link. Thus, the measured round-trip-time measured is roughly 6 milliseconds if we ignore the propagation delay on the links. If the buffer contains 100 segments, the round-trip-time becomes :math:`1+100 \times 5+ 5` milliseconds as new segments are only transmitted on the `2 Mbps` link once all previous segments have been transmitted. Unfortunately, if the reliable transport protocol uses a retransmission timer and performs `go-back-n` to recover from transmission errors it will retransmit a full window of segments. This increases the occupancy of the buffer and the delay through the buffer... Furthermore, the buffer may store and send on the low bandwidth links several retransmissions of the same segment. This problem is called `congestion collapse`. It occurred several times during the late 1980s on the Internet [Jacobson1988]_. 1528/10000 · 1528