Virtual WiFi on Linux?

[Jim Thompson]

On Oct 19, 2005, at 10:56 AM, coderman wrote:

> On 10/19/05, Jim Thompson <jim at netgate.com> wrote:
>
>> ...
>> *two* radios is one too many in 2.4GHz, unless they're operating co-
>> channel.
>>
>> http://www.netgate.com/zz_faq.php#67
>>
>
> this is an instance where theory diverges from practice apparently.

Its not 'theory' its *physics*.

> i can show you a 4 radio node on channels 1, 4, 7, 11 that supports
> decent throughput, all cards in the same enclosure.  multi-radio is
> getting especially popular in mesh networking hardware.
>
> is there interference?  absolutely.  does it cause massive throughput
> degredation? nope.

Lets see some real world data.

> (this is really a complex discussion of shielding, channel allocation,
> antenna and connector design, etc, etc.  the short answer is that you
> can absolutely use multiple radios effectively)

I've allowed that there are a couple approaches (none which match the  
ones you've expressed here) that allow
multiple radios to work together.

I helped build those products, too.

An 11 Mbps DSSS radio can provide reliable service with an in-band  
interferor falling within its pass band
as long as the Signal-to-Interference+Nose Ratio (SINR) is greater  
than roughly 10 dB

Therefore, if the  interfering signal is more than 10 dB below the  
DSSS signal, it will not cause significant interference.  However,
when the signal causing interference exceeds the 10 dB SIR threshold,  
the DSSS STA will experience a dropped
packet provided there is an overlap in time.

Also, shorter packets (because they are less likely to overlap in  
time) will show less performance degradation than longer packets,  
but, of
course, these shorter packets also reduce the throughput of a single  
802.11 radio too.   (Sending back-to-back 100 byte packets will get you
around 3Mpbs on an 11Mbps channel.  Sending max-sized frames will get  
you 2X that.  All of this "on paper" since the real world will only
reduce these figures.)

> this does bring up an interesting point: exactly what is the real
> world effect?  i'd like to see a benchmark showing how additional
> radios on non overlapping channels affect throughput between them.
> are you aware of such a study?  i may try something with a crude multi
> radio setup this weekend if nothing is forthcoming.

You *just* said "does it cause massive throughput degradation? nope."  
and now you propose to actually try the experiment this coming weekend?

How can you make the assertion if you've not performed the experiment?

Yes, I am aware of such studies, but they were internal to Vivato.  I  
don't have the data to publish.   Orinoco/Lucent (before they were  
Agere) had something published that showed if you could get a pair of  
low-gain antennas on the AP far enough apart (2m separation if memory  
serves), and used low-power clients with (essentially) no gain, then  
the impact to throughput could be minimized.

This popped up in Google fairly quickly.
http://www.cse.iitk.ac.in/users/braman/papers/ursiga-2005.pdf

> as a side note, another instance where theory diverges from practice
> is the use of amplifiers for recv gain.  in theory this gains you
> nothing because the amp will increase noise along with signal.  in
> practice most radios are more adept at distinguising signal from noise
> when the power of the signal is higher.

So while you can't improve SNR, you can improve the received signal  
level to a point where its above
the sensitivity limit, and if there is sufficient SNR (especially  
after the additional noise from the LNA), demodulation will be  
successful.

That doesn't violate any theory I know about.

> long distance timing issues a third example; in theory the 802.11 MAC
> SIFS would make this impossible.  in practice the MAC is never
> implemented so rigidly...

yes, but if it were implemented to SPEC...

> any additional real world details you have on this would be
> appreciated; the other links you posted were informative.
>
>
>
>> I don't understand how IPsec fits.   You need to securely communicate
>> the same set of data (keys)
>> to a (potentially quite large) group of (potentially untrusted)
>> machines over what is essentially a broadcast medium.
>>
>> BIBA seems like one way to get this done.
>> http://www.ece.cmu.edu/~adrian/projects/biba/
>>
>
> correct; i was referencing a different concept (security between hosts
> which contain radios where you have dedicated backhaul between them).
>
> BIBA would work nicely, and other group key management and key
> predistribution schemes could also be used.

Sure.  (Why does it always reduce to a key distribution problem?  :-)

>> I don't think you're going to be able to meet the latency bounds.
>> 802.11's MAC
>> wants any "collision event" to happen within the preamble.   We're
>> talking usec here.
>>
>
> right. like you mention, some of the existing WLAN switching systems
> keep all control and low latency timing functions at the dumb radio
> endpoint.  anything dealing with SIFS time periods and preambles would
> probably enforce this requirement.
>
> i think the other tasks, like WLAN switching, could fit the latency
> bounds acceptably.  this complicates scheduling because you have to
> work around inflexible operations using short timing at a given radio.
>  how complicated this would be i can only speculate...

Lets just say its been studied into depth with a group of people who  
deeply grok
the 802.11 MAC and PHY and it is possible, given a hardwired  
connection or sufficiently low-latency protocol.

>> Sending data over a wireless medium is expensive.  There is only "so
>> much" of it, and you can't scale it like
>> you can wired networking technologies by (just) pulling more wire.
>> Three parallel Ethernet links in the same
>> piece of conduit work fine, and you get 3X the bandwidth. You can't
>> do that with radio.
>>
>
> what ever happened to UWB / Multi OFDM Alliance?  they were supposed
> to fix this problem for us.  ;)

You can't solve the problem with modulation envelopes.

> yes.  my definition of "it works" is clearly more hackish and
> inefficient.  i think such a view still has value as long you are up
> front about limitations.  i will readily admit that multi-radio is
> "dirty" from an ideal spectrum model, but that doesn't mean it is not
> useful.  (we may disagree there too though.)

OK, if we are arguing semantics.  I agree.

>> One of my ideas here is to have the 'virtual AP' (which only handles
>> one STA) use the *STA's* MAC as the BSSID.
>>
>
> i'll have to try this now;  i know that when a client forges it's MAC
> as the BSSID / AP MAC many AP's completely freak out.  one model which
> i can't recall even went into a reset loop, apparently thinking
> something had gone seriously wrong internally.

exactly the kind of effect that I was anticipating.   difficult to  
fix in firmware-based MACs, too.

>> I don't know.  You'd have to talk to Wayport.  (I was employed there
>> when I wrote the patent description).
>> ...
>> So, for the most part, I think they've turned a blind eye, even as
>> their competitors have implemented similar techniques.
>>
>
> this is encouraging at least.  i suppose there is no need to be
> concerned until patent infringement suits start flying at cisco and
> crew. *grin*

Note that patents grant "negative rights" to the holder.  Wayport  
could decide to sue you (or me), for infringement
and not sue Cisco or Jouni.

This is why IBM (and others) can say "we won't sue <linux>" on these  
patents (but watch out MSFT!)

jim