Reviewing Basic Network Traffic Concepts

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Wally Mead, Janet Sheperdigian—PBS Courseware

Editor's Note This article is excerpted from "Optimizing Network Traffic," which is part of the Microsoft Press Notes From the Field series that outlines the best system management practices and procedures. For more information on this and other Microsoft Press books, go to https://www.microsoft.com/mspress/.

This chapter explains some basic, but essential concepts of network traffic generated by Microsoft Windows NT Server networking services, providing a framework for analyzing, optimizing, and predicting traffic. It defines amounts of traffic created by these services and their frequency, and organizes them by function: client initialization, and client-to-server and server-to-server communication.

The discussion describes each network service's impact on the network and how effectively its traffic can be optimized, and it provides baseline numbers for specific types of traffic (based on a small local area network—LAN). These are general figures, so actual traffic in your organization may vary. The final sections of this chapter include test results based on the sample LAN to help you assess potential traffic as your organization grows, and information on Network Monitor to help you examine actual traffic. NetMon is included with Windows NT Server and Systems Management Server.

Use the information in this chapter as a foundation on which to build a more efficient network for your organization. Systems administrators familiar with these concepts, or who have taken training on Microsoft Windows NT Server 4.0 Network Analysis and Optimization, may want to go right to Chapter 2 and read about everyday traffic on Microsoft's network.

On This Page

What You'll Find In This Chapter
Windows NT Server and Networking Services
Client Initialization Traffic
Client-to-Server Traffic
Server-to-Server Traffic
Network Monitor
Predicting Network Traffic

What You'll Find In This Chapter

• Description of Microsoft Windows NT Server networking services.

• Explanations of how services impact network traffic.

• Walkthrough of client initialization traffic.

• Review of client-to-server network traffic.

• Detailed look at server-to-server traffic.

• Tips for optimizing service-based network communications.

Warning: This chapter makes recommendations for tuning the Windows NT registry using the Registry Editor. Using the Registry Editor incorrectly can cause serious, system-wide problems that require you to reinstall Windows NT. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

Windows NT Server and Networking Services

Windows NT automatically installs various network services, some providing essential network communication and others providing optional functionality. You must configure them correctly or they can bog down the network.

This section describes the Windows NT services covered in this chapter, lists different ways of characterizing them, and describes how the traffic generated by these services varies according to protocol.

Windows NT networking services

Service	Description
NetLogon	Validates user account logon and synchronizes domain accounts. Also supports the establishment and maintenance of trust relationships.
Computer Browser	Provides browsing capabilities that allow users to find resources on the network without having to remember connection syntax and locations.
DHCP	Provides automated administration of TCP/IP addresses and other configuration parameters for DHCP clients.
WINS	Provides a centralized location to resolve computer names for browsing and resource access.
Directory Replicator	Provides automated duplication of directories among multiple Windows NT-based computers.
Domain Name System (DNS)	Provides for name resolution of TCP/IP host names into IP addresses.
Microsoft Internet Explorer	Provides access to World Wide Web (WWW) locations for viewing and downloading files.

Characterizing Services

You can characterize Windows NT Server services by:

• The type of traffic they generate.

• How often they generate it.

• The traffic's relative impact on the network.

To analyze the functionality of a specific service:

1. Use an isolated network.

2. Use a network capturing and analysis tool, such as Network Monitor.

3. Initiate network traffic relative to the service you want to characterize.

4. Identify each frame in the capture.

Comparing Network Protocols

The type of traffic a network service generates depends somewhat on the protocol it uses. Traffic consists of frames, which contain address and protocol information, and the data being transferred. There are three types:

• Broadcast frames. Delivered to all network hosts. These can have a specific host as their destination, but because of protocol or addressing reasons, they go to all hosts, creating more network traffic than is probably necessary.

• Multicast frames. Delivered to a subset of network hosts. Although they do not generate as much traffic as broadcasts, they create more traffic than frames sent to a specific destination media access control (MAC) address.

• Directed frames. Delivered to a specific network host. Hosts that receive directed frames and do not find their own MAC address can discard them. Protocols that use directed frames generate the least amount of network traffic.

Protocols supported by Windows NT differ in their implementation of frames (units of communication) and this often influences the amount of traffic placed on the network. For instance, NWLink initiates broadcast frames, putting a lot of traffic on the network, while Transmission Control Protocol/Internet Protocol (TCP/IP) initiates directed frames, which creates less traffic and makes it a more popular choice.

Broadcast traffic has a large effect on a network's ability to operate efficiently. It tends to go unnoticed on LANs, which usually have plenty of available bandwidth, but it is still a good idea to minimize it. On the WAN, where there are more contenders for available bandwidth, broadcast traffic is more troublesome. You can reduce it on the WAN by configuring routers so that they do not forward broadcasts. This reduces overall traffic, but it has a downside in that applications using broadcasts will not have full functionality throughout the entire enterprise even though they will on the LAN, where they do not have to cross routers. This may be an acceptable solution, in which case you are home free, but there obviously are several sides to consider when approaching this issue.

TCP/IP was designed to avoid the disadvantages of other protocols (such as NetBEUI—the NetBIOS Enhanced User Interface) that broadcast a high percentage of frames. TCP/IP delivers directed frames over a routed network environment while using minimum bandwidth. For this reason, TCP/IP is a good choice as a network protocol, and this chapter uses it exclusively when examining network traffic.

Client Initialization Traffic

Network services generate varying amounts of traffic. To understand their impact during a normal workday, it helps to look at them to see what types of traffic they generate and when they generate it. The first type of network traffic occurs when a client computer initializes.

Network services that generate client initialization traffic.

Traffic type	When generated
DHCP	During IP address acquisition, renewal, and release.
WINS	During NetBIOS name registration, resolution, renewal, and release.
File session	When two computers set up a session.
Logon validation	When a user logs on to the network and is validated by a domain controller (DC).

Capture and analysis of these network tasks provides information you can use to control or reduce client initialization traffic, which normally represents 20 percent of the traffic clients generate.

Figure 1.1: Approximate percentage of client traffic in an eight-hour day.

Note: This illustration reflects the percentage of each task's traffic based on an eight-hour day, assuming the levels of use as noted in the figure. If users log on five times each day, or only once every two weeks, then the percentages of other traffic adjust accordingly.

DHCP Traffic

In an Internet Protocol (IP) network environment, before a host (computer, router, printer, and so on) can access the network and communicate with other hosts, it must have a properly configured IP address and subnet mask (which blocks the shared address information and reads only the significant information). You can configure these values manually or use dynamic host configuration protocol (DHCP), which assigns them automatically. The process of acquiring an address occurs one time for each client on the network and generates four frames:

