When too many packets are present in (a part of) the subnet, performance degrades. This
situation is called congestion. When the number of packets
dumped into the subnet by the hosts is within its carrying capacity, they are all delivered
(except for a few that are afflicted with transmission errors) and the number delivered is
proportional to the number sent. However, as traffic increases too far, the routers are no
longer able to cope and they begin losing packets. This tends to make matters worse. At very
high trafffic, performance collapses completely and almost no packets are delivered.
When too much traffic is offered, congestion sets in and
performance degrades sharply.
Congestion can be brought on by several factors. If all of a sudden, streams of packets begin
arriving on three or four input lines and all need the same output line, a queue will build up. If
there is insufficient memory to hold all of them, packets will be lost. Adding more memory may
help up to a point, but Nagle (1987) discovered that if routers have an infinite amount of
memory, congestion gets worse, not better, because by the time packets get to the front of
the queue, they have already timed out (repeatedly) and duplicates have been sent. All these
packets will be dutifully forwarded to the next router, increasing the load all the way to the
destination.
Slow processors can also cause congestion. If the routers' CPUs are slow at performing the
bookkeeping tasks required of them (queueing buffers, updating tables, etc.), queues can build
up, even though there is excess line capacity. Similarly, low-bandwidth lines can also cause
congestion. Upgrading the lines but not changing the processors, or vice versa, often helps a
little, but frequently just shifts the bottleneck. Also, upgrading part, but not all, of the system,
often just moves the bottleneck somewhere else. The real problem is frequently a mismatch
between parts of the system. This problem will persist until all the components are in balance.
It is worth explicitly pointing out the difference between congestion control and flow control, as
the relationship is subtle. Congestion control has to do with making sure the subnet is able to
carry the offered traffic. It is a global issue, involving the behavior of all the hosts, all the
routers, the store-and-forwarding processing within the routers, and all the other factors that
tend to diminish the carrying capacity of the subnet.
Flow control, in contrast, relates to the point-to-point traffic between a given sender and a
given receiver. Its job is to make sure that a fast sender cannot continually transmit data
faster than the receiver is able to absorb it. Flow control frequently involves some direct
feedback from the receiver to the sender to tell the sender how things are doing at the other
end.
situation is called congestion. When the number of packets
dumped into the subnet by the hosts is within its carrying capacity, they are all delivered
(except for a few that are afflicted with transmission errors) and the number delivered is
proportional to the number sent. However, as traffic increases too far, the routers are no
longer able to cope and they begin losing packets. This tends to make matters worse. At very
high trafffic, performance collapses completely and almost no packets are delivered.
When too much traffic is offered, congestion sets in and
performance degrades sharply.
Congestion can be brought on by several factors. If all of a sudden, streams of packets begin
arriving on three or four input lines and all need the same output line, a queue will build up. If
there is insufficient memory to hold all of them, packets will be lost. Adding more memory may
help up to a point, but Nagle (1987) discovered that if routers have an infinite amount of
memory, congestion gets worse, not better, because by the time packets get to the front of
the queue, they have already timed out (repeatedly) and duplicates have been sent. All these
packets will be dutifully forwarded to the next router, increasing the load all the way to the
destination.
Slow processors can also cause congestion. If the routers' CPUs are slow at performing the
bookkeeping tasks required of them (queueing buffers, updating tables, etc.), queues can build
up, even though there is excess line capacity. Similarly, low-bandwidth lines can also cause
congestion. Upgrading the lines but not changing the processors, or vice versa, often helps a
little, but frequently just shifts the bottleneck. Also, upgrading part, but not all, of the system,
often just moves the bottleneck somewhere else. The real problem is frequently a mismatch
between parts of the system. This problem will persist until all the components are in balance.
It is worth explicitly pointing out the difference between congestion control and flow control, as
the relationship is subtle. Congestion control has to do with making sure the subnet is able to
carry the offered traffic. It is a global issue, involving the behavior of all the hosts, all the
routers, the store-and-forwarding processing within the routers, and all the other factors that
tend to diminish the carrying capacity of the subnet.
Flow control, in contrast, relates to the point-to-point traffic between a given sender and a
given receiver. Its job is to make sure that a fast sender cannot continually transmit data
faster than the receiver is able to absorb it. Flow control frequently involves some direct
feedback from the receiver to the sender to tell the sender how things are doing at the other
end.
No comments:
Post a Comment