2.5 Application Requirements


2.5 Application Requirements

The application component interfaces with the user and device components and is a key part of the requirements analysis. Application requirements are requirements that are determined from application information, experience, or testing; applications need these to successfully operate on the system.

Figure 2.4 shows example application requirements. Application requirements are more technical than user requirements but may still be subjective.

click to expand
Figure 2.4: Types of application requirements.

2.5.1 Application Types

In the system description (user, application, device, and network), the application component is pivotal. This component is often where many requirements for the network are determined, as applications couple users and devices to the network. Applications are often end-to-end, between multiple devices; thus their requirements span the underlying network.

In the early days of networking, applications required basic connectivity and data transfer across the network. Although applications still have these requirements, they are often also required to be high performance or to have predictable or guaranteed behavior to support user requirements for timeliness, interactivity, reliability, quality, adaptability, and security. Thus, user requirements have an impact on application requirements. We can use these service and performance requirements to distinguish between applications that need predictable or guaranteed service and those that can use best-effort service.

Based on service and performance requirements, we will type applications as mission-critical, rate-critical, and real-time/interactive, where:

  • Mission-critical applications have predictable, guaranteed, and/or high-performance RMA requirements.

  • Rate-critical applications have predictable, guaranteed, and/or high-performance capacity requirements.

  • Real-time and interactive applications have predictable, guaranteed, and/or high-performance delay requirements.

These application types will be described by their requirements and service metrics.

RMA

Let's first look at RMA, consisting of reliability, maintainability, and availability. Reliability is a statistical measure of the frequency of failure of the network and its components; it represents the unscheduled outages of service. Maintainability is statistical measure of the time to restore the system to fully operational status after it has experienced a fault. Availability is a measure of the relationship between the frequency of mission-critical failures and the time to restore service. How do these measures relate to the applications that will use the network?

RMA requirements can be subjective. Many users argue that their applications require a high degree of reliability, maintainability, and/or availability from the network, but there are some applications that must maintain high degrees of RMA in order to function. A loss of any part of RMA in such applications may be serious or disastrous, such as:

  • Loss of revenue or customers. An application that handles a lot of transactions and money, such as investment banking, airline reservation, or credit card processing applications, is an example.

  • Unrecoverable information or situation. Telemetry processing and teleconferencing applications are good examples of this type of reliability.

  • Loss of sensitive data. Examples include customer ID/billing and intelligence-gathering applications.

  • Loss of life. Examples include transportation or health care monitoring applications.

In these situations, either the system is not available to process user/application requests or the system is not available to complete the transactions that are in progress. For applications such as these, a network that offers only best-effort service is not likely to be sufficient due to its unpredictable and unreliable behavior. These applications require predictable or guaranteed reliability, maintainability, and availability, which may take the form of a predictable or bounded RMA, or a high degree of RMA, or both. Applications that require predictable or high RMA are termed here mission-critical applications.

Capacity

In terms of capacity, some applications require a predictable, bounded, or high degree of capacity. Such applications, termed here rate-critical applications, include voice, non-buffered video, and some tele*service applications (applications that provide a subset of voice, video, and data together to be delivered concurrently to groups of people at various locations, e.g., teleconferencing, telemedicine, teleseminars [thus the tele*]). Rate-critical applications may require thresholds; limits; or guarantees on minimum, peak, and/or sustained capacities.

Note the difference between rate-critical applications and best-effort applications such as traditional file transfer (where the file transfer application is not written to operate only when a predictable or guaranteed service is available). In file transfer (such as in FTP running over TCP, described earlier), the application receives whatever capacity is available from the network based on the state of the network at that time and the interactions between TCP and the lower layers. Although at times this may be a high degree of capacity, it is inconsistent and there is no control over the resources in the network to predict or guarantee a specific (usually minimum) capacity to function properly. This can often also be tied to the end-to-end delay of the network, for capacity will affect delay.

Delay