Requesting an IP address with DHCP.

Frames	Description
DHCP Discover	Client's broadcast to locate a DHCP server.
DHCP Offer	DHCP server's response identifying the IP address the client can lease.
DHCP Request	Client's response indicating it accepts the server's offer.
DHCP ACK	Server's response acknowledging (ACK) the lease by providing the lease life and any TCP/IP parameters.

If you use DHCP, communications generally occur when:

• A DHCP client initializes for the first time (requires all four frames).

• During an automatic renewal at one-half lease life, requiring two frames (DHCP Request and DHCP ACK), and approximately 200 milliseconds.

• Client moves to a new subnet (requires DHCP Request, DHCP NACK, and then four frames as if it were a new client).

• DHCP client replaces its network adapter card (requires all four frames).

• Client manually refreshes or releases its address with IPCONFIG.

• Client restarts (DHCP Request and DHCP ACK as broadcast traffic, similar to the automatic renewal).

Note: The default lease life is 3 days (72 hours). Using this default, automatic renewal will occur at one-half lease life (36 hours).

Relative Network Impact

DHCP does not significantly increase network traffic: acquiring an IP address lease through DHCP takes less than one second (approximately 300 milliseconds). If DHCP is generating an excess amount of network bandwidth, it can be due to an extremely small lease duration, or to a router forwarding DHCP messages from other subnets. DHCP leasing traffic includes two phases.

DHCP lease phases.

DHCP Traffic	Frames	Bytes	Frequency
Acquire IP Address Lease	4	1,368	Once per client
Renew IP Address Lease	2	684	Every startup and at one-half lease life

IP Address Lease Acquisition

When a new DHCP client initializes, it first uses DHCP to acquire an IP address by sending four frames to the server (see the table "Requesting an IP address with DHCP" above).

IP Address Lease Renewal

To renew its lease before expiration, a client uses the last two DHCP frames of the IP address. There are two methods of DHCP lease renewal:

• At startup, the client computer requests a renewal of its current IP address with a DHCP request frame. If successful, the DHCP server responds with a DHCP ACK (acknowledgement) frame. This process uses broadcast frames.

• At one-half of the lease duration period a client issues a DHCP request frame directly to its DHCP server. If the client's address is valid, the server responds with a DHCP ACK frame. The request and ACK use directed frames because the client has already renewed the address from its server at startup.

If a DHCP client cannot complete its renewal at 50% of lease duration, it tries to renew at 87.5% and at 100% before it returns to the four-frame initialization mode.

Optimizing

To reduce the amount of traffic generated by DHCP you can:

• Adjust the duration of the IP address lease in the Scope Properties dialog box of DHCP Manager. For instance, if you increase the default lease life of three days to 30 days you reduce the frequency of client renewals. If the number of clients using DHCP equals the number of available DHCP IP addresses on your network, use a short lease life. If the number of DHCP clients is less than the number of available DHCP IP addresses on your network, use a longer lease.

• Configure a relay agent to forward DHCP broadcasts to other subnets. You can configure IP addresses for DHCP servers using most DHCP relay agent software. The relay agent eliminates traffic by forwarding DHCP requests to only the subnets containing DHCP servers.

Note: For more information on IP address lease frames, see "Configuring DHCP" in Windows NT Server 4.0 Resource Kit: Networking Guide.

WINS Client Traffic

After a Microsoft TCP/IP client initializes its IP address it registers NetBIOS names (its computername, which is also the TCP/IP host name). When using these "friendly" names to access other systems, the NetBIOS names must be resolved to IP addresses. NetBIOS names are registered, resolved, renewed, and released using either b-node broadcasts or a NetBIOS Name Server, such as Windows Internet Naming Service (WINS). (For information on NetBIOS node types, sees p. 130.)

Relative Network Impact

WINS client-related traffic affects available network bandwidth, but not significantly. Even so, if you understand the traffic, you can plan for it. If the network is saturated, you can reduce WINS traffic frequency to free up bandwidth for other services.

Types of WINS traffic.

WINS traffic	Frames	Bytes	Frequency
Registration	2	214	Once per service or application at startup
Renewal	2	214	Once per service or application every one-half time to live (TTL—the period after which the client must renew its name)
Resolution	2	196	Varying frequencies
Release	2	214	Every service shutdown

Name Registration

NetBIOS names are registered for every service or application that supports NetBIOS. Examples include Windows NT Workstation and Server services, Network Monitor, and special names to indicate roles on the network, such as primary domain controller (PDC) or backup domain controller (BDC). The number of names registered depends on the number of network services and applications the client computer initializes, typically three or four.

Name Renewal

A name is successfully registered when the WINS server responds with a message that includes a time-to-live (TTL) after which the client must renew the name. The TTL determines the amount of traffic that WINS renewals generate. The WINS server default configuration for a renewal interval is 144 hours, or six days—the server assigns a TTL of 518,400 seconds. This pattern repeats every three days because WINS clients renew their names every one-half TTL.

Common names registered by a Microsoft client computer.

Name registered	Description
Computername <00>	Registered by the client's Workstation service.
Computername <03>	Registered by the Messenger service, allowing the host to receive messages, such as net send computername.
Username <03>	Registered by the Messenger service, allowing the user to receive messages, such as net send username.
Computername	Registered by the Server service. It appears as computername <20>, depending on the utility used to view the names registered, allowing the host to receive connection requests from other hosts.
Workgroup or domainname <00>	Registered as a group NetBIOS name, as opposed to a unique NetBIOS name, similar to the computername. This registers the computer as a member of the domain or workgroup.
Workgroup or domainname <1E>	Registered as a Group NetBIOS Name and used for browser elections.
Domainname <1B>	Registers the local computer as the Domain Master Browser for the domain. Registered as a unique NetBIOS name.
Domainname <1C>	Registers the local computer as a DC for the domain. Registered as a group NetBIOS name.
Workgroup or domainname <1D>	Registers the local client as the local subnet's Master Browser for the workgroup or domain. Registered as a unique NetBIOS name.

Name Resolution

For TCP/IP networks, WINS acts as a NetBIOS name server to resolve registered names into IP addresses. Name resolution traffic occurs very frequently on the network: during logon validation, resource browsing, server connections, and print job notifications.

Name Release

The client (host) owns the registered name until it releases it by stopping a service or shutting down making it available for another computer to register.

Optimizing

You can use several techniques to reduce WINS registration and renewal traffic.

• Disable unnecessary services. For instance, if the client does not provide any network resources, you can disable the server service.

