WiPal: Efficient Offline Merging of IEEE 802.11 Traces

WiP al: Efficient Offline Mer ging of IEEE 802.11 T races Thomas Clav eirole LIP6/CNRS — UPMC Univ P ar is 06 thomas.cla veirole@lip6.fr Marcelo Dias de Amorim LIP6/CNRS — UPMC Univ P ar is 06 marcelo .amorim@lip6.fr ABSTRA CT Merging wireless traces is a fundamental step in measure- ment-based studies in volving multiple packet snif fers. Ex- isting merging tools either require a wired infrastructure or are limited in their usability . W e propose W iPal, an offline merging tool for IEEE 802.11 traces that has been designed to be efficient and simple to use. W iPal is flexible in the sense that it does not require any specific services, neither from monitors (like synchronization, access to a wired net- work, or embedding specific software) nor from its software en vironment (e.g., an SQL server). W e present WiP al’ s op- eration and show how its features — notably , its modular design — improve both ease of use and efficiency . Experi- ments on real traces show that WiP al is an order of magni- tude faster than other tools providing the same features. T o our knowledge, W iPal is the only offline trace merger that can be used by the research community in a straightforward fashion. 1. INTR ODUCTION Sniffing is a usual technique for monitoring wireless net w orks. It consists in spreading within some target area a num b er of monitors (or sniffers ) that capture all wireless traffic they hear and pro duce traces consisting of mac frame exc hanges. Wireless sniffing is a funda- men tal step in a num b er of net w ork op erations, includ- ing net work diagnosis [1], security enhancement [2], and b eha vioral analysis of proto cols [3, 4, 5, 6]. Wireless sniffing often in v olv es a centralized pro cess that is resp onsible for combining the traces [3, 4, 5]. The ob jectiv e is to ha v e a global view of the wireless activit y from multiple lo cal measuremen ts. Individual sniffers can also comp ensate for their frame losses with data from other sniffers. Merging is how ever a difficult task; it requires precise synchronization among traces (up to a few microseconds) and b earing the unreliable nature of the medium (frame loss is una v oidable). The literature has provided the communit y with a num b er of merging to ol, but they either require a wired infras- tructure or are too sp ecific to the experimentations con- ducted in the pap ers (see more details in Section 2) [3, 7, 8, 4]. In this paper w e present WiPal, an IEEE 802.11 trace merging to ol that fo cuses on ease-of-use, flexibility , and sp eed. By explaining WiPal’s design choices and inter- nals, w e in tend to complete existing papers and giv e additional insights ab out the complex pro cess of trace merging. WiPal has multiple characteristics that dis- tinguish it from the few other traces mergers: Offline to ol. Being an offline to ol enables WiPal to b e indep enden t of the monitors: one may use any soft w are to acquire data. Most trace mergers ex- p ect monitors to embed sp ecific softw are [3, 7]. Indep enden t of infrastructure. WiPal’s algorithms do not exp ect features from traces that w ould re- quire monitors to acces s a netw ork infrastructure (e.g., synchronization). Monitors just need to re- cord data in a compatible input format. Complian t with multiple formats. WiP al supp orts most of the existing input formats, whereas other trace mergers require a specific format. Some tools ev en require a custom dedicated format [3]. Hands-on to ol. WiPal is usable in a straightforw ard fashion by just calling the adequate programs on trace files. Other mergers require more complex setups (e.g., a database serv er [4] or a netw ork setup inv olving multiple servers [3].) This pap er pro vides an analysis that supp orts these c hoices (cf. Section 5). First, the prop osed sync hroniza- tion mec hanism exhibits b etter precision than existing algorithms. Second, WiP al is an order of magnitude faster than the other publicly av ailable offline merger, Wit [4]. This analysis uses CRA WD AD’s uw/sigcomm- 2004 dataset [9], recorded during the SIGCOMM 2004 conference. 1 It allows us to calibrate v arious parameters of WiPal, v alidate its op eration, and sho w its efficiency . WiP al is ho w ever not designed for a specific dataset and works on any wireless traces using the appropriate 1 T o the exten t of our kno wledge, this is the only one dataset that is b oth publicly av ailable and that provides enough data to p erform merging operations. 1 A. The traces are not synchronized and miss some frames. B. One iden tifies some reference frames common to b oth traces. This information enables trace syn- c hronization. C. One adjusts the frames’ timestamps and synchro- nize T 1 and T 2 . D. One can merge the traces. Duplicate frames are only accoun ted once. Figure 1: Merging tw o traces T 1 and T 2 . input format (WiPal’s test suite includes v arious syn- thetic traces with different formats). W e do believe that WiP al will b e of great utility for the researc h comm u- nit y working on wireless netw ork measurements. 2. TRA CE MERGING: O VER VIEW Wireless sniffing requires the use of multiple moni- tors for c over age and r e dundancy reasons. Co v erage is concerned when the distance b etw een the monitor and at least one of the transmitters to b e sniffed is to o large to ensure a minimum reception threshold. Redundancy is the consequence of the unreliability of the wireless medium. Even in go o d radio conditions monitors may miss successfully transmitted frames. After the collec- tion phase, traces must b e combined into one. A merged trace holds all the frames recorded b y the differen t mon- itors and giv es a global view of the netw ork traffic. The traditional approach to merging traces inv olves a synchr onization step, whic h aligns frames according to their timestamps. This enables iden tifying all frames that are identical in traces so that they appear once and only once in the output trace (Cheng et al [3] refer to it as unific ation .) This process is illustrated in Fig. 1. Sync hronization is difficult to obtain b ecause, in or- der to b e useful, it m ust b e very precise. Imprecise frame timestamps may result in duplicate frames and incorrect ordering in the output trace. An inv alid syn- c hronization ma y also lead to distinct frames accounted for the same frame in the output trace. In order to av oid suc h undesirable effects one needs precision of less than 106 µs [5]. T o the extent of our knowledge, no existing hardw are supp orts synchronizing netw ork cards’ clo cks with suc h a precision (note that we are in terested in frame arriv al times in the card, not in the op erating system). Therefore, all merging to ols p ost-pro cess traces to r esynchr onize them with the help of r efer enc e fr ames , whic h are frames that appear in multiple traces. One ma y readjust the traces’ timing information using the timestamps of the reference frames (see Fig. 1.) Finding reference frames is ho w ever a hard task, since we must b e sure a given reference frame is an o ccurrence of the same frame in every traces. That is, some frames that o ccur frequen tly (e.g., mac ackno wledgements) cannot b e used as reference frames b ecause their conten t do es not v ary enough. Therefore, only a subset of frames are used as reference frames, as explained later in this pap er (cf. Section 4). A few trace merging to ols exist in the literature, but they do not fo cus on the same set of features as this pa- p er. F or instance, Jigsa w [3] is able to merge traces from h undreds of monitors, but requires monitors to access a netw ork infrastructure. WisMon [7] is an online to ol that has similar requirements. This pap er how ever con- siders smaller-scale systems (dozens of monitors) but where no monitor can access a netw ork infrastructure. Another system close to ours is Wit [8, 4]. Despite Wit pro vides v aluable insights on how to develop a merging to ol, it is difficult to use, mo dify , and extend in prac- tice (cf. authors’ note in CRA WDAD [8]). Thus our motiv ation to prop ose a new trace merger. Note that this pap er only refers to Wit’s merging pro cess (as Wit has other features lik e, e.g., a mo dule to infer missing pac k ets ). 3. WiP al’S BASICS WiP al has b een designed according to the follo wing constrain ts: No wired connectivit y . The sniffers must b e able to w ork in environmen ts where no wired connectiv- it y is pro vided. This enables p erforming measure- men ts when it is difficult to ha ve all sniffers access a shared net work infrastructure (e.g., in some con- ference v enues, or when studying interferences b e- t w ee n tw o wireless netw orks b elonging to distinct en tities). Simplicit y to the end-user. W e b eliev e simplicit y is the k ey to re-usability . Users are not exp ected to install and set up complex systems (e.g., a data- base back end) in order to use WiPal. Clean design. WiPal exhibits a mo dular design. De- v elop ers can easily adapt part of the trace merger (e.g., the reference frames identification pro cess, the synchronization, or merging algorithm.) 2 Figure 2: WiP al’s o verall structure. F or these reasons, w e opted for an offline trace merger that do es not require that traces b e synchronized a pri- ori. Concretely , the sniffers only hav e to record their measuremen ts on a lo cal storage device, using the wide- ly used PCAP (P ack et CAPture) file format. WiPal comes as a set of binaries to manipulate wireless traces, including the merging tool presented in this pap er. It w orks directly on PCAP files b oth as input and out- put. WiP al is comp osed of roughly 10k lines of C++ and makes heavy usage of modern generic and static programming tec hniques. WiPal is downloadable from http://wipal.lip6.fr . 4. WiP al’S DET AILED OPERA TION Fig. 2 depicts WiP al’s structure. Eac h box represents a distinct mo dule and arrows sho w WiP al’s data flow. WiP al takes tw o wireless traces as input and pro duces a single merged trace. 2 In the following, we explain in detail the functioning of each one of the mo dules. 4.1 Identifying refer ence frames This section explains the pro cess of extracting refer- ence frames. This op eration inv olves tw o steps: extrac- tion of unique frames and intersection of unique frames (see Fig. 2.) Let us first define what a unique frame means. A frame is said to b e unique when it app ears “in the air” 2 In order to merge more than tw o traces, it suffices to ex- ecute the merging to ol as many times as required (t wo b y t wo). once and only once for the whole duration of the mea- suremen t. A frame that is unique within eac h trace but that actually app eared twice on the wireless medium should not be considered as unique. The pro cess of extracting unique frames finds candi- dates to b ecome reference frames. The pro cess of inter- secting unique frames identifies then identical unique frames from both traces to b ecome reference frames. 4.2 Extraction of unique frames WiP al consider ev ery b eacon frame and non-retrans- mitted prob e resp onse as a unique frame. These are managemen t frames that access p oints send on a regu- lar basis (e.g., every 100 ms for b eacon frames). The uniqueness of these frames is due to the 64-bit times- tamps they embed (these timestamps are not related to the actual timestamps used for synchronization). In practice, the extraction process do es not load full frames into memory . It uses 16-b yte hashes instead, whic h are stored in memory and used for comparisons. Limiting the size of stored information is an imp ortant asp ect since, as we will see later, WiPal’s in tersection pro cess p erforms a lot of comparisons and needs to store man y unique frames in memory . T ests with CRA W- D AD’s uw/sigcomm2004 dataset [9] ha ve sho wn that this tec hnique is practical. Concretely , WiP al needs less than 600 MB to load 7,700,000 unique frames. There are some rare cases where the assumption that b eacons and prob e resp onses are unique do es not hold. The u w/sigcomm2004 dataset has a total num b er of 50,375,921 unique frames (ab out 14% of 364,081,644 frames). Among those frames, we detected 5 collisions (distinct unique frames sharing identical hashes.) Wi- P al’s in tersection process includes a filtering mechanism to detect and filter such collisions out. 4.3 Intersection The intersection pro cess intersects the sets of unique frames from both input traces. There are m ultiple algo- rithms to p erform such a task. Based on Cheng et al. [3], a solution is to “b o otstrap” the system by finding the first unique frame common to b oth traces and then use this reference frame as a basis for the synchronization mec hanism, as sho wn in Algorithm 1. One may also use subsequent reference frames to up date synchroniza- tion. This algorithm is practical b ecause the inner lo op only searches a very limited subset of I 2 . It has several dra wbac ks though: (i) the performance of the algorithm strongly dep ends on the precision of the synchroniza- tion pro cess; (ii) finding the first reference frame is still an issue; (iii) this algorithm couples intersection with sync hronization, whic h is undesirable with resp ect to mo dularit y; and (iv) there is a possibility that some frames are read multiple times from I 2 . More sp ecifi- cally , access to I 2 is not sequen tial. 3 Algorithm 1 Intersection using synchronization. Input: tw o lists of unique frames I 1 and I 2 . Output: a list of reference frames. δ ← synchronization precision for all u 1 ∈ I 1 do t u 1 ← u 1 ’s time of arriv al for all u 2 ∈ I 2 b et ween t u 1 − δ and t u 1 + δ do if u 2 is an o ccurrence of u 1 then App end ( u 1 , u 2 ) to output. end if end for end for Algorithm 2 WiPal’s intersection algorithm. Input: tw o lists of unique frames I 1 and I 2 . Output: a list of reference frames. h ← ∅ . Implemen t h with a hash table. for all u 1 ∈ I 1 do Insert u 1 in to h . end for for all u 2 ∈ I 2 do if h contains an o ccurrence u 1 of u 2 then App end ( u 1 , u 2 ) to output. end if end for WiP al includes an algorithm that is muc h simpler to implemen t and that av oids the dra wbacks of the ab o v e- men tioned solution. The main c haracteristics of the prop osed algorithm (detailed in Algorithm 2) are: (i) it do es not require a b o otstrapping phase; (ii) it do es not dep end on any kind of synchronization; and (iii) It sequen tially reads each frame only once from I 1 and I 2 . The algorithm starts by loading all unique frames of the first trace into memory . This precludes using it as an online to ol. Note that loading all unique frames from a trace into memory may hog resources; this jus- tifies the imp ortance of having small identifiers for the unique frames. These constrain ts are how ever negligible compared to those of Algorithm 1. T o support our argu- men t, let us show an example using the uw/sigcomm- 2004 dataset. The biggest traces are those from snif- fers mojave and sonor an on channel 11 (roughly 19 GB eac h.) Extracting these traces’ unique frames and in- tersecting them using WiPal needs 575 MB of memory . Therefore, memory aggressiveness is not a concern in Algorithm 2. Another adv an tage of Algorithm 2 is its ability to de- tect collisions of unique frames within the first trace. Collisions are detected by duplicate elements in h . Wi- P al detects such cases, memorizes collisions, and filter them out of the hash table b efore starting the algo- rithm’s second lo op. Of course, collisions in the second trace remain undetected. Ev en if WiPal detected them, there w ould still be the p ossibility that a collision spans across b oth traces (i.e., eac h trace con tains one occur- Figure 3: Av erage sync hronization error w.r.t. linear regression windo w size. rence of a colliding unique frame). Suc h cases lead to pro ducing in v alid reference frames. T o detect them, Wi- P al lo oks at p ossible anomalies w.r.t. the interarriv al times b et w een unique frames. In practice, inv alid ref- erences are rare: only three o ccurrences when merging u w/sigcomm2004’s c hannel 11 (a 73 GB input which pro duces a 22 GB output). 4.4 Synchronization Sync hronizing tw o traces means mapping trace one’s timestamps to v alues compatible with trace tw o’s. Wi- P al computes such a mapping with an affine function t 2 = a t 1 + b . It estimates a and b with the help of ref- erence frames as the pro cess runs. WiP al’s synchronization pro cess op erates on windows of w + 1 reference frames (finding an optimal v alue of w is discussed below). F or eac h reference frame R i , the pro cess p erforms a linear regression using refer- ence frames R i −b w/ 2 c , . . . , R i + d w/ 2 e . A t the b eginning and at the end of the trace, we use R 1 , . . . , R w and R N − w , . . . , R N ( N is the num b er of reference frames.) The result gives a and b for all frames b etw een R i and R i +1 . W e p erformed a n um b er of experiments that rev ealed that the optimal v alue for w is 2 (i.e., WiP al p erforms linear regressions on 3-frame windows). Fig. 3 shows the results of performing t w o merge op erations with v arying windo w sizes. The merges concern channel 11 of the sa- har a – chihuahuan and kalahari – mojave sniffers from u w/sigcomm2004. The av erage synchronization error is computed as follows. Consider only the subset S of frames that are shared by b oth the first and second trace T 1 and T 2 . F or a giv en frame f , let t f , 1 b e the arriv al time of f inside T 1 (after clock synchronization) and t f , 2 b e the arriv al time of f inside T 2 . The av erage syn- c hronization error is given by 1 | S | P f ∈ S | t f , 2 − t f , 1 | . As previously underlined, w = 2 leads to the minim um av- erage synchronization error. Note that tec hniques that use w = 1 (i.e., that p erforms linear in terp olations on couples of reference frames) w ould lead to the worst syn- c hronization error. F urthermore, merging traces with 4 Num b er of shared frames w = 1 w > 1 sahar a – chihuahuan 32,312,812 32,320,267 kalahari – mojave 840,143 840,227 T able 1: Num b er of frames found to b e shared b y b oth input traces when merging sahar a – chi- huahuan and kalahari – mojave with w = 1 and w > 1 (c hannel 11). w = 1 misses some shared frames. T able 1 sho ws the n um b er of frames that are iden tified as duplicates in the input traces. Whereas using w > 1 alwa ys gives iden ti- cal results, using w = 1 leads to some missed duplicates (7,455 for sahar a – chihuahuan and 84 for kalahari – mojave ). Although this is a small num b er compared to the total n umber of frames in the output traces, it indicates that sync hronizing traces using linear in terp o- lation (as Wit [8] do es) may lead to incorrect results. Unfortunately , it is difficult to know whether some du- plicates were missed when w > 1 (w e do not know which frames to expect as duplicates). 4.5 Merging W e now present how WiP al p erforms the final step, namely the merging pro cess itself. Its role is to copy frames from synchronized traces to the output trace. Of course, it m ust order its output correctly while av oiding duplicate frames. Algorithm 3 details WiPal’s merging algorithm. F or the sak e of illustration, we present here a simplified v er- sion that assumes that only one frame is emitted at a giv en time inside the monitoring area. It simultaneously iterates on b oth inputs, where each iteration adds the earliest input frame to the output (lines 15 and 16.) Duplicate frames are the ones that hav e identical con- ten ts and that are spaced less than 106 µs (line 11.) The rationale for this v alue is that 106 µs is half of the min- im um gap b etw een t w o v alid IEEE 802.11 frames [5]. Therefore, the appearance of identical frames during suc h an interv al is in fact a unique o ccurrence of the same frame . 5. EV ALU A TION This section provides an ev aluation of WiP al using CRA WD AD’s u w/sigcomm2004 dataset [9]. W e in ves- tigate b oth the correctness and the efficiency of WiPal. W e merge all traces sniffed from channel 11 and then use some heuristics to ev aluate the quality of the result. W e also analyze WiPal’s sp eed. T races from five sniffers comp ose the uw/sigcomm- 2004 dataset: chihuahuan , kalahari , mojave , sahar a , and sonor an . Fig. 4 sho ws the merging sequence w e used to merge all traces. The reason why kalahari and mojave share so few frames is that kalahari is an order Algorithm 3 WiPal’s merging algorithm. Input: tw o synchronized traces T 1 and T 2 . Output: the merge of T 1 and T 2 . 1: pro cedure Adv ance ( f : frame, T : trace) 2: App end f to output; f ← T ’s next frame (or nil ) 3: end pro cedure 4: f 1 ← T 1 ’s first frame; f 2 ← T 2 ’s first frame 5: while f 1 6 = nil or f 2 6 = nil do 6: if f 1 = nil then Adv ance ( f 2 , T 2 ) 7: else if f 2 = nil then Adv ance ( f 1 , T 1 ) 8: else 9: t f 1 ← f 1 ’s time of arriv al 10: t f 2 ← f 2 ’s time of arriv al 11: if f 1 = f 2 and | t f 1 − t f 2 | < 106 µs then 12: App end either f 1 or f 2 to output. 13: f 1 ← T 1 ’s next frame (or nil ) 14: f 2 ← T 2 ’s next frame (or nil ) 15: else if t f 1 < t f 2 then Adv ance ( f 1 , T 1 ) 16: else Adv ance ( f 2 , T 2 ) 17: end if 18: end if 19: end while of magnitude smaller than mojave . 5.1 Correctness Chec king the correctness of the output is difficult. Being able to test whether traces are correctly merged or not would b e equiv alen t to knowing exactly in ad- v ance what the merge should lo ok like. Unfortunately , there is no reference output against whic h w e could com- pare. Thus, w e prop ose several heuristics to chec k if WiP al in tro duces or not inconsistencies in its outputs. W e also c hec k WiP al’s correctness with a test-suite of syn thetic traces for which we know exactly what to ex- p ect as output. A brok en merging pro cess could lead to several incon- sistencies in the output traces. Regarding the u w/sig- comm2004 dataset, we in vestigate in particular tw o of those inconsistencies: duplicate unique frames and du- plicate data frames. Duplicate unique frames. As seen previously , every unique frame should only o ccur once in the traces (including merged traces). Y et, it is difficult to a v oid collisions in practice (see Section 4.2). Th us one should not consider all collisions as inconsis- tencies. When merging uw/sigcomm2004, the final trace has 5 collisions. W e manually v erified that they are not inconsistencies in tro duced b y WiPal’s merging pro cess. Duplicate data frames. W e search traces on a p er- sender basis for successive duplicate data frames (only considering non-retransmitted frames). Such cases should not occur in theory – without retrans- missions sequence num b ers should at least v ary . 5 Figure 4: Summary of u w/sigcomm2004’s merg- ing pro cess, c hannel 11. P ercentages indicate the num b er of frames that are shared b y par- en t traces. Bottom figures indicate the av erage sync hronization error. Surprisingly , traces from u w/sigcomm2004 contain 20,303 suc h anomalies. W e hav e no explanations wh y the dataset exhibits those phenomena. W e c hec k ed how ever that the merged trace do es not ha v e more duplicates than the original traces. 5.2 Efficiency Merging all the traces (73 GB) tak es ab out 2 hours and 20 minutes (real time) on a 3 GHz pro cessor with 2 GB RAM. W e balance merge op erations on tw o hard driv es, whose av erage throughput during computations are ab out 60 MB/s and 30 MB/s. The av erage CPU usage is 75%, which means one could p erform faster with faster hard drives (about 1 hour and 40 minutes). Comparing WiP al with online trace mergers does not mak e muc h sense: their mo de of op eration is different, and these also ha ve different requirements (e.g., wired connectivit y and lo ose sync hronization.) The compar- ison would b e unfair. W e can how ever compare Wi- P al with Wit [8], another offline merger. Wit works on top of a database back end, which means that trace files need to b e imp orted into a database b efore any further op eration can b egin (e.g., merging or inferring missing pac k e ts). Using the same machine as b efore, imp ort- ing channel 11 of uw/sigcomm2004 into Wit’s database tak es around 33 hours (user time). This means that, b efore Wit b egins its merge op erations, WiPal can p er- form at least 14 runs of a full merge with the same data. WiPal allows then tremendous sp eed improv e- men ts. One of the reasons for suc h a difference is WiP al uses high performance C++ code while Wit is just a set of Perl scripts using SQL to interact with a database. 6. CONCLUSION This pap er in tro duced the WiP al trace merger. As an offline merger, WiPal do es not require sniffers to b e sync hronized nor to hav e access to a wired infras- tructure. WiPal provides sev eral improv ements ov er existing equiv alent softw are: (i) it comes as a simple program able to manipulate trace files directly , instead of requiring a more complex softw are setup, (ii) its syn- c hronization algorithm offer b etter precision than the existing algorithms; and (iii) it has a clean mo dular de- sign. F urthermore, we also show ed WiPal is an order of magnitude faster than Wit [8], the other av ailable offline merger. W e hav e several plans for the future of WiPal. First, w e are currently extending it to include other features (b esides merging). As a flav or of future features of WiP al, it will p erform traffic statistics on IEEE 802.11 traces. W e will also make b etter use of WiP al’s mo d- ularit y and test other algorithms for the v arious stages of the merging op eration. 7. REFERENCES [1] Y.-C. Cheng, M. Afanasyev, P . V erk aik, P . Benk¨ o, J. Chiang, A. C. Sno eren, S. Sav age, and G. M. V o elker, “Automating cross-lay er diagnosis of en terprise wireless netw orks,” in SIGCOMM’07 . [2] P . Bahl, R. Chandra, J. Padh ye, L. Ravindranath, M. Singh, A. W olman, and B. Zill, “Enhancing the securit y of corp orate wi-fi netw orks using DAIR,” in MobiSys’06 . [3] Y.-C. Cheng, J. Bellardo, P . Benk¨ o, A. C. Sno eren, G. M. V o elker, and S. Sav age, “Jigsaw: solving the puzzle of en terprise 802.11 analysis,” in SIGCOMM’06 . [4] R. Maha jan, M. Ro drig, D. W etherall, and J. Zahorjan, “Analyzing the mac-level b ehavior of wireless netw orks in the wild,” in SIGCOMM’06 . [5] J. Y eo, M. Y oussef, and A. Agraw ala, “A framew ork for wireless lan monitoring and its applications,” in WiSe’04 . [6] A. P . Jardosh, K. N. Ramachandran, K. C. Almeroth, and E. M. Belding-Roy er, “Understanding congerstion in IEEE 802.11b wireless netw orks,” in IMC’05 . [7] D. Dujovne, “Wismon: A wireless net w ork statistical to ol,” T ech. Rep., 2006. [8] R. Maha jan, M. Ro drig, and J. Zahorjan, “CRA WD AD to ol to ols/analyze/802.11/wit (v. 2006-09-29),” Downloaded from http://cra wdad.cs. dartmouth.edu/to ols/analyze/802.11/Wit, Sept. 2006. [9] M. Ro drig, C. Reis, R. Maha jan, D. W etherall, J. Zahorjan, and E. Lazowsk a, “CRA WDAD data set uw/sigcomm2004 (v. 2006-10-17),” Downloaded from http: //cra wdad.cs.dartmouth.edu/u w/sigcomm2004, Oct. 2006. 6