DAWN-sim: A large network simulator

[Ian-Clowes]

As some may know my personal design concept for DAWN is that it should be able to drop into a large network to help reduce the overall number of devices required, power use, user annoyance, etc. By "large" I mean a network of 100 decent sized APs supporting 4000 users - as may be found at a reasonable sized conference. I know we can quibble about users / devices, connections per AP, etc - they just happen to be the figures I've decided are reasonable from the point of view of making DAWNs internal data structures and algorithms efficient enough. Factors of 2-5 difference wouldn't fundamentally change them IMHO. In turn I expect this would mean an ability to work well in smaller environments, such as an office with 100 users and 10 APs. And possibly a larger scale like 100k people with 2000 AP at a sports arena.

While doing this it should "add value", meaning that if a number of devices give a mediocre user experience without DAWN due to "long" connections draining overall radio efficiency then DAWN should enhance that user experience while running on the same hardware with modest resource requirements - in other words no need to double the spec of the APs to benefit from DAWN.

Having set the scene I'll switch the point of this post 😄. It'd be infeasible to build many of these networks during development, so I'm edging towards building a "DAWN Simulator". This would allow the core DAWN code to be built in a standalone executable that could be run on a full-sized Linux workstation. Each instance would represent an AP in the DAWN network, and could be passed messages via some mechanism or another (maybe STDIN, maybe a pipe, etc) to represent what hostapd does on a typical router.

For example, a "game space" might be populated with 100 DAWN-sim instances on a 10 x 10 grid. An increasing number of simulated devices are then added into the space, and moved around every "turn". Messages would then be sent to each DAWN-sim instance to represent what is happening in the simulated space, for example each device sends a beacon report to all AP within 2 grid units. DAWN's algorithms then tell each device what they should do during the next "turn", such as connect to a different AP before moving around the grid. By doing this the linearity or othewise nature of DAWN can be looked at, for example I suspect that the current probe data analysis could become a bottleneck. I have some ideas on refining that - but would like to see the impact they have. Within the modelling I'd like to try and account for different types of device - 802.11k, pre-that, etc.

Thank you for reading so far 😄. My reason for posting is to ask how well the above scenarios match your own aspirations for what DAWN can do. Do you run a large network, and if so how many APs of what class for how many users? What challenge areas do you see that might be worth including, such as types of device or user?

[edrikk]

Although the idea of a simulator is neat, I think it may be more of a purely technical exercise than a real-world exercise. Because at the end of the day, to make it a real-world "emulator" all the various variables would have to be developed in. e.g. walls, materials, non-DAWN APs?, Android vs iOS percentages and differing behaviors across, distances, bands, natural but "random" movement of devices, stationary devices, etc etc.)

To go back to your point about first two (and especially 2nd) paragraph, my gut feeling is that end-users will get a lot more benefit with a rebuild of the UI layer. It can be started small by overhauling the single current summary page, and can be expanded (maybe by clicking key items on the summary page) to go deeper in future releases.

Some things that can help:

• Current UI is just not formatted to work on a Mobile device. It's just not usable in that context. Especially if you're walking around to troubleshoot / see how the device transitions etc.
• MACs should be replaced with hostnames, or at the very least hostname should be present on the summary page.
• If DAWN initiates the removal of a device, this should be told to the user in a user-friendly way. Maybe clicking on a device tells the user this information, and maybe there is a separate page that lists all where user can filter, sort, etc.
• To the above bullet, telling the Users what parameters are having affect at and what percentage would be hugely beneficial. Right now, DAWN is a magic box. Telling the user in a simple PIE chart and maybe with drill-down details X percentage were kicked because of threshold of parameter A, Y percentage because of parameter B, etc would be really helpful in helping setup the AP landscape. This would be helpful at the overall level; Maybe a drilldown would be per AP?
• 99% of the Users want to see where the devices are connected. This is both for home use, but also it's important for large scale deployments. At home people are curious and/or want to make sure things are working. In a large rollout, people want to know the same, but also get a sense of hotspots (in terms of people aggregating in specific areas, help adjust floor plans for future events, etc).

Just some thoughts. :)

[Ian-Clowes]

I'll just respond on the simulator part here, otherwise we'll have a muddle of topics. I'll open a new topic on the UI when it is further up my mind. You might want to premept that by opening it now and moving the relevant part of the above message.

I agree it wouldn't be a perfect simulation of everything. The main aim would be to test the core algorithms against some key external behaviours with a large data set. Although I wouldn't expect to build in Android / iOS specific behaviour (largely because I son't know how they differ 😃) I would include something like ~5dB random variation on the "nominal" radio signal for the grid straight-line distance. That would help emulate natural flux plus the effect of someone walking past a filing cabinet on thier way to the water cooler, and should tickle the "going, going, gone" 3-strikes test that DAWN has before kicking a client.

[seemebreakthis]

I suspect a large group of OpenWrt users, myself included, are home users who want to have a stable wireless network and adequate coverage within their homes. For instance in my setup there will never be more than 5 or so APs running DAWN.

For bigger enterprises I could picture those guys opting for commercial solutions like Cisco rather than OpenWrt..... ?

[Ian-Clowes]

I suspect a large group of OpenWrt users, myself included, are home users who want to have a stable wireless network and adequate coverage within their homes. For instance in my setup there will never be more than 5 or so APs running DAWN.

Yes, I think that will be a majority of users. My personal aim is to have that working well by UK summer time when I'll be relying on phones, laptop, etc working with the dumb AP covering the garden area.

I see being able to scale as a useful proxy for using as few resources as necessary and hence being able to run "as well as posisble" on even a small network. If there were potential users at the small-mid-large office size that would be interesting.

[PolynomialDivision]

I would be definitely interested in that "garden area" topic, since I also run a community wireless mesh. I would love to see where are the bounds and limitations of DAWN. However, having 5K Clients in one single broadcast domain is not that efficient. I think we would need to build multiple layer 3 networks and combine dawn with layer 3 roaming. That would be awesome.

[Ian-Clowes]

I hadn't really thought about the layers, but now I do wouldn't DAWN be transparent to any L3 behaviours?

If the DAWN instances were on a /24 wired network purely for exchanging DAWN info to move clients to the best AP then the wifi part could be backhauled on a different network, with L3 roaming.

Putting that another way, L3 roaming could be useful and in place if the clients were self selecting which AP to use without DAWN. DAWN could then be added to improve the AP steering.

[PolynomialDivision]

If the DAWN instances were on a /24 wired network purely for exchanging DAWN info to move clients to the best AP then the wifi part could be backhauled on a different network, with L3 roaming.

Yeah of course. However, when the decision is made to steer a client to an AP you could already do the l3 network reconfiguration (whatever that means in your setup, e.g. putting up tunnels, vxlan, ...). But maybe letting DAWN be transparent to L3 behaviors is the better decision. :)

[Darin755]

I don't think DAWN will ever be able to scale to the size you are talking. The way DAWN works is that it uses broadcast to sync the list of current devices. However, When you start taking about 100 devices broadcasting you will see a huge amount of network and CPU usage as there is a lot of overhead. Right now if I had to setup something like you are describing I would just stick to plain 802.11r with 802.11k enabled.

That's not to say it is impossible to do 802.11v. All of your commercial wifi systems use a centralized controller to manage everything. This allows for a much cleaner system and allows for central control. If you wanted to do something like this on OpenWRT I would look into some of the scripts people wrote pre DAWN as you probably could modify them to use a central device as the "controller" that keeps everything in sync.