2. cnp3-ebook
3. English
4. Zen

30 ../../protocols/bgp.rst:99
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Internet uses a single interdomain routing protocol : the Border Gateway Protocol (BGP). The current version of BGP is defined in :rfc:`4271`. BGP differs from the intradomain routing protocols that we have already discussed in several ways. First, BGP is a `path-vector` protocol. When a BGP router advertises a route towards a prefix, it announces the IP prefix and the interdomain path used to reach this prefix. From BGP's point of view, each domain is identified by a unique `Autonomous System` (AS) number [#fasdomain]_ and the interdomain path contains the AS numbers of the transit domains that are used to reach the associated prefix. This interdomain path is called the `AS Path`. Thanks to these AS-Paths, BGP does not suffer from the count-to-infinity problems that affect distance vector routing protocols. Furthermore, the AS-Path can be used to implement some routing policies. Another difference between BGP and the intradomain routing protocols is that a BGP router does not send the entire contents of its routing table to its neighbors regularly. Given the size of the global Internet, routers would be overloaded by the number of BGP messages that they would need to process. BGP uses incremental updates, i.e. it only announces the routes that have changed to its neighbors. 1299/10000 · 1299
30 ../../protocols/congestion.rst:178
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — routers that have several queues served by a round-robin scheduler 66/10000 · 66
30 ../../protocols/dnssec.rst:332
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — See http://spoofer.caida.org/summary.php for an ongoing measurement study that analyses the networks where an attacker could send packets with any source IP address. 165/10000 · 165
30 ../../protocols/email.rst:172
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :rfc:`2045` defines three new types of header lines to support MIME : 69/10000 · 69
30 ../../protocols/ethernet.rst:172
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 10Base2 7/10000 · 7
30 ../../protocols/http.rst:122
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a `status line` , that indicates whether the request was successful or not 74/10000 · 74
30 ../../protocols/http2.rst:226
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first frame that a client sends over an HTTP/2.0 session is the `Settings` frame. This is a control frame that indicates some parameters that the client proposes for this session. Several of these parameters are defined in :rfc:`7540`. The most important ones are probably the `SETTINGS_MAX_FRAME_SIZE` that specifies the maximum length of the HTTP/2.0 frames that this implementation supports and the `SETTINGS_MAX_CONCURRENT_STREAMS` that specifies the maximum number of parallel streams that this implementation can manage. The `SETTINGS_MAX_FRAME_SIZE` must be at least :math:`2^{14}` bytes but can go up to :math:`2^{24} -1` bytes. There is no minimum value for `SETTINGS_MAX_CONCURRENT_STREAMS`, but :rfc:`7540` recommends to support at least 100 different stream identifiers. 786/10000 · 786
30 ../../protocols/ipv6.rst:117
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IPv6 addresses often contain a long sequence of bits set to ``0``. In this case, a compact notation has been defined. With this notation, `::` is used to indicate one or more groups of 16 bits blocks containing only bits set to `0`. For example, 245/10000 · 245
30 ../../protocols/ethernet.rst:94
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An Ethernet network provides an unreliable connectionless service. It supports three different transmission modes : `unicast`, `multicast` and `broadcast`. While the Ethernet service is unreliable in theory, a good Ethernet network should, in practice, provide a service that: 276/10000 · 276
30 ../../protocols/routing.rst:96
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `RB` advertises `2001:db8:1234::/48` at a distance of `2` and `2001:db8:5678::/48` at a distance of `3` 103/10000 · 103
30 ../../protocols/rpc.rst:115
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `jsonrpc`: a string indicating the version of the protocol used to encode the response 86/10000 · 86
30 ../../protocols/ssh.rst:227
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``payload`` : the data (after optional compression) passed by the user 70/10000 · 70
30 ../../protocols/tcp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Optional header extension` is used to add optional information to the TCP header. Thanks to this header extension, it is possible to add new fields to the TCP header that were not planned in the original specification. This allowed TCP to evolve since the early eighties. The details of the TCP header extension are explained in sections :ref:`TCPOpen` and :ref:`TCPReliable`. 381/10000 · 381
30 ../../protocols/tls.rst:100
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Verify that the client interacts with a valid server 52/10000 · 52
30 ../../protocols/wifi.rst:26
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 150 Mbps 8/10000 · 8
30 ../../exercises/network.rst:256
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Discussion questions 20/10000 · 20
30 ../../principles/naming.rst:137
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Names provide a lot of flexibility compared to addresses. For the network, they play a similar role as variables in programming languages. No programmer using a high-level programming language would consider using hardcoded values instead of variables. For the same reasons, all networked applications should depend on names and avoid dealing with addresses as much as possible. 378/10000 · 378
30 ../../principles/reliability.rst:91
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first problem is that electrical transmission can be affected by electromagnetic interference. Interference can have various sources including natural phenomenons (like thunderstorms, variations of the magnetic field,...) but also other electrical signals (such as interference from neighboring cables, interference from neighboring antennas,...). Due to these various types of interference, there is unfortunately no guarantee that when a host transmit one bit on a wire, the same bit is received at the other end. This is illustrated in the figure below where a `DATA.request(0)` on the left host leads to a `Data.indication(1)` on the right host. 653/10000 · 653
30 ../../principles/sharing.rst:212
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us now try to present a broad overview of the congestion problem in networks. We will assume that the network is composed of dedicated links having a fixed bandwidth [#fadjust]_. A network contains hosts that generate and receive packets and nodes (routers and switches) that forward packets. Assuming that each host is connected via a single link to the network, the largest demand is :math:`\sum{Access Links}`. In practice, this largest demand is never reached and the network will be engineered to sustain a much lower traffic demand. The difference between the worst-case traffic demand and the sustainable traffic demand can be large, up to several orders of magnitude. Fortunately, the hosts are not completely dumb and they can adapt their traffic demand to the current state of the network and the available bandwidth. For this, the hosts need to `sense` the current level of congestion and adjust their own traffic demand based on the estimated congestion. Network nodes can react in different ways to network congestion and hosts can sense the level of congestion in different ways. 1097/10000 · 1097
31 ../../exercises/ex-sharing.rst:609
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this network, a 250 Kbps link is used between the routers. The propagation delays in the network are negligible. Host `A` sends 1000 bits long segments so that it takes one msec to transmit one segment on the `A-R1` link. Neglecting the transmission delays for the acknowledgments, what is the minimum round-trip time measured on host `A` with such segments ? 362/10000 · 362