1. On the processing time for detection of Skype traffic P.M. Santiago del Río, J. Ramos, J.L. García-Dorado, J. Aracil Universidad Autónoma de Madrid A. Cuadra-Sánchez, M. Cutanda-Rodríguez Indra Sistemas International Workshop on TRaffic Analysis and Classification TRAC 2011 Istanbul July, 7th 2011

2. 1 Contents  Introduction.  Skypeness.  Performance Evaluation.  Conclusion and Future work. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

3. 2 Contents  Introduction. Detecting Skype. Motivation.  Skypeness.  Performance Evaluation.  Conclusion and Future work. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

4. 3 How to detect Skype traffic?  Skype: Proprietary, obfuscated and encrypted protocol. Random ports. UDP packets (TCP only used in presence of UDP-restricted firewalls).  Traffic Classification Techniques: Port numbers: –Not valid (random port numbers). DPI: –Computationally expensive (payload inspection). –Insufficient accuracy (encrypted content). Machine-learning: –Sufficient accuracy. –Sufficient performance (from a computational viewpoint) On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

5. 4 Motivation  Why detect Skype traffic? Popularity: –Users (increasing thanks to mobile smartphones). –Profits. Security reasons: –Lawful interception. –e.g. EU directive 2006/24/EC. Quality of Service (QoS). Billing/accounting and restrictions. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

6. 5 Motivation  Why so fast? Increase in data transmissions speeds: –10 Gb/s (and even faster…). –A lot of sorts of traffic. Current traffic classifications applications: –Accuracy: –Processing speed: On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

7. 6 Motivation  Why in commodity hardware? Alternative to specialized hardware (e.g. FPGAs): –Less flexibility. –More cost. Low-cost integration and minimal interference with current infrastructure. Good performance and limited cost. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

8. 7 Contents  Motivation.  Skypeness. Detector Fundamentals HW & SW Architecture  Performance Evaluation.  Conclusion and Future work. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

9. 8 Skypeness  Goals: 1.Accurate 2.Fast 3.Cheap On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

10. 9 Detector Fundamentals  Based on Tstat Skype classifier: Packet length. Interrarival times. Bit rate. Chi Square Test (packet payload inspection required)  UDP packets. TCP only used in presence of UDP-restricted firewalls.  Smooth data (moving average). On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

11. 10 Detector Fundamentals  Detection algorithm: Proportion of packet windows whose mean packet size/inter-arrival/bit-rate are inside the valid intervals. If these proportions are greater than the threshold, the flow is marked as Skype. Ground-truth obtained in several scenarios (wired and wireless, real and emulated networks conditions, etc). Thresholds values optimized with C4.5 trees. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th CharacteristicIntervalThreshold Packet size [Bytes][30,200]0.75 Interarrival [ms][i n-1 ±15]0.6 Bit rate [Kb/s][0,150]0.75

12. 11 Software Architecture  3 modules: Capturing and parsing packets. Creating and updating flows. Detecting Skype.  Modular architecture: Provides flexibility. Makes possible adding other tests. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

13. 12 Software Architecture  Capturing module details: Raw socket and mmap functions to map NIC receive queues at user-space. Parse IP/TCP-UDP headers, obtaining: – 5-tuple (IP src/dst, port src/dst, transport protocol). –Packet size –Arrival timestamp  Flow-builder module details: Unidirectional flows. Hash-based table. Pre-allocated memory pool. Sorted. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

14. 13 Hardware Architecture  Commodity hardware: 4 AMD Opteron processors. 32x4 GB DDR3 memory. Intel 10 Gigabit NIC: –Multiqueue Tx and Rx (up to 16 per interface). On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

15. 14 Hardware Architecture  NUMA: Non Uniform Memory Access Memory split in several groups. The lower the distance, the higher the performance.  Ubuntu Server 10.04 64 bits, 2.6.35 kernel On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

16. 15 Contents  Motivation.  Skypeness.  Performance Evaluation. Accuracy results. Processing performance results.  Conclusion and Future work. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

17. 16 Accuracy results  Using 3 traces: T1 and T2: from 96-hour of only Skype traffic (PoliTo). T3: Synthetic P2P (and no Skype) traffic (UAM). On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th TraceSkypeOtherFP(%)FN(%) T1 Bytes~8GB0-0.41 Packets~40M0-0.79 Flows~1K0-11.33 T2 Bytes~230M0-5.88 Packets~3M0-6 Flows~1600-6.29 T3 Bytes0~1GB0- Packets0~5.3K0- Flows0~500-

18. 17 Processing performance results  Receiving real traffic: Variable rate (100 Mb/s … 1 Gb/s). Tcpreplay limitation to 1 Gb/s. 1 Rx queue and 1 Skypeness instance: –Only using 2 cores: 1 for receiving and 1 for detecting. –Located in NUMA nodes 1 and 4 respectively (worst case in terms of distance). Using Trace 4: –3G real traffic. –~70M packets. –~12M TCP/UDP flows. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

19. 18 Processing performance results  Receiving real traffic: No packet loss at 1 Gb/s.  But… how about 10 Gb/s? On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th Bit rate [Mbps] Packet rate [Kpps] Max. Flow rate per second Total Packet Loss Rate 10030~26K0 25075~53K0 500150~90K0 750225~120K0 1000300~170K0

20. 19 Processing performance results  Assigning a Rx queue per socket: Up to16 Rx queues and 16 detecting processes.  Offline experiments: Read from memory (instead of from the NIC). –Bandwidth of DDR3: 170.6 Gb/s »Much greater than a backbone link. Skypeness instances and traces are located in memory as far as possible in terms of NUMA distance (worst case). On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

21. 20 Processing performance results  3.7 Gb/s a single instance.  45 Gb/s using 16 instances.  No perfect scaling due to serialized access to shared memory by NUMA. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

22. 21 Contents  Motivation.  Skypeness.  Performance Evaluation.  Conclusion and Future work. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

23. 22 Conclusion  Skypeness detects Skype traffic: With sufficient accuracy: –False negative rate of 6%. –False positive rate of zero. At high speed: –1Gb/s and up to 3.4 Gb/s per instance (from NIC and memory respectively). –Total throughput of 45 Gb/s with 16 instances. Using commodity hardware.  Feasibility of Skype traffic detection at high- speed networks (10-40 Gb/s) using commodity hardware. On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

24. 23 Future (and present) work  Capturing packets from a 10 Gb/s NIC: Using PacketShader capture engine.  Online experiments at 10 Gb/s  Apply methodology to other classes of traffic: –RTP (done!) –P2P other classification techniques: –DPI On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th

25. Thank you for your attention! Questions? On the processing time for detection of Skype traffic TRAC 2011 Istanbul, July 7th