Network Communications 29th Edition (Spring 2011)

Spring 2011 Network Communications 29th Edition

Network communications provide the required connectivity to support distributed computer processing. Network products support a stable and dependable communication protocol for distributed data transport. A variety of communication protocols supports distributed applications and data resources located at sites throughout an organization.

For several years, network technology was a relatively static environment while computer performance was increasing at an accelerating rate. Today communication technology supports a dramatic shift in network solutions, providing worldwide communications over the Internet and bringing information from millions of sources directly to the desktop in real time. Cell phone technology provides real time public access to wireless communications connecting us to global Internet information resources no matter where we might be.

GIS Communications
GIS applications rate among the heavy users of network traffic along with document management and video conferencing as portrayed in figure 5-1. GIS technology provides a visual display environment to the user supporting very quick analysis of large amounts of graphic data. Access to distributed data sources for real-time display and analysis puts large demands on network communications. Data must be transported across the network to where the program is executed to display the information.



Data is a collection of digital computer information stored in media that have the capability to record and retain the data structure. This data is represented by little pieces of information called bits. Each bit takes up the same space on storage or transmission media. For convenience, these little bits can be grouped into bytes of information with each byte containing eight bits. Data can be transported from one location to another within packets that protect the integrity of this data.

Data is typically transported from one storage location to another over copper wire or glass fiber physical networks. Other types of transport media include microwave, radio wave, and satellite digital transmissions. Each network protocol has limits to its supported rate of data transport based on the technology used to support the transmission.

Communication Network Technology
Network transport solutions can be grouped into two general technology classes. These classes include LANs and WANs. The volume of data (measured in bits) that can be transported per second represents the transport rate (capacity) of a specific network segment. This capacity is called network bandwidth and is typically measured in millions of bits (megabits [Mb]) or billions of bits (gigabits [Gb]) per second.

Figure 5-2 illustrates the different types of networks and following are their descriptions.



Local Area Networks
Local area networks support high-bandwidth communication for short distances. These networks support local operating environments (usually within a building or local campus environment). Data transport over a single technology is single threaded, which means only one data transmission can be supported on a single LAN segment at any time. The cost for LAN environments is inexpensive relative to other hardware costs supporting the system environment.

Wide Area Networks
Wide area networks support communication between remote locations. Technology provides much lower bandwidth than LAN environments, but transmission is possible over long distances. This is a data transport environment, which means data is packaged in a series of additional packets and transported as a stream of data along the transmission medium. The cost for WAN connections is relatively high compared to LAN environments. The Internet is a global WAN environment.

Wireless Communications
Wireless communications use radio frequency bands as a data transport media. Radio frequencies used for wireless transmissions connect user devices to area communication transceivers, and the transceivers connect the communications to the local or wide area communication networks. Wireless communications broadcast over shared public frequencies and tend to experience higher latency than hard wire connections.

Data Units
Data capacity is measured in terms of megabytes or gigabytes when stored on computer disk. Megabyte is abbreviated using a large "B," while megabit is abbreviated using a small "b." One must remember 1 MB = 8 Mb when converting data volume from disk storage to network traffic. Network traffic also includes some protocol overhead, so a simple rule-of-thumb is to translate 1MB of data to about 10 Mb of traffic.

Network Bandwidth
Network traffic capacity is measured in terms of connection bandwidth. Figure 5-2 shows the currently popular network protocols and available traffic capacity for the various communication environments.

The capacity of a network segment is established by the connection (communication port) bandwidth specifications. Computers are connected to the network through a network interface card (NIC) or a wireless transmitter. Network segments are connected by routers and switches, boxes that provide communication ports for connecting network segments. Wireless communications transmit over radio frequencies to antennas that are connected to the communication network infrastructure (routers and switches). All of these routers, switches, and transmitters are connected by wires that represent the network communication infrastructure.

