Exit Zen
175
../../protocols/email.rst:274
English
000101 001111 101110 011100 000000 111101 100101 111110
0/560 · 56
175
../../protocols/ipv6.rst:583
English
Two types of informational ICMPv6 messages are defined in :rfc:`4443` : `echo request` and `echo reply`, which are used to test the reachability of a destination by using :manpage:`ping6(8)`. Each host is supposed [#fpingproblems]_ to reply with an ICMP `Echo reply` message when it receives an ICMP `Echo request` message. A sample usage of :manpage:`ping6(8)` is shown below.
0/3780 · 378
175
../../protocols/wifi.rst:120
English
802.11 RTS/CTS frames are used to reserve the transmission channel, in order to transmit one data frame and its acknowledgment. The RTS frames contain a `Duration` and the transmitter and receiver addresses. The `Duration` field of the RTS frame indicates the duration of the entire reservation (i.e. the time required to transmit the CTS, the data frame, the acknowledgments and the required SIFS delays). The CTS frame has the same format as the acknowledgment frame.
0/4690 · 469
175
../../protocols/tcp.rst:567
English
The designers of TCP implementations should ensure that two TCP entities never enter a TCP `RST` war where host `A` is sending a `RST` segment in response to a previous `RST` segment that was sent by host `B` in response to a TCP `RST` segment sent by host `A` ... To avoid such an infinite exchange of `RST` segments that do not carry data, a TCP entity is *never* allowed to send a `RST` segment in response to another `RST` segment.
0/4350 · 435
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
176
../../protocols/email.rst:276 • ../../protocols/email.rst:295 • ../../protocols/email.rst:309
English
Decimal
0/100 · 7
176
../../protocols/ipv6.rst:605
English
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.
0/7580 · 758
176
../../protocols/wifi.rst:126
English
IEEE 802.11 RTS frame format
0/280 · 28
176
../../protocols/tcp.rst:570
English
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.
0/4240 · 424
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
177
../../protocols/email.rst:276
English
5 15 46 28 0 61 37 62
0/510 · 51
177
../../protocols/ipv6.rst:627
English
Rate limitation of ICMP messages
0/320 · 32
177
../../protocols/wifi.rst:129
English
The 802.11 service
0/180 · 18
177
../../protocols/tcp.rst:603
English
Starting from the `Established` state, there are two main paths through this FSM.
0/810 · 81