-1-

APNOMS2005

Flow-based Application-aware Internet Traffic Monitoring and Field Trial

ExperiencesTS Choi, SH Yoon, HS Chung, JS Park, BJ Lee, SS Yoon, TS Jeong

ETRI{choits, shpyoon, hschung, jungsp, bjlee, ssyoon, tsjeong}@etri.re.kr

Abstract

In recent years, traffic measurement and analysis have received significant attention due to the increased requirements from various aspects such as SLA monitoring, P2P traffic monitoring and security attacks, etc. But technical challenges have been increased as well because link speed and traffic volume to measure have become huge and the characteristics of Internet applications, which takes major portion of entire traffic volume, have changed dramatically. Traffic measurement system has to deal with very high-speed links. Newly emerging applications such as P2P, streaming, and network game applications don’t follow the traditional application identification method, that is, the use of fixed port numbers. These applications, however, take most of the Internet bandwidth. In this paper, we propose novel mechanisms to cope with such challenges and have incorporated the proposed mechanisms into our proof-of-concept system. Also the paper describes various field trial experiences conducted over real operational networks.

Keywords: Flow-based, Application-aware, Application Traffic Monitoring, Precise Application Classification

214

-2-

APNOMS2005

Introduction ▣ High-speed networks (Mbps → Gbps → Tbps)▣ High-volume traffic▣ Variety of Applications

◈ Streaming media (Windows Media, Real Media, Quicktime)◈ P2P traffic◈ Network Games◈ Network Security Attacks, etc.

▣ Limitations of port-based recognition◈ The port database maintained by IANA doesn’t reflect the real-world situation

– Several applications can use the same port number– Identification error can be occurred by ephemeral port number– Some applications can use a dynamic port number– Etc.

◈Most bandwidth hogs, nowadays, dynamically allocate ports– They are not linked up with any fixed ports!

In recent years, traffic measurement and analysis have received significant attention due to the increased requirements from various aspects such as SLA monitoring, P2P traffic monitoring and security attacks, etc. But technical challenges have been increased as well because link speed and traffic volume to measure have become huge and the characteristics of the current and newly emerging Internet applications, which take major portion of entire traffic volume, have changed dramatically.

For the diversity of the current and newly emerging Internet applications, the main difficulties come from highly dynamic nature of the development and the use of the current Internet applications. Traditionally, Internet traffic was dominated mostly by the client-server type of applications such as WWW, FTP, TELNET, etc. However, this characteristic has been changed significantly when new applications such as peer-to-peer, streaming and network game applications were introduced. These applications use a range of port numbers or dynamically allocated ones for their sub-transactions. Internet Assigned Numbers Authority (IANA) recommends the usage of application port numbers: 0 ~ 1023 for well-known ports, 1024 ~ 49151 for registered ports, and 49152 ~ 65535 for dynamic and/or private ports. However, the application developers do not strictly follow this recommendation. This means that distinguishing flows based on a port number and other header properties is not safe and accurate enough.

In this paper, we propose novel mechanisms to cope with such challenges and provide performance study results of them. They include traffic capture cards which are designed and implemented by us with various functionalities described in the above. And various software enhancements to improve the performance of traffic measurement and analysis in high speed and volume environment. We have incorporated the proposed mechanisms into our proof-of-concept system called WiseTrafView, whose main target application is usage-based accounting.

215

-3-

APNOMS2005

Related Work

▣Per-packet analysis system◈CAIDA’s Ocxmon, TCPDUMP, Ethereal, Sprint’s IPMon

▣Flow-based traffic analysis system◈Cisco’s NetFlow, CAIDA’s CoralReef, Flowscan, Netramet

▣Application-aware traffic analysis system◈Cisco’s NBAR, IDSes, Mmdump, SM-MON

▣Shortcomings◈ precise categorization is not achievable ◈ statistical analysis result is not satisfactory◈ lack adaptability and extensibility