Local area (LAN) wired network providers have standardized on Ethernet protocols - they are simple to manage and provide the capacity we need for local network communications. Wide area networks still use a variety of protocols, including a collection of telephone wire and fiber transmissions (modem, T-carrier and E-carrier fiber communications, Cable TV lines, digital subscriber lines-DSL, etc) as well as wireless communications (radio frequencies, infrared transmitters, satellite communications, etc).

What is Data (i.e. Why so many Protocols?)
I remember a trip I made to the Chicago Science and Industry Museum when I was a young boy. They had a simple light bulb display that demonstrated how computers think. This was in the early 1960's back when computers were not common household appliances. The display showed how a series of on and off light bulbs could be used to add and subtract numbers - the scientific breakthrough that gave us computers. Who ever thought we could share our thoughts and ideas with a mechanical device that could be trained to do our brain work? Figure 5-3 answers a fundamental question that changed our world.



We call these patterns of 1's and 0's data. Patterns that represent our thoughts and ideas, and can be manipulated to produce information products we can use in our work. Data is not a physical thing that has mass and takes up space - the content is a pattern representing our ideas. Understanding this concept is important, since it explains why we have so many different ways to store and move data. It is also important since it suggests the physical laws of space and travel do not apply directly to data itself, only to the medium we use to store and move data. This opens a world of possibilities to communicate and store data in ways we may not even imagine today - we are limited only by our imagination. Satellites collecting high resolution images of our world that we can display on our cell phones - changes beyond our imagination less than 10 years ago. Will science soon overcome the communication infrastructure limitations we experience today? I expect so.



Client/Server Communications
Data is passed over the network using a variety of client/server communication protocols. Communication processes located on client and server platforms define the communication format and address information. Data is packaged in communication packets as shown in Figure 5-4; packets which contain communication control information required to transport the data from its source client process to the destination server process.



Network Transport Protocol
The communication packet is constructed at different layers during the transmission process. In figure 5-5, a data stream from the host A application is sent through the protocol layers to establish a data frame for network transmission. The Transmission Control Protocol (TCP) header packages the data at the transport layer, the Internet Protocol (IP) header is added at the Internet layer, and the Media Access Control (MAC) address information is included at the physical network layer. The data frame is then transmitted across the network to host B where the reverse process moves the data to the host application. A single data transfer can include several communications back and forth between the host applications.





GIS Client/Server Communication Protocols
Figure 5-6 provides an overview of the primary communication protocols used for GIS operations. Each protocol implementation includes client and server components to support data delivery. The client process prepares the data for transmission, and the server process delivers the data to the application environment.



Network file services (NFS) (UNIX) and Common Internet File System (CIFS) (Windows) Protocols
Support remote disk mounting enabling a client application to access data from a distributed server platform (network file share). All query intelligence resides in the client application, providing query instructions to access data located on the server platform. Data must be transferred to the client application to support query execution.

Database Access Protocols
ArcSDE includes client and server communication components. The database management system (DBMS) includes intelligence to support query processing. Compressed data is provided for network transfer and database storage. Data is uncompressed by the client application (ArcObjects). Data must be transferred to the client application to support analysis and display.

An alternative ArcSDE client direct connect option is available that connects with a DBMS client application program interface (API) executed on the client desktop. The ArcSDE middleware functions are supported on the client platform, and the DBMS network client supports data transmission to the server. Query processing remains on the DBMS server.

ICA and RDP Protocols
The protocols support remote terminal display and control of applications hosted on a shared Windows Terminal Server. Both protocols transmit display and control information to the terminal client. Both the Independent Computing Architecture (ICA) protocol and Remote Desktop Protocol (RDP) compress data for transmission.

HTTP Protocols
The Hypertext Transfer Protocol (HTTP) is a standard Web transmission protocol. In this transaction-based environment, service selection and display are controlled by the browser client. Data is compressed for transmission. There are a variety of Internet Protocols that can be implemented within the HTTP framework.