• Increase the NetBIOS name cache. After a NetBIOS name is resolved, it is placed into the client's internal NetBIOS name cache. Whenever name resolution occurs the cache is checked before initiating a request to the WINS server. By default, entries stay in the cache for 10 minutes (600,000 milliseconds). You can reduce WINS queries for frequently used servers by increasing the value of the registry subkey:

  HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \CacheTimeout

• Implement the LMHOSTS file. This file resolves NetBIOS names to IP addresses using a static ASCII text file. A disadvantage is that the LMHOSTS is not dynamic like the WINS server: when you bring new servers online you need to add them manually to the LMHOSTS file.

  The LMHOSTS file is scanned when the client starts (or restarts). You can pre-load specific entries into the NetBIOS name cache to prevent any network traffic from occurring during resolution (because the name is already in the NetBIOS name cache). This is helpful if a server or set of servers is frequently accessed.

  Note: You can further reduce traffic by sharing the contents of a centralized LMHOSTS file. This produces network traffic only at startup to find the file, when searching for pre-loaded entries, and during name query attempts.

• Adjust the name resolution TTL in WINS Manager. The default is six days. Increasing the TTL decreases network traffic.

File Session Traffic

Unless you are using DHCP, WINS, or DNS, all computers generate network traffic when they establish a file session with a server.

Relative Network Impact

The amount of traffic is not large, only about 11 frames totaling 1,300 bytes. If a user connects to multiple resources on a single server, only one session is established. Each connection generates the traffic necessary to establish the connection, but not the session. Traffic can increase if each user establishes multiple sessions per day. However, most file session traffic occurs after session establishment, when the files are accessed on the server.

Types of file session traffic.

File session traffic	Frames	Bytes	Frequency
Address Resolution	2	120	Every connection
TCP Session	3	180	Every initial connection to server
Establish NetBIOS Session	2	186	Every initial connection to server
SMB Protocol Negotiation	2	~365	Every initial connection to server
Connection Sequence	2	~360	Every connection attempt
Session Termination	5	360	Final disconnect from each server

Optimizing

File session traffic is relatively light (compared to the traffic typically generated after a connection is made), and there is little you can do to optimize it. However, the same set of frames is used during several types of communications, which is helpful in analyzing other types of traffic.

To limit the amount of file session traffic.

• Remove any excess protocols (connection requests are sent over all protocols simultaneously).

• Place commonly accessed clients and servers close together. For instance, if a single group of clients on one subnet generates the most activity to a specific server, move that server to that client's subnet, to eliminate adding traffic to other subnets during file session activity.

Logon Validation Traffic

One of the first functions a network provides to a user is logon validation. The user requests validation by entering a user name and password in a logon dialog box. Once the logon server is located, communication to validate the logon request, check the system time, and possibly run logon scripts, user profiles, and so on occurs.

Relative Network Impact

To determine the network impact of logon validation, you must assess the number of logon servers, when logon traffic occurs, and if remote clients are logging on to the domain. The minimum amount of client logon traffic is 3105 bytes, in 24 frames.

Types of logon traffic.

Logon traffic	Frames	Bytes	Frequency
Session Establishment	15	2,000	Once per logon session
Validation (Windows 95)	4	760	Once per logon session
Validation (Windows NT)	20	2,700	Once per logon session
Session Termination	5	360	Once per logon session

Finding a Logon Server

Finding a DC to validate the user account is accomplished in two ways:

• For Windows 9x- and Windows NT–based client computers, a request is broadcast to the NETLOGON mailslot, requiring at least two frames.

• For clients configured as h-node WINS clients, WINS is queried for all registered DCs in the domain and then validation is requested using directed frames.

Validating the Logon Request

Next, the client takes the first server response to its request, and initiates this traffic.

• The client resolves the NetBIOS name of the selected logon server, either by querying WINS, or by broadcast.

• A TCP session is established with the logon server using the TCP three-way handshake process.

• A NetBIOS session is established with the logon server.

• Server Message Block (SMB) protocol negotiation occurs.

• SMB tree connection to \\logonserver\IPC$ is established.

For Windows 9x clients, after the logon request process is complete, the client validates the logon by communicating with the logon server using remote API calls.

Windows NT–based computers use three unique steps to validate a logon request:

• A list of trusted domains is accessed through the Logon Information dialog box.

• A secure channel between the Windows NT–based computer and the validating DC is established generating eight frames (approximately 1,400 bytes) of traffic.

• Logon is validated using remote API calls generating around 900 bytes of traffic depending upon name lengths (user, computer, and domain).

After the client account is validated, logon scripts, user profiles, or system policies can begin, resulting in additional network traffic.

Session Termination

The session ends when the connection to interprocess communication (IPC$) is closed, and the NetBIOS and TCP sessions are terminated.

Optimizing

You can optimize logon validation services by:

• Scaling your DCs sensibly. A conservative recommendation is that one DC can handle normal logon validation requests for about 2,000 user accounts. To make sure you have enough DCs use these Performance Monitor counters to monitor logon requests:

Performance Monitor counters.

Object/counter	Description
Server: Logon/sec	Monitors the number of logon requests per second. These include both successful and unsuccessful attempts for interactive, network, and service account logon requests.
Server: Logon Total	Monitors the total number of interactive, network, and service account logon requests, both successful and unsuccessful attempts, since the server was last started.

• Increasing simultaneous logon validations. By default, DCs have their Server service configured for Maximize Throughput for File Sharing. While this is the proper setting for a file and print server, it does not provide the best performance for a DC that needs to validate logon requests. Instead, configure the Server service of all DCs for Maximize Throughput for Network Applications. If you properly configure this option, most DCs can triple their number of simultaneous logons, from about 6 or 7 per second, to around 20.

• Placing the DC in an appropriate location. Generally, the closer the DC is to the client, the quicker validation can be processed.

  For a remote site, you must balance the cost of logging on over the WAN to a central DC against the cost of placing a BDC at the remote site. Even if you can afford to put a DC at each remote site, it increases WAN traffic during directory services synchronization (replication) and increases the possibility of a directory services database getting out-of-date if the WAN goes down.

• Determining hardware requirements for DCs. Use the number of accounts in the directory services database to see if you need to upgrade hardware.

Client-to-Server Traffic

When a client computer communicates with a server computer these types of traffic are generated:

Network services that generate client-to-server traffic.

