Top_Down_Network_DesignChapter_4_Notes (1) (1).docx

16 Pages
Unlock Document

Ryerson University
Information Technology Management
ITM 600
Khalil Arbousa

Top Down Network Design Chapter 4 Notes. Characterizing Network Traffic Characterizing Traffic Flow • Characterizing traffic flow is the process of identifying sources and destinations of network traffic and analyzing the direction and symmetry of data traveling between sources and destinations. • Flow can be bidirectional and symmetric. (Both ends of the flow send traffic at about the same rate.) • In other applications, the flow can be bidirectional and asymmetric. • Client stations send small queries and servers send large streams of data. • In a broadcast application, the flow is unidirectional and asymmetric. Identifying Major Traffic Sources and Stores • First identify user communities and data stores for existing and new applications. • A user community is a set of workers who use a particular application or set of applications. • A user community can be a corporate department or set of departments. • As more corporations use matrix management and form virtual teams to complete ad-hoc projects, it becomes more necessary to characterize user communities by application and protocol usage rather than by departmental boundary. Documenting Traffic Flow on the Existing Network • Documenting traffic flow involves identifying and characterizing individual traffic flows between traffic sources and stores. • RFC 2722 describes an architecture for the measurement and reporting of network traffic flows, and discusses how the architecture relates to an overall traffic flow architecture for intranets and the Internet. • Measuring traffic flow behavior can help a network designer determine which routers should be peers in routing protocols that use a peering system, such as the Border Gateway Protocol (BGP). • Measuring traffic flow behavior can also help network designers do the following: o Characterize the behavior of existing networks o Plan for network development and expansion o Quantify network performance o Verify the quality of network service o Ascribe network usage to users and applications • An individual network traffic flow can be defined as protocol and application information transmitted between communicating entities during a single session. • A flow has attributes such as: o direction, o symmetry, o routing path and routing options, o number of packets, number of bytes, and o addresses for each end of the flow. • The simplest method for characterizing the size of a flow is to measure the number of Kbytes or Mbytes per second between communicating entities. • To characterize the size of a flow, use a protocol analyzer or network management system to record load between important sources and destinations. Characterizing Types of Traffic Flow for New Network Applications • Characterize by direction and symmetry. • Direction specifies whether data travels in both directions or in just one direction. • Direction also specifies the path that a flow takes as it travels from source to destination through an internetwork. • Symmetry describes whether the flow tends to have higher performance or QoS requirements in one direction than the other direction. • Characterize network traffic flow by classifying applications as supporting one of a few well-known flow types: o Terminal/host traffic flow o Client/server traffic flow o Peer-to-peer traffic flow o Server/server traffic flow o Distributed computing traffic flow Terminal/Host Traffic Flow • Terminal/host traffic is usually asymmetric. • The terminal sends a few characters and the host sends many characters. • Telnet is an example of an application that generates terminal/host traffic. • With some full-screen terminal applications, such as some IBM 3270- based terminal applications, the terminal side sends characters typed by the user and the host side returns data to repaint the screen. • More modern terminal applications just send changes to the user's screen, thus reducing network traffic. • Terminal/host traffic flows are less prevalent on networks than they once were, but they have not disappeared • Thin clients, which have become quite popular, can behave like terminal/host applications. Client/Server Traffic Flow • Client/server traffic is the best known and most widely used flow type. • Clients send queries and requests to a server. The server responds with data or permission for the client to send data. • The flow is usually bidirectional and asymmetric. • Requests from the client are typically small frames, except when writing data to the server, in which case they are larger. • Responses from the server range from 64 bytes to 1500 bytes or more, depending on the maximum frame size allowed for the data link layer in use. • Hypertext Transfer Protocol (HTTP) is probably the most widely used client/server protocol. • The flow for HTTP traffic is not always between the web browser and the web server because of caching. • A cache engine is software or hardware that makes recently accessed web pages available locally, which can speed the delivery of the pages and reduce WAN bandwidth utilization. • A cache engine can also be used to control the type of content that users are allowed to view. Thin Client Traffic Flow • A special case of the client/server architecture is a thin client, which is software or hardware that is designed to be particularly simple and to work in an environment where the bulk of data processing occurs on a server. • With thin client technology, (also known as server-based computing), user applications originate on a central server • A downside of thin client technology is that the amount of data flowing from the server to the client can be substantial, especially when many computers start up at the same time every day. • Networks with thin clients should be carefully designed with sufficient capacity and an appropriate topology. Switched networking (rather than shared media) is recommended, and to avoid problems caused by too much broadcast traffic. Peer-to-Peer Traffic Flow • flow is usually bidirectional and symmetric. • Communicating entities transmit approximately equal amounts of information. • There is no hierarchy. • Each device is considered as important as each other device, and no device stores substantially more data than any other device. • There are many flows in both directions. • Recently peer-to-peer applications for downloading music, videos, and software have gained popularity. • Most enterprises and many university networks disallow this type of peer- to-peer traffic for two reasons. First, it can cause an inordinate amount of traffic, and, second, the published material is often copyrighted by someone other than the person publishing it. Server/Server Traffic Flow • Server/server traffic includes transmissions between servers and transmissions between servers and management applications. • Servers talk to other servers to implement directory services, to cache heavily used data, to mirror data for load balancing and redundancy, to back up data, and to broadcast service availability • The flow is generally bidirectional. • The symmetry of the flow depends on the application. With most server/server applications, the flow is symmetrical, but in some cases there is a hierarchy of servers, with some servers sending and storing more data than others. Distributed Computing Traffic Flow • Distributed computing refers to applications that require multiple computing nodes working together to complete a job. • Some complex modeling and rendering tasks cannot be accomplished in a reasonable timeframe unless multiple computers process data and run algorithms simultaneously. • The visual effects for movies are often developed in a distributed- computing environment. • data travels between a task manager and computing nodes and between computing nodes. • McCabe distinguishes between tightly coupled and loosely coupled computing nodes. Nodes that are tightly coupled transfer information to each other frequently. Nodes that are loosely coupled transfer little or no information. Traffic Flow in Voice over IP Networks • The most important concept to understand when considering traffic flow in VoIP networks is that there are multiple flows. • The flow associated with transmitting the audio voice is separate from the flows associated with call setup and teardown. • The flow for transmitting the digital voice is essentially peer-to-peer, between two phones or PCs running software, such as Microsoft's NetMeeting or Cisco's SoftPhone. • Call setup and teardown, on the other hand, could be characterized as a client/server flow because a phone needs to talk to a more complicated device, such as a server or traditional phone switch, that understands phone numbers, addresses, capabilities negotiation, and so on. • These protocols generally fit the client/server paradigm, but they also use distributed and peer-to-peer processing, and have some terminal/host behavior. Documenting Traffic Flow for New and Existing Network Applications • characterize the flow type for each application and list the user communities and data stores that are associated with applications. • You can use Table 4-4 to enhance the Network Applications charts already discussed in Chapters 1 and 2. • When identifying the type of traffic flow for an application, select one of the well-known types: o Terminal/host o Client/server o Peer-to-peer o Server/server o Distributed computing Characterizing Traffic Load • To select appropriate topologies and technologies to meet a customer's goals, it is important to characterize traffic load with traffic flow. • Characterizing traffic load can help you design networks with sufficient capacity for local usage and internetwork flows. • The goal is simply to avoid a design that has any critical bottlenecks. • To avoid bottlenecks, you can research application usage patterns, idle times between packets and sessions, frame sizes, and other traffic behavioral patterns for application and system protocols. • Another approach to avoiding bottlenecks is simply to throw large amounts of bandwidth at the problem. A strict interpretation of systems analysis principles wouldn't approve of such an approach, but bandwidth is cheap these days. LAN bandwidth is extremely cheap. Calculating Theoretical Traffic Load • traffic load (sometimes called offered load) is the sum of all the data network nodes have ready to send at a particular time. • A general goal for most network designs is that the network capacity should be more than adequate to handle the traffic load. • The challenge is to determine if the capacity proposed for a new network design is sufficient to handle the potential load. • In general, to calculate whether capacity is sufficient, only a few parameters are necessary: o The number of stations o The average time that a station is idle between sending frames o The time required to transmit a message once medium access is gained • By studying idle times and frame sizes with a protocol analyzer, and estimating the number of stations, you can determine if the proposed capacity is sufficient. • After you have identified the approximate traffic load for an application flow, you can estimate total load for an application by multiplying the load for the flow by the number of devices that use the application. • The research you do on the size of user communities and the number of data stores (servers) can help you calculate an approximate aggregated bandwidth requirement for each application and fill in the "Approximate Bandwidth Requirement for the Application" column in Table 4-4. Documenting Application-Usage Patterns • The first step in documenting application-usage patterns is to identify user communities, the number of users in the communities, and the applications the users employ • In addition to identifying the total number of users for each application, you should also document the following information: o The frequency of application sessions (number of sessions per day, week, month or whatever time period is appropriate) o The length of an average application session o The number of simultaneous users of an application • If it is not practical to research these details, you can make some assumptions: o assume that the number of users of an application equals the number of simultaneous users. o assume that all applications are used all the time so that your bandwidth calculation is a worst-case (peak) estimate. o assume that each user opens just one session and that a session lasts all day until the user shuts down the application at the end of the day. Refining Estimates of Traffic Load Caused by Applications • you need to research the size of data objects sent by applications, • the overhead caused by protocol layers, and • any additional load caused by application initialization. • (Some applications send much more traffic during initialization than during steady-state operation.) Estimating Traffic Overhead for Various Protocols • To completely characterize application behavior, you should investigate which protocols an application uses. • you can calculate traffic load more precisely by adding the size of protocol headers to the size of data objects Estimating Traffic Load Caused by Workstation and Session Initialization • workstation initialization can cause a load on networks due to the number of packets and, in some cases, the number of broadcast packets. • this is becoming less of a problem as network bandwidth has become so inexpensive, and extremely fast CPUs in workstations are readily available so that broadcast processing isn't a concern • The tables in Appendix A show typical workstation behavior for the following protocols: o Novell NetWare o AppleTalk o TCP/IP o TCP/IP with DHCP o NetBIOS (NetBEUI) o NetBIOS with a Windows Internet Naming Service (WINS) server o SNA Boot-Time Traffic for Older Protocols • Many universities, schools, governments, and nonprofit organizations still use older protocols. • Also, some companies that have theoretically standardized on TCP/IP are often surprised when a network engineer studies their network traffic. • A lot of equipment that is supposedly running only TCP/IP tends to still send out traffic for other protocols. • Printers are notorious for still sending Novell NetWare traffic in many different formats. Estimating Traffic Load Caused by Routing Protocols • To characterize network traffic caused by routing protocols, Table 4-7 shows the amount of bandwidth used by legacy distance-vector routing protocols. • Estimating traffic load caused by legacy routing protocols is especially important in a topology that includes many networks on one side of a slow WAN link. • A router sending a large distance-vector routing table every minute can use a significant percentage of WAN bandwidth • Newer routing protocols, such as OSPF and EIGRP, use very little bandwidth. In the case of OSPF, your main concern should be the amount of bandwidth consumed by the database synchronization packets that routers send every 30 minutes. • By subdividing an OSPF network into areas and using route summarization, this traffic can be minimized • EIGRP also sends Hello packets, but more frequently than OSPF (every 5 seconds). On the other hand, EIGRP doesn't send any periodic route updates or database synchronization packets. It only sends route updates when there are changes. Characterizing Traffic Behavior • To select appropriate network design solutions, you need to understand protocol and application behavior in addition to traffic flows and load. • For example, to select appropriate LAN topologies, you need to investigate the level of broadcast traffic on the LANs. • To provision adequate capacity for LANs and WANs, you need to check for extra bandwidth utilization caused by protocol inefficiencies and nonoptimal frame sizes or retransmission timers. Broadcast/Multicast Behavior • A broadcast frame is a frame that goes to all network stations on a LAN. • A multicast frame is a frame that goes to a subset of stations • Layer 2 internetworking devices, such as switches and bridges, forward broadcas
More Less

Related notes for ITM 600

Log In


Don't have an account?

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.