2. cnp3-ebook
3. English
4. Zen

171 ../../principles/linkstate.rst:19
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Usually, the same weight is associated to the two directed edges that correspond to a physical link (i.e. :math:`R1 \rightarrow R2` and :math:`R2 \rightarrow R1`). However, nothing in the link state protocols requires this. For example, if the weight is set in function of the link bandwidth, then an asymmetric ADSL link could have a different weight for the upstream and downstream directions. Other variants are possible. Some networks use optimization algorithms to find the best set of weights to minimize congestion inside the network for a given traffic demand [FRT2002]_. 579/10000 · 579
171 ../../principles/sharing.rst:1068
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Consider now a window of two segments. Host `A` can send two segments within 2 msec on its 1 Mbps link. If the first segment is sent at time :math:`t_{0}`, it reaches host `D` at :math:`t_{0}+4`. Host `D` replies with an acknowledgment that opens the sending window on host `A` and enables it to transmit a new segment. In the meantime, the second segment was buffered by router `R1`. It reaches host `D` at :math:`t_{0}+6` and an acknowledgment is returned. With a window of two segments, host `A` transmits at roughly 500 Kbps, i.e. the transmission rate of the bottleneck link. 580/10000 · 580
171 ../../protocols/email.rst:270
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `0x14fb9c03d97e` 16/10000 · 16
171 ../../protocols/ipv6.rst:570
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If ``A`` sends a 1500 bytes packet, ``R1`` will return an ICMPv6 error message indicating a maximum packet length of 1400 bytes. ``A`` would then fragment the packet before retransmitting it. The small fragment would go through, but the large fragment will be refused by ``R2`` that would return an ICMPv6 error message. ``A`` can fragment again the packet and send it to the final destination as two fragments. 411/10000 · 411
171 ../../protocols/wifi.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field. 598/10000 · 598
171 ../../protocols/tcp.rst:558
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — by extension, some implementations respond with an `RST` segment to a segment that is received on an existing connection but with an invalid header :rfc:`3360`. This causes the corresponding connection to be closed and has caused security attacks :rfc:`4953` 258/10000 · 258
172 ../../glossary.rst:108
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — SYN cookie 10/10000 · 10
172 ../../principles/reliability.rst:841
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Utilisation of the sliding window with modulo arithmetic 56/10000 · 56
172 ../../principles/linkstate.rst:24
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a link-state router boots, it first needs to discover to which routers it is directly connected. For this, each router sends a HELLO message every `N` seconds on all its interfaces. This message contains the router's address. Each router has a unique address. As its neighboring routers also send HELLO messages, the router automatically discovers to which neighbors it is connected. These HELLO messages are only sent to neighbors that are directly connected to a router, and a router never forwards the HELLO messages that it receives. HELLO messages are also used to detect link and router failures. A link is considered to have failed if no HELLO message has been received from a neighboring router for a period of :math:`k \times N` seconds. 751/10000 · 751
172 ../../principles/sharing.rst:1141
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Our last example is a window of four segments. These segments are sent at :math:`t_{0}`, :math:`t_{0}+1`, :math:`t_{0}+2` and :math:`t_{0}+3`. The first segment reaches host `D` at :math:`t_{0}+4`. Host `D` replies to this segment by sending an acknowledgment that enables host `A` to transmit its fifth segment. This segment reaches router `R1` at :math:`t_{0}+5`. At that time, router `R1` is transmitting the third segment to router `R2` and the fourth segment is still in its buffers. At time :math:`t_{0}+6`, host `D` receives the second segment and returns the corresponding acknowledgment. This acknowledgment enables host `A` to send its sixth segment. This segment reaches router `R1` at roughly :math:`t_{0}+7`. At that time, the router starts to transmit the fourth segment to router `R2`. Since link `R1-R2` can only sustain 500 Kbps, packets will accumulate in the buffers of `R1`. On average, there will be two packets waiting in the buffers of `R1`. The presence of these two packets will induce an increase of the round-trip-time as measured by the transport protocol. While the first segment was acknowledged within 4 msec, the fifth segment (`data(4)`) that was transmitted at time :math:`t_{0}+4` is only acknowledged at time :math:`t_{0}+11`. On average, the sender transmits at 500 Kbps, but the utilization of a large window induces a longer delay through the network. 1390/10000 · 1390
172 ../../protocols/email.rst:272 • ../../protocols/email.rst:291 • ../../protocols/email.rst:305
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 8-bit 5/10000 · 5
172 ../../protocols/ipv6.rst:572
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, an IPv6 implementation does not store the transmitted packets to be able to retransmit them if needed. However, since TCP (and SCTP) buffer the segments that they transmit, a similar approach can be used in transport protocols to detect the largest MTU on a path towards a given destination. This technique is called PathMTU Discovery :rfc:`1981`. 360/10000 · 360
172 ../../protocols/wifi.rst:107
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a frame is sent from a WiFi device to a server attached to the same LAN as the access point, the first address of the frame is set to the MAC address of the access point, the second address is set to the MAC address of the source WiFi device and the third address is the address of the final destination on the LAN. When the server replies, it sends an Ethernet frame whose source address is its MAC address and the destination address is the MAC address of the WiFi device. This frame is captured by the access point that converts the Ethernet header into an 802.11 frame header. The 802.11 frame sent by the access point contains three addresses : the first address is the MAC address of the destination WiFi device, the second address is the MAC address of the access point and the third address the MAC address of the server that sent the frame. 854/10000 · 854
172 ../../protocols/tcp.rst:559
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — by extension, some implementations send an `RST` segment when they need to close an existing TCP connection (e.g., because there are not enough resources to support this connection or because the remote host is considered to be unreachable). Measurements have shown that this usage of TCP `RST` is widespread [AW05]_ 316/10000 · 316
173 ../../glossary.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The SYN cookies is a technique used to compute the initial sequence number (ISN) 80/10000 · 80
173 ../../principles/reliability.rst:846
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Unfortunately, frame losses do not disappear because a reliable protocol uses a sliding window. To recover from losses, a sliding window protocol must define : 159/10000 · 159
173 ../../principles/linkstate.rst:52
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 286/10000 · 286
173 ../../protocols/email.rst:272
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 00010100 11111011 10011100 00000011 11011001 01111110 55/10000 · 55
173 ../../protocols/ipv6.rst:576
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a TCP segment is transported in an IP packet that is fragmented in the network, the loss of a single fragment forces TCP to retransmit the entire segment (and thus all the fragments). If TCP was able to send only packets that do not require fragmentation in the network, it could retransmit only the information that was lost in the network. In addition, IP reassembly causes several challenges at high speed as discussed in :rfc:`4963`. Using IP fragmentation to allow UDP applications to exchange large messages raises several security issues [KPS2003]_. 561/10000 · 561
173 ../../protocols/wifi.rst:109
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.11 control frames are simpler than data frames. They contain a `Frame Control`, a `Duration` field and one or two addresses. The acknowledgment frames are very small. They only contain the address of the destination of the acknowledgment. There is no source address and no `Sequence Control` field in the acknowledgment frames. This is because the acknowledgment frame can easily be associated to the previous frame that it acknowledges. Indeed, each unicast data frame contains a `Duration` field that is used to reserve the transmission channel to ensure that no collision will affect the acknowledgment frame. The `Sequence Control` field is mainly used by the receiver to remove duplicate frames. Duplicate frames are detected as follows. Each data frame contains a 12 bits sequence number in the `Sequence Control` field and the `Frame Control` field contains the `Retry` bit flag that is set when a frame is transmitted. Each 802.11 receiver stores the most recent sequence number received from each source address in frames whose `Retry` bit is reset. Upon reception of a frame with the `Retry` bit set, the receiver verifies its sequence number to determine whether it is a duplicated frame or not. 1211/10000 · 1211