Traffic type	Description
Browser	Traffic generated when clients register as possible providers of network resources, retrieving a list of backup browsers, a list of servers on the network, and a list of resources on a server.
Domain Name System (DNS)	Traffic generated by TCP/IP hosts during TCP/IP host name resolution. Usually generated by TCP/IP utilities such as Ping and Telnet, or applications such as Internet Explorer.
Web-based browsing	Traffic generated by the Internet Explorer browser application to download pages from a Web site.

Note: Client-to-server traffic represents 80 percent of total client-generated traffic.

Figure 1.2: Approximate percentage of client traffic in an eight-hour day.

Browser Service (Browsing) Traffic

The browser process helps users locate network resources:

1. Servers are added to the browse list by issuing announcements to the master browser.

2. The master browser shares the list of servers (as well as domains) with the backup browsers.

3. A client computer retrieves a list of backup browser computers from the master browser.

4. The client computer contacts a backup browser to retrieve a list of servers.

5. The client contacts the server to retrieve a list of shared resources on the server.

Each of these steps produces network traffic.

Relative Network Impact

The basic types of traffic are shown in the table below. Remember that browsing differs from protocol to protocol, significantly affecting network impact.

Types of client browser traffic.

Client browser traffic	Frames	Bytes	Frequency
Host Announcement	1	243	Once per server every 12 minutes (at a steady state)
Find Backup Browser	2	450	Once per browsing computer at initial browse attempt
Election	Many	225	After each computer capable of becoming the master browser initializes
Retrieve Browse List	20	2,150	Every browse attempt by client and every 12 minutes for each backup browser
Retrieve Shared List (Windows 9 x)	16	1,900	Every browse list by client
Retrieve Shared List (Windows NT)	19	3,300	Every browse list by client

Host Announcements

Computers that can provide network resources announce themselves every 12 minutes, and more frequently during initialization to ensure the server's addition to the browse list. These announcements occur automatically, regardless of whether the computer has any shared resources.

Retrieving a Browse List

To access shared resources, the client retrieves a list of available resources by first finding the local master browser and retrieving a list of backup browsers. It then contacts a backup browser, and connects to it, retrieving the browse list. The amount of traffic generated varies depending on which domain is being browsed, how many entries are in the browse list, and how many shared resources are available on the target server.

Note: Most routers on remote subnets are not configured to forward browser broadcasts. WINS makes it possible to browse network resources throughout the enterprise without forwarding broadcasts.

Optimizing

You can optimize client browser traffic by:

• Disabling unnecessary server components. If a computer rarely shares network resources, consider disabling its server component. This removes the announcements, and reduces the size of the browse list that must be maintained and transferred.

  Every server requires 27 bytes in the browse list, plus additional space for the comment, if assigned. Consider limiting or reducing the size of computer comments.

• Controlling the number of potential browsers. Reduce the registration, renewal, and release of the NetBIOS names with WINS or b-node broadcasts. For Windows NT, set this registry subkey value to No:

  HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Browser \Parameters \MaintainServerList.

  For Windows 95, use the Network icon in Control Panel to configure the File and Printer Sharing Properties Browse Master parameter to Disabled.

  For Microsoft Windows for Workgroups, add MaintainServerList to the [network] section of SYSTEM.INI, and set it to No.

• Eliminating unnecessary network protocols. The browsing system is protocol dependent, meaning that browsing occurs on a protocol-by-protocol basis on each network segment (there is a master browser and backup browsers for each protocol on each network segment). If a network uses three protocols, all browser announcements and elections are repeated three times, one for each protocol. Reducing the number of protocols has a large impact on reducing browser-related network traffic.

DNS Traffic

When users access a computer using standard Windows networking commands and utilities, such as Network Neighborhood or the net command, the NetBIOS name of the target computer must be resolved (often by WINS) into an IP address. When users access a computer using TCP/IP utilities, such as Internet Explorer or the PING command, the IP host name of the target computer must be resolved into an IP address. This process, called host name resolution, can be accomplished using the Domain Name System (DNS).

Relative Network Impact

DNS traffic affects the network in two ways: the number of requests generated by clients and the number of recursive lookups generated by servers.

Types of DNS traffic.

DNS traffic	Frames	Bytes	Frequency
Name Lookups	2	~180	Every name resolution
Zone Replication—A zone is a database file that contains records for a particular domain.	4	~200	At addition of secondary server to the zone, and periodically (every 60 minutes by default)
Integration with WINS	4	240	Every non-local name lookup

DNS Lookups

DNS lookups are the client request and server response communications. When an IP client needs to resolve a TCP/IP host name into an IP address, it sends a DNS query to its DNS server. This request is a frame of varying size, depending upon the length of the host name to be resolved. Host names can be up to 256 characters.

DNS Recursive Lookups

When the DNS server receives the client's request, the server determines if it has an entry and, if it does, issues a directed response that includes the IP address of the host name in question.

If the client's configured DNS server does not contain a listing for the requested name, it forwards the request to another DNS server for resolution. The process of forwarding requests is called recursion or zone transfer, and must be configured by the administrator.

Optimizing

Reduce recursion traffic by:

• Not configuring recursion. Of course, this limits the number of requested names DNS can supply, and it requires that all host names be added to each DNS server, which is an administrative burden.

• Designating DNS server. Ensuring that the DNS server that will most likely resolve most of the names for a particular client is designated as its DNS server. This reduces the chance of a recursive lookup and its associated traffic.

• Increasing the TTL of cached entries using DNS Manager. DNS Manager Help explains how to configure for all records in a zone, for an individual record, or for WINS records.

Intranet Browsing Traffic

Relative Network Impact

As intranet browsing becomes more popular as a means of accessing files, it contributes larger amounts of client-based network traffic as a result of large file downloads.

Types of intranet traffic.

ntranet traffic	Frames	Bytes	Frequency
Connecting to a Web site	2	180	Each connection to server
Requesting a Web page	2	360+	Multiple per page
Browsing Security	varies	varies	Multiple per page

Connecting to a Web Site

To connect to a Web site, the Web server's name is resolved using a method of name resolution, such as DNS lookup. Once the client is connected, it requests pages (files) from the Web server using the Hypertext Transfer Protocol (HTTP) command GET. The requested file is specified in the HTTP section of the frame. Additional HTTP GET messages are sent if there are images or graphics that need to be downloaded. Each requested file transfer requires a new TCP session (and TCP Port).

When the Web server receives the request and determines that the requested file is available, it sends HTTP response frames. If the response is larger than 1,238 bytes it takes at least two response frames to transfer the file. Subsequent frames carry 1,450 bytes of file data because most of the HTTP header information is not included.

