Exit Zen
52
../../principles/reliability.rst:217
English
`Bit stuffing` reserves the `01111110` bit string as the frame boundary marker and ensures that there will never be six consecutive `1` symbols transmitted by the physical layer inside a frame. With bit stuffing, a frame is sent as follows. First, the sender transmits the marker, i.e. `01111110`. Then, it sends all the bits of the frame and inserts an additional bit set to `0` after each sequence of five consecutive `1` bits. This ensures that the sent frame never contains a sequence of six consecutive bits set to `1`. As a consequence, the marker pattern cannot appear inside the frame sent. The marker is also sent to mark the end of the frame. The receiver performs the opposite to decode a received frame. It first detects the beginning of the frame thanks to the `01111110` marker. Then, it processes the received bits and counts the number of consecutive bits set to `1`. If a `0` follows five consecutive bits set to `1`, this bit is removed since it was inserted by the sender. If a `1` follows five consecutive bits sets to `1`, it indicates a marker if it is followed by a bit set to `0`. The table below illustrates the application of bit stuffing to some frames.
0/11800 · 1180
52
../../principles/transport.rst:127
English
The figure below provides a representation of the connectionless service as a `time-sequence diagram`. The user on the left, having address `S`, issues a `Data.request` primitive containing Service Data Unit (SDU) `M` that must be delivered by the service provider to destination `D`. The dashed line between the two primitives indicates that the `Data.indication` primitive that is delivered to the user on the right corresponds to the `Data.request` primitive sent by the user on the left.
0/4910 · 491
52
../../principles/security.rst:516
English
To counter this replay attack, we need to ensure that Alice never sends the same information twice to Bob. A possible mode of operation is shown below.
0/1510 · 151
52
../../exercises/ipv6.rst:484
English
When creating these forwarding tables, try to minimize the number of entries that you install on each router.
0/1090 · 109
52
../../exercises/routing-protocols.rst:649
English
In these exercises, we mainly consider the ``show`` that extracts information from the BGP daemon. We type `show bgp` and press the `tabulation` key to see the available commands in the `show bgp`.
0/1970 · 197
52
../../exercises/tcp-2.rst:649
English
To understand the operation of the TCP congestion control, it is often useful to write time-sequence diagrams for different scenarios. The example below shows the operation of the TCP congestion control scheme in a very simple scenario. The initial congestion window (``cwnd``) is set to 1000 bytes and the receive window (``rwin``) advertised by the receiver (supposed constant for the entire connection) is set to 2000 bytes. The slow-start threshold (``ssthresh``) is set to 64000 bytes.
0/4900 · 490
52
../../protocols/bgp.rst:162
English
the `Local Routing Information Base` (`Loc-RIB`) contains all the routes that are considered as acceptable by the router. The `Loc-RIB` may contain several routes, learned from different BGP peers, towards the same destination prefix.
0/2340 · 234
52
../../protocols/congestion.rst:229
English
A wide range of congestion control schemes have been proposed in the scientific literature and several of them have been widely deployed. A detailed comparison of these congestion control schemes is outside the scope of this chapter. A recent survey paper describing many of the implemented TCP congestion control schemes may be found in [TKU2019]_.
0/3490 · 349
52
../../protocols/email.rst:232
English
A
0/100 · 1
52
../../protocols/ethernet.rst:199
English
The attentive reader may question the need for different `EtherTypes` for IPv4 and IPv6 while the IP header already contains a version field that can be used to distinguish between IPv4 and IPv6 packets. Theoretically, IPv4 and IPv6 could have used the same `EtherType`. Unfortunately, developers of the early IPv6 implementations found that some devices did not check the version field of the IPv4 packets that they received and parsed frames whose `EtherType` was set to `0x0800` as IPv4 packets. Sending IPv6 packets to such devices would have caused disruptions. To avoid this problem, the IETF decided to apply for a distinct `EtherType` value for IPv6. Such a choice is now mandated by :rfc:`6274` (section 3.1), although we can find a funny counter-example in :rfc:`6214`.
0/7790 · 779
52
../../protocols/http.rst:183
English
By parsing this line, a server cannot determine which `index.html` file is requested. Thanks to the `Host:` header line, the server knows whether the request is for `http://web.example.com/index.html` or `http://www.dummy.net/index.html`. Without the `Host:` header, this is impossible. The `Host:` header line allowed web hosting companies to develop their business by supporting a large number of independent web servers on the same physical server.
0/4510 · 451
52
../../protocols/ipv6.rst:178
English
``/32`` for an Internet Service Provider
0/400 · 40
52
../../protocols/ethernet.rst:175
English
Category 5 UTP or STP, 100 m maximum
0/360 · 36
52
../../protocols/routing.rst:162
English
:math:`hash(NextHeader,IP_{src},IP_{dst},Port_{src},Port_{dst}) \pmod{N}`
0/730 · 73
52
../../protocols/tcp.rst:179
English
Apart from these two paths in the TCP connection establishment FSM, there is a third path that corresponds to the case when both the client and the server send a `SYN` segment to open a TCP connection [#ftcpboth]_. In this case, the client and the server send a `SYN` segment and enter the `SYN Sent` state. Upon reception of the `SYN` segment sent by the other host, they reply by sending a `SYN+ACK` segment and enter the `SYN RCVD` state. The `SYN+ACK` that arrives from the other host allows it to transition to the `Established` state. The figure below illustrates such a simultaneous establishment of a TCP connection.
0/6240 · 624
52
../../protocols/tls.rst:268
English
Perfect Forward Secrecy (PFS) is an important property for key exchange protocols. A protocol provides PFS if its design guarantees that the keys used for former sessions will not be compromised even if the private key of the server is compromised. This is a very important property. ``DHE_RSA`` provides Perfect Forward Secrecy, but the ``RSA`` key exchange does not provide this property. In practice, ``DHE_RSA`` is costly from a computational viewpoint. Recent implementations of TLS thus prefer ``ECDHE_RSA`` or ``ECDHE_ECDSA`` when Perfect Forward Secrecy is required.
0/5750 · 575
52
../../protocols/wifi.rst:146
English
Two types of encapsulation schemes were defined to support IP in Ethernet networks : the original encapsulation scheme, built above the Ethernet DIX format is defined in :rfc:`894` and a second encapsulation :rfc:`1042` scheme, built above the LLC/SNAP protocol [IEEE802.2]_. In 802.11 networks, the situation is simpler and only the :rfc:`1042` encapsulation is used. In practice, this encapsulation adds 6 bytes to the 802.11 header. The first four bytes correspond to the LLC/SNAP header. They are followed by the two bytes Ethernet Type field (`0x800` for IP and `0x806` for ARP). The figure below shows an IP packet encapsulated in an 802.11 frame.
0/6530 · 653
53
../../bibliography.rst:323
English
Semke, J., Mahdavi, J., and Mathis, M., `Automatic TCP buffer tuning <http://doi.acm.org/10.1145/285243.285292>`_. SIGCOMM Computer Communication Review 28, 4 (Oct. 1998), 315-323.
0/1800 · 180
53
../../glossary.rst:315
English
The original file containing the list of all Internet hosts. This file has been deprecated, but Unix variants still maintain a local ``/etc/hosts`` containing mappings between names and IP addresses. See http://man7.org/linux/man-pages/man5/hosts.5.html for a description of the format of this file on Linux.
0/3080 · 308
53
../../principles/reliability.rst:220 • ../../principles/reliability.rst:258
English
Original frame
0/140 · 14