2. cnp3-ebook
3. principles/sharing
4. English
5. Zen

24 ../../principles/sharing.rst:194
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Packets per second versus bits per second 41/10000 · 41
25 ../../principles/sharing.rst:197
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The performance of network nodes (either routers or switches) can be characterized by two key metrics : 103/10000 · 103
26 ../../principles/sharing.rst:199
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the node's capacity measured in bits per second 47/10000 · 47
27 ../../principles/sharing.rst:200
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the node's lookup performance measured in packets per second 60/10000 · 60
28 ../../principles/sharing.rst:202
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The node's capacity in bits per second mainly depends on the physical interfaces that it uses and also on the capacity of the internal interconnection (bus, crossbar switch, ...) between the different interfaces inside the node. Many vendors, in particular for low-end devices will use the sum of the bandwidth of the nodes' interfaces as the node capacity in bits per second. Measurements do not always match this maximum theoretical capacity. A well designed network node will usually have a capacity in bits per second larger than the sum of its link capacities. Such nodes will usually reach this maximum capacity when forwarding large packets. 648/10000 · 648
29 ../../principles/sharing.rst:204
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a network node forwards small packets, its performance is usually limited by the number of lookup operations that it can perform every second. This lookup performance is measured in packets per second. The performance may depend on the length of the forwarded packets. The key performance factor is the number of minimal size packets that are forwarded by the node every second. This rate can lead to a capacity in bits per second which is much lower than the sum of the bandwidth of the node's links. 506/10000 · 506
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 ../../principles/sharing.rst:214
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us first explore which mechanisms can be used inside a network to control congestion and how these mechanisms can influence the behavior of the end hosts. 158/10000 · 158
32 ../../principles/sharing.rst:216
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As explained earlier, one of the first manifestation of congestion on network nodes is the saturation of the network links that leads to a growth in the occupancy of the buffers of the node. This growth of the buffer occupancy implies that some packets will spend more time in the buffer and thus in the network. If hosts measure the network delays (e.g. by measuring the round-trip-time between the transmission of a packet and the return of the corresponding acknowledgment) they could start to sense congestion. On low bandwidth links, a growth in the buffer occupancy can lead to an increase of the delays which can be easily measured by the end hosts. On high bandwidth links, a few packets inside the buffer will cause a small variation in the delay which may not necessarily be larger that the natural fluctuations of the delay measurements. 848/10000 · 848
33 ../../principles/sharing.rst:218
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If the buffer's occupancy continues to grow, it will overflow and packets will need to be discarded. Discarding packets during congestion is the second possible reaction of a network node to congestion. Before looking at how a node can discard packets, it is interesting to discuss qualitatively the impact of the buffer occupancy on the reliable delivery of data through a network. This is illustrated by the figure below, adapted from [Jain1990]_. 449/10000 · 449
34 ../../principles/sharing.rst:226
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When the network load is low, buffer occupancy and link utilization are low. The buffers on the network nodes are mainly used to absorb very short bursts of packets, but on average the traffic demand is lower than the network capacity. If the demand increases, the average buffer occupancy will increase as well. Measurements have shown that the total throughput increases as well. If the buffer occupancy is zero or very low, transmission opportunities on network links can be missed. This is not the case when the buffer occupancy is small but non zero. However, if the buffer occupancy continues to increase, the buffer becomes overloaded and the throughput does not increase anymore. When the buffer occupancy is close to the maximum, the throughput may decrease. This drop in throughput can be caused by excessive retransmissions of reliable protocols that incorrectly assume that previously sent packets have been lost while they are still waiting in the buffer. The network delay on the other hand increases with the buffer occupancy. In practice, a good operating point for a network buffer is a low occupancy to achieve high link utilization and also low delay for interactive applications. 1199/10000 · 1199
35 ../../principles/sharing.rst:230
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Discarding packets is one of the signals that the network nodes can use to inform the hosts of the current level of congestion. Buffers on network nodes are usually used as FIFO queues to preserve packet ordering. Several `packet discard mechanisms` have been proposed for network nodes. These techniques basically answer two different questions : 347/10000 · 347
36 ../../principles/sharing.rst:232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `What triggers a packet to be discarded ?` What are the conditions that lead a network node to decide to discard a packet? The simplest answer to this question is : `When the buffer is full`. Although this is a good congestion indication, it is probably not the best one from a performance viewpoint. An alternative is to discard packets when the buffer occupancy grows too much. In this case, it is likely that the buffer will become full shortly. Since packet discarding is an information that allows hosts to adapt their transmission rate, discarding packets early could allow hosts to react earlier and thus prevent congestion from happening. 646/10000 · 646
37 ../../principles/sharing.rst:233
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Which packet(s) should be discarded ?` Once the network node has decided to discard packets, it needs to actually discard real packets. 136/10000 · 136
38 ../../principles/sharing.rst:236
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — By combining different answers to these questions, network researchers have developed different packet discard mechanisms. 122/10000 · 122
39 ../../principles/sharing.rst:238
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Tail drop` is the simplest packet discard technique. When a buffer is full, the arriving packet is discarded. `Tail drop` can be easily implemented. This is, by far, the most widely used packet discard mechanism. However, it suffers from two important drawbacks. First, since `tail drop` discards packets only when the buffer is full, buffers tend to be congested and real-time applications may suffer from increased delays. Second, `tail drop` is blind when it discards a packet. It may discard a packet from a low bandwidth interactive flow while most of the buffer is used by large file transfers. 601/10000 · 601
40 ../../principles/sharing.rst:239
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Drop from front` is an alternative packet discard technique. Instead of removing the arriving packet, it removes the packet that was at the head of the queue. Discarding this packet instead of the arriving one can have two advantages. First, it already stayed a long time in the buffer. Second, hosts should be able to detect the loss (and thus the congestion) earlier. 370/10000 · 370
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 ../../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
43 ../../principles/sharing.rst:246
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In datagram networks, `Forward Explicit Congestion Notification` (FECN) can be used. One field of the packet header, typically one bit, is used to indicate congestion. When a host sends a packet, the congestion bit is unset. If the packet passes through a congested node, the congestion bit is set. The destination can then determine the current congestion level by measuring the fraction of the packets that it received with the congestion bit set. It may then return this information to the sending host to allow it to adapt its retransmission rate. Compared to packet discarding, the main advantage of FECN is that hosts can detect congestion explicitly without having to rely on packet losses. 697/10000 · 697