For example, downloading the /samples/default.htm (from a Microsoft Internet Information Server—IIS—2.0 installation) generated 76 frames (including the DNS lookup and response) and 48,539 bytes of traffic. Ten files totaled 38,343 bytes. The other 10,200 bytes were used by the DNS lookup and response, the 10 HTTP GET commands, the required TCP session, and the TCP acknowledgements.

Intranet Browsing Security

The default configuration for IIS 3.0 enables anonymous connections. User accounts and passwords are not needed to access sites. If Windows NT challenge-response security is enabled on the server, it responds to a client request with an access denied HTTP frame and terminates the session. The client establishes a new TCP session with the server, and sends its un-encoded information to the server. The server responds with the appropriate encryption key to use.

Without security, downloading the /samples/default.htm page took 74 frames and 48,375 bytes (excluding the two DNS frames). With Windows NT challenge-response security enabled, the same page took 115 frames and downloaded 56,145 bytes.

Optimizing

Because intranet browsing can generate significant amounts of network traffic, any measure to optimize this traffic is beneficial.

• Keep Web site pages small. As a general rule, a good HTML design limits page scrolling.

• Limit the size of graphics or .AVI files used. Reuse common graphics throughout the intranet.

• Consider level of security needed with your site. Security requires additional authentication traffic for each session that is established. Allowing anonymous connections prevents the authentication traffic from occurring on the network.

• Instruct users to increase the client's local cache. Previously downloaded files do not have to be downloaded again.

Server-to-Server Traffic

Server-to-server traffic, generated between server computers carrying out network maintenance tasks, includes:

Network services that generate server-to-server traffic.

Traffic type	Description
Account synchronization	Synchronization of the user accounts databases between the PDC and BDCs.
Trust relationships	Establishment of a trust relationship, as well as the importing of trusted accounts. Also includes traffic generated by pass-through authentication.
Server browser traffic	Server announcements, master browser elections, and browse list exchanges between browser servers.
WINS replication	Replication of WINS server database records to another WINS server.
Directory replication	The automatic duplication of a directory structure among computers.
DNS server	DNS server zone transfers.

Figure 1.3: Approximate percentage of server-to-server traffic in an eight-hour day.

Account Synchronization Traffic

In a Windows NT Server network, user logon validation requests are processed by either the PDC or a BDC. Changes to the user accounts database are made only on the PDC so for logon requests to be properly validated, each BDC must have an updated copy of these databases.

User accounts that are synchronized.

Database	Contents
SAM Accounts	User and group accounts, all built-in global groups, and computer accounts added to the domain such as DCs and Windows NT Workstation-based computers.
SAM Built-in	Built-in local group accounts such as Administrators, Users, and Guests.
LSA	LSA Secrets that are used for trust relationships, DC computer account passwords, and account policy settings.

Relative Network Impact

Multiple updates to the accounts database generate a large amount of network traffic. The configuration of the NetLogon service, which performs synchronization, determines the frequency and amount of traffic.

Types of account synchronization traffic.

Account synchronization traffic	Frames	Bytes	Frequency
Finding the PDC	4	745	Once per BDC startup
Establishing a Session	11	1,280	Every synchronization event
Establishing a Secure Channel	8	1,550	Once per BDC startup
Verifying Database	6	1,350	Once per BDC startup
PDC Update Notice	1	400	Every synchronization event
Synchronizing Database	7	2,000 +	Every synchronization event

Complete Database Updates

Beginning with Windows NT 3.5x, most synchronization events are partial—only updated records are transferred to the BDC—but full synchronization is used to ensure database integrity when:

• A new backup DC is installed.

• The change log file fills, and starts wrapping (over-writing changes).

• An error occurs during a partial synchronization.

• The administrator at the BDC issues a net accounts/sync command.

Finding the Primary Domain Controller

When a BDC initializes it must verify and possibly update its user accounts database by locating the PDC. The BDC caches the entry for later use.

Establishing a Session

The session between the BDC and the PDC involves: name resolution, address resolution, a TCP session, a NetBIOS session, server message block (SMB) protocol negotiation, and a connection to IPC$.

Establishing a Secure Channel

After a session is established, the BDC establishes a secure channel with the PDC. The secure channel is not broken until one of the two DCs is shut down, allowing new sessions, verification, and updates to occur (because they can time-out) without requiring re-establishment of the secure channel.

Verifying the Database

Once the required sessions and secure channel are established, database verification can proceed. This takes about 1,344 bytes (six frames—more are used if updates are included) depending on the computer names.

Partial Database Updates

By default, the PDC verifies its databases every five minutes, looking for changes to any of the three databases. When the PDC finds a change it sends an update message to any BDC without an up-to-date database. To determine which BDCs require the update, the PDC consults a table it maintains of BDCs and their database version IDs.

Note: By default Windows NT Server 4.0 sends update announcements to ten BDCs at a time. If there are more than ten, the PDC sends a second round of announcements when synchronization is complete for one BDC and continues in this fashion until all BDCs have synchronized.

When the BDC receives the update announcement, it compares version IDs and requests updated data if they are different. If the BDC and PDC session is still viable, the BDC generates four frames to verify the account database using NetLogon Service. The PDC sends the updated data using SMB or RPC calls (depending on the size of the update), generating multiple frames. This entire process can take as few as ten frames to complete.

Optimizing

You can control user account synchronization traffic by configuring registry parameters for the NetLogon service in this subkey:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Netlogon \Parameters

ReplicationGovernor

This is the most commonly modified NetLogon parameter. It controls the percentage of network bandwidth the NetLogon service can use while synchronizing user accounts. Its default value is 100, meaning NetLogon can use 100 percent of the network bandwidth while the PDC buffers 128 KB of data, which of course is disastrous in a WAN environment where users need bandwidth.

If you add the ReplicationGovernor to the NetLogon key and set it to 50, NetLogon buffers only 50 percent as much data (64 KB) for transmission, and has synchronization messages on the network only 50 percent of the time. Do not set it too low (never lower than 25), or synchronization may never complete.

Other NetLogon Parameters

These parameters can help control the amount of network traffic generated during synchronization:

NetLogon parameters.

Parameter	Controls
Pulse	How often the PDC looks for changes to its directory services database. The default is five minutes; the maximum is 48 hours. Don't set this too high: if BDCs are not synchronized with the PDC for a long period of time, a full synchronization occurs.
PulseMaximum	How often the PDC sends a pulse message to each BDC even if its user accounts database is up-to-date. The default is every two hours; the maximum is 48 hours. Increasing it reduces the number of pulse messages.
ChangeLogSize	How many changes are made to the user accounts database. The default value is 64 KB (about 2,000 32-byte changes). When this limit is hit (for example, if lots of users change passwords), log entries are overwritten, forcing a full synchronization. The result is that more traffic is sent to the BDC than is really necessary.
PulseConcurrency	How many announcements the PDC sends to BDCs during synchronization. The default is 10 for Windows NT Server 4.0. Increasing this uses more network bandwidth for synchronization; decreasing it uses more time.

