2. cnp3-ebook
3. English
4. Zen

176 ../../protocols/ipv6.rst:605
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another very useful debugging tool is :manpage:`traceroute6(8)`. The traceroute man page describes this tool as `"print the route packets take to network host"`. traceroute uses the `Time exceeded` ICMP messages to discover the intermediate routers on the path towards a destination. The principle behind traceroute is very simple. When a router receives an IP packet whose `Hop Limit` is set to ``1`` it is forced to return to the sending host a `Time exceeded` ICMP message containing the header and the first bytes of the discarded packet. To discover all routers on a network path, a simple solution is to first send a packet whose `Hop Limit` is set to `1`, then a packet whose `Hop Limit` is set to `2`, etc. A sample traceroute6 output is shown below. 758/10000 · 758
176 ../../protocols/wifi.rst:126
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IEEE 802.11 RTS frame format 28/10000 · 28
176 ../../protocols/tcp.rst:570
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The normal way of terminating a TCP connection is by using the graceful TCP connection release. This mechanism uses the `FIN` flag of the TCP header and allows each host to release its own direction of data transfer. As for the `SYN` flag, the utilization of the `FIN` flag in the TCP header consumes one sequence number. The figure :ref:`fig-tcprelease` shows the part of the TCP FSM used when a TCP connection is released. 424/10000 · 424
176 ../../principles/reliability.rst:854
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The simplest sliding window protocol uses the `go-back-n` recovery. Intuitively, `go-back-n` operates as follows. A `go-back-n` receiver is as simple as possible. It only accepts the frames that arrive in-sequence. A `go-back-n` receiver discards any out-of-sequence frame that it receives. When `go-back-n` receives a data frame, it always returns an acknowledgment containing the sequence number of the last in-sequence frame that it has received. This acknowledgment is said to be `cumulative`. When a `go-back-n` receiver sends an acknowledgment for sequence number `x`, it implicitly acknowledges the reception of all frames whose sequence number is earlier than `x`. A key advantage of these cumulative acknowledgments is that it is easy to recover from the loss of an acknowledgment. Consider for example a `go-back-n` receiver that received frames `1`, `2` and `3`. It sent `OK1`, `OK2` and `OK3`. Unfortunately, `OK1` and `OK2` were lost. Thanks to the cumulative acknowledgments, when the sender receives `OK3`, it knows that all three frames have been correctly received. 1082/10000 · 1082
177 ../../glossary.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Transmission Control Protocol is a protocol of the transport layer in the TCP/IP protocol suite that provides a reliable bytestream connection-oriented service on top of IP 176/10000 · 176
177 ../../principles/reliability.rst:856
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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`). 385/10000 · 385
177 ../../principles/sharing.rst:1254
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As an illustration, let us consider the network scenario above and assume that the router implements the DECBit binary feedback scheme [RJ1995]_. This scheme uses a form of Forward Explicit Congestion Notification and a router marks the congestion bit in arriving packets when its buffer contains one or more packets. In the figure below, we use a `*` to indicate a marked packet. 380/10000 · 380
177 ../../protocols/email.rst:276
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 5 15 46 28 0 61 37 62 51/10000 · 51
177 ../../protocols/ipv6.rst:627
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Rate limitation of ICMP messages 32/10000 · 32
177 ../../protocols/wifi.rst:129
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The 802.11 service 18/10000 · 18
177 ../../protocols/tcp.rst:603
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Starting from the `Established` state, there are two main paths through this FSM. 81/10000 · 81
177 ../../principles/linkstate.rst:57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.Links[]: links advertised in the LSP. Each directed link is represented with the following information: 107/10000 · 107
178 ../../glossary.rst:81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP/IP 6/10000 · 6
178 ../../principles/sharing.rst:1409
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When the connection starts, its congestion window is set to one segment. Segment `S0` is sent an acknowledgment at roughly :math:`t_{0}+4`. The congestion window is increased by one segment and `S1` and `S2` are transmitted at time :math:`t_{0}+4` and :math:`t_{0}+5`. The corresponding acknowledgments are received at times :math:`t_{0}+8` and :math:`t_{0}+10`. Upon reception of this last acknowledgment, the congestion window reaches `3` and segments can be sent (`S4` and `S5`). When segment `S6` reaches router `R1`, its buffers already contain `S5`. The packet containing `S6` is thus marked to inform the sender of the congestion. Note that the sender will only notice the congestion once it receives the corresponding acknowledgment at :math:`t_{0}+18`. In the meantime, the congestion window continues to increase. At :math:`t_{0}+16`, upon reception of the acknowledgment for `S5`, it reaches `4`. When congestion is detected, the congestion window is decreased down to `2`. This explains the idle time between the reception of the acknowledgment for `S*6` and the transmission of `S10`. 1097/10000 · 1097
178 ../../protocols/email.rst:278
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — F P u c A 9 l \+ 52/10000 · 52
178 ../../protocols/ipv6.rst:629
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — High-end hardware based routers use special purpose chips on their interfaces to forward IPv6 packets at line rate. These chips are optimized to process `correct` IP packets. They are not able to create ICMP messages at line rate. When such a chip receives an IP packet that triggers an ICMP message, it interrupts the main CPU of the router and the software running on this CPU processes the packet. This CPU is much slower than the hardware acceleration found on the interfaces [Gill2004]_. It would be overloaded if it had to process IP packets at line rate and generate one ICMP message for each received packet. To protect this CPU, high-end routers limit the rate at which the hardware can interrupt the main CPU and thus the rate at which ICMP messages can be generated. This implies that not all erroneous IP packets cause the transmission of an ICMP message. The risk of overloading the main CPU of the router is also the reason why using hop-by-hop IPv6 options, including the router alert option is discouraged [#falert]_. 1033/10000 · 1033
178 ../../protocols/wifi.rst:131
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Despite the utilization of acknowledgments, the 802.11 layer only provides an unreliable connectionless service like Ethernet networks that do not use acknowledgments. The 802.11 acknowledgments are used to minimize the probability of frame duplication. They do not guarantee that all frames will be correctly received by their recipients. Like Ethernet, 802.11 networks provide a high probability of successful delivery of the frames, not a guarantee. Furthermore, it should be noted that 802.11 networks do not use acknowledgments for multicast and broadcast frames. This implies that in practice such frames are more likely to suffer from transmission errors than unicast frames. 682/10000 · 682
178 ../../protocols/tcp.rst:605
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first path is when the host receives a segment with sequence number `x` and the `FIN` flag set. The utilization of the `FIN` flag indicates that the byte before `sequence number` `x` was the last byte of the byte stream sent by the remote host. Once all of the data has been delivered to the user, the TCP entity sends an `ACK` segment whose `ack` field is set to :math:`(x+1) \pmod{2^{32}}` to acknowledge the `FIN` segment. The `FIN` segment is subject to the same retransmission mechanisms as a normal TCP segment. In particular, its transmission is protected by the retransmission timer. At this point, the TCP connection enters the `CLOSE\_WAIT` state. In this state, the host can still send data to the remote host. Once all its data have been sent, it sends a `FIN` segment and enter the `LAST\_ACK` state. In this state, the TCP entity waits for the acknowledgment of its `FIN` segment. It may still retransmit unacknowledged data segments, e.g., if the retransmission timer expires. Upon reception of the acknowledgment for the `FIN` segment, the TCP connection is completely closed and its :term:`TCB` can be discarded. 1133/10000 · 1133
178 ../../principles/linkstate.rst:59
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — LSP.Links[i].Id: identification of the neighbor 47/10000 · 47
178 ../../principles/reliability.rst:890
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A `go-back-n` sender is also very simple. It uses a sending buffer that can store an entire sliding window of frames [#fsizesliding]_. The frames are sent with increasing sequence numbers (modulo `maxseq`). The sender must wait for an acknowledgment once its sending buffer is full. When a `go-back-n` sender receives an acknowledgment, it removes from the sending buffer all the acknowledged frames and uses a retransmission timer to detect frame losses. A simple `go-back-n` sender maintains one retransmission timer per connection. This timer is started when the first frame is sent. When the `go-back-n sender` receives an acknowledgment, it restarts the retransmission timer only if there are still unacknowledged frames in its sending buffer. When the retransmission timer expires, the `go-back-n` sender assumes that all the unacknowledged frames currently stored in its sending buffer have been lost. It thus retransmits all the unacknowledged frames in the buffer and restarts its retransmission timer. 1011/10000 · 1011