There has been a lot of discussion recently about capping eduroam on ITSS-D. I’d like to take the opportunity to present the state of the centrally managed wireless network, but also to provide some rationale behind this decision, which was taken back in 2009. I hope this will provide some context.
The OWL 2 project started in 2008 with the goal of providing centrally managed wireless service to cover public areas of the University. Since its inception, the network has grown considerably in size. At the moment we run four Cisco 5508 controllers and manage 858 access points covering most of the public areas of the University. A fifth controller has been purchased and will be put into production shortly. In peak periods of the year, we have about 4,000 simultaneous clients. At the time of writing, about 3600 clients in total are connected through eduroam, OWL and a number of local SSIDs.
Since 2008, when first devices were deployed, traffic patterns have changed significantly. Popularity of video streaming is on the increase and thanks to the ubiquity of mobile devices, demand for wireless access has been growing fast.
In 2009 we introduced an application firewall, to tackle p2p activity on the wireless service. At the same time we have imposed a throughput cap, to provide fair service for all users. It was then agreed, to provide a service that was equivalent to a home ADSL, providing 2Mbps for downlink and 512Kbps for uplink. We appreciate concerns from some heavy users that these may be insufficient in the light of today’s standards, however the rationale behind the decision hasn’t changed – we don’t aim at providing a cutting edge network to compete with the wired network, but simply providing a convenient way to access the Internet for local and roaming users across various departments.
Hardware considerations
Devices which were deployed in the initial phase of the project were not 802.11n capable, hence the benefits of using MIMO and more throughput are not applicable across the entire network. 802.11n standard had only been published a year into the project. Cisco LAP-1142N which is currently our dominant platform for new provisions, accounts for just under half of the WAPs deployed (48%). Such state of play is a hurdle in relaxing throughput restrictions, as our priority is clear – we aim to provide a reliable network. If we were to double or treble the current cap, units whose wireless mainly consists of 802.11g devices would be at risk, compared to the ones running the latest standard. To ensure a reliable service we are compelled to use the lowest common denominator.
Local network
Another reason why our approach is somewhat pragmatic is the fact, that some units’ LANs have many more access points than others. We have at least a dozen units with over 20 access points and one of the largest ones has over 50 devices. While some departments or colleges may have a Gigabit connection to the backbone and use more than one FroDo to connect annex sites, others only have a 100Mbit feed on a single FroDo. A quick calculation shows that uncapped wireless traffic alone could saturate the “slower” backbone links.
Events
We had number of units contacting us to say, that their clients reported slow connection to wireless and complained about connection dropouts. Upon investigation, it turned out, that a unit was hosting a conference. As a result there was a large increase (doubling or even quadrupling) in the number of clients on each access point. That in turn put a heavy strain on the wireless service (also used to provide network access to Visitor Network). This is another reason, why we are rather modest in our approach – it’s a constant balancing of priorities to keep as many customers happy as possible. We find similar dilemmas in other services, eg. disk space, inbox size, etc.
Wireless phones
We host a physically separate network to connect wired VoIP phones and security appliances. It’s different in the case of wireless phones, which use the eduroam SSID to reach their Call Manager. I assume everyone realizes the importance and sensitivity of voice traffic on the network.
To summarize, it’s not really our whim or determination to inconvenience you and your customers. Rather a challenging battle to provide a reliable service balancing the many, often conflicting, constraints. There is room for improvement and we review our policies, but each decision has to be carefully considered, with the greater picture in mind. I trust I have given you a better understanding these concerns necessary compromises. We welcome your opinions and suggestions, so please get in touch with the networks team on networks@oucs.ox.ac.uk if you have questions or doubts.
Edit: As of 7 May 2013, the throughput cap is set to 8Mbit/s symmetric.