Increasing interactivity is arguably the driving force behind the evolution of many applications. Consider the evolutionary path of information access, from telnet and FTP to Gopher and Archie (Gopher is a menu system that simplifies locating resources on the Internet, and Archie is a database that consists of hundreds of file directories) to Mosaic (the precursor to Netscape) and Netscape, made even more interactive with the use of JAVA and virtual reality markup language (VRML). As we saw in the previous section, interactivity relies predominantly on the performance characteristic delay.

Delay is a measure of the time differences in the transfer and processing of information. There are many sources of delay, including propagation, transmission, queuing, processing, and routing. This section focuses on end-to-end and round-trip delays, which encompass all of the delay types mentioned earlier. From an application service perspective, optimizing the total, end-to-end or round-trip delay is usually more important than focusing on individual sources of delay. Individual sources of delay become more important as we get into the lower-layer components, as well as in architecture and design optimizations.

Historically, applications used on the Internet did not have strict delay requirements. They relied on best-effort service from the Internet and did not request or expect any service guarantees. Other applications, found primarily on private networks (with proprietary network technologies and protocols), have had more strict delay requirements (as well as capacity and RMA requirements). Some private networks have been effective in providing predictable or guaranteed delay, either through overengineering of the network with substantial spare capacity or at the trade-off of interoperability with other networks. But we now find that applications with delay requirements are migrating to the Internet, often using VPNs, and applications previously dedicated to a single user or device are now being used across the Internet, forcing a reevaluation of offering services other than best effort on the Internet. This is also forcing a reevaluation of traffic engineering techniques by service providers.

The term real-time has been interpreted to mean many different things. Often, real-time means "as fast as possible" by those who do not know, understand, or care about the actual delay relationships between traffic sources and destinations within their network. It is quite difficult to quantify real-time when it is used this way. There are more meaningful ways to describe real-time, as well as non-real-time, interactive, asynchronous, burst, and bulk. These are all described in the following sections.

Real-time applications are those that have a strict timing relationship between source and destination, with one or more timers set for the receipt of information at the destination. Information received after the timers expire at the destination is considered worthless and is dropped. Thus, this definition of real-time does not mean that information has to be transferred within a universally known time boundary but rather that the delay boundary is understood by source and destination and that the destination does not wait beyond this boundary. Real-time could mean end-to-end delays of 30 ms for some applications and 30 seconds for others. An example of this is nonbuffered video playback. If the video stream is delayed beyond the playback timer, the destination will show one or more blank portions of frames (appearing as blips on the screen) and drop the late video. This is done to preserve the time continuity of the video being shown at the playback device. This is what having a strict timing relationship between source and destination means—that the information flow is subject to maintaining time continuity.

Real-time is the first of several terms we need to clarify. These terms are often used carelessly, although, as the network architect/designer, we have to take them seriously. Therefore, it is up to us to make sure that ambiguous terms, as well as requirements based on such terms, are clarified. This book tries, whenever possible, to provide strict interpretations of such terms to help make them clear.

Given this strict interpretation of real-time, there obviously are not that many real-time applications. But there are some (and their numbers are growing), and it is important to be able to identify them and recognize their strict delay requirements, for they can have a strong impact on the network architecture and design.

Currently, most applications are considered non-real-time. Non-real-time applications have various end-to-end delay requirements, at times more stringent (in terms of the amount of delay) than real-time applications, but the important factor here is that the destination will wait (within reason) until the information is received. How long the destination will wait is a function of the timers set in the applications, at the devices, and by the protocols used. Non-real-time applications include interactive and asynchronous, which account for the vast majority of applications.

With real-time applications at one extreme of performance, asynchronous applications are at the other extreme. Asynchronous applications are relatively insensitive to time, either assuming no timing relationship between source and destination or that the timing relationship is outside the bounds of the applications session. A good example of an asynchronous application is email. When email is sent to a recipient, all knowledge of timing (i.e., the time when the email is received at any intermediate stop or at the final destination) is lost to the sender. Only if there is an error in the system or recipient information, or if it is requested, is the sender notified. Facsimile is another asynchronous application. When a fax is sent (when it is buffered in the sending device), the sender loses any knowledge of when the fax arrives at its destination.

