Wherever possible, those functions having the greatest effect on performance have been imple mented in NETDRIVER. There they can be exe cuted at high priority without changing the pro cess context, which would be required for functions executed in NETACP.
Digital Technical]ournal No. 3 September 1986
Those functions that occur more infrequently have been implemented in NETACP, which pro vides the necessary process context. These func tions include state changes and others that require a process context to allow access to a large pageable database or system service. These include logical link creation and deletion, net work management functions operating on the volatile database, and routing table maintenance. Network Server Processes
Transferring large files across a network or accessing many remote files can consume con siderable resources on a remote system. Thus the provision of accurate accounting information for remote file access operations is quite desirable. This need led to the implementation of FAL as a single-threaded server. That server runs in the context of a process logged in to the remote sys tem on an account that is accessible to the initia tor of the file access request.
RMS, being procedure based, does not know whether or not an application program intends to access additional files via the same account on the remote system. Originally, the DAP imple mentation in RMS was designed to terminate the logical link with FAL upon closing a file or finish ing a file search sequence. Consequently, for example, a wild-card operation transferring n
files using the COPY command results in the invocation of a total of n + 1 FAL processes. One process performs the RMS search sequence, each of the others transfers in serial fashion each file that is found. Unfortunately, this approach significantly reduced overall throughput, espe cially when a large number of small files were being transferred.
The primary disadvantage of using separate processes for individual network tasks lies in the overhead required to create the process. The increasing complexity of authorization and pro tection mechanisms within the VMS system has increased the start-up time during process cre ation . This increase is experienced by users activating network tasks on other nodes as an increase in response time.
Support for network server processes was introduced in 1 983 to solve the overhead prob lem. A NETSERVER process can handle serially many logical links that require the same account on the server node. NETACP maintains a list of those NETSERVER processes that have been started for particular accounts but are now cur-
Digital Tecbnical]ournal
No. 3 September 1986
I
I
rently idle. When a new 'ogical link request specifying the same account is received, NETACP will forward the request to an appropriate idle NETSERVER process instead of creating a new process to handle the request. On a busy system, this action can trim seconds off the start-up time for the logical link. To pr¢vent the problem of the local system filling up with NETSERVER processes that no one nee
�
s to talk to, an idle NETSERVER will time out ahd delete itself after a certain amount of time.I
In 1 986, FAL was extended to include the capability to serially prodess multiple logical links (and as a result, multiple files) . This addi tion yielded a significant improvement in overall throughput for file transfer activity, especially for wild-card operations.
Window-based Congestion Control In a large network, data packets must be routed through several nodes bef
�
re reaching their des tinations. Congestion in ani
intervening node can severely decrease the thro1ughput of all logical links using that path. Con�inuing to send more data through a congested n<;>de only makes things worse. The systems at the ends of the logical link have no knowledge of which path is being used; therefore, they have no direct way of knowing where congestion may be occurring in the net work. This problem was addressed through theimplementation of a win
�
ow-based "back-off" scheme designed to detect the presence of con gestion somewhere alongl
the path. The rate at which data is sent willb
e reduced until the effects of the congestionat
e no longer seen. Node Database StructureDigital Equipment Corporation has a very large internal communications network. As that net
work grew in size, its volatile node database became a performance bottleneck. Searches through the database to locate a particular entry by name were causing ex
�
essive paging. Noting that the node database isi
frequently accessed using either the node name or the address as a search key, it was decide�
that the speed of a look-up should be the sa�
e for either type of search. To accomplish th�t, the node database was augmented by two balanced binary search trees, one keying off the node address, the other off the node name. 3 Each entry in each tree con tains a pointer to the node database entry refer enced by that entry. It also has a separate pointer97
The DECnet- VAX Product - An Integrated Approach to Networking
to the node in the companion tree, making it pos sible to parse the node database by either name or address.
Another problem with the volatile node data base developed in 1 984 as our internal network grew to over 2,500 nodes: the size of the data base caused the NETACP process to exceed its paging file quota. That quota was increased to accommodate 5 ,000 nodes, a limit exceeded less than one year later. At that point the best solution was to reduce the number of pages required by the node database rather than to continue taking a larger portion of the paging file.
In a very large network, most nodes are repre sented merely as names and addresses. Most of the other node parameters, such as routing ini tialization passwords, are generally used only for a small subset of the total node population. With that in mind an optimization that "walked" the binary trees was built into the search routines. Any node with only its name and address defined is completely represented by the binary tree entries; so no database entry is allocated. When a tree search locates an entry with no associated database entry, the name and address information from the tree entries will be used to initialize a template database entry to return to the caller. In a node database with 7, 000 entries, this opti mization resulted in a reduction of almost 2 ,500 pages in the paging file, which cut NETACP's total page file utilization almost in half.
Buffer Size Optimization
The DECnet architecture does not allow the seg mentation and reassembly of data packets at the data link layer. The architecture requires that the buffer size used by the NSP layer (the transport layer) must be small enough to be handled by any data link in the network. Traditionally, this has meant using 576-byte buffers in the NSP layer.
The 576-byte buffers limited the network's performance when Ethernet, with its 1 500-byte data link buffers, was supported. The NSP layer was still constrained to use the smaller buffers, since lower capacity data links existed in the net work. It was recognized that performance could be improved between nodes on the same Ether net by using the larger Ethemet buffers. In this case there was no chance of the packets being routed through a node that could not handle them. The problem was to recognize when this optimization could be safely used.
98
Solving this problem was easy on a routing node since it could determine that the destina tion node was exactly one "hop" distant on the same Ethernet. On a nonrouting node, however, this information was not readily available.
Fortunately, the NSP protocols establish the buffer size as the smaller of those offered by the two parties involved. Furthermore, a nonrouting node maintains (in its routing layer) a cached list of the nodes residing on the same Ethernet. That list enables the nonrouting node to address pack ets to other nodes directly without passing the packets through a routing node. This action per mits a nonrouting node to always offer the use of
1 500-byte buffers when it initiates a logical link request on an active Ethernet circuit. When the request arrives at the target node, the cache there will correctly reflect whether or not the source node is on the same Ethernet. If so, the node can either offer the larger buffers or demand the nor mal buffer size.
Summary
The DECnet-VAX product makes possible the provision of a comprehensive set of networking capabilities that are compatible with implemen tations in other operating systems. DECnet-VAX does this while integrating a high proportion of those capabilities into the heart of the operat ing system. That integration supplies services that make local and remote operations appear indistinguishable.
This integration was achieved by anticipating the need for integrated networking capabilities from the start. The necessary "hooks" were pro vided in a sufficiently general fashion to allow the continued development and expansion of the networking product. This design allowed DECnet Phase II to be included with the early releases of the VMS software, which did not have to change as DECnet-VAX progressed through Phases III and IV. Similarly, as the VMS system itself evolved to support multinode VAXcluster networks, DECnet-VAX was able to provide clus ter addressing through its coupling with the operating system.
As both the VMS operating system and DNA
continue to evolve, the design of the DECnet VAX software will permit it to follow both, providing transparent networking capabilities for users of VMS.
Digital TecbntcalJournal No. 3 September 1986
Acknowledgments
Any discussion about the basic design of the VMS software should acknowledge the contribu tions of its primary architects David Cutler and Richard Hustvedt. The design and implementa tion of DECnet-VAX owe much to the work of Scott Davis, Alan Eldridge, and Tim Halvorsen.
References
1 . N. La Pelle, M. Seger, and M. Sylor, "The Evolution of Network Management Prod ucts," Digital Tecbnietil journal (Septem
ber 1 986, this issue) : 1 1 7- 1 28.
2 . P. Karger, "Security in DECnet: Authentica tion and Discretionary Access Control,'' Digi tal Equipment Corporation Internal Techni cal Report, DEC TR- 1 2 1 .
3 . D. Knuth, The Art of Computer Program
ming , Volume 3 (Reading: Addison Wesley,
1 973) . Digital Tecbnical]ournal No. 3 September 1986 New Products 99 •