![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to c.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 15.net|
Return to c.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 15.net |
1.1 root 1: .\" Copyright (c) 1983, 1986 The Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted
5: .\" provided that the above copyright notice and this paragraph are
6: .\" duplicated in all such forms and that any documentation,
7: .\" advertising materials, and other materials related to such
8: .\" distribution and use acknowledge that the software was developed
9: .\" by the University of California, Berkeley. The name of the
10: .\" University may not be used to endorse or promote products derived
11: .\" from this software without specific prior written permission.
12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
15: .\"
16: .\" @(#)c.t 6.4 (Berkeley) 3/7/89
17: .\"
18: .nr H2 1
19: .\".ds RH "Buffering and congestion control
20: .br
21: .ne 2i
22: .NH
23: \s+2Buffering and congestion control\s0
24: .PP
25: One of the major factors in the performance of a protocol is
26: the buffering policy used. Lack of a proper buffering policy
27: can force packets to be dropped, cause falsified windowing
28: information to be emitted by protocols, fragment host memory,
29: degrade the overall host performance, etc. Due to problems
30: such as these, most systems allocate a fixed pool of memory
31: to the networking system and impose
32: a policy optimized for ``normal'' network operation.
33: .PP
34: The networking system developed for UNIX is little different in this
35: respect. At boot time a fixed amount of memory is allocated by
36: the networking system. At later times more system memory
37: may be requested as the need arises, but at no time is
38: memory ever returned to the system. It is possible to
39: garbage collect memory from the network, but difficult. In
40: order to perform this garbage collection properly, some
41: portion of the network will have to be ``turned off'' as
42: data structures are updated. The interval over which this
43: occurs must kept small compared to the average inter-packet
44: arrival time, or too much traffic may
45: be lost, impacting other hosts on the network, as well as
46: increasing load on the interconnecting mediums. In our
47: environment we have not experienced a need for such compaction,
48: and thus have left the problem unresolved.
49: .PP
50: The mbuf structure was introduced in chapter 5. In this
51: section a brief description will be given of the allocation
52: mechanisms, and policies used by the protocols in performing
53: connection level buffering.
54: .NH 2
55: Memory management
56: .PP
57: The basic memory allocation routines manage a private page map,
58: the size of which determines the maximum amount of memory
59: that may be allocated by the network.
60: A small amount of memory is allocated at boot time
61: to initialize the mbuf and mbuf page cluster free lists.
62: When the free lists are exhausted, more memory is requested
63: from the system memory allocator if space remains in the map.
64: If memory cannot be allocated,
65: callers may block awaiting free memory,
66: or the failure may be reflected to the caller immediately.
67: The allocator will not block awaiting free map entries, however,
68: as exhaustion of the page map usually indicates that buffers have been lost
69: due to a ``leak.''
70: The private page table is used by the network buffer management
71: routines in remapping pages to
72: be logically contiguous as the need arises. In addition, an
73: array of reference counts parallels the page table and is used
74: when multiple references to a page are present.
75: .PP
76: Mbufs are 128 byte structures, 8 fitting in a 1Kbyte
77: page of memory. When data is placed in mbufs,
78: it is copied or remapped into logically contiguous pages of
79: memory from the network page pool if possible.
80: Data smaller than half of the size
81: of a page is copied into one or more 112 byte mbuf data areas.
82: .NH 2
83: Protocol buffering policies
84: .PP
85: Protocols reserve fixed amounts of
86: buffering for send and receive queues at socket creation time. These
87: amounts define the high and low water marks used by the socket routines
88: in deciding when to block and unblock a process. The reservation
89: of space does not currently
90: result in any action by the memory management
91: routines.
92: .PP
93: Protocols which provide connection level flow control do this
94: based on the amount of space in the associated socket queues. That
95: is, send windows are calculated based on the amount of free space
96: in the socket's receive queue, while receive windows are adjusted
97: based on the amount of data awaiting transmission in the send queue.
98: Care has been taken to avoid the ``silly window syndrome'' described
99: in [Clark82] at both the sending and receiving ends.
100: .NH 2
101: Queue limiting
102: .PP
103: Incoming packets from the network are always received unless
104: memory allocation fails. However, each Level 1 protocol
105: input queue
106: has an upper bound on the queue's length, and any packets
107: exceeding that bound are discarded. It is possible for a host to be
108: overwhelmed by excessive network traffic (for instance a host
109: acting as a gateway from a high bandwidth network to a low bandwidth
110: network). As a ``defensive'' mechanism the queue limits may be
111: adjusted to throttle network traffic load on a host.
112: Consider a host willing to devote some percentage of
113: its machine to handling network traffic.
114: If the cost of handling an
115: incoming packet can be calculated so that an acceptable
116: ``packet handling rate''
117: can be determined, then input queue lengths may be dynamically
118: adjusted based on a host's network load and the number of packets
119: awaiting processing. Obviously, discarding packets is
120: not a satisfactory solution to a problem such as this
121: (simply dropping packets is likely to increase the load on a network);
122: the queue lengths were incorporated mainly as a safeguard mechanism.
123: .NH 2
124: Packet forwarding
125: .PP
126: When packets can not be forwarded because of memory limitations,
127: the system attempts to generate a ``source quench'' message. In addition,
128: any other problems encountered during packet forwarding are also
129: reflected back to the sender in the form of ICMP packets. This
130: helps hosts avoid unneeded retransmissions.
131: .PP
132: Broadcast packets are never forwarded due to possible dire
133: consequences. In an early stage of network development, broadcast
134: packets were forwarded and a ``routing loop'' resulted in network
135: saturation and every host on the network crashing.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.