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 220.127.116.11: bytes=32 time=1050ms TTL=246
Reply from 18.104.22.168: bytes=32 time=1513ms TTL=246
Reply from 22.214.171.124: bytes=32 time=1464ms TTL=246
Reply from 126.96.36.199: bytes=32 time=3253ms TTL=246
Reply from 188.8.131.52: bytes=32 time=3448ms TTL=246
Reply from 184.108.40.206: bytes=32 time=753ms TTL=246
Reply from 220.127.116.11: bytes=32 time=1575ms TTL=246
Reply from 18.104.22.168: bytes=32 time=1469ms TTL=246
Reply from 22.214.171.124: bytes=32 time=228ms TTL=246
Reply from 126.96.36.199: bytes=32 time=1538ms TTL=246
(188.8.131.52 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.