There have been many research and development efforts in the field of traffic measurement and analysis for the past decade. As a result, many tools and hardware were introduced to meet various objectives such as traffic profiling, traffic engineering, attack/intrusion detection, QoS monitoring and usage-based accounting. CAIDA’s OCxmon [1], Tcpdump[2], Ethereal [3], and SPRINT’s IPMon [4] can be used to capture full packets and analyze them off-line for the purpose of various traffic profiling. They are per-packet analysis system.

Cisco’s Netflow [5], CAIDA’s CoralReef [6], Flowscan [7], and NetraMet [8] are flow-based traffic analysis system. They capture IP packet header information and compose them into flow records. Then various analysis tasks such as traffic profiling, usage-based accounting, and/or traffic engineering can be performed either on-line or off-line.

For the recognition of Internet applications, several efforts have been introduced. Most solutions are targeted for P2P or streaming applications identification or security anomaly detection. Cisco Systems’ NBAR (Network-Based Application Recognition) [9] provides basic application recognition facilities embedded in their Internet Operating System (IOS). Most intrusion detection systems (IDSes) are also equipped with basic application recognition modules which usually function on a signature matching-basis. For streaming and P2P application identification, Mmdump[10]and SM-MON[11] used payload inspection method. Many other methods for P2P traffic characterization [12,13] which depend on port number based matching were also published.

These systems exhibit shortcomings in that precise categorization is not achievable and statistical analysis result is not satisfactory. The biggest problem of the existing solutions, however, is that they lack adaptability and extensibility; when a new type’s of application arises, such systems must be re-written and re-installed partially or, in some cases, totally.

216

-4-

APNOMS2005

Key Concepts

▣Hardware Methodology◈No packet loss even in extreme situation◈Upper bound of CPU resource utilization◈Packet filtering, sampling and content inspection capabilities

▣Software Methodology◈Precise Application classification method◈Extensible application recognition language◈Flow definition extension and application detection automation for

content-aware precise application analysis

We have designed our hardware cards with more strict objectives to meet billing applications. For the billing accuracy, it is desirable not to loss any packets during measurements even for the worst case, that is, when the smallest possible packets come in back to back at the wire speed. In addition to this requirement, we have also considered the upper limit of CPU resource utilization. Since our card is a PCI card, it has to be placed in a system with PCI bus slot and share the CPU resource with other processes such as system processes and user application processes. If the card takes too much of the resource, the performance of the monitoring and/or analysis application can be degraded sharply. Our goal is to guarantee to consume it less than 30% in the worst case. In our Giga Ethernet card test, we verified that the card never exceeds 30% of the total CPU resource.

The novel mechanisms in our traffic measurement and analysis software consist of the following four items: general purpose Internet application traffic accounting, accuracy in application accounting, adaptability and expendability for newly emerging applications, and auto-detection mechanism of the new applications.

Most application monitoring systems currently available focus on a specific target such as P2P and/or streaming applications identification and security anomaly detection. Of course, there is an appropriate rationale for each effort. Our initial goal is the precise Internet application accounting for charging. Thus, we have put our efforts to come up with a general purpose Internet application identification methodology. Since we are using several novel methods which is described in details below to identify most of the well-known Internet applications, the accuracy of application traffic accounting is much higher in comparison with most other currently available monitoring applications which depend on port to application mapping. Since Internet applications lifecycle is very dynamic, it is very important to design the monitoring system to adapt such a characteristic. We added a run-time configuration language for such a purpose. When a new application appears in the Internet, we need to identify it promptly for its monitoring. Manual detection is very time-consuming and labor intensive work and thus requires automation.We are currently working on such automation and a preliminary result is explained below.

217

-5-

APNOMS2005

Hardware Methodology

