2. cnp3-ebook
3. English
4. Zen

41 ../../protocols/tcp.rst:127
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `acknowledgment number` set to the `sequence number` of the received `SYN+ACK` segment incremented by 1 :math:`\pmod{2^{32}}` 129/10000 · 129
41 ../../protocols/tls.rst:175
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``Server Name Indication (SNI)`` extension defined in :rfc:`6066` is an important TLS extension for web servers. It is used by the client to indicate the name of the server that it wishes to contact. The IP address associated to this name has been queried from the DNS and used to establish the TCP connection. Why should the client indicate the server name in the TLS ``ClientHello`` ? The motivation is the same as for the ``Host`` header line in HTTP/1.0. With the SNI extension, a single TLS server can support several web sites that use different domain names. Thanks to the SNI extension, the server knows the concerned domain name at the start of the TLS session. Without this extension, hosting providers would have been forced use one IP address per TLS-enabled server. 783/10000 · 783
41 ../../protocols/wifi.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field. 598/10000 · 598
41 ../../exercises/reliability.rst:82
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A go-back-n sender has sent :math:`2^n` data frames. All the frames have been received correctly and in-order by the receiver, but all the returned acknowledgments have been lost. Show by using a time sequence diagram (e.g. by considering a window of four frames) what happens in this case. Can you fix the problem on the go-back-n sender ? 340/10000 · 340
41 ../../bibliography.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Dimitropoulos, X., Krioukov, D., Fomenkov, M., Huffaker, B., Hyun, Y., Claffy, K., Riley, G., `AS Relationships: Inference and Validation <http://doi.acm.org/10.1145/1198255.1198259>`_, ACM SIGCOMM Computer Communication Review (CCR), Jan. 2007 245/10000 · 245
41 ../../principles/sharing.rst:240
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Probabilistic drop`. Various random drop techniques have been proposed. A frequently cited technique is `Random Early Discard` (RED) [FJ1993]_. RED measures the average buffer occupancy and discards packets with a given probability when this average occupancy is too high. Compared to `tail drop` and `drop from front`, an advantage of `RED` is that thanks to the probabilistic drops, packets should be discarded from different flows in proportion of their bandwidth. 468/10000 · 468
42 ../../exercises/sockets.rst:330
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Besides character strings, some applications also need to exchange 16 bits and 32 bits fields such as integers. A naive solution would have been to send the 16- or 32-bits field as it is encoded in the host's memory. Unfortunately, there are different methods to store 16- or 32-bits fields in memory. Some CPUs store the most significant byte of a 16-bits field in the first address of the field while others store the least significant byte at this location. When networked applications running on different CPUs exchange 16 bits fields, there are two possibilities to transfer them over the transport service : 613/10000 · 613
42 ../../exercises/network.rst:369
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Routes on A 11/10000 · 11
42 ../../glossary.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — frame 5/10000 · 5
42 ../../exercises/reliability.rst:84
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Same question as above, but assume now that both the sender and the receiver implement selective repeat. Note that the answer can be different from the above question. 167/10000 · 167
42 ../../principles/referencemodels.rst:275
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
42 ../../principles/network.rst:240
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Learning the location of the sources is not sufficient, nodes also need to forward packets towards their destination. When a node receives a packet whose destination address is already present inside its port-address table, it simply forwards the packet on the interface listed in the port-address table. In this case, the packet will follow the port-address table entries in the downstream nodes and will reach the destination. If the destination address is not included in the port-address table, the node simply forwards the packet on all its interfaces, except the interface from which the packet was received. Forwarding a packet over all interfaces is usually called `broadcasting` in the terminology of computer networks. Sending the packet over all interfaces except one is a costly operation since the packet is sent over links that do not reach the destination. Given the tree-shape of the network, the packet will explore all downstream branches of the tree and will finally reach its destination. In practice, the `broadcasting` operation does not occur too often and its performance impact remains limited. 1119/10000 · 1119
42 ../../principles/sharing.rst:242
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Discarding packets is a frequent reaction to network congestion. Unfortunately, discarding packets is not optimal since a packet which is discarded on a network node has already consumed resources on the upstream nodes. There are other ways for the network to inform the end hosts of the current congestion level. A first solution is to mark the packets when a node is congested. Several networking technologies have relied on this kind of packet marking. 455/10000 · 455
42 ../../principles/transport.rst:106
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first possibility was named `big-endian` in a note written by Cohen [Cohen1980]_ while the second was named `little-endian`. Vendors of CPUs that used `big-endian` in memory insisted on using `big-endian` encoding in networked applications while vendors of CPUs that used `little-endian` recommended the opposite. Several studies were written on the relative merits of each type of encoding, but the discussion became almost a religious issue [Cohen1980]_. Eventually, the Internet chose the `big-endian` encoding, i.e. multi-byte fields are always transmitted by sending the most significant byte first, :rfc:`791` refers to this encoding as the :term:`network-byte order`. Most libraries [#fhtonl]_ used to write networked applications contain functions to convert multi-byte fields from memory to the network byte order and the reverse. 844/10000 · 844
42 ../../principles/security.rst:412
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, encrypting a message to sign it can be computationally costly, in particular if the message is a large file. A faster solution would be to summarize the document and only sign the summary of the document. A naive approach could be based on a checksum or CRC computed over the message. Alice would then compute :math:`C=Checksum(M)` and :math:`SC=E_p(A_{priv},C)`. She would then send both `M` and `SC` to the recipient of the message who can easily compute `C` from `SC` and verify the authenticity of the message. Unfortunately, this solution does not protect Alice and the message's recipient against a man-in-the-middle attack. If Mallory can intercept the message sent by Alice, he can easily modify Alice's message and tweak it so that it has the same checksum as the original one. The CRCs, although more complex to compute, suffer from the same problem. 873/10000 · 873
42 ../../exercises/ipv6.rst:436
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Sometimes, static routes must be configured on networks to enforce certain paths. Consider the six routers network shown in the figure below. 141/10000 · 141
42 ../../exercises/routing-protocols.rst:512
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now run this simple network. 35/10000 · 35
42 ../../exercises/tcp-2.rst:593
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Our last scenario is when the first segment sent is lost. In this case, two round-trip-times are required to retransmit the missing segment and recover from the loss. This script is available from :download:`/exercises/packetdrill_scripts/slow-start-frr3.pkt`. 260/10000 · 260
42 ../../protocols/bgp.rst:131
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a list of IP prefixes that are withdrawn 40/10000 · 40
42 ../../protocols/congestion.rst:211
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connections with a small round-trip-time can achieve a higher throughput than TCP connections having a longer round-trip-time when losses occur. This implies that the TCP congestion control scheme is not completely fair since it favors the connections that have the shorter round-trip-times. 295/10000 · 295