1. Sungwon Yi, Xidong Deng, George Kesidis, and Chita R. Das Department of Computer Science and Engineering, The Pennsylvania State University Abstract Introduction Motivation In addition to unresponsive UDP traffic, aggressive TCP flows pose a serious challenge to congestion control and stability of the Internet. This paper considers the problem of dealing with such unresponsive TCP sessions that collectively constitute a Denial-of-Service (DoS) attack on conforming TCP sessions. We propose to use the recently proposed HaTCh scheme along with a small Content Addressable Memory (CAM) to dynamically detect and quarantine the unresponsive TCP flows in order to provide fair service to the conforming TCP users. The proposed scheme, called HaDQ, is based on HaTCh, which accurately estimates the number of active flows without maintenance of per-flow state. For sampling and detecting the high bandwidth flows, we exploit the advantage of a smaller, first-level cache of HaTCh since it isolates the aggressive, high-bandwidth flows from the rest. The high- bandwidth flows from the smaller cache are then moved to the quarantine memory and monitored to compute a fair drop probability. Simulation-based performance analysis indicates that by using a proper configuration of the monitoring period and the detection threshold, the proposed scheme can achieve a low false drop rate (false positives) of less than 0.1%. Most importantly, comparison with two prior schemes (CHOKe and FRED), which were proposed for handling unresponsive UDP flows, shows that HaDQ is more effective in penalizing the bandwidth attackers and enforcing fairness between conforming and aggressive TCP flows. The unresponsive flows pose a serious challenge to Internet congestion control. Most of these unresponsive flows are UDP applications, which unlike their TCP counterpart, do not respond to network congestion. Thus, UDP flows can effectively shut out the responsive TCP flows by occupying almost the entire bandwidth and can ultimately lead to congestion collapse. Although several Active Queue Management (AQM) schemes has been proposed to handle the congestion, the effectiveness of these schemes still heavily relies on the voluntary use of the congestion control mechanism by the end-users. In addition to the UDPflows, TCP congestion control is vulnerable to the greedy users wishing to accelerate their download rates. Individual users can easily compromise TCP congestion control by deactivating or bypassing the slow-start in their work-station's TCP/IP stack or by spawning multiple parallel TCP sessions, a technique known as turbo- TCP. We view such activities by end-users as malicious denial-of-service (DoS) to the population of standard TCP users. In the future, this activity is likely to spread and will pose a serous security concern. This paper presents a novel mechanism that dynamically detects, quarantines, and penalizes unresponsive TCP flows. Conclusions The proposed HaDQ scheme uses the hit count of L1 cache (in HaTCh) to dynamically detect and quarantine unresponsive flows (minimize per-flow state), estimates the fair sharing of available bandwidth (C/N) to identify the unresponsive flows, and enforces fair sharing of the available bandwidth between responsive and unresponsive flows. We are currently working on a WORM defense mechanism based on HaDQ. Detection Capability: Why HaTCh? In Figures 4 (a) and (b), FRED showed slightly better protection of the standard TCP flows compared to CHOKe, but both the schemes failed to sufficiently penalize the unresponsive TCP flow. Under FRED, the single unresponsive TCP flow occupied 13% and 11% of the total bandwidth; these numbers significantly increased to 39% and 31%, respectively, under CHOKe. On the other hand, HaDQ precisely activated the punitive measures against the unresponsive TCP flow and enforced fair sharing of the available bandwidth in both cases. In Figures 4 (c) and (d), we added an UDP flow, whose injection rate is 16 times the fair sharing of the available bandwidth assuming that all the traffic is multiplexed in a queue. Under CHOKe and FRED, the UDP and unresponsive TCP flows again consumed significant amount of bandwidth, whereas HaDQ effectively enforced the fair bandwidth sharing. Traffic Mix Tail-Drop (Mbs) ARED (Mbs) 500 Standard TCPs 1 TCP w/o WC 0.087 1.342 0.087 1.147 500 Standard TCPs 1 TCP w/o WC & RTO 0.078 5.620 0.039 25.138 1000 Standard TCPs 1 TCP w/o WC 0.044 0.271 0.044 0.790 1000 Standard TCPs 1 TCP w/o WC & RTO 0.041 3.502 0.027 16.689 Conforming Flows Quarantined Flows (Not Identified) Quarantined Flows Search Quarantine Memory HaTCh L1 L2 Cache Calculate Drop Probability Drop Packet FIFO Queue P flow > 0 Arriving Packet Found YES NO NOT Found (a) 500 Conforming TCPs and 1 Unresponsive TCP and 1 Unresponsive TCP (b) 1000 Conforming TCPs and 1 Unresponsive TCP and 1 Unresponsive TCP (c) 500 Conforming TCPs, 25 UDP, and 25 UDP, and 1 Unresponsive TCP 1 Unresponsive TCP (d) 1000 Conforming TCPs, 50 UDPs, and 50 UDPs, and 1 Unresponsive TCP 1 Unresponsive TCP Figure 4: Throughput Comparison of CHOKe, FRED, and HaDQ Figure 3: Average Hit Count  Detection (Sampling) Mechanisms Mechanisms  Classical Sampling - require longer time - require longer time  MULTOPS - require precise traffic statistics - require precise traffic statistics  RED-PD - Drop history grows O(N) - Drop history grows O(N)  SRED In Figure 3, the average hit count of each flow with SRED showed a similar value regardless of the packet injection rate. On the other hand, the average hit count in HaTCh clearly increased as the packet injection rate increased. Simulation Results Figure 2: HaDQ Design and Control Flow Modern routers can easily discriminate between UDP and TCP packets. Thus, UDP can be effectively isolated from the TCP flows by diverting them to a small dedicated queue. * WC: Window Control, RTO: Retransmission Timeout  TCP/UDP Management  Unresponsive Flows  [INFOCOM03, Towsley] – impact of unresponsive flows on AQM performance flows on AQM performance  [ToN99, Floyd] – how unresponsive flows can cause fairness problem and congestion collapse fairness problem and congestion collapse  Impact of Single Unresponsive TCP (a) Packet Injection Rate (b) Average Hit Count  Dynamic Quarantine (DQ)  DQ mechanism is based on hit count associated with entries of L1 cache entries of L1 cache TCP sessions whose hit counts exceed a threshold TCP sessions whose hit counts exceed a threshold will be “quarantined” in CAM. will be “quarantined” in CAM. Threshold is based on the TM device’s additional Threshold is based on the TM device’s additional processing ability for quarantined-but-not-yet-punished processing ability for quarantined-but-not-yet-punished flows. flows. To minimize false positives, actual bit rates of quarantined sessions are estimated by TM device. To minimize false positives, actual bit rates of quarantined sessions are estimated by TM device. Punitive measures applied to sessions based on Punitive measures applied to sessions based on the fair share (C/N) of the link bandwidth. the fair share (C/N) of the link bandwidth.  Note that turbo-TCP can be handled by HaDQ since all threads have the same session id. (Src-Dst address pair) HaDQ (HaTCh-based Dynamic Quarantine) Figure 1: HaTCh Architecture  SRED  In HaTCh [CDC03], we  proved the consistency of the SRED estimator  developed a more robust and accurate dual-cache (RAM) mechanism, called Hash-based Two-level caChe (HaTCh) called Hash-based Two-level caChe (HaTCh)  Under HaTCh, high bandwidth flows are isolated from L2 cache resulting in higher hit count in L1 cache in higher hit count in L1 cache  statistically estimated the number of active flows using a small memory, called zombie list (flow id, hit count) memory, called zombie list (flow id, hit count)  used this number in indicating the severity of congestion HaTCh ☞ Partial solution for UDP problem!!! Need for a router mechanism  How to minimize per-flow state ?  How to identify unresponsive flows ?  How should a router react ? CHALLENGES in handling unresponsive flows Dynamic Quarantine of Unresponsive TCP Sessions