create new tag
view all tags

NetScale Lab Blog

2014-05-29 - Prepping Our Next Paper

We are in the process of wrapping up an invited paper and were originally going to focus on the impact of probe requests from unaffiliated user elements (UEs, aka smartphones). The premise is fairly simple, smartphones tend to be aggressively tuned to pursue WiFi. One way in particular to make WiFi aggressive is to undergo frequent probe requests, aka is anyone out there? The use of a probe request will cause any APs (hidden or visible) to pipe up on a particular channel, thus allowing one to find WiFi faster versus simply waiting for the next beacon.

In short, the UE wakes up its WiFi adapter and rapidly scans the available WiFi space, 2.4 and 5 GHz for most devices (aka 802.11n). Issue a probe request (generic request, any AP), wait a small bit, hop to the next channel, rinse and repeat across all channels. Repeat the same thing for hidden APs (i.e. APs that do not broadcast via beacons and only respond to probe requests). If the UEs find a viable AP, the process stops and the UE proceeds to join the "trusted" or pre-known AP. Various UE software might also prompt the user to join the WiFi network if new APs are found.

While this process can speed up how fast you can find an AP, the flip side is that if there are no nearby APs that you can join, you keep issuing probe requests. When this occurs for only a few smartphones at home, this is not a big deal. However, imagine a dense environment where you have tens, hundreds, or even thousands of WiF devices doing this. Imagine say a stadium environment where you have thousands of APs whose WiFi range overlaps a small WiFi deployment. During scans in the 2.4 range that have plenty of overlapping channels (only 3 orthogonal ones at 1, 6, 11), not only do direct probe requests impact performance but also, probe requests on overlapping channels can also impact performance. The impact is reduced in the 5 GHz band due to there being more channels with less overlap but the problem still remains.

We have done some preliminary explorations on the impact in the 2.4 band via a few older 802.11g routers that we had. Unfortunately, we did not have a chance yet to run the experiments across 802.11n or 802.11ac APs to verify our results. As the impact could vary considerably, we ended up spiking that topic temporarily (saving it for later in the summer).

Hence, we are pivoting on a paper which has come along nicely drawing in particular on the effect of WiFi quality, namely that of the WiFi chipset / configuration on the handset. An overlooked notion for WiFi is the quality of the reception, i.e. how good is the antenna / chipset at the UE? For high end smartphones, we have seen a consistent march towards better quality where now quality is starting to match that of laptops and tablets. For the lower end smartphones, this is a bit more of a problem as cheapening the WiFi is one way to save money on a handset. As our CellNet paper back in 2012 had shown, this can be problematic resulting in flipped curves whereby cellular exceeds WiFi. Our paper is focusing on that particular interplay, exploring how taking the same students from the cohort in the NetSense study and giving them phones with better WiFi (the campus WiFi remained largely unchanged) results in dramatically different WiFi consumption, approaching if not exceeding the two-thirds estimates from prior works. The most interesting part is that consumption tended to continue unabated when on LTE which was quite fascinating.

Hopefully we can toss up an arXiV link soon with the paper as well as a few d3js graphs to show off several of the results that Shu had cooked up before she graduated.

2014-06-26 - FMNC Server - It's Alive!

Finally, success on getting the FMNC back end to start working. While I had done a fair amount of work a while back with our RIPPS project that involved TCP payload rearrangement, it has been a while since I have been working with our ScaleBox code base. The issue in particular I had been wrestling was the TCP header construction for the out of order packet delivery, particularly following the three-way handshake and the first data packet from the client (ex. say a web client).

The TCP three-way handshake is fairly well defined:

  • The client sends a TCP packet with the SYN flag set and an initial sequence number of X. This is the Initial Sequence Number (ISN) for the client.
  • The server responds with a packet with the TCP packet with the SYN and ACK flags set (aka the SYN-ACK). The ISN for the server is denoted by Y which is sequence number for the newly responded packet. The Acknowledgment Number is set as X+1.
  • The client then respond with a pure ACK (typically) with the Acknowledgment Number set to Y+1. While it is technically possible to include data in that third part of the three-way handshake, most of the time it is a pure ACK. A "pure ACK" is a packet whose sole responsibility is to ACK a received packet which is denoted by a packet that contains a zero byte TCP payload.

From there, it is off to the data races. My client for this case had been curl as I was mimicking a web request. The issue that I had was that despite the fact that I sent a pure ACK back from my FMNC server to the Mac OS X client, my subsequent data packets were not being received correctly. I banged my head against this issue for a day as I was trying to figure out what was going on. The debug richness for the FMNC server and packet sending in ScaleBox got a considerable boost while trying to figure what was happening.

Well, after running things through Wireshark (which by the way does not detect this) and making my eyes go bonkers comparing various hex symbols, I thought, hey, why not just force the ACK flag and put in a good ACK even if we aren't really ACK'ing anything of importance. My muddled thinking was that why should I set the ACK if I am not ACK'ing anything, lest I convey / trigger Fast Retransmit (ACK with the same number three times in a row, trigger a quick retransmission) since the Fast Retransmit hat is what we are basing part of FMNC on via TCP Sting. Of course, had I bothered to dive a bit deeper into the standard rather than working from how I thought it should work, I would have seen that yes of course, the ACK flag needs to be set on all packets post-SYN. One minor tweak later and voila, tcpdump no longer grumps about sequence number marking and curl is a happy camper. facepalm.jpg

I did learn a few interesting things:

  • Evidently Wireshark thinks that if you don't have the ACK bit set, your ACK value should be zero. Would have been really nice for it to flag and note that any packet post-SYN for a TCP session should have its ACK flag set.
  • The -vvv option when doing a write to disk via the -w option for tcpdump tells you how many packets you have captured. Cool.
  • tcpdump was smart enough to figure out that I was hosing things up (not doing relative sequencing) but inconveniently would not point out where I was messing up. I was about an hour or so away from opening up the tcpdump source code on relative sequence number computations.

You are welcome to live on the bleeding edge with ScaleBox and can grab Subversion access for download here.

Look for some early results next week hopefully with some spiffy d3js graphs.

2014-06-26 - created by Aaron Striegel

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | More topic actions
Topic revision: r1 - 2014-05-29 - AaronStriegel
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback