Exit Zen
149
../../protocols/email.rst:258
English
47
0/100 · 2
149
../../protocols/ipv6.rst:499
English
Header compression on low bandwidth links
0/410 · 41
149
../../protocols/wifi.rst:23 • ../../protocols/wifi.rst:25
English
54 Mbps
0/100 · 7
149
../../protocols/tcp.rst:452
English
This retransmission strategy has been refined based on the experience of using TCP on the Internet. The first refinement was a clarification of the strategy used to send acknowledgments. As TCP uses piggybacking, the easiest and less costly method to send acknowledgments is to place them in the data segments sent in the other direction. However, few application layer protocols exchange data in both directions at the same time and thus this method rarely works. For an application that is sending data segments in one direction only, the remote TCP entity returns empty TCP segments whose only useful information is their acknowledgment number. This may cause a large overhead in wide area network if a pure `ACK` segment is sent in response to each received data segment. Most TCP implementations use a `delayed acknowledgment` strategy. This strategy ensures that piggybacking is used whenever possible, otherwise pure `ACK` segments are sent for every second received data segments when there are no losses. When there are losses or reordering, `ACK` segments are more important for the sender and they are sent immediately :rfc:`813` :rfc:`1122`. This strategy relies on a new timer with a short delay (e.g. 50 milliseconds) and one additional flag in the TCB. It can be implemented as follows.
0/13010 · 1301
150
../../glossary.rst:137
English
Regional Internet Registry. An organization that manages IP addresses and AS numbers on behalf of :term:`IANA`.
0/1110 · 111
150
../../principles/transport.rst:797
English
Connection release
0/180 · 18
150
../../protocols/email.rst:258
English
v
0/100 · 1
150
../../protocols/ipv6.rst:501
English
Given the size of the IPv6 header, it can cause huge overhead on low bandwidth links, especially when small packets are exchanged such as for Voice over IP applications. In such environments, several techniques can be used to reduce the overhead. A first solution is to use data compression in the datalink layer to compress all the information exchanged [Thomborson1992]_. These techniques are similar to the data compression algorithms used in tools such as :manpage:`compress(1)` or :manpage:`gzip(1)` :rfc:`1951`. They compress streams of bits without taking advantage of the fact that these streams contain IP packets with a known structure. A second solution is to compress the IP and TCP header. These header compression techniques, such as the one defined in :rfc:`5795` take advantage of the redundancy found in successive packets from the same flow to significantly reduce the size of the protocol headers. Another solution is to define a compressed encoding of the IPv6 header that matches the capabilities of the underlying datalink layer :rfc:`4944`.
0/10630 · 1063
150
../../protocols/wifi.rst:23
English
35/120
0/100 · 6
150
../../protocols/tcp.rst:480
English
Due to this delayed acknowledgment strategy, during a bulk transfer, a TCP implementation usually acknowledges every second TCP segment received.
0/1450 · 145
151
../../glossary.rst:244
English
root nameserver
0/150 · 15
151
../../principles/dv.rst:113
English
Consider now that the link between `D` and `E` fails. The network is now partitioned into two disjoint parts: (`A` , `D`) and (`B`, `E`, `C`). The routes towards `B`, `C` and `E` expire first on router `D`. At this time, router `D` updates its routing table.
0/2590 · 259
151
../../principles/transport.rst:801
English
When we discussed the connection-oriented service, we mentioned that there are two types of connection releases : `abrupt release` and `graceful release`.
0/1540 · 154
151
../../principles/sharing.rst:714
English
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.
0/3950 · 395
151
../../protocols/email.rst:260
English
14
0/100 · 2
151
../../protocols/ipv6.rst:503
English
The last type of `IPv6 header extension` is the `Routing` header. The ``type 0`` routing header defined in :rfc:`2460` is an example of an IPv6 option that must be processed by some routers. This option is encoded as shown below.
0/2290 · 229
151
../../protocols/wifi.rst:24
English
802.11b
0/100 · 7
151
../../protocols/tcp.rst:482
English
The default go-back-n retransmission strategy used by TCP has the advantage of being simple to implement, in particular on the receiver side, but when there are losses, a go-back-n strategy provides a lower performance than a selective repeat strategy. The TCP developers have designed several extensions to TCP to allow it to use a selective repeat strategy while maintaining backward compatibility with older TCP implementations. These TCP extensions assume that the receiver is able to buffer the segments that it receives out-of-sequence.
0/5420 · 542
152
../../glossary.rst:246
English
A name server that is responsible for the root of the domain names hierarchy. There are currently a dozen root nameservers and each DNS resolver See http://www.root-servers.org/ for more information about the operation of these root servers.
0/2410 · 241
152
../../principles/dv.rst:115
English
If `D` sends :math:`[D=0, A=1, B=\infty, C=\infty, E=\infty]`, `A` learns that `B`, `C` and `E` are unreachable and updates its routing table.
0/1420 · 142