Re: IETF 97 - Registration and Hotel Reservations Open Now!

John C Klensin <klensin@jck.com> Sat, 13 August 2016 01:47 UTC

Return-Path: <klensin@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888A312D0EB for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 18:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbyatgXvzimA for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 18:47:24 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71D912D0DF for <ietf@ietf.org>; Fri, 12 Aug 2016 18:47:23 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1bYO2i-0006Xr-Vv; Fri, 12 Aug 2016 21:47:21 -0400
Date: Fri, 12 Aug 2016 21:47:16 -0400
From: John C Klensin <klensin@jck.com>
To: dcrocker@bbiw.net, IETF discussion list <ietf@ietf.org>
Subject: Re: IETF 97 - Registration and Hotel Reservations Open Now!
Message-ID: <CEA68E4EFA18DF3B7280EA6D@JcK-HP8200>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9Ah68sX2Vn3q7yZsxs2_xrcSpN0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Aug 2016 01:47:25 -0000


--On Friday, August 12, 2016 13:19 -0700 Dave Crocker
<dhc@dcrocker.net> wrote:

> 
>> The way it works at the moment seems to be that if you are
>> lucky enough to be doing an email check at the right time and
>> book at once you are OK, otherwise you miss out
> 
> 
> I've been wondering about how to approach this topic in a way
> that makes sense for the IETF list and it occurs to me that it
> might be worth remembering that our industry is based on
> statistical multiplexing, and that's about probabilities and
> timing...
> 
>     If we make sure there is a room for everyone who might
> want one, we will allocate too many and will waste quite a bit
> of money, due to the guarantees we have to make to the hotel.
> 
>     So for practical purposes the room block needs to be of a
> size that is likely to be exceeded... at some point... almost
> always.

If the observation Ole and others have made repeatedly is
correct (and I have every reason to believe it is), a block
large enough to accommodate everyone who is interested in being
in the HQ hotel would so constrain the range of possible
facilities as to limit IETF meetings to one or two locations in
the world, interfering with a number of other priorities.
Perhaps that just reinforces your point, but I think it leads to
a different set of equally reasonable questions with statistical
properties.

>     Currently, that 'some point' is measured in minutes, or at
> best small numbers of hours.

>     My question, therefore, is how large must the window be,
> before all the rooms typically sell out?

Well, if our criteria include "equally fair to everyone", it
needs to be somewhat in excess of 24 hours, to allow for
timezone differences.  But, if one goes down that statistical
path, then one either needs to have a rolling window or the
people whose maximum attention times are convenient wrt the
announcement time have an advantage over those who get the
announcement later, no matter how wide you make the window
(unless, as you suggest above and Ole has suggested is
impossible without overconstraining other objectives, there are
sufficient rooms in the pool that everyone who wants one can get
one and get it at the best conference rate).

However, if we accept that there is no way that all of those who
want to get into the HQ hotel will be able to (especially if a
relatively small hotel has been chosen as the HQ hotel), and we
believe that fairness is a reasonable objective (and we assume
that the allocated room block is actually selling out rather
than having hotels game the contract, block, and rates to
maximize their income -- see Adam Roach's note about hotel
behavior patterns), then we have a good approximation to
classical models of how one allocates scarcity.  One possible
answer is that we don't care: we rotate or even randomize the
announcement time in a way that, in the long term, gives
everyone (or everyone non-privileged) an equal chance at
competition for a room and assume that luck will sort everyone
out.  Another is that we _really_ don't care: we allocate the HQ
hotel to the IAOC, IESG, IAB, Secretariat Staff, the Nomcom,
ISOC Staff, those who work on the Network, maybe WG Chairs and
other elites, etc., don't bother making an announcement at all
(note that this leads to a completely reliable prediction of how
many rooms we need for the block as a side-benefit).

If, on the other hand, we do care, then several people have
suggested a way to deal with the problem.  Refining those ideas
slightly based on some experience with similar situations, we
would take applications for the HQ hotel, possibly with a window
of a week or more because the race conditions you suggest would
not apply, perhaps with a small fee, and then run a lottery for
the number of available rooms.  If someone didn't "win" a room
and decided on that basis to not attend the meeting, that
wouldn't be the IETF's problem.  The time zone and announcement
time issues would vanish.  Depending on how much we trust each
other, we might need some safeguards against people entering the
lottery and then auctioning the rooms, but that isn't rocket
science (or we could decide we didn't care about that either).
We'd also need to make another decision, following Melinda's
comment and Jari's follow-up: whether to give those with
disabilities (or at least those willing to trade some privacy
for improved odds) priority and how much.  If we could figure
out the "how much" part, the ways of handling weighting in a
random selection process are quite well understood.

And, coming back to an only slightly different issue, the
decisions as to how to handle these things should be able to be
discussed openly in the community and the community should have
the ability to decide.  That doesn't mean anything silly -- such
as declaring that a hotel should have more rooms than it
actually has -- but it shouldn't be handled on the basis that
the community is a client of the IAOC in a situation where the
IAOC is a no-choice monopoly provider and therefore either the
community should take whatever the IAOC decides to give them
(and like it) or that the IAOC and Meetings Committee, by virtue
of being appointed or designated, have knowledge superior to the
community's about what the community wants and needs.

    john