HTTP display traffic resolution is established by the published map service for Web browser clients, and by the desktop resolution for ArcGIS Desktop clients. Traffic for the ArcGIS Desktop is normally higher because of the larger image transfers. Image size is directly proportional to the physical screen display resolution; thus, larger image displays result in higher traffic.



Client/Server Network Performance
The data transfer traffic and the network bandwidth can be used to estimate minimum network transport times for a single map display transaction. A typical light GIS application requires up to 1 MB of data to generate a new map display (2 MB for a medium display). Typical terminal/browser display traffic is about 200 KB of data for the same map display.

Figure 5-7 shares typical data transfer requirements in megabytes, shows the conversion to megabits of traffic for transmission, includes any adjustments of this data performed by the communication protocol, and identifies the total volume of traffic in megabits that must be transmitted (protocol overhead may be greater than what was used in this sample conversion).



The minimum data transport times are calculated for five standard bandwidth solutions (56 kilobits per second [Kbps] for standard dial-up communications; 1.54 megabits per second [Mbps] for typical WAN communications; and 10 Mbps, 100 Mbps, and 1 gigabit per second [Gbps]) for LAN communications. Any existing data traffic on shared network segments would increase these network transfer times.

During peak work periods, operational workflow performance can slow to a crawl similar to what is experienced in larger cities when driving on major highway arteries during rush hour. This simple illustration identifies the primary cause for many remote client performance problems. Sufficient bandwidth is critical to support productive user workflow performance requirements.

File server configurations support query from the client applications. When selecting data from a file (coverage or shape file), the total file (file index for large spatial data file formats) must be delivered to the client for query processing. Data not required by the application is rejected at the client location. This accounts for the considerable amount of traffic overhead experienced by these communications.

ArcSDE client/server configurations support DBMS query processing on the server platform. The query processing includes locating the requested data and filtering that data so only the specific data extent requested by the client is returned over the network. If the client application requests a small volume of data (e.g., point data or a single parcel in a parcel layer), the resulting data transfer can be small and network transport time would improve accordingly.

Best practices are established for network configuration alternatives. Desktop applications accessing file or DBMS data sources perform best in a local area network environment. Transaction-based services, or persistent Windows Terminal Server connections, provide reliable environments for processing over less stable wide area network connections.

Several problems can occur when connecting a client application to a DBMS across a WAN connection. Increased traffic between the client application and the DBMS is only one consideration. Network latency is another performance consideration and is addressed in the following section. A third issue is the need for a persistent connection between the client application and the DBMS; if the client network connection is lost during a DBMS transaction the data may not be received by the DBMS. When the network connection is restored, the DBMS and client application session may not be in sync. Once the application session is out of sync, the DBMS will protect data integrity and roll back to the last time the session was saved. This can result in lost work when accessing a DBMS over an unstable network connection – an event that can contribute to user frustration and reduced productivity.



Network Latency Considerations
The maximum bandwidth capacity used by a single user is limited by the total system transaction time.With standard client/server database display transactions, hundreds of data requests are sent to the server spread throughout the display transaction time (ArcGIS Desktop provides sequential requests for each layer in the display, completing each layer transaction before sending requests for the next display layer). A typical map display may have 10–20 data layers supporting the display analysis, which can translate to hundreds of sequential database transactions. Figure 5-8 shows a typical map display profile, showing the client desktop processing time, network transport time, and database processing time required to support a typical map display.

Bandwidth capacity is typically measured in megabits per second. During a typical local map display transaction, the total display response time with 1 millisecond latency can be less than 1.9 seconds. A total of 10 Mb of data must be transferred from the server to the client application to support a medium map display (figure 5-7 shows 5 Mbps for a light display). The same display with 30 millisecond latency will take over 7.6 seconds. 

Normal database access protocols are "chatty," which means a typical database query requires a large number of trips to and from the server to complete the client display transaction. There are many trips to and from the server (query transactions) for each layer in the map display. Figure 5-9 shows 200 query transactions are required to support a single map display.



Network latency can impact bandwidth utilization over long WAN distances. Latency is easy to measure, using a simple Windows command prompt (tracert "server host name"). Results provide the number of network hops and the associated network latency time for a single trip.

For LAN environments, network latency is very low (typically < 1 millisecond per trip to the server). Many trips between the server and client have limited performance impact. The primary system latency contribution is client and server processing service times.

For longer WAN distances that involve several router hops, there can be a measurable network latency delay, and for chatty database protocols, network latency can have a measurable performance impact. In the example above, total transaction time over the WAN (including cumulative network latency) is 7.65 seconds. The maximum bandwidth utilized by a single user on this WAN connection is 1.31 Mbps. These days, many global WAN connections include satellite communication links. The fastest communication transfer is limited by the speed of light, which for very long distances will introduce a minimum bandwidth latency that technology will not overcome. Good performance over WAN environments results from protocols that minimize trips (communication chatter) between the client and server platforms.

Figure 5-10 shows how network latency is addressed in the CPT Calculator tool. Rows 12, 13, and 14 address network communication traffic. Row 12 is the LAN traffic, while rows 13 and 14 represent remote site communications. Network bandwidth connections are identified in column G. Total number of remote users sharing the remote site connections is identified in column D. Latency is identified for remote connections in column E. Communication chatter is identified in column I (default of 10 for Web and WTS workflows; 200 for medium workstation workflows adjusted by display complexity). Latency delay is shown as pink in the Workflow Performance Summary.

 Figure 5-11 shows how network latency is addressed in the CPT Design tool. The GREY rows represent the data center LAN, WAN, and Internet connections. Network bandwidth for each network row is set in column H. The Network latency setting (milliseconds) is set in column AE (network chatter for each workflow is also identified in column AE). Latency delay is shown as pink in the Workflow Performance Summary. 

Shared Network Capacity
The total number of clients on a single network segment is a function of network traffic transport time (size of data transfer and network bandwidth) and the total number of concurrent clients. Only one client data frame can be transmitted over a shared network segment at any time.



With older switch technology, multiple transmissions on the same Ethernet network segment would result in collisions, which can require additional transmissions to complete data frame delivery. Ethernet segments would fail rapidly during saturation because of the high number of transmissions. Ethernet switches today include options for configuring shared segments in a full duplex mode, which when configured properly take advantage of switch buffer cache and improve transmission efficiency.

Figure 5-12 shows multiple client sessions sharing the same network segment where each data exchange is represented by the small boxes. Only one data exchange can be supported at one time on the same network segment. Shared networks must adjust traffic flow to accommodate random transmission arrival times. When peak traffic loads (concurrent transaction arrival times) remain within the available bandwidth, users will not experience network delays. On the other hand, when concurrent transaction arrival times exceed available network capacity, users will experience delays. Concurrent transactions must wait for network connection, resulting in transmission delays. Delays will increase during heavy traffic loads as the network reaches saturation. Wait time (transmission delay) is a function of network transport time (figure 5-7) and bandwidth utilization. Higher traffic per display and busier shared network segments contribute to longer transmission delays. 

A GIS application may require 1 MB of spatial data, or up to 10 Mb of network traffic, to support a single map display as illustrated in figure 5-13. Applications can be tuned to prevent display of specific layers when the map extent exceeds defined thresholds. Only the appropriate data should be displayed for each map extent (e.g., it may not be appropriate to display individual parcel layers in a map showing the full extent of San Diego, California). Proper tuning of the application can reduce network traffic and improve display performance. 

Network Design Guidelines
For many years, standard published guidelines were used for configuring network communication environments. Figure 5-14 identifies the importance of designing to network communication standards and also monitoring network utilization.



These standards were application specific and based on typical user environment needs. Communication environments are statistical in nature, since only a percentage of user processing time requires transmission over the network. Network data transfer time is a small fraction of the GIS users' total response time (on properly configured high capacity networks). Network data transfer time can dominate response time when bandwidth is too small or when too many clients are on the same shared network segment.

