From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BFE693B478 for ; Fri, 22 Apr 2016 02:44:47 -0400 (EDT) Received: by mail-lf0-x233.google.com with SMTP id g184so73727138lfb.3 for ; Thu, 21 Apr 2016 23:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JLaLubV08bnFMcJzWEjUKmbkkMfk4j4FArZQrqdHVy8=; b=BWC5J+dnuboHHl0PXXcXnXBAav1+NtOlbtZ5ZxbIxmQgLsIS0L2COMtV9Scbn72UJ1 m1q4xFrY0i0xiRNE9QfwMVPiBGePghGEDqjPLledIEHCx7/0KMnSnQhHgWAOjOXxJgDG BkK91733hOTdsehvnLI1KmECid1hTyE24ye9gP0IURaqUsaDJQGTGOjv7hCVJJvw2Suk HUZShyNSaTssNr4V5KQGk6iRS/PIckKOLzielKmIxzGysnuaCLKP7pXMrGNuDMRnrsiQ 08GKTVjgrCFQkJYv6QMXzX8X5KTeqzjMVRRzXtm8pw81E58rR2LpehCVgUrXGWhFmSVD mUCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JLaLubV08bnFMcJzWEjUKmbkkMfk4j4FArZQrqdHVy8=; b=F8g3QbnkeRV3cA4RUxFukKFWUeqHSDb+CR27iQuUVih0imqrTgEqQbwjWS3aaMXB1O gENFDmpqBqTOU72xboFDs0SnycAOqVhmXtGKuMVolbAcs4zZrOCTmzjP8pwZVcTfJgw2 InRqnWoqOm5xwmBRFBADYLSTsUVjHwV5Jngxc7U8kv21AT2hqTvkL4OicwO96iKPCcKS +G9I3E/n42qfqLSFFhsMJSHQE4IFN9R1guAx5Fvx/fsxki9+xCInm5+SeXPzJkB8EZJH AcadZOsHZkLFJDJ11Q1ZDz6DJ74BfW7Uni/JpCJeCj8K3cpz2lHqa9dJQqLJT41tVp3I 2MZA== X-Gm-Message-State: AOPr4FUxDqRJ4YhegO9RXC9O5UEg0EfKZkLWrTEKvOiIlovMe51vIGIqaITYurjNnLITvQUIOvoJDzuj6yK3lA== X-Received: by 10.25.131.147 with SMTP id f141mr8168536lfd.12.1461307486511; Thu, 21 Apr 2016 23:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.42 with HTTP; Thu, 21 Apr 2016 23:44:16 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 22 Apr 2016 08:44:16 +0200 Message-ID: To: David Lang Cc: Dave Taht , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] the hidden station problem X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 06:44:48 -0000 On Thu, Apr 21, 2016 at 7:57 PM, David Lang wrote: > On Thu, 21 Apr 2016, Dave Taht wrote: > >> I was watching myself do then make-wifi-fast Q&A and henning mentioned >> the hidden station problem and it's interaction with minstrel... >> >> https://www.youtube.com/watch?v=3DRb-UnHDw02o >> >> Since we are doing up some better testbeds, I am curious as to what >> might be a good (simplified) setup (bench or air) for it, and/or if >> there has been a paper that shows the interaction problems with >> minstrel in particular. > > > the basic way to see this is to take two stations and move them far enoug= h > apart, or put shielding between them so that they cannot talk to each oth= er. > > Then position a third station so that it can see both of the first two. Yes, three stations would be the minimum, but I would suggest trying it with 4 stations (all of them in IBSS/Adhoc-Mode). With three stations you still have one who can see everyone, which might change the effects. As soon as you have the chain of 3/4 stations, just setup IP forwarding routes and send traffic over the chain in one or both directions. > If you really turn the power down, you may be able to get away with them > fairly near each other with a metal sheet next to one of them. Easy to do in an office building with 5 GHz devices... often you cannot even reach offices through two walls. > You will see that you can talk to either of them quite nicely if the othe= r > is pretty idle, but if you have them both sending a lot of data at the sa= me > time, disaster strikes. Yes. > If you are writing a simulator, add a probability that a packet transmitt= ed > from an edge station to the central station doesn't get through. Ramp up > this probability and watch what happens. A better simulator would scale t= he > probability up based on the amount of airtime needed, so that as the send= er > slowes down, the probability goes up. Not sure how well current simulators can handle this. > This is one of the hardest problems for wifi to deal with. It manifests a= s > massive amounts of lost packets when the first two are sending to the thi= rd > one, and no amount of backoff helps. Slowing down the transmit rate just > makes things worse as it takes longer to transmit each bundle and so it's > more likely to be stepped on. I think reporting the "used airtime" in the beacons would help. This might be a first step to detect the presence of hidden stations because your own view of the airtime is different than the one of your neighbor. It would also be possible to add a hash of all known neighbor mac addresses to your beacon. This way your neighbors KNOW if there is the potential of a hidden station. > Reading up on Minstrel at > https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/rat= econtrol/minstrel > there is a comment > >> Inspection of the code in different rate algorithms left us bewildered. >> Why did all the code bases we looked at contain the assumption that pack= ets >> sent at slow data rates are more likely to succeed than packets sent at >> higher datarates? The physics behind this assumption baffled us. A slow = data >> rate packet has the highest possibility of being =E2=80=9Cshot down=E2= =80=9D by some other >> node sending a packet. > the answer to this is that the higher data rates require a better signal = to > noise ratio, and so if the problem is that the stations are too far apart= , > or there is a wall between them that makes the signal weaker, or that the= re > is just a lot of low-volume noise in the area, the slower data rates are = far > more likely to be understandable than the faster data rates. Since Wifi w= as > designed long before anyone imagined how common it would become (I rememb= er > when the pcmcia cards were >$1000 each rather than the current <$10 for a > much faster USB adapter), they designed the protocol to fall back to lowe= r > rates if the packets don't get through. Exactly... the "lower bits per airtime" should help the receiver to decode the frames. QAM64 (for high data rates) needs a lot more SNR (or SNIR, Signal to Noise and Interference Ratio) than QPSK. > This works well if you are out in the boonies and trying for range. It fa= ils > horribly in very high density environments (this is why most conference w= ifi > is worthless for example) > > This is why it's a good idea to disable the lowest data rates if you know > that you don't need them. > > reading the minsrel page, it seems intuitively obvious to me that this > random packet drop would really mess with their moving average and thus t= he > decisions they end up making. I wonder if it would make sense to try the best data-rate again for a second time if you detect you are in a hidden station environment with a "low amount of airtime available". Henning