The difficulties in building a conference wireless network, TERENA TNC edition

It’s hard to build a conference wireless network. I’ve built a few over the past five years, and it is always a big engineering challenge. As you build the network, you refine your plans. When users arrive and start sending traffic, you refine your plans. As loads ebb and flow, you refine your plans. I won’t say it’s easy, but it is a well traveled path. Every major gathering of networkers requires wireless connectivity.

I’m accustomed to the user experience on wireless LANs built for industry trade groups like the Wi-Fi Alliance, the IEEE 802.11 working group, and the IETF. The Wi-Fi Alliance uses Michael Hijdra and his team at 2Fast4Wireless, and Verilan does work for both IEEE 802.11 and the IETF. This week, I’m speaking at the TERENA NetConnect conference. It’s only the first day, but I’ve had lots of trouble with the network.

First of all, the network uses web “authentication.” All of the conference attendees have been given a unique account, but the use of accounts is enforced by a captive web portal, not WPA. The Wi-Fi Alliance, IEEE 802, and the IETF all run an 802.1X network, though they also offer an option for unauthenticated access. It seems unfortunate to avoid using 802.1X at the TERENA TNC conference because TERENA’s Eduroam project has done a great deal to drive adoption of 802.1X, and many of the attendees are therefore familiar with 802.1X configuration.

When the plenary hall filled up, the performance went down very quickly. In the first eight minutes, I was disconnected four times. At eight minutes, the network connection gave up the ghost and quit working altogether. Before that point, I was seeing round-trip times that I hadn’t seen since the great AT&T frame relay outage of 1998, when round trips were measured in seconds from my then-office to, well, anywhere. Round trip times were also measured in second-plus range here, and are substantially higher even than the GPRS/EDGE network I use when commuting to work:

Reply from 4.2.2.1: bytes=32 time=2964ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1050ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1513ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1464ms TTL=246
Reply from 4.2.2.1: bytes=32 time=3253ms TTL=246
Reply from 4.2.2.1: bytes=32 time=3448ms TTL=246
Reply from 4.2.2.1: bytes=32 time=753ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1575ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1469ms TTL=246
Reply from 4.2.2.1: bytes=32 time=228ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1538ms TTL=246

(4.2.2.1 is one of my favorite test IP addresses. It’s short, quick, easy to type, and it belongs to a highly redundant DNS server so it is almost always there.)

In the plenary, I was sitting towards the back of the room. As it became clear that the network was failing, people closed up their laptops in frustration. In the afternoon session, an attempted demonstration was aborted due to network performance problems. In all of the rooms, Windows reports low signal strength, so some of the performance problems could be due to AP placement constraints.

Last but definitely not least, there are two network names in use. A sign posted at the plenary room indicates that the split is used for load balancing, and instructs us to use the appropriate one based on user name:

I have connected to both networks, and they appear to use the same DHCP server. This is probably a misguided attempt at broadcast containment and/or load balancing. The Wi-Fi/IEEE 802/IETF networks use a single SSID and let the infrastructure figure out load balancing in a way that is transparent to the users.

One Response to “The difficulties in building a conference wireless network, TERENA TNC edition”

  1. Tomasz says:

    I have been to the same conference. While my experience with the network was the same, I would like to pint out that eduroam with it’s 802.1X authentication WAS provided and was functional most of the time. Unfortunately network problems influenced the authentication phase and one could risk an observation that over lousy network conditions, WEB portal authentication is more reliable then WPA.

Leave a Reply