Like any good conference, festival, or gathering, it's as much about the serendipity engine of coming together in large groups which then facilitates unexpected and novel interactions. More often than not the event's official content and schedule plays second fiddle to the more intimate clusters of conversation before, during, and after sessions. WebSummit, like any human get together, is about the people first and foremost, people whose interconnection is supported by the transport fabrics of the venue and host city. People come because of the promise of connection; connection to other people, to ideas, and to methods that facilitate their learning. Today, people expect to connect both digitally and physically, each a proxy to and serving the other.
Thus, event WiFi is one of today's crucial and ubiquitous service fabrics at technology events, and unfortunately it was indeed sub-standard and woefully underprovisioned at WebSummit. Notwithstanding the underlying politics, event Wifi is a three dimensional fabric that helps to distribute information to attendees, to connect them to the outside world during the proceedings (including connecting the outside world in) whilst catalysing human connections. The WebSummit WiFi did not seem to follow certain best practice patterns for high density deployments (which are documented freely and openly on the web) but more on this later, including some key points and recipes for anyone else thinking about high density WiFi at 'webscale' events! First, let's look at how one might potentially extricate WebSummit from the RDS (Royal Dublin Society) conference and exhibition centre without damaging the brand and buzz around the event itself.
WebSummit needs more leverage in this 'Mexican standoff' of sorts. It's trapped in the only event campus large enough to host its *current* numbers by an incumbent who have demonstrated they just don't get it. The irony is WebSummit can neither write the network technology requirements itself yet (and/or bake them in to contractual service level agreements for a range of reasons) nor is it permitted to take advantage of entities who actually know how to provide this type of elastic wired and wireless network due to the RDS's current stance. The RDS is unable to 'fail fast' and can only 'fail big' as there is no incentive nor room to rapidly iterate when your deployment cycle is once a year, involves actual physical hardware, and especially when you have a monopoly. WebSummit is unfortunately paying the RDS yearly to learn a little more about high density WiFi design and operation yet the RDS is still falling short and thus damaging both WebSummit and Ireland's national brand. The lack of quality and stability in this utility service is damaging the attendees experience, damaging WebSummit's intrinsic and global marketing channels, and also damaging the country's reputation by re-enforcing negative Irish stereotypes rather than the positive ones which attracted many of the people in the first place. I could go on here about how the Web itself uses encapsulation and abstraction models and how web startups only learn about 'web scale' (and thus the underlying OSI layers and network patterns) as they mature and gain traction, but I'd like to get back to the venue choice for a moment first...WebSummit needs world class conference and trade show facilities within a stone's throw of the city centre's pubs, restaurants, hotels, transport infrastructure, and preferably all within walking distance of Grafton St. It needs all this with a nexus capable of hosting ~20,000 people at a keynote, but does it really? Intimacy is not a scale free network and it is scarcity that helps to determine perceived value. Let's suppose for a minute that WebSummit explicitly states that Dublin's nucleus is it's true 24/7 campus. Albeit there is no rival to the RDS in terms of 'one (giant) throat to choke', perhaps a new campus could be imagined as an intertwined web of smaller more intimate locations (just like the Night Summit itself!).
Consider if you will for a moment the docklands with a bit of vision?
Have a think about the above with a kind of a SXSW feel? Sure, it would take a master stroke of organisation and liaison with a range of parties but the Convention Centre Dublin has a 2,000 seater auditorium as does the Bord Gáis Energy Theatre, and the 3 Arena has a 14,500 seat capacity (combined with taking over the Odeon Cinema and anything else they could get their hands on nearby!). Just a thought to bootstrap your thinking! I'm sure many Irish people would give you 20 reasons how something like this could fail all without any constructive criticism, ideas, or alternatives but.... what if...?
So, on to the WiFi... and known good patterns. Well, here is what WebSummit could do or have another entity do...
High Level Design / Basic Requirements
Client Requirements:
- One to three devices per attendee (all manner of smartphones and laptops)
- 2.4 GHz and 5GHz support
- Minimum RSSI -67dBm / SNR 25dB in coverage areas
- Minimum 5/5Mbps throughput to maximum 20/20mbps
- Application traffic types primarily miscellaneous web browsing
- HD video conferencing and voice should be available and prioritised
- Sub 5ms response from default gateway
- Sub 5ms response from cached DNS entries
- Multicast and local client to client connectivity not supported except in smaller spaces
- Limited wired connections of 100/100Mbps for all speakers and those wanting to do live demos.
WiFi Related:
- MCA(Multi-Channel Architecture) which rules out Meru!
- Distributed WiFi micro-cell architecture (rules out Xirrus!)
- Overhead directional 'patch' antennas
- 2.4GHz 'event-legacy' and 5GHz 'event' ESSIDs (throughout main hall)
- ESSID's anchored to major spaces (named accordingly vs. full site roaming)
- Limited layer 2 roaming
- ESSID's anchored to major spaces (named accordingly vs. full site roaming)
- Limited layer 2 roaming
- 20MHz only channel widths for maximum spectrum re-use and clean air
- 802.11g/n only (802.11ac in some locations but not required!)
- Basic (i.e. mandatory) 18Mbps data rates and above only
- Predictive modelling/full survey but mandatory post-validation survey
- SNR to 25dB in all expected coverage areas
- Full WIPS+ Spectrum Analyzer capable and dedicated radios/APs.
- 802.11k (and/or proprietary load balancing in mini-radio clusters in super dense client areas)
- Careful use of RX-SOP (if available ;)
- Careful use of RX-SOP (if available ;)
Wired Backbone and Event Services:
- Minimum dual active/active 10Gbps ISP transit links via disparate vendors/metro rings (with ability for vendors/exhibitors to terminate their own feeds)
- Minimum 40Gbps+ capable edge routing/firewalling
- 10Gbps dual redundant access edge uplinks to distribution
- Full 20-40Gbps or more primary campus backbone/infrastructure to the CORE
- N+1 redundant architecture throughout as far as the access/edge and APs
- Well architected L3 domains (to partition and minimise L2 failure domains)
- Routers should route and firewalls should firewall, thus DNS and DHCP should be provided for via dedicated servers or appliances
- Software caches and/or major CDN edges onsite
- Local redundant / Anycast DNS resolvers and/or caches (i.e. not performed on routers/FWs)
- Dedicated physical links and paths (where possible) for exhibitors/vendors and/ or workshops or labs.
- L7 Application Visibility / DPI (Deep Packet Inspection) and associated shaping/throttling or queuing to a scavenger class for known bandwidth hogs
- Optional per-client SRC IP bi-directional rate limiting
NetOps/SecOps and Customer Service:
- A full NoC (Network Operations Centre) that also engaged attendees via locally hosted status pages and other social media channels i.e. Twitter etc..
- All digital signage giving informative and constant network info/updates
- Constant and distributed monitoring via humans/sensors/APs to adjust for a growing noise floor and to track down any 'evil twin' APs or strong rogues
- Full Network Management, Capacity Management, Alerting etc.
- Technically qualified roaming volunteers to assist attendees get connected including at event hubs and booths
Note: This is just a mixed flavour of some high and low level critical design elements (of course more explicit requirements should be created and customised with respect to WebSummit's specific functional and non-functional requirements including proper design documentation etc.). But there is no escape however from doing simple maths with respect to the number of supported CAM table and ARP entries per infrastructure device and factoring things like the TCP set up per second and concurrent NAT sessions at layer 3 boundaries... also.. know your clients i.e. do some capacity planning in advance + wouldn't it be lovely to use all Public IPs for clients at events ;)
Disclaimer: I was not at #WebSummit but was watching live from Berlin whilst talking to some people who were (and am now back home in Dublin for a short stint!).
If anyone wants to leave constructive comments, spots errors/omissions, or would like to follow up please do so or ping me on twitter @irldexter and in case anyone is wondering my background is here @podomere
2 comments:
Some interesting ideas Donal. Nice article. You say that micro cells would rule out Xirrus. I was surprised to read that so looked it up and on their high density application notes they say "With ArrayOS version 6.3 it is possible to define Micro cell sizes,
with a radius of less than 10 ft, in very granular adjustments."
Indeed, thanks for pointing that out and I stand corrected however I don't believe this is how they they were deployed nor the common line for the Xirrus add-value i.e. not in a small grid formation with X hundred APs (albeit 10ft would be too micro :) and happy to be corrected!). Additionally they would have to be overhead with external 'patch' antennas to follow the most proven well known very high density deployments (rather than centralised and effectively omnidirectionally radiating throughout a crowd!) as the Xirrus line is you need less devices due to the onboard array/radio density so it kind of flies in the face of a more distributed model. Check out their high density paper: http://www.xirrus.com/cdn/pdf/xirrus_highdenswifi_appnotes_v2_120412
Post a Comment