Return to c.t CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 15.net

Annotation of 43BSDReno/share/doc/smm/15.net/c.t, revision 1.1

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.