Unknown | 151 lines | 151 code | 0 blank | 0 comment | 0 complexity | da93192e23f413b002bdcde56ecc6b22 MD5 | raw file
1.\" Copyright (c) 1983, 1986, 1993 2.\" The Regents of the University of California. All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 3. All advertising materials mentioning features or use of this software 13.\" must display the following acknowledgement: 14.\" This product includes software developed by the University of 15.\" California, Berkeley and its contributors. 16.\" 4. Neither the name of the University nor the names of its contributors 17.\" may be used to endorse or promote products derived from this software 18.\" without specific prior written permission. 19.\" 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" @(#)c.t 8.1 (Berkeley) 6/8/93 33.\" 34.nr H2 1 35.\".ds RH "Buffering and congestion control 36.br 37.ne 2i 38.NH 39\s+2Buffering and congestion control\s0 40.PP 41One of the major factors in the performance of a protocol is 42the buffering policy used. Lack of a proper buffering policy 43can force packets to be dropped, cause falsified windowing 44information to be emitted by protocols, fragment host memory, 45degrade the overall host performance, etc. Due to problems 46such as these, most systems allocate a fixed pool of memory 47to the networking system and impose 48a policy optimized for ``normal'' network operation. 49.PP 50The networking system developed for UNIX is little different in this 51respect. At boot time a fixed amount of memory is allocated by 52the networking system. At later times more system memory 53may be requested as the need arises, but at no time is 54memory ever returned to the system. It is possible to 55garbage collect memory from the network, but difficult. In 56order to perform this garbage collection properly, some 57portion of the network will have to be ``turned off'' as 58data structures are updated. The interval over which this 59occurs must kept small compared to the average inter-packet 60arrival time, or too much traffic may 61be lost, impacting other hosts on the network, as well as 62increasing load on the interconnecting mediums. In our 63environment we have not experienced a need for such compaction, 64and thus have left the problem unresolved. 65.PP 66The mbuf structure was introduced in chapter 5. In this 67section a brief description will be given of the allocation 68mechanisms, and policies used by the protocols in performing 69connection level buffering. 70.NH 2 71Memory management 72.PP 73The basic memory allocation routines manage a private page map, 74the size of which determines the maximum amount of memory 75that may be allocated by the network. 76A small amount of memory is allocated at boot time 77to initialize the mbuf and mbuf page cluster free lists. 78When the free lists are exhausted, more memory is requested 79from the system memory allocator if space remains in the map. 80If memory cannot be allocated, 81callers may block awaiting free memory, 82or the failure may be reflected to the caller immediately. 83The allocator will not block awaiting free map entries, however, 84as exhaustion of the page map usually indicates that buffers have been lost 85due to a ``leak.'' 86The private page table is used by the network buffer management 87routines in remapping pages to 88be logically contiguous as the need arises. In addition, an 89array of reference counts parallels the page table and is used 90when multiple references to a page are present. 91.PP 92Mbufs are 128 byte structures, 8 fitting in a 1Kbyte 93page of memory. When data is placed in mbufs, 94it is copied or remapped into logically contiguous pages of 95memory from the network page pool if possible. 96Data smaller than half of the size 97of a page is copied into one or more 112 byte mbuf data areas. 98.NH 2 99Protocol buffering policies 100.PP 101Protocols reserve fixed amounts of 102buffering for send and receive queues at socket creation time. These 103amounts define the high and low water marks used by the socket routines 104in deciding when to block and unblock a process. The reservation 105of space does not currently 106result in any action by the memory management 107routines. 108.PP 109Protocols which provide connection level flow control do this 110based on the amount of space in the associated socket queues. That 111is, send windows are calculated based on the amount of free space 112in the socket's receive queue, while receive windows are adjusted 113based on the amount of data awaiting transmission in the send queue. 114Care has been taken to avoid the ``silly window syndrome'' described 115in [Clark82] at both the sending and receiving ends. 116.NH 2 117Queue limiting 118.PP 119Incoming packets from the network are always received unless 120memory allocation fails. However, each Level 1 protocol 121input queue 122has an upper bound on the queue's length, and any packets 123exceeding that bound are discarded. It is possible for a host to be 124overwhelmed by excessive network traffic (for instance a host 125acting as a gateway from a high bandwidth network to a low bandwidth 126network). As a ``defensive'' mechanism the queue limits may be 127adjusted to throttle network traffic load on a host. 128Consider a host willing to devote some percentage of 129its machine to handling network traffic. 130If the cost of handling an 131incoming packet can be calculated so that an acceptable 132``packet handling rate'' 133can be determined, then input queue lengths may be dynamically 134adjusted based on a host's network load and the number of packets 135awaiting processing. Obviously, discarding packets is 136not a satisfactory solution to a problem such as this 137(simply dropping packets is likely to increase the load on a network); 138the queue lengths were incorporated mainly as a safeguard mechanism. 139.NH 2 140Packet forwarding 141.PP 142When packets can not be forwarded because of memory limitations, 143the system attempts to generate a ``source quench'' message. In addition, 144any other problems encountered during packet forwarding are also 145reflected back to the sender in the form of ICMP packets. This 146helps hosts avoid unneeded retransmissions. 147.PP 148Broadcast packets are never forwarded due to possible dire 149consequences. In an early stage of network development, broadcast 150packets were forwarded and a ``routing loop'' resulted in network 151saturation and every host on the network crashing.