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
- Re: IETF 97 - Registration and Hotel Reservations… Dave Crocker
- Re: IETF 97 - Registration and Hotel Reservations… Tim Chown
- Re: IETF 97 - Registration and Hotel Reservations… JORDI PALET MARTINEZ
- Re: IETF 97 - Registration and Hotel Reservations… John C Klensin
- RE: IETF 97 - Registration and Hotel Reservations… Andrew Allen
- mtgvenue (was Re: IETF 97 - Registration and Hote… Melinda Shore
- Re: IETF 97 - Registration and Hotel Reservations… John Levine
- Re: IETF 97 - Registration and Hotel Reservations… John Levine
- RE: IETF 97 - Registration and Hotel Reservations… Christer Holmberg
- Re: IETF 97 - Registration and Hotel Reservations… John Levine
- Re: IETF 97 - Registration and Hotel Reservations… John Levine
- Re: IETF 97 - Registration and Hotel Reservations… John Levine
- Re: IETF 97 - Registration and Hotel Reservations… Dave Taht
- Re: IETF 97 - Registration and Hotel Reservations… Adam Roach
- Re: IETF 97 - Registration and Hotel Reservations… Ted Lemon
- Re: IETF 97 - Registration and Hotel Reservations… Dave Crocker
- Re: IETF 97 - Registration and Hotel Reservations… Jari Arkko
- Re: IETF 97 - Registration and Hotel Reservations… Pat Thaler
- Re: IETF 97 - Registration and Hotel Reservations… Melinda Shore
- Re: IETF 97 - Registration and Hotel Reservations… Stewart Bryant
- Re: IETF 97 - Registration and Hotel Reservations… Ted Lemon
- Re: IETF 97 - Registration and Hotel Reservations… John C Klensin
- Re: IETF 97 - Registration and Hotel Reservations… Dave Taht
- RE: [Recentattendees] IETF 97 - Registration and … Lucy yong
- Re: IETF 97 - Registration and Hotel Reservations… Jari Arkko
- RE: IETF 97 - Registration and Hotel Reservations… Roni Even
- Re: IETF 97 - Registration and Hotel Reservations… JORDI PALET MARTINEZ
- RE: [Recentattendees] IETF 97 - Registration and … Christer Holmberg
- RE: IETF 97 - Registration and Hotel Reservations… Christer Holmberg
- Re: IETF 97 - Registration and Hotel Reservations… Michael StJohns
- Re: IETF 97 - Registration and Hotel Reservations… Dave Crocker
- Re: IETF 97 - Registration and Hotel Reservations… Donald Eastlake
- Re: IETF 97 - Registration and Hotel Reservations… Donald Eastlake
- Re: IETF 97 - Registration and Hotel Reservations… grenville armitage
- Re: IETF 97 - Registration and Hotel Reservations… Paul Wouters
- Re: IETF 97 - Registration and Hotel Reservations… John C Klensin
- IETF 97 - Registration and Hotel Reservations Ope… IETF Secretariat