I don't know how many attendees at IETF 62 tried to use the hotel wireless Internet service, but I did, and it was terrible. I purchased the week-long service on Sunday, and had to purchase it again several times during the week ("don't worry, we'll fix up the charging" said the front desk, and they did). On Sunday all the protocols I needed worked (HTTP, IMAP, ssh, SIP, Kerberos, etc), but later in the week anything but HTTP was hit-or-miss (IMAP in particular never worked at all). I considered complaining to the front desk ("your protocol isn't working, sir?") but it was easier just to go downstairs.
Interesting. I also purchased it for the week, and with the exception of one evening when I couldn't get through and went to the wired terminal room, the hotel service was the one that worked. Now, everything I did was over a VPN, so I didn't test some of the things you did, but I certainly had the traffic patterns of those applications within my encrypted data stream.
Something that could come out of this discussion that would be constructive and helpful might be a set of guidelines for hosts with respect to the network. I wonder if we could focus the thread in that direction?
What I think we have learned is that flash crowds impact the wireless strongly. We found that 802.11a was useful; I'm theorizing, but I would guess that has something to do with more capacity and less users. We found that 802.11g interacted poorly with 802.11b. Again, theorizing on the fly, I'm going to guess that the frequency collision and the fact that most people had 802.11b-only WiFi meant that the 802.11g users presented little more than a ddos. That can be fixed in two ways: do a better job of 802.11b AP placement, if that was the "other" issue, or have more of us buy 802.11b/g capable NICs. I think it would be wise if the did both - if I can say this without appearing to be casting aspersions on the IETF 62 network operation, let's encourage good network design, and also encourage IETF participants to bring 802.11b//g cards.
Another issue may have been (Fred in theory mode again) with the DHCP service. I saw a number of cases where folks had trouble getting an address, or their address was changed a few moments after it came up, or they got one only to have it go away and not be replaced. That suggests that somehow the address assignment policy or the server software executing it had some problems.
The best bet, I think, would be for the IETF 62 team to put together a note (not to this list, but among the appropriate group) detailing the issues and making recommendations for future meetings.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf