/share/doc/smm/18.net/c.t

  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.