a traditional tool, NetADHICT would show that traffic is up, that itis HTTP, and when the surge in traffic started and if and when it ended.NetADHICT's other behavior would differ based on how long the flash crowdremains. If it is much shorter than the maturation period, then the flashcrowd would be contained in the terminal nodes. These would likely bedominated by HTTP and the administrator would have to refer to the webserver's logs for more information. If the flash crowd remained longer thanthe maturation period, though, NetADHICT would begin segregating traffic,searching for commonalities in the packets of the flash crowd. If the flash crowd were from a particular network with a common prefix,NetADHICT might recognize it by specifying the address in the created(p,n)-grams. Or, it might find (p,n)-grams that matched other parts of theheader or even payload contents such as the requested URL. The key thing toremember is that NetADHICT will keep refining its classification of incomingpackets so long as certain nodes continue to receive more than their "fairshare" of packets, and so long as there exists (p,n)-grams that match asignificant fraction of a high traffic node's packets. The resulting cluster equations (encoded in the structure of the tree)would give the administrator more information than the traditional toolsbefore he dove into the web logs. Further, because NetADHICT can provideexemplars of the "new" packets, a network administrator would have asignificant head start in determining the precise characteristics and originof the flash crowd. Identifying P2P Traffic Peer-to-peer (P2P) traffic is in some ways similar to flash crowds. Thedifferences lie in that many P2P protocols are not well documented and manyactively try to evade traditional traffic classification. For example, manyBitTorrent clients now provide the option to encrypt their data so thatpayload inspection cannot identify the protocol [20]. In addition toencrypting its payload, BitTorrent does not use standard ports. Because ofthis, traditional tools often either cannot classify or mis-classify P2Ptraffic that use these evasion tactics. NetADHICT does not need to know about protocol structure, so it can bemore useful than traditional tools in such situations. In our evaluationexperiments [10] we found that ADHIC, when confronted with (unencrypted)BitTorrent as a new protocol, segregated the traffic into just two terminalclusters. These clusters corresponded to the UDP tracker packets and the TCPcontent packets. Thus, we believe that a network administrator, wheninvestigating a new high network volume application, would see one or a fewnodes with increased traffic. If the P2P session lasted several maturationperiods, NetADHICT would begin splitting those nodes, building a P2P dominatedsubtree. Other than the port-based color labeling, NetADHICT cannot classifytraffic, but it could provide a pcap file of P2P traffic withall other traffic filtered out for the administrator to investigate. NetADHICT application-level classifications are more robust than thoseproduced by traditional port-classifying tools. For example, suppose that aP2P client uses port 80 for its traffic. Traditional tools would likely mis-classify the new application traffic as HTTP. In experiments we have foundthat NetADHICT, because it often ignores ports, continues to cluster P2Ptraffic correctly even when clients use misleading ports [10]. Identifying Worm Traffic Finally, let us consider the case