Rab Nawaz Jadoon. Characterizing Network Traffic DCS. Assistant Professor. Department of Computer Science. COMSATS IIT, Abbottabad Pakistan

Transcription

1 Characterizing Network Traffic DCS COMSATS Institute of Information Technology Rab Nawaz Jadoon Assistant Professor COMSATS IIT, Abbottabad Pakistan Telecommunication Network Design (TND)

2 Characterizing Types of Traffic Flow for New Network Applications 2

3 Characterizing Traffic Flow A good technique for characterizing network traffic flow is to classify applications as supporting one of a few well-known flow types. Terminal/Host Traffic Flow Asymmetric For example Telnet (terminal sends few character, while host sends back many character i.e user name and password authentication. Client/Server Traffic Flow Bidirectional flow Asymmetric For example, FTP, HTTP protocols etc. Request from the clients are small frames while responses ranges from 64 bytes to 15 bytes. 3

4 Thin Client traffic Flow/Server based computing A special case of client/server architecture Bulk of data processing on server side. Peer to Peer Traffic Flow Bidirectional and symmetric Traffic Flow Each device is considered as important as each other device, and no device stores substantially more data than any other device. Recently, peer-to-peer applications for downloading music, videos, and software have gained popularity. Each user publishes music or other material and allows other users on the Internet to download the data. This is because of every user acts as both a distributor and consumer of data. Traffic flow is bidirectional and symmetric. E.g. video conferencing 4

5 Traffic Flow Server/Server Traffic Flow Servers talk to other servers to, implement directory services, cache heavily used data, mirror data for load balancing and redundancy, back up data, broadcast service availability. With server/server network traffic, 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. 5

6 Traffic Flow Distributed Computing Traffic Flow With distributed computing, data travels between a task manager and computing nodes and between computing nodes. Characterizing traffic flow for distributed computing applications might require you to, Study the traffic with a protocol analyzer or model potential traffic with a network simulator. 6

7 Traffic Flow in VOIP Networks Traffic flow in VoIP networks is that there are two flows. The flow associated with transmitting the audio voice. The flow associated with call setup and teardown. The flow for transmitting the digital voice is peer-to-peer, between two phones or between two PCs running software such as Skype or Cisco IP Communicator (CIPC). Call setup and teardown, on the other hand, can be characterized as a client/server flow because a phone needs to talk to a more complicated machine like server or switching machine. 7

8 Traffic Flow The audio voice flow between two IP endpoints RTP, RTP Connectionless, run on top of UDP. The main call setup, teardown, and control protocols in an IP network are, H.323, the Cisco Skinny Client Control Protocol (SCCP), Simple Gateway Control Protocol (SGCP), Media Gateway Control Protocol (MGCP), and Session Initiation Protocol (SIP). 8

9 Documenting Traffic Flow for New and Existing Network Applications 9

10 Documenting Traffic Flow To document 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. 10

11 11

12 Traffic Load Characterizing traffic load can help you design networks with sufficient capacity for local usage and internetwork flows. traffic load estimates are unlikely to be precise. The goal is simply to avoid a design that has any critical bottlenecks. 12

13 Traffic load Traffic load(sometimes called offered load) is the sum of all the data all 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 enough 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. 13

14 Calculating Theoretical Traffic Load For example, for a network with a proposed capacity 1 Mbps, If 1000 stations send 1000-bit frames every second, the offered load equals the capacity. This is according to the theory of the William Stalling 14

15 Calculating Theoretical Traffic Load In general, to calculate whether capacity is sufficient, only a few parameters are necessary: The number of stations. The average time that a station is idle between sending frames. The time required to transmit a message once medium access is gained. 15

16 Calculating Theoretical Traffic Load For a client/server application, idle time for the server depends on, The number of clients using the server, and the architecture and performance characteristics of the server (disk access speed, RAM access speed, caching mechanisms, and so on). Idle time on the client side depends partly on user action, which means it is impossible to precisely predict idle time. 16

17 Calculating Theoretical Traffic Load 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. 17

18 Traffic Load In general, to accurately characterize traffic load, you need to understand Application usage patterns and QoS requirements in addition to idle times and frame sizes. 18

19 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. (this is already covered before) 19

20 Documenting Application-Usage patterns In addition to identifying the total number of users for each application, you should also document the following information: The frequency of application sessions (number of sessions per day, week, month, or whatever time period is appropriate) The length of an average application session The number of simultaneous users of an application 20

21 Documenting Application-Usage patterns you can more accurately predict the aggregate bandwidth requirement for all users of an application. If it is not practical to research these details, you can make some assumptions: The number of users of an application equals the number of simultaneous (real time) users. All applications are used all the time, so that your bandwidth calculation is a worstcase (peak) estimate. Each user opens just one session, and that session lasts all day until the user shuts down the application at the end of the day. 21

22 Estimates of Traffic Load Caused by Applications To completely characterize application behavior, you should investigate which protocols an application uses. When you know the protocols, you can calculate traffic load more precisely by adding the size of protocol headers to the size of data objects. Table (next slide) shows some typical protocol header sizes. 22

23 Traffic Overhead for Various Protocols 23

24 Estimates of Traffic Load Caused by Applications In addition to applications that are set to start upon bootup, the following system-level protocols send packets as a workstation initializes: Address Resolution Protocol (ARP) Dynamic Host Configuration Protocol (DHCP) Internet Control Message Protocol (ICMP), rsion 4 and 6 Internet Group Management Protocol (IGMP), version 4 and 6 Domain Name System (DNS) 24

25 Multicast DNS (mdns) NetBIOS name queries Network Time Protocol (NTP) Simple Service Discovery Protocol (SSDP) Service Location Protocol (SLP) Simple Network Management Protocol (SNMP) Cont 25

26 Estimating Traffic Load Caused by Routing Protocols Estimating traffic load caused by legacy routing protocols is 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 30sec can use a significant percentage of WAN bandwidth. 26

27 Estimating Traffic Load Caused by Routing Protocols Because routing protocols limit the number of routes per packet, on large networks, a router sends multiple packets to send the entire table. Routing Information Protocol (RIP), for example, sends a routing packet every 30 seconds. Each route in the packet uses 20 bytes, and there are 25 routes per packet. When headers are added, this means that a router running RIP sends one or more 532-byte packets every 30 seconds, depending on the size of the routing table. 27

28 Estimating Traffic Load Caused by Routing Protocols Newer routing protocols, such as Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP), use little bandwidth. 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 sends route updates only when there are changes. 28

29 29