2. cnp3-ebook
3. English
4. Zen

20 ../../principles/reliability.rst:54
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`10^{12}` 15/10000 · 15
20 ../../bibliography.rst:29
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Beech, W., Nielsen, D., Taylor, J., `AX.25 Link Access Protocol for Amateur Packet Radio <http://www.tapr.org/pdf/AX25.2.2.pdf>`_, version 2.2, Revision: July 1998 164/10000 · 164
20 ../../exercises/network.rst:161
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Assuming that the network uses source routing, what are the possible paths from `R1` to `R4` ? 94/10000 · 94
20 ../../exercises/reliability.rst:39
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — when every second acknowledgment is discarded due to transmission errors 72/10000 · 72
20 ../../glossary.rst:153
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BGP 3/10000 · 3
20 ../../exercises/transport.rst:147
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — DATA segments contain a sequence number that is incremented for each byte transmitted 85/10000 · 85
20 ../../principles/transport.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Bob : `This is not the correct password.` 41/10000 · 41
20 ../../protocols/dns.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reverse DNS 11/10000 · 11
20 ../../principles/security.rst:270
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `A cryptographic algorithm should be secure even if the attacker knows everything about the system, except one parameter known as the secret key.` 146/10000 · 146
20 ../../exercises/dns.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — What is the lifetime associated to this IPv6 address ? 54/10000 · 54
20 ../../exercises/ipv6.rst:151 • ../../exercises/ipv6.rst:229
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — router ``R3`` uses address ``2001:db8:1341:34::3`` on its East interface and address ``2001:db8:1341:13::3`` on its North interface 131/10000 · 131
20 ../../exercises/lan.rst:195
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The network contains five nodes and six links. 46/10000 · 46
20 ../../exercises/routing-policies.rst:167
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A ``traceroute6`` towards ``ipv6.google.com`` provides the following output : 77/10000 · 77
20 ../../exercises/routing-protocols.rst:261
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The requested information is sent in a `LS Update` packet shortly after that. 77/10000 · 77
20 ../../exercises/tcp-2.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — packetdrill_ writes 10 bytes of data through the :manpage:`write` system call. The stack immediately sends these 10 bytes inside a segment whose ``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` and ends at sequence number ``10``. packetdrill_ replies by injecting an acknowledgment for the entire data after 100 milliseconds. 352/10000 · 352
20 ../../exercises/trace.rst:109
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When analyzing packet traces with wireshark_, it is often very useful to use `Display filters` that only show the packets that match some specific criteria. There filters are described in several online documents: 213/10000 · 213
20 ../../protocols/bgp.rst:68
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets. 1049/10000 · 1049
20 ../../protocols/congestion.rst:108
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first difficulty in adding Explicit Congestion Notification (ECN) in TCP/IP network was to modify the format of the network packet and transport segment headers to carry the required information. In the network layer, one bit was required to allow the routers to mark the packets they forward during congestion periods. In the IP network layer, this bit is called the `Congestion Experienced` (`CE`) bit and is part of the packet header. However, using a single bit to mark packets is not sufficient. Consider a simple scenario with two sources, one congested router and one destination. Assume that the first sender and the destination support ECN, but not the second sender. If the router is congested it will mark packets from both senders. The first sender will react to the packet markings by reducing its transmission rate. However since the second sender does not support ECN, it will not react to the markings. Furthermore, this sender could continue to increase its transmission rate, which would lead to more packets being marked and the first source would decrease again its transmission rate, ... In the end, the sources that implement ECN are penalized compared to the sources that do not implement it. This unfairness issue is a major hurdle to widely deploy ECN on the public Internet [#fprivate]_. The solution proposed in :rfc:`3168` to deal with this problem is to use a second bit in the network packet header. This bit, called the `ECN-capable transport` (ECT) bit, indicates whether the packet contains a segment produced by a transport protocol that supports ECN or not. Transport protocols that support ECN set the ECT bit in all packets. When a router is congested, it first verifies whether the ECT bit is set. In this case, the CE bit of the packet is set to indicate congestion. Otherwise, the packet is discarded. This eases the deployment of ECN [#fecnnonce]_. 1893/10000 · 1893
20 ../../protocols/dnssec.rst:189
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To obtain an authenticated record for `www.example.org`, Alice's resolver first needs to retrieve the `NS` which is responsible for the `.org` Top-Level Domain (TLD). This record is served by the DNS root server and Alice's resolver can retrieve the signature (`RRSIG` record) for this `NS` record. Since Alice knows the `DNSKEY` of the root, she can verify the validity of this signature. 389/10000 · 389
20 ../../protocols/email.rst:107
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `bcc:` header line is used by the sender to provide a list of comma separated email addresses that must receive a blind carbon copy of the message. The `bcc:` header line is not delivered to the recipients of the email message. 231/10000 · 231