Steve,
I completely agree with your comment and suggestions (including
at least knowing hotel network capabilities in advance of
arrival), but note that at least some of the reason while the
hotel networks perform so badly under IETF meeting load is that
many of them are seriously underprovisioned at multiple points.
If the meetings team were to perform simple tests (that we
helped design) based on the number of people in that team, they
would be likely to get good information about capability
limitations (e.g., ports and options) but would be unlikely to
get sufficient information about performance under serious load.
Clearly, we could figure out how to run a load test, but I
assume it would take a lot of cooperation from the hotel (or
several hundred of us occupying rooms).
best,
john
--On Friday, 25 July, 2014 08:09 -0400 Steve Crocker
<steve(_at_)shinkuro(_dot_)com> wrote:
If we're going to discuss hotel networks, encryption of the
channel is nice to have but there are more serious problems.
o Many hotel networks restrict the ports that can be reached.
This results in an absolute failure for some of us.
o Many hotel networks do not support the full range of options
for DNSSEC.
o Many hotel networks have very poor bandwidth and become
overloaded when the IETF comes to town.
The meetings team does an excellent job of planning and
running the meetings. They do extensive investigation of each
proposed meeting site and they do a stellar job setting up and
running the networks at each meeting. I wish they would also
test the hotel networks in advance and report to all of us the
limitations we're likely to encounter. And, of course, it
would be pretty easy for a volunteer group of IETFers to
organize a reporting effort too.