Just as it is important to identify real-time applications, because of their strict timing requirements, it is also important to identify asynchronous applications, because of their lack of timing requirements. Asynchronous applications have little or no effect on the network architecture and design and can usually be ignored.

Just as there are not many real-time applications, there are also not many asynchronous applications. Thus, most applications fall in the non-real-time realm, between real-time at one extreme and asynchronous at the other extreme. These applications are called interactive. Interactive applications assume some timing relationship between source and destination while the application session is active; however, the timing relationship is not as strict as in real-time. Interactive applications are what many people would normally consider real-time, under the connotation of real-time as "as fast as possible." Common interactive applications, such as telnet, FTP, and Web applications, all fall under this classification.

Finally, interactive applications may be further subdivided into burst and bulk interactive types. The difference between these types is subtler than with real-time or asynchronous applications. To distinguish between interactive bulk and burst applications, we need to first understand when the processing times of the system components, particularly the application component, overwhelm the end-to-end or round-trip delay of the network. In other words, we want to distinguish between when an application will frequently and quickly interact with a user and when a user will have to wait substantial periods of time while the application is processing information. These delay types are summarized in Figure 2.5.

click to expand
Figure 2.5: Delay types.

Based on this, interactive burst applications are those in which the end-to-end or round-trip network delay is the predominant delay for that application. This type of application is important to identify, for it is sensitive to network delay. Thus, the network architecture and design will need to accommodate the delay requirements from these applications. An example of an interactive burst application is telnet. During a telnet session, the predominant delay experienced by the user is from the network, not from any processing at the local or remote devices. There are many applications of this type, where users interact with applications and devices across the network and expect responses "as fast as possible."

Interactive bulk applications are those in which the end-to-end or round-trip network delay is not the predominant delay for that application; rather processing at the device or application component is the predominant delay. Thus, processing information at either or both end points overwhelms the end-to-end or round-trip times in the network. This is important to recognize—the network delay requirement by that application becomes less significant because it is already eclipsed by application and/or device delays. For example, when an application has high processing delays, say on the order of 100s of milliseconds or seconds then we have more flexibility in supporting delay in the network than if the processing delay was on the order of microseconds. An example of interactive bulk applications is large file transfer (e.g., FTP). Although FTP has an degree of interaction with the user, there can be times (especially when the file size is large) when the processing of information at the receiving end, as well as the overall time it takes to transfer the entire file, is several orders of magnitude greater than the end-to-end or round-trip network delay.

Why the elaborate breakdown of application types based on delay? As we can see from the preceding discussion, there are times when an application's requirement for delay is important to consider in the network architecture and design and other times when it is not as important. Whenever we can selectively ignore some applications and focus on others, the network architecture and design problems become more tractable.

In the next chapter we will discuss some of the time parameters associated with interactive burst and bulk applications.

2.5.2 Application Groups

We have so far used various examples of applications to convey application requirements. It is often useful to group applications with similar performance characteristics because it helps both in the mapping of performance characteristics and in gathering and understanding requirements. It has been useful to me to form groups for applications and keep adding to them as I encounter new applications. When trying to rapidly identify network requirements for a new customer, I have successfully used these groups to help identify requirements by comparing the new applications with those in groups I have already developed. This process is particularly useful if you have to do requirements analysis quickly or if you frequently have new customers.

With use of the requirements analysis process, the following application groups have been identified. There is some overlap between these groups, and this is not a complete set of groups. It is intended to illustrate how grouping works. You are encouraged to develop your own application groups as you apply the requirements analysis process to your networks.

  • Telemetry/command and control applications. Although the title may sound somewhat military, it actually describes a variety of applications in which data and command information are transmitted between remote devices and one or more control stations for command, control, tracking, and determination of status of the remote devices. A remote device may be a mundane one, such as an automated teller machine (ATM), sensors in the home, or remote computer, or esoteric devices, such as remotely piloted vehicles (RPVs), spacecraft, or commercial aircraft. Telemetry/command and control applications can be characterized as having realtime and/or interactive delay and are often considered mission-critical.

  • Visualization applications. This group ranges from 2D viewing of objects to 3D and virtual reality viewing, immersion, and manipulation of objects. Visualization may be of a numerical simulation or of experimental data. Examples include visualizations of fluid flow fields around various objects (e.g., weather modeling, aeronautics, medicine); to medical, biomedical, and molecular simulations; to commercial and military gaming simulations. Visualization applications can often be characterized as rate-critical and interactive-burst.

  • Distributed-computing applications. Applications in this group may range from having the computing devices sharing the same local bus (as in parallel computing) to being co-located at the same LAN (as in a computing cluster), to being distributed across LAN, MAN, and WAN boundaries (as in grid computing). The degree of distribution or parallelism in the computing is also determined by the granularity of the task and the degree of coupling between the computing devices. An example of distributed computing is in making use of desktop computers in the corporate environment late at night, when they are usually idle, by coupling their computing capability to accomplish large tasks normally done on a mainframe. Distributed-computing applications can be characterized as realtime or interactive burst.

  • Web development, access, and use applications. Applications in this group are the current interactive equivalents of the traditional remote device and information access utilities telnet and FTP. Web access and use involve accessing remote devices and downloading and/or uploading information. This is done with the aid of graphic interfaces. Typically, Web sessions are interactive, and the amounts of information are small relative to the other application groups (with the possible exception of telemetry/command and control). This group of applications is generally considered interactive—a mix of interactive-burst and interactive bulk.

  • Bulk data transport applications. When the amounts of information desired are relatively large and the sessions are less interactive (or asynchronous), applications can optimize the data transfer rate at the expense of interactivity. The traditional example of this is FTP, and currently more effective applications such as mftp and arcp are available. For more information on mftp and arcp, see www.nas.nasa.gov. These applications generally do not have high performance requirements.

  • Tele*service applications. This group describes the applications that provide a subset of voice, video, and data together to be delivered concurrently to groups of people at various locations. Examples include teleconferencing, telemedicine, and teleseminars (thus the tele*). The multicast backbone of the Internet is an example of network support for this application group. Tele*service applications can be characterized as having interactive and real-time delay and are often considered rate-critical and mission-critical.

  • Operations, administration, maintenance, and provisioning (OAM&P) applications. System OAM&P applications are required for the proper functioning and operation of the network. Examples include domain name service (DNS), mail services/SMTP, news services/NNTP, address resolution service, network monitoring and management, network security, and systems accounting. These applications are often considered mission-critical and interactive.

  • Client-server applications. This group includes applications whose traffic flows behave in a client-server fashion, such as enterprise resource planning (ERP), supply chain management (SCM), and customer relationship management (CRM) tools. We will discuss traffic flows and client-server flow behavior in detail in Chapter 4. These applications are often mission-critical and interactive.

You may be able to apply more application groups to your networks. If you develop requirements for multiple networks, you will be able to expand upon or modify this list to meet your analysis needs.

2.5.3 Application Locations

Along with typing and grouping applications, it is often useful to determine where an application applies in your (or your customer's) environment. There are usually some applications that apply everywhere, which everyone uses and that reside on almost all devices (e.g., servers, desktops, laptops). However, there are often applications that apply to particular users, user groups, servers, floors within a building, or buildings. When possible, identifying such applications and where they apply will help you in mapping traffic flows during the flow analysis process.

An example of an applications map, or drawing of where applications apply, is shown in Figure 2.6. In this figure of a campus environment, there are three sets of buildings, shown in gray. The location where each application applies is outlined. This is an estimate of the probable locations for applications in an environment and is the first step toward providing location information in the requirements analysis. In some cases, all applications will apply everywhere. In other cases, we will not be able to determine where some applications apply. Whenever such information is available, however, mapping that information will help us in the requirements and flow analyses.

click to expand
Figure 2.6: Example applications map.

Application types, their performance requirements, their locations, and application groups form the interface between the application component and the rest of the system.




Network Analysis, Architecture and Design
Network Analysis, Architecture and Design, Second Edition (The Morgan Kaufmann Series in Networking)
ISBN: 1558608877
EAN: 2147483647
Year: 2003
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net