The network must be designed to support peak traffic demands. The amount of traffic varies based on the different types of applications and user work patterns. Standard guidelines used during system design provide a place to start configuring a network environment. Once the network is operational, network traffic demands should be monitored and necessary adjustments made to support peak user requirements.



Standard Workflow Network Traffic Guidelines
Figure 5-15 provides an overview of the standard network design performance factors. Baseline display traffic design factors are validated during Esri performance benchmark testing. Capacity Planning Calculator workflow traffic estimates are further modified base on performance adjustment parameters gathered from Esri performance sensitivity benchmarks. Performance adjustments were discussed in the System Design Strategies chapter on Software Performance.



Capacity Planning Network Traffic Adjustments
Figure 5-16 provides an overview of the CPT Lookup table used for traffic adjustments based on data source selection. Traffic adjustment factors are applied to all traffic accessing the data selected source. 

CPT Calculator Network Analysis
Figure 5-17 provides an overview of the CPT Calculator highlighting the network performance analysis components. Data Center and Remote site service connections identify bandwidth constraints that must be evaluated during the system design. Standard Esri workflow display traffic loads are used to evaluate network suitability across all WAN and Internet site connections. The Capacity Planning Calculator can be used to estimate workflow client display traffic (megabits per display). Client traffic (Mbpd) is included with the workflow service times on the CPT Workflow tab and used by the Design tab to complete the network suitability analysis. 

Enterprise System Architecture
GIS user workflows access applications, services, and/or data sources maintained within the enterprise data center. Users may be located on the LAN, at remote locations over the WAN, or operate from mobile clients over wireless WAN or Internet connections. Remote and local users may also access a variety of Web services over the public Internet. Figure 5-18 provides a sample Enterprise GIS network communication diagrams showing GIS users located at three remote sites, one connected over an Internet connection and the other two connected over a WAN connection. Additional GIS users are located within the central LAN environment.

Network connections within the local LAN infrastructure can normally be adjusted to accommodate peak traffic loads. Remote WAN and Internet connections often present constraints that must be addressed in the system design, and may limit software technology deployment options.



Figure 5-19 shows how the same distributed network connections are represented in the CPT Design. Data center networks are represented by GREY rows and remote sites by GREEN rows. Client workflows are located within the network segments where they work. Available bandwidth for each network segment is identified in column H. Network traffic must flow through both the remote site and Data Center connections to reach the server environment. The CPT Design requirements analysis module layout (configuration of the Data Center and remote site network segments, and the user workflows) makes it possible to represent workflow display traffic flow across the appropriate service provider network connections. This configuration establishes a foundation for completing the CPT Design network suitability analysis.



Network Suitability Analysis
Many network administrators establish and maintain metrics on network utilization, which help them estimate increased network demands when planning for future user deployments. The CPT Design tab includes a network suitability analysis which uses display traffic from the Workflow tab to compute peak site traffic workflow loads. Sum of all site traffic workflows is compared with the site bandwidth to identify peak network utilization. Figure 5-20 identifies network suitability analysis performance by the CPT Design tab.



The CPT Design tab computes display response times for each workflow, based on total of all system component service times and queue times during peak system loads. User productivity must be adjusted if workflow response time does not support minimum think time. Figure 5-21 provides an overview of the workflow performance validation process and shows the final workflow performance summary (available once system level performance validation and any required workflow productivity adjustments are complete). <br style="clear: both" />

User Productivity Adjustment
Figure 5-22 shows what happens during heavy traffic conditions when network bandwidth is saturated beyond capacity limits. User productivity determines the average server transaction request rate (i.e. 10 displays per minute or 1 display every 6 seconds); users will start to slow down when they are not able to maintain their productivity rate. To maintain productivity, the user must receive the requested map display from the server (response time) and have sufficient time (minimum think time) to review the display information and submit the next transaction request.

If the display response time plus the minimum think time exceeds 6 seconds, the user will not be able to maintain a productivity of 10 displays a minute and will have to slow down. The CPT Design tab calculates display response time and available user think time for each user workflow. If the computed think time is less than the workflow minimum think time, the workflow productivity must be reduced to show a valid workflow load. The CPT Design tab has an ADJUST function that automatically adjusts user productivity to honor identified minimum think time requirements. Once minimum think time equals computed think time, the CPT identifies resolution is complete. You can learn more about system performance factors and relationships that impact system capacity and user productivity in chapter 9. Network suitability analysis is an important part of system architecture design; making sure you have sufficient network infrastructure to ensure remote user productivity is critical for implementation success.

In a real environment, when the network traffic approaches available bandwidth the user productivity will slow down. You can experience this when traveling during rush hour traffic; as the amount of traffic increases you must slow down – it is not possible to put more traffic through the available network than what fits within the available bandwidth capacity. This condition is represented in the CPT Design tab in Figure 5-23.

The default user productivity in column E generates an unacceptable peak throughput of 25 Mbps traffic (available bandwidth is 24 Mbps). The CPT computes a negative think time shown in column AG and turns the workflow productivity cell (column E) to RED. This is not a valid workflow and user productivity must be reduced to identify the real system performance impacts.

Figure 5-24 highlights the CPT Design Reset Adjust selection cell (AF2). This function will allow the CPT to adjust user productivity so calculated think time is reduced to equal minimum think time. Once this adjustment is complete, the workflow loads will fit within the available network bandwidth and the calculated loads will represent a real workflow.

<br style="clear: both" />

CPT Workflow tab Network Metrics
Figure 5-25 provides an overview of the Capacity Planning Workflow tab highlighting workflow display chatter, client display traffic, and database traffic columns used by the CPT Design tab to complete an Enterprise level network suitability analysis. <br style="clear: both" />

Enterprise Design Network Suitability Analysis
Figure 5-26 shows how network suitability is addressed on the CPT Design tab. This is where all of the user workflows and network traffic comes together, providing an opportunity to complete a comprehensive Enterprise network suitability analysis.

Network suitability analysis is completed by the CPT Design tool. User workflows are configured within their respective GREY data center network segments (LAN, WAN, INTERNET) and within their GREEN remote site locations. Network traffic for each workflow is calculated in column G. Workflow traffic is calculated from the traffic per display (Mbpd) in column R and the total display throughput (DPM) in column F (DPM x Mbpd / 60 sec). The total traffic for each network is collected in column F (centered across columns F and G for better display). Total network traffic for a specific network segment is the sum of all the workflow traffic located on that network (network traffic summations must be updated manually when adding new remote sites). Network bandwidth for each site connection is identified in column H. Traffic bandwidth utilization for each network is identified in column R (traffic / bandwidth).

Network performance counts. Figure 5-27 shows the contribution networks make to workflow display response time. For local workflows (100 Mbps workstation connections), network traffic has a relatively small impact on overall display performance. For Windows Terminal Server Citrix workflows over shared 1.5 Mbps remote site connections, network impact is still not a big performance impact (as long as you have sufficient capacity).

Web services tend to deliver higher display traffic than WTS ArcGIS Desktop clients, and network bandwidth can make a significant contribution to user display performance. Server display render time can be much less a factor than the network connection. Network performance improves with increased bandwidth (45 Mbps bandwidth connection is 30 times faster than a 1.5 Mbps connection). Light display traffic performs much better than heavy display traffic. Network performance impacts should be considered carefully during design and deployment of Web services.

The following video provides an overview of the CPT Calculator network traffic functions. The video also provides an overview of the CPT Design User Requirements Module and shows how the CPT Design completes the network suitability analysis.

Previous Editions
Network Communications 28th Edition Network Communications 27th Edition

Page Footer Specific license terms for this content System Design Strategies 26th edition - An Esri ® Technical Reference  Document • 2009 (final PDF release)