Trust Relationships

A master accounts domain with multiple resource domains is a good solution for environments that have centralized administration and individual control of distributed resources. Trust relationships allow user accounts from the accounts domain to access resources in the resource domains.

Relative Network Impact

Three areas generate network traffic:

• Establishing a trust relationship takes approximately 110 frames (16,000 bytes).

• Using trusted accounts when permissions are granted to trusted domain users so they can access a local resource, and when a trusted account is added to a local group.

• Pass-through authentication (the most frequent generator of trust traffic) is of two types: when a user in a trusted domain requests access to a resource in a trusting domain, and when a user at a Windows NT Workstation computer attempts to log on using a trusted account and the computer it is attempting to log on is a member of a trusting domain.

Types of trust relationship traffic.

Trust relationship traffic	Frames	Bytes	Frequency
Establish trusts	110	16,000	One time
Import accounts	110	16,000	Every import attempt
Pass-through authentication	20	3,200	Every access of new server in trusting domain

Optimizing

Trust relationships do not produce much network traffic, but you can reduce it by:

• Reducing the number of trusts. Review existing or planned resource domains to ensure that each one is appropriate and necessary. Break non-essential trusts.

• Reducing verifications. Reduce traffic associated with the verification of trusted accounts by adding the appropriate users to a global group or adding the trusted global group to a local group or local resource.

  Example: In a simple test, looking up a single security ID (SID) for a global group took 552 bytes, but the same lookup for SIDs for two trusted user accounts took 636 bytes. That is not much difference, but this tested only two users. When many users are allowed access to a resource in a trusting domain, you can reduce traffic substantially by using a global group.

Server Browser Traffic

Servers generate several types of browsing traffic. All computers with server components (that is, the ability to share network resources) announce themselves to the master browser in their local domain. Servers that operate as a potential browser, backup browser, or master browser are involved in several other communications:

• Browser elections occur whenever the master browser cannot be located on the local subnet and whenever a DC initializes.

• Master browsers in different domains communicate with each other so that servers and resources can be accessed throughout the network.

• Backup browsers receive updated browse lists from the local master browser.

Relative Network Impact

Server browsing produces a large share of network traffic.

Types of server browser traffic.

Server browser traffic	Frames	Bytes	Frequency
Host Announcement	1	243	Once per server every announcement period (12 minutes at a steady state)
Local Master Announcement	1	250	After each announcement request or election and every 12 minutes
Workgroup Announcement	1	250	Once per master browser every announcement period (15 minutes at a steady state)
Elections	20	5,300	Every restart of a DC
Browse List Exchange	36	3,900	Every browse attempt by client, and every 12 minutes for each backup browser

The basics of the server browsing process are:

• At startup, the domain's PDC assumes the role of domain master browser and the BDCs become backup browsers; if there is no master browser, BDCs become local masters.

• Every 15 minutes, each master browser (on each subnet) announces itself to the master browsers of other domains on the local subnet.

• Every 12 minutes, each domain master browser contacts WINS for a listing of all domains.

• Every 12 minutes, each master browser contacts the domain master browser to update the browse lists.

• Every 12 minutes, each backup browser contacts its local master browser to retrieve an updated browse list.

Optimizing

You can reduce browsing traffic by:

• Reducing network protocols. The browsing process runs separately on each installed and bound protocol. If TCP/IP, NWLink IPX/SPX, and NetBEUI are all active on the network, each set of browser traffic, elections, host announcements, workgroup announcements, and so on, occur on each protocol independently. This can triple network traffic. Eliminate unneeded protocols.

• Reducing browser entries. If computers do not require resource sharing, disable their server components to reduce browse lists and, therefore, the traffic passing between browser servers. Each client type (Windows for Workgroups, Windows 95, or Windows NT) has a different method for disabling the server service. Besides the basic 27 bytes, each browse list entry can include server comments. Reduce server comments to save space.

• Tuning optimization parameters. Browsing registry parameters are under

  HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Browser \Parameters.

  Configure these parameters to control the amount of network traffic generated by the browser:

  • MasterPeriodicity

    Specifies how frequently a master browser contacts the domain master browser. The default is 720 seconds; the minimum is 300 seconds; the maximum is 4,294,967 seconds. This parameter is added as a registry entry (REG_DWORD) and can be changed dynamically without restarting the computer. It affects WAN traffic because subnet master browsers must communicate with the domain master browser.

  • BackupPeriodicity

    Specifies how frequently a backup browser contacts the master browser. The default is 720 seconds. Setting it to 1800 (30 minutes) reduces the frequency of browse list updates. Adding it as a REG_DWORD requires restarting the computer. This parameter does not effect the WAN because backup browsers always communicate with a local master browser, never with a remote one.

WINS Replication Traffic

A single WINS server can support 10,000 WINS clients, but if it does not provide the required level of fault tolerance and performance a backup server may be advisable. If multiple WINS servers are configured, clients can register and query while servers replicate or share databases and they get faster name resolution because each WINS server can identify clients registered with its WINS partners.

WINS Record Sizes

WINS database entries vary in size, depending on type:

• If the client has a single network adapter card, the amount of data stored depends on whether a scope ID is configured (40 bytes without, 280 bytes with).

• If the client has multiple network adapters configured for TCP/IP (is multi-homed), the amount of data stored depends on the number of configured IP addresses (40 to 280 bytes per host).

• If the registered name is an Internet group name, such as Domainname <1C>, the amount of data stored depends of the number of registered hosts (maximum is 25 hosts, 480 bytes).

Relative Network Impact

The amount of traffic generated by WINS replication depends on the size of records in the WINS database, the number of updated records, and the frequency of replication.

Types of WINS traffic.

WINS traffic	Frames	Bytes	Frequency
Establishing Relationship	20	2,300	Once per replication relationship
Verifying Databases	12	900	Once per update request to each replication partner
Updating Databases	14	1,200	Once per update request to each replication partner

Three distinct steps are involved in the WINS replication process: establishing the replication relationship, verifying the database version numbers, and replicating records.

Establish Relationship

The first step in the replication process, adding a WINS server as a replication partner, is done by using WINS Manager. This process uses approximately 20 frames (about 2,000 bytes). The first 54 bytes in each frame are normal Ethernet, IP, and TCP packet headers; the remainder contain the appropriate WINS RPC call.

