Re: Hotel networks (Was Re: Security for the IETF wireless network)

[George Michaelson <[e-mail]>]

I'd just like to say thanks to the NOC. I encountered no difficulties of
their making, and several things appeared to work better than before (tm)
which is always good.

I had the 1x as my pref from prior IETF and "it just worked".

OSX appears to have gone to a place where stop-start on wifi across
sleep/wake is a pain, but I cannot hold the noc responsible for that.
Contrariwise, I arrived 2 DAYS before the kick off of 'real' IETF and I had
IETF backed net almost immediately.

Well done. Thanks.

-G




On Fri, Jul 25, 2014 at 9:43 AM, Steve Crocker <[e-mail]> wrote:

> I’m not at this IETF meeting and I’m not referring to the current hotel
> network.  In the past, I’ve encountered all sorts of restrictions and
> limitations.  Also, there is often a big difference between the main hotel
> and the others.  In Maastricht, for example, I stayed at what was
> apparently a dorm hotel and I could not get access to nonstandard ports,
> e.g. for SSL protected access to my email.
>
> Steve
>
> On Jul 25, 2014, at 9:40 AM, joel jaeggli <[e-mail]> wrote:
>
> On 7/25/14, 9:29 AM, John C Klensin wrote:
>
> 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).
>
>
> so,
>
> We've taken the hotel's captive portal / nat platform /internet service
> out of the path for the residential network for the week. We do this
> where possible, and in cases where we cannot this is typically noted.
>
> While wifi coverage, lre/dsl and internal topology are out of our
> control, the hotel network is being served by the the IETF network and
> has no restrictions respecting authentication, ports available,
> middleboxes and so forth. There is nothing especially interesting to
> report there.
>
> best,
>    john
>
>
> --On Friday, 25 July, 2014 08:09 -0400 Steve Crocker
> <[e-mail]> 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.
>
>
>