Exit Zen
174
../../principles/reliability.rst:722
English
Utilisation of the sliding window with modulo arithmetic
0/560 · 56
174
../../principles/sharing.rst:783
English
:math:`rate(t+1)=\alpha_N + \beta_N rate(t)` when the network is *not* congested
0/800 · 80
175
../../glossary.rst:177
English
switch
0/100 · 6
175
../../principles/linkstate.rst:33
English
Once a router has discovered its neighbors, it must reliably distribute all its outgoing edges to all routers in the network to allow them to compute their local view of the network topology. For this, each router builds a `link-state packet` (LSP) containing the following information:
0/2860 · 286
175
../../principles/reliability.rst:727
English
Unfortunately, frame losses do not disappear because a reliable protocol uses a sliding window. To recover from losses, a sliding window protocol must define :
0/1590 · 159
175
../../principles/sharing.rst:785
English
With a linear adaption algorithm, :math:`\alpha_C,\alpha_N, \beta_C` and :math:`\beta_N` are constants. The analysis of [CJ1989]_ shows that to be fair and efficient, such a binary rate adaption mechanism must rely on `Additive Increase and Multiplicative Decrease`. When the network is not congested, the hosts should slowly increase their transmission rate (:math:`\beta_N=1~and~\alpha_N>0`). When the network is congested, the hosts must multiplicatively decrease their transmission rate (:math:`\beta_C < 1~and~\alpha_C = 0`). Such an AIMD rate adaptation algorithm can be implemented by the pseudo-code below.
0/6140 · 614
176
../../glossary.rst:179
English
A relay operating in the datalink layer.
0/400 · 40
176
../../principles/linkstate.rst:35
English
LSP.Router: identification (address) of the sender of the LSP
0/610 · 61
176
../../principles/reliability.rst:729
English
a heuristic to detect frame losses
0/340 · 34
176
../../principles/sharing.rst:799
English
Which binary feedback ?
0/230 · 23
177
../../glossary.rst:111
English
SYN cookie
0/100 · 10
177
../../principles/linkstate.rst:36
English
LSP.age: age or remaining lifetime of the LSP
0/450 · 45
177
../../principles/reliability.rst:730
English
a `retransmission strategy` to retransmit the lost frames
0/570 · 57
177
../../principles/sharing.rst:801
English
Two types of binary feedback are possible in computer networks. A first solution is to rely on implicit feedback. This is the solution chosen for TCP. TCP's congestion control scheme [Jacobson1988]_ does not require any cooperation from the router. It only assumes that they use buffers and that they discard packets when there is congestion. TCP uses the segment losses as an indication of congestion. When there are no losses, the network is assumed to be not congested. This implies that congestion is the main cause of packet losses. This is true in wired networks, but unfortunately not always true in wireless networks. Another solution is to rely on explicit feedback. This is the solution proposed in the DECBit congestion control scheme [RJ1995]_ and used in Frame Relay and ATM networks. This explicit feedback can be implemented in two ways. A first solution would be to define a special message that could be sent by routers to hosts when they are congested. Unfortunately, generating such messages may increase the amount of congestion in the network. Such a congestion indication packet is thus discouraged :rfc:`1812`. A better approach is to allow the intermediate routers to indicate, in the packets that they forward, their current congestion status. Binary feedback can be encoded by using one bit in the packet header. With such a scheme, congested routers set a special bit in the packets that they forward while non-congested routers leave this bit unmodified. The destination host returns the congestion status of the network in the acknowledgments that it sends. Details about such a solution in IP networks may be found in :rfc:`3168`. Unfortunately, as of this writing, this solution is still not deployed despite its potential benefits.
0/17630 · 1763
178
../../glossary.rst:113
English
The SYN cookies is a technique used to compute the initial sequence number (ISN)
0/800 · 80
178
../../principles/linkstate.rst:37
English
LSP.seq: sequence number of the LSP
0/350 · 35
178
../../principles/sharing.rst:806
English
Congestion control with a window-based transport protocol
0/570 · 57
179
../../glossary.rst:114
English
TCB
0/100 · 3
179
../../principles/reliability.rst:737
English
The figure below shows the FSM of a simple `go-back-n` receiver. This receiver uses two variables : `lastack` and `next`. `next` is the next expected sequence number and `lastack` the sequence number of the last data frame that has been acknowledged. The receiver only accepts the frame that are received in sequence. `maxseq` is the number of different sequence numbers (:math:`2^n`).
0/3850 · 385
179
../../principles/sharing.rst:809
English
AIMD controls congestion by adjusting the transmission rate of the sources in reaction to the current congestion level. If the network is not congested, the transmission rate increases. If congestion is detected, the transmission rate is multiplicatively decreased. In practice, directly adjusting the transmission rate can be difficult since it requires the utilization of fine grained timers. In reliable transport protocols, an alternative is to dynamically adjust the sending window. This is the solution chosen for protocols like TCP and SCTP that will be described in more details later. To understand how window-based protocols can adjust their transmission rate, let us consider the very simple scenario of a reliable transport protocol that uses `go-back-n`. Consider the very simple scenario shown in the figure below.
0/8280 · 828