Verify Database

Once the relationship is established replication can occur at predefined intervals or after some number of records are updated. Once the relationship is triggered, it and the databases must be verified. This is a simple process that generates about 12 frames (900 bytes of traffic) using a standard TCP session, two requests and responses, and TCP session termination frames.

Update Database

Once the replication partner relationship is configured and verified, databases are updated by transferring records between the WINS servers. This transfer uses TCP Port 42.

Optimizing

WINS database replication can significantly affect WANs with slow link speeds, but you can optimize WINS traffic by changing the configuration of WINS replication partners. WINS replication partners are configured as push, pull, or both. Push partners send announcements to their configured partners when a specific number of database entries have changed. Pull partners request updates at configured intervals or when their push partner notifies them of updates.

• Push Partners

  Change the configuration of push notification to occur after a specific number of records are updated: the default is 20. Database changes, not time intervals, are used to initiate push notifications and replications. Increasing this number reduces the frequency of WINS replication, and increases the number of updated records in a batch. It also increases latency, so you must tune this carefully.

  For instance, a value can be configured as a percentage of the total names in the database, such as 25 percent. This allows more control over the replication.

• Pull Partners

  Change the configuration of pull requests to occur at a specific time interval. For example, you might configure WINS to send pull requests every 30 minutes for local WINS servers, every hour for remote WINS servers connected by high-speed links (T1 or higher), and every six hours for remote WINS server connected by means of slow-links (56 Kbps). This allows you to control data transfer frequency.

Directory Replication Traffic

The Directory Replicator service allows automatic replication of a directory tree between computers. Most commonly, it replicates user logon scripts between PDC and BDCs, ensuring that a client can run its logon script no matter which DC validates it.

Relative Network Impact

Logon scripts are not extremely large and do not change often enough to generate much replication traffic. However, if the Directory Replication service needs to replicate other files it can create significant network traffic.

Types of directory replication traffic.

Directory replication traffic	Frames	Bytes	Frequency
Announcement	1	340	Once per importing domain or server for every update of the export tree
Establish Session	11	1,1280	Once from each import computer every update event
Verify Directory	30	~5,100	Once from each import computer every update event
Update Directory	Various		Once from each import computer every update event

Optimizing

You can optimize directory replication traffic by:

• Creating a flat, shallow directory structure. With large, deep, top-level replicated directories, the Directory Replicator service checks and then copies an entire top-level directory if any file in that directory has changed. Because files are always likely to change, the service is constantly rechecking and recopying entire directories. You can decrease network replication traffic by creating multiple, shallower, top-level directories.

• Using Server Manager to control replication. Server Manager prevents the Directory Replicator service from exporting specific directories during certain periods of the day. You can add a lock to the export server, for instance, to prevent it from replicating directories during heavy network usage times.

• Updating registry parameters. Directory replication entries are found in the Registry under:

  HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Replicator \Parameters.

  To control the Directory Replicator service modify:

  • Interval. Determines how often the originating (export) server checks for updates to its specified directory structure. It also sends notifications to its target (import) computers to retrieve the new data. Default is five minutes. You can increase it to 60 minutes or more (on the export server) to reduce replication frequency, although this leaves changes unreplicated for longer intervals.

  • Pulse. Acts as a counter to control how often an import computer contacts an export server. If an import computer fails to hear from the export server after Pulse X Interval minutes, it contacts the export server for an update. Default is two minutes. Increasing the Pulse parameter can reduce traffic by giving the export server more time to contact the import computer.

Domain Name System Server Traffic

Larger organizations can implement primary and secondary Domain Name System (DNS) name servers for a zone (a database file that contains records for a particular domain) to provide sufficient name resolution services for clients.

Relative Network Impact

The transfer of database files from the primary name server to the secondary name servers (zone transfer) generates network traffic. (See "Client-to-Server Traffic" section above for more information on client-based DNS traffic.) A DNS record averages 26 bytes (compressed). Multiply the number of records in the zone file by 26 to estimate the traffic generated in a zone transfer.

Types of DNS traffic.

DNS traffic	Frames	Bytes	Frequency
Name Lookups	2	~180	Each DNS name lookup request by client.
Zone Replication	3	180	At addition of secondary server to the zone, and periodically (every 60 minutes by default).
Replication Request	2	403	Each DNS name lookup request by client.
Session Termination	2	240	Each DNS name lookup request by client.

Optimizing

You can use DNS Manager to control zone transfers. In the Zone Properties dialog select the SOA Record tab. You can configure these values:

Zone transfer parameters.

Parameter	Description
Refresh Interval	How long the secondary name server waits before it queries the primary to initiate a zone transfer. Default is 60 minutes.
Retry Interval	How long the secondary name server waits before attempting to initiate a zone transfer upon failure. Default is 10 minutes.
Expire Time	How long the secondary name server continues to respond to name queries even though it cannot connect to the primary name server for an update.

For tuning, Refresh Interval is the most useful parameter: decreasing its frequency increases zone transfers. This means more frequent updating, but more network traffic.

Network Monitor

To analyze the traffic generated by the networking services on your system, you can use the Network Monitor analysis tool. A simple version is included in Windows NT Server 4.0; the full version is included with Microsoft Systems Management Server. Refer to the Windows NT Server Concepts and Planning Manual, "Chapter 10: Monitoring Your Network," and the Microsoft Windows NT Server 4.0 Resource Kit Supplement 1, "Chapter 7: Monitoring Bandwidth and Network Capacity" for complete information.

The simple version of Network Monitor captures frames only on a local network, whereas the full version captures traffic on both local and remote networks and can automatically filter and edit the traffic.

Versions of Network Monitor.

Function	Network Monitor (simple)	Network Monitor (full)
Local capturing	To and from the computer running Network Monitor only	All devices on the entire subnet
Remote capturing	Not available	Yes
Determining top user of network bandwidth	Not available	Yes
Determining which protocol consumed the most bandwidth	Not available	Yes
Determining which devices are routers	Not available	Yes
Resolving a device name into a media access control address	Not available	Yes
Editing and retransmitting network traffic	Not available	Yes

Network Monitor provides a Capture window that displays four areas of information you can use to analyze network performance:

Network Monitor Capture Window.

Pane	Description
Graph	Bar charts of current activity: Percentage of network utilization, frames per second, bytes per second, broadcasts per second, and multicasts per second.
Session Statistics	Summarizes host communication including the initiated frame type.
Total Statistics	Statistics for traffic on the entire network, captured frames, per second utilization, and network adapter card.
Station Statistics	Summarizes frames by host, type, and the total number sent and received.

Network Monitor requires a supported network adapter card. Windows NT 4.0 supports a newer version of the network device interface specification (NDIS) that has a capturing mode called "local only." You install the Network Monitor Agent driver onto a network card in a Windows NT system. This sets the card in promiscuous mode, which allows the monitor to watch all network packets that go through the system—even packets for other destination systems are copied and passed up to the Network Monitor Application.

See the Windows NT 4.0 Hardware Compatibility List (HCL) for a list of Network Monitor tested and supported network adapters.

Predicting Network Traffic

Most networks are in a constant state of flux, growing and changing according to the needs of their users. The better you understand how your network operates, the more effectively you can optimize communication and predict the effect of adding servers, services, or additional clients. Use these guidelines to project the amount of generated traffic:

• Identify the service that will be added to the network.

• Determine variables associated with implementing the added service. For instance, for DHCP, determine how many DHCP servers will be installed, how many DHCP clients will be used, and how long the lease duration is.

  Estimate:

  • Traffic that one client or server would generate.

  • Impact of implementing the service using a given number of clients or servers.

  • Frequency of that traffic.

• Recognize that predicting network traffic is not an exact science, but a process to help understand and plan for network traffic. In most cases, adding a service increases network traffic, but you have to balance the benefit against the cost.

The numbers in the table below are based on a sample test LAN. They do not precisely indicate numbers you can expect on your organization's network (see Chapter 2 for a case study), but they can provide a relative baseline that helps you predict the impact of network services.

Network service traffic for prediction purposes.

Service	Traffic	Frequency
DHCP	Acquire IP address—4 frames (1,368 bytes)	Once per client.
	Renew IP address lease— 2 frames (684 bytes)	Every startup and at one-half lease life.
WINS client-to-server	Registration—2 frames (214 bytes)	Once per service or application at startup.
	Renewal—2 frames (214 bytes)	Once per service or application every one-half time to live (TTL).
	Resolution—2 frames (196 bytes)	Varying frequencies.
File sessions	Address resolution—2 frames (120 bytes)	At each attempt to communicate with another TCP/IP host (when aged from ARP cache).
	TCP session— 3 frames (180 bytes)	Once per first connection to each target TCP host.
	NetBIOS session— 2 frames (186 bytes)	Once per first NetBIOS connection to a target computer.
	SMB protocol negotiation—2 frames (~350 bytes)	Once per first Server Message Block (SMB) connection to a target computer.
	Connection sequence—2 frames (~350 bytes)	Once per network resource access.
	Session disconnection—5 frames (360 bytes)	Once per final connection to TCP host disconnection.

Network service traffic for prediction purposes. (continued)

Service	Traffic	Frequency
Logon validation	Session establishment— 15 frames (2,000 bytes)	Once per user logon.
	Validation sequence—4 frames (760 bytes) Windows 95	Once per user logon.
	Validation—20 frames (3,700 bytes) Windows NT	Once per user logon.
	Session breakdown—5 frames (360 bytes)	Once per user logon.
	Scripts, policies, profiles—traffic varies	Optional—once per user logon.
Browser	Host Announcement—1 frame (243 bytes)	Once per "server" computer every announcement period (12 minutes at steady state).
	Local Master Announcement— 1 frame (250 bytes)	After each announcement request or election, and every 12 minutes.
	Workgroup Announcement— 1 frame (250 bytes)	Once per each master browser every announcement period (15 minutes at steady state).
	Elections—many frames (225 bytes each)	After each computer capable of becoming the master browser initializes.
	Finding a backup browser—2 frames (~450 bytes)	Once per browsing computer at initial browse attempt.
	Retrieving a browse list—20 frames (2,150 bytes)	Every browse attempt by client, and every 12 minutes for each backup browser.
	Retrieving a list of shared resources—16 frames (1,900 bytes for Windows 95) 19 frames (3,300 bytes for Windows NT)	Every browse list by client.

Retrieve list of domains.

Every 12 minutes by each domain master browser.

Network service traffic for prediction purposes. (continued)

Service	Traffic	Frequency
DNS	Name lookups—2 frames ( ~180 bytes depending upon name length). Traffic is multiplied if recursion is required.	Each DNS name lookup request by client. Recursion traffic may not be required if name is still cached at queried DNS server.
	TCP session—3 frames (180 bytes)	At addition of secondary server to the zone, and periodically (every 60 minutes by default).
	Request transfer (~85 bytes).
	Transfer zone records—1 frame, depending upon size and number of records.
	TCP session termination—4 frames (240 bytes)
Intranet browsing	Downloading a page—3 frames (180 bytes)	Once per file requested (page, graphic, AVI, and so on).
	GET command—1 frame (~350 bytes depending upon host name and file structure)	Required at each load attempt.
	Download file—multiple frames (up to 1514 bytes)	Required if new or updated file.
User accounts database synchronization	Finding the PDC—4 frames (~745 bytes)	Once per BDC startup.
	Establish session—11 frames 1,280 bytes	Every synchronization event.
	Establish secure channel—8 frames (1,550 bytes)	Once per BDC startup.
	Verify the databases—6 frames (1,350 bytes)	Once per BDC startup.
	PDC Update notice—1 frame (~400 bytes)	Every synchronization event.
	Synchronization of the database— 2 frames (~1,400 bytes for one user modification)	Every synchronization event.

Network service traffic for prediction purposes. (continued)

Service	Traffic	Frequency
Establishing a trust relationship	~110 frames (16,000 bytes)	Once per each trust relationship created.
Importing trusted accounts	~115 frames (18,600 bytes) for 12 trusted accounts.	Each attempt to import a trusted account into a trusting domain.
Verification of trusted account	~45 frames (7,000 bytes) for a single account (Global Group).	Every attempt to view a resource (or group) that contains a trusted account.
Pass-through authentication	20 frames (~3,700 bytes)	Once for the first attempt to access a resource on a trusting computer, or logon to a trusted domain from a trusting computer.
Directory replication	Announcement—1 frame (~340 bytes)	Once per importing domain or server for every update of the export tree.
	Establish session—9 frames (~1,300 bytes)	Once from each import computer every update event.
	Verify directory—30 frames (~5,100 bytes)	Once from each import computer every update event.
	Update directory—various amounts of network traffic.	Once from each import computer every update event.
WINS replication	Establish relationship—20 frames (2,300 bytes)	Once per replication relationship.
	Database verification—12 frames ~ (900 bytes)	Once per update request to each replication partner.
	Database update—approximately 14 frames (~2,100 bytes varies with number of updates)	Once per update request to each replication partner.