For the no loss goal, we designed our cards to store the captured packets into kernel buffers called session buffers. We allow multiple session buffers for various applications to access them independently. The maximum size of the buffers for an one GigaEthernet card is 400 MByte which is the upper limit of a PCI memory size that a system with the card can allow. It can hold the backlog of the incoming packets in worst possible case. As long as a monitoring application is faster enough to fetch the packets in these buffers, the packet drop doesn’t occur. However, in real situation, any monitoring application at least has to process the packets such as header inspection, hashing, or flow generation, etc. If such processing is not faster enough to fetch a certain duration of traffic volume, packet drop happens to be occur. One good example case is when DoS attack with small packets happens for certain duration. Typical NIC or other dedicated cards are having hard time to handle such a case.

Besides these most strict requirements, our card has other value-added functionalities. For scalability purpose, we added packet filtering and sampling capabilities. It supports static, probabilistic, and flow sampling. And for precise application traffic recognition and anomalous traffic detection, we added content inspection capability in it. It supports up to 16 bytes payload searching.

We have developed a series of cards: DS-3, Fast Ethernet, OC-3 ATM/POS, OC-12 ATM/POS, and Giga Ethernet. We have conducted several performance tests and have concluded that PCI-based solution can be feasible upto 1 Giga Ethernet but a standalone device solution for OC-48 or above has to be considered to meet the strict requirements. It is in the scope of our future work due to the complexity and resources involved. Figure above illustrates our GigaEthernet Capture card.

218

-6-

APNOMS2005

Precise Internet Application Classification

▣ Type FP: Fixed Port-based Recognition Type◈ for an application which uses a well-known port number or which uses a

registered port number but is popularly used◈ Applications : WWW, FTP, SMTP, BGP, etc.

▣ Type PI: Payload Inspection-based Recognition Type◈ for an application which uses a registered port number but requires payload

inspections for precise classification

◈ Applications : HTTP_ALT(8080,8081,9000), MSNMessenger(6891-6900), KAZZA(1214), …

▣ Type DP: Dynamic Port-based Recognition Type◈ for an application which uses a dynamic port number assignment◈ Applications : Passive FTP, RTSP, Windows Streaming, …

▣ Type RR: Reverse Reference-based Recognition Type◈ for an application which uses a registered but requires comparison with a

correlated reverse flow for the precise classification◈ Applications : eDonkey down, WINMX down, GuruGuru BBS(9999)…

• Type-FP: Fixed Port-based Recognition TypeRecognition is performed on the basis of a predefined port number to application mapping. Major well known services, such as WWW, FTP, SMTP, BGP, etc., and comparatively popular applications using registered ports can be simply recognized by this method. There exists, however, a rather higher probability of misrecognition due to the current Internet applications characteristics as explained before.• Type-PI: Payload Inspection-based Recognition TypeRecognition is performed on the basis of both port numbers and signatures, a.k.a. patterns, in the application PDU (Payload Data Unit). This method produces an effect when two or more equivalently influential applications share a registered port number. Any well known services or popular applications can also be identified by this method if higher level of correctness assurance is required.• Type-DP: Dynamic Port-based Recognition TypeRecognition is performed on the basis of port numbers obtained by inspecting other flows’ payloads. In the sense of payload inspection, this method is similar to type-PI; however, the difference is that, in this type, the sought pattern provides a referential hint to identify another flow (a type-DP flow or an induced flow) that may take place soon after. One of the common type-DP flow examples is a passive mode FTP. In most cases, dynamic port allocation results in two or more induced flows. We, therefore, must maintain and refer the dynamic port information so that not only a single flow but a set of induced flows can be recognized, although most of the induced flows may be spread over a number of links and over a comparatively long period. Nevertheless, to keep an incidental flow from being recognized as an induced flow, we restrict it so that an induced flow can be appeared only between the original source and destination address pair of the inducing flow. • Type-RR: Reverse Reference-based Recognition TypeRecognition is performed on the basis of a referential note obtained by recognizing a type-PI flow on the other links. We define a reverse flow: When there exists a flow, X, of which <src_addr, dst_addr, src_port, dst_port, protocol> is <a, b, x, y, p>, if another flow, Y, is specified by (b, a, y, x, p), then Y is a reverse flow of X. The purpose of the type-RR method is, thus, to recognize reverse flows of type-PI flows. In most cases, type-RR flows are control flows of legitimate TCP connections whose constituting packets contain only IP and TCP headers or flows whose constituting packets do not contain any distinctive patterns in the payload

219

-7-

APNOMS2005

Application Recognition Configuration Language (ARCL)

application WWW {port_rep_name HTTP port 80 protocol TCP{ // FP type

decision_group HTTP_REQ_REP_ACK {src_port >= 1024dst_port == 80

}decision_group HTTP_REP_REQ_ACK {

src_port == 80dst_port >= 1024

}}

port_rep_name HTTP_ALT port 8080 protocol TCP{ // PI typesrc_disc_pattern=="HTTP" in pkt 0-2 at byte 0 - 4( dst_disc_pattern=="GET" in pkt 0-3 at byte 0 - 10 ||

dst_disc_pattern=="POST" in pkt 0-3 at byte 0 - 10 )decision_group HTTP_ALT_REQ_REP_ACK {

src_port >= 1024

dst_port == 8080 || dst_port == 8081 || dst_port == 9000}decision_group HTTP_ALT_REP_REQ_ACK {

src_port == 8080 || src_port == 8081 || src_port == 9000 dst_port >= 1024

}}

}

application EDONKEY { // RR typeport_rep_name EDONKEY_DOWN port 4662 protocol TCP{

dst_disc_pattern=="0xe33d000000" in pkt 2-3 at byte 0 - 4decision_group EDONKEY_DOWN_REQ_REP_ACK {

src_port >= 1024dst_port == 4662 ~ 4666 || 4242 || 4224 || 4660 || 5555

}decision_group EDONKEY_DOWN_REP_REQ_ACK {

src_port == 4662 ~ 4666 || 4242 || 4224 || 4660 || 5555dst_port >= 1024

}}……

}

application FTP { // DP typeport_rep_name FTP port 21 protocol TCP{

src_ref_pattern=="r/227 Entering Passive Mode ¥(¥d{1,3},¥d{1,3},¥d{1,3},¥d{1,3},(¥d{1,4}),(¥d{1,4})¥)/$src_port = atoi($1)*1024 + atoi($2)" in pkt any at byte 0-35 induce FTP_DOWN_P

decision_group FTP_REQ_REP_ACK {src_port >= 1024dst_port == 21

}decision_group FTP_REP_REQ_ACK {

src_port == 21dst_port >= 1024

}}

}

In the previous slide, we described how to categorize the Internet applications into a set of distinctive types. Another important issue is then how to actually capture and analyze the contents of packets based on the above classification criteria. This involves the development of a high performance packet capturing device, a software or hardwired filter which inspects the contents of packets and aggregates them into meaningful flow information, and server software which classifies them into the distinctive application types and analyzes their traffic usage. Considering highly dynamic nature of the development and the use of Internet applications, an adaptive and extensible content filter is essential component.

For this purpose, we propose an application recognition policy language, Application Recognition Configuration Language (ARCL), which succinctly describes the way to capture and analyze the contents of packets. The language is simple and effective in that the system can be swiftly reconfigured to detect and recognize unprecedented or modified applications without the developer’s writing and distributing extension modules for processing the newer applications, which usually results in fairly long period of shrunk recognition coverage even after detecting and analyzing the new applications.

Specifically, an ARCL specifies the following features:- The classes of applications into which each flow is categorized- The classes of subgroups of applications into which each packet of a flow is categorized- The methods and their parameters required to map flows to applications-The methods and their parameters required to map packets to subgroups

The overall ARCL specification described in BNF (Backus-Naur Form) is too bulky to be introduced in this paper; therefore, we show an example featuring most of the functionality of ARCL above. The boldfaced words are predefined keywords and user-defined proper names are in italics. The basic hierarchy of ARCL semantics and syntax possesses three levels. The highest category is an application (application), the next is a representative port (port_rep_name), and the last is a subgroup (decision_group). There is a one-to-many relationship between a higher and a lower category. The basic concept can be explained by this example: “HTTP flows are type-FP. HTTP_ALT flows can be recognized by type-PI in both directions; a flow of which source port or destination port is 8080 must be inspected with the corresponding patterns. The referential signature and the method to obtain a dynamic port are specified in the src_ref_pattern sentence. Passive FTP flows are type-DF and E-Donkey flows are type-RR.

220

-8-

APNOMS2005

Capture AgentCapture Agent

Analysis Server

Database

GUI

...

NIC IPCAPCard

...

NIC IPCAPCard

splitter

flow and packetrecords (NFS)

recognition and analysisresults (ODBC)

ARCLConfig-File

... ......

System Architecture and Implementation

We have incorporated the proposed mechanisms into our proof-of-concept system called WiseTrafView, whose main target application is usage-based accounting. Figure on the left side in the above slide shows a bird’s-eye view of the system. Capture Agent captures packets which are tapped and transferred to the Agent by an electronic or optical signal splitter. Upon receiving raw packets the Agent at first filters out non-IP packets. Then, by processing the remaining IP packets, the Agent composes flows and generates two types of records that compactly describe the flow and packet information respectively. TCP, UDP, and ICMP packets are properly handled during the flow generation process. Analysis Server, at first, classifies the flow and packet records into one of the four types on the basis of source and destination ports. The specific processing routines that result from instantiating the recognition methods classify candidate flows of each type to corresponding applications. Finally, by means of chain-based rule matching, each packet in a flow is further classifiedto subgroups of applications. The Server processes records transmitted from multiple Agents in a comprehensive way. A type-DP flow can take place on several independent links that are different from the link on which the inducing flow was monitored. A type-RR flow, likewise, can occur on a link other than the coupled reverse link of the original type-PI flow because of the asymmetricity of Internet routing. Considering these possibilities, the Server should keep the records from multiple Agents together. Recognition results are maintained in a database, and can be easily retrieved and represented by a GUI. In the meantime, an ARCL file configures the way the Agents and the Server operate in the all of the above processes.

Figure on the right side in the above slide shows a snapshot of our system GUI. On the left side, a particular link which is monitored is chosen. On the right side, a summary graph which represents eight top applications, a summary table which shows monitored period, total bytes, packets, average bandwidth, and traffic volume percentage of protocols, and applications detailed statistics are shown.

221

-9-

APNOMS2005

Performance Analysis

0

20

40

60

80

100

2 3 4 5 7 10 20 50 82 150

200

250

300

400

700

1200

1488

PPS(1000Packet Per Second), 60by te pkt s ize

Packet Loss(%

)

Intel Pro/1000 XF Server Adapter IPCAP GBE Capture Adapter

0

20

40

60

80

100

2 3 4 5 7 10 20 50 82 150

200

250

300

400

700

1200

1488

CPU

Usage(%

)

In this slide, we illustrated our capture card performance test result. We compared off-the-self NIC and our capture card. The former is Intel Pro/1000 XF server adapter and the latter is our GBE card. These cards are installed in the PC server system with the following specification: 2 Intel Xeon CPU 3.06GHz, 2 GB RAM, Linux RedHat 9.0, kernel 2.4.20-8. We used SMARTBITS to generate 60byte packets back to back for the worst-case performance testing. The test packets were generated for 30 seconds with constant PPS (Packets per Second) and we monitored packet loss rate and CPU utilization. Tcpdump and top utilities are used for the measurement.

In the case of Intel card, packet loss occurred after 4,000 pps and loss occurred after 400,000 pps for our card. In our card, the loss occurred because of the tcpdump packet handling bottleneck since it prints out information about each packet and stores them in a file. Our card processing performance is well advance that of tcpdump processing speed. Intel NIC consumes nearly 100% of CPU and discards almost all the packets at 200,000 pps. Meanwhile, our card has 75% packet loss ratio and 58% CPU utilization. Note that our card doesn’t discard any packets when it captures and doesn’t perform any further processing in worst case scenario although Intel NIC does it.

We also conducted comparison study with Netflow. Netflow uses an application port number to identify a specific application. Thus, the comparison between the two clearly illustrates the accuracy of application classification. One good example is “Passive FTP” case, where Netflow couldn’t measure any passive FTP traffic but ours precisely did. There are many other examples possible such as P2P and streaming applications. But due the space limitation, we couldn’t include the test details in this paper. The main purpose of this slide is to provide our hardware performance. Application classification accuracy is another issue.

222

-10-

APNOMS2005

Deployment Experiences

▣ CATR◈ Conformance Testing was successful

▣ CERNET (Chinese Research Network)◈ First Deployment on an operational

International Link◈ Proved the technology’s feasibility

▣ KISTI & KISDI (Korean Research Networks)◈ Verified usefulness on some

applications (e.g., detail traffic analysis and anomaly detection, etc.)

▣ KIX & Some Commercial ISPs◈ Provided accounting data for various

management purposes◈ E.g., detailed traffic patterns and

matrices

Inbound Traffic

Outbound Traffic

Tap Tap

Agent

Agent

Server

oversea

Domestic

We installed the system on the oversea point !!

The system has been installed and operated on a number of sites including a large scale campus network, a medium scale enterprise network (ETRINet), KISTI and KISDI (international links to Star-tap, USA and CERNET, China), KIX (one of the biggest public Internet exchange (IX) in Korea), and other ISPs in Korea.

A trial at CATR (China Academy of Telecommunications Research), which was our first attempt, performed conformance testing of our system’s hardware and software functionality. It tested FastEthernet, POS OC-3, and Giga Ethernet cards and analysis software for over six months. The test turned out to be successful. CATR agreed that our system is efficient, precise and economical.

In CERNET (China Education and Research NETwork), we tested our POS OC-3 system. The trial was conducted on a link between CERNET and NETCOM (one of major ISPs in China). The link was fully utilized with various Internet applications. We tested there for a week and analyzed Internet applications on that link successfully. With this trial, we verified our system’s commercial feasibility.

KISTI (Korea Institute of Science & Technology Information) and KISDI (Korea Information Strategy Development Institute) have many international connectivity for research purpose. Among them, we have tested our POS OC-3 and GBE systems on the links toward CERNET and Star tap. During this trial, we have verified usefulness on some Internet applications such as detail traffic analysis and anomaly detection, etc. We tested our systems for over six months respectively.

Lastly, we conducted our system evaluation in commercially operational networks such as KIX (Korea Internet eXchange) and some major ISPs in Korea. Through these trials, we provided accounting data for various management purposes such as detailed traffic patterns and matrices for heavily used peer-to-peer and multimedia applications to name a few.

In summary, it took more than one and half years all together. We fixed many bugs and improved the quality of our system throughout the trials. In general, we have verified the feasibility of our system at various environment. The figures on the right illustrates KISTI trial schematic and analyzed result of CATR trial.

223

-11-

APNOMS2005

Applicability

▣ Provisioning Application-specific Services◈ Traffic-based application classification functions should be combined with various traffic control

techniques

▣ Enhanced Network Management◈ Application-aware Routing/Traffic Engineering◈ Application-aware Filtering, Admission Control, Resource Allocation, etc.

▣ Security Surveillance◈ Network-based Security Surveillance

▣ General Contents Surveillance◈ Copy-righted Contents Transmission Detection / Noxious Contents Containment

▣ Advanced Accounting◈ Usage-based Accounting◈ Content-based Accounting◈ Beneficiary Accounting

Besides applying our system for content-aware usage based accounting for billing, it can be utilized for many other purposes such as provisioning application-specific services, enhanced network management, network-based security surveillance, general contents surveillance, and advanced accounting.

With precise application classification capability, application specific provisioning such as per-application QoS control is possible. There are some off-the-self QoS control and provisioning solutions but most of them simply relies on port-based application recognition. And it is normally deployed at the demarcation point between enterprise network and ISP network. In the backbone or Internet exchange point, its usage can be very constraint. Thus, our system’s methodology can be used to enhance such a limitation.

Our system can be used to enhance network management tasks such as application-aware routing, traffic engineering, filtering, admission control, and resource allocation. This capability will provide great flexibility to the network managers.

Network-based and content surveillance is also possible. IDS or IPS is typically used to achieve such objectives but like QoS provisioning system, mostly its functionality is limited at enterprise networks. However, network-wide security surveillance is becoming more and more important. This requires a general solution besides simple content inspection.

Lastly, our system can be utilized for advanced accounting. Simple packet or byte counting can’t be useful for accurate accounting. Content-aware usage accounting and its beneficiary relationship identification is essential for precise accounting and charging.

224

-12-

APNOMS2005

Summary and Future Work

▣ Proposed novel mechanisms to cope with high-speed and volume traffic monitoring and precise Internet applications usage accounting challenges

▣ Realized a proof-of-concept system with real operational network deployments

▣ To decrease the portion of unidentified applications traffic volume as much as possible

▣ Under development of an automated application pattern detection tool▣ Very High-speed Traffic Measurement System such as OC-48 or above

References[1] CIADA’s OCxMon, http://www.caida.org/tools/.[2] TCPDUMP, http://sourceforge.net/projects/tcpdump/. [3] Ethereal, http://www.ethereal.com/.[4] Sprint ATL, "IP Monitoring Project,“ http://www.sprintlabs.com/Department/IP-Interworking/Monitor/.[5] http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm.[6] K. Keys, D. Moore, Y. Koga, E. Lagache, M. Tesch, and K. Claffy, "The Architecture of CoralReef: An

Internet Traffic Monitoring Software Suite," Proc. of Passive and Active Measurement Workshop 2001, Amsterdam, Netherlands, April 2001.

[7] D. Plonka, Flowscan: A network traffic flow reporting and visualization tool. In Proceedings of USENIX LISA, 2000.

[8] NetTraMet, http://www.caida.org/tools/measurement/netramet/[9] NBAR, http://www.cisco.com/warp/public/732/Tech/qos/nbar/[10] Jacobus van der Merwe, Ramon Caceres, Yang-hua Chu, and Cormac Sreenan “mmdump- A Tool for

Monitoring Internet Multimedia Traffic,” ACM Computer Communication Review, 30(4), October 2000.[11] Hun-Jeong Kang, Myung-Sup Kim and James Won-Ki Hong, "A Method on Multimedia Service Traffic

Monitoring and Analysis", Lecture Notes in Computer Science 2867, Edited by Marcus Brunner, Alexander Keller, 14th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM 2003), Heidelberg, Germany, October, 2003, pp. 93-105.

[12] Subhabrata Sen and Jia Wang, "Analyzing peer-to-peer traffic across large networks", in Proceedings of the second ACM SIGCOMM Workshop on Internet Measurement Workshop, Nov. 2002.

[13] Alexandre Gerber, Joseph Houle, Han Nguyen, Matthew Roughan, and Subhabrata Sen, "P2P The Gorilla in the Cable", National Cable & Telecommunications Association (NCTA) 2003 National Show, Chicago, IL, June 8-11, 2003.

We proposed novel mechanisms to cope with high-speed and volume traffic monitoring and precise Internet applications usage accounting challenges and realized a proof-of-concept system with real operational network deployments. We showed the feasibility of our ideas and conducting the research to improve scalability and performance. Our current development is upto 1 Gbpsspeed and needs further efforts to handle 2.5 Gbps or higher. And our initial application was usage-based accounting. We are currently working on other applications such as security anomaly detection, traffic engineering, and QoS monitoring.

225