Not really. Use a cache. If nothing changed, reply so and move on. If it's really 60 seconds, then you are maintaining the SSL connection, so you don't need a complete reauth. OTOH, if you are maintaining an SSL connection, then a push is pretty easy.
Brian On Apr 16, 2013, at 11:25 AM, Peter Stanforth <[email protected]> wrote: > Brian > Big difference between a simple "Am I ok?" and a reauthentication and channel > request. > The former could be very light weight and make DB processing a lot simpler > > On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <[email protected]> wrote: > >> We already have the notion of an expiry time on the spectrum allocation. If >> you make that short (60 seconds), then the client has to come back to the >> database to get a refresh. No further pull mechanism is needed. Its not >> clear that doing something better helps a lot. The server has to get the >> location of the client and determine if any changes in spectrum have >> occurred. That's a full geospatial query, with some possibilities of >> maintaining caches of recently changed curves. >> >> A push is hard in many environments because NATs, firewalls and other middle >> boxes make it difficult to establish a connection from outside to inside. >> We could maintain a very simple ping from client to server that just kept >> the path open, and then use that to send the push notification. >> >> Maintaining pull mechanisms with circa 60 second timeouts is fine as long as >> the number of clients is small. A million clients on one server might work >> without this level of interactivity, with it and we're as much as two orders >> of magnitude less capacity. There are always problems like avalanche >> restart due to power failures, so it's probably not really this bad, but >> it's a pretty big problem. >> >> Brian >> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <[email protected]> >> wrote: >> >>> All, >>> >>> At the meeting in Orlando we discussed a device update function (or kill >>> switch, or PUSH). This arises from the UK regulatory requirement that a >>> database should be able to contact any device within a short time. After >>> review of PAWS use case document with regards to this, I think our UK >>> requirement is neatly captured in requirement P.16 "The protocol MUST >>> support the capability for the database to inform master devices of changes >>> to spectrum availability information" >>> >>> This requirement is already part of the current draft of the ETSI >>> Harmonised Standard. Its main elements are summarised below, and the full >>> text is attached: >>> >>> +++++++++++ >>> DEFINITION >>> The master WSD update is the process by which a database informs a master >>> WSD that its operational parameters, and those of the slave WSDs attached >>> it, are still valid or are no longer valid >>> REQUIREMENTS >>> - A master WSD shall support WSD update function. For this, a master WSD >>> shall either >>> *be able to receive an update from the Controller Database WSDB within >>> Tping seconds (push update), or >>> *send an update request to the Controller Database WSDB every Tping >>> seconds (pull update). >>> - A master WSD shall support a Tping value of [60] seconds or higher. >>> - A master WSD shall cease transmission, and shall instruct the slaves >>> attached to it to cease transmission, if it receives update from the WSDB >>> that the operational parameters are no longer valid. >>> - A master WSD shall cease transmission, and shall instruct the slaves >>> attached to it to cease transmission, if it loses connection with the WSDB >>> ++++++++++ >>> >>> It is worth signalling that, at least among UK stakeholders, there is wide >>> support for the pull method and little support for the push method. This is >>> consistent with the view that it will be very difficult to implement the >>> push functionality over the internet. >>> >>> As a first step, I would like to ask the PAWS WG to consider support for >>> this functionality in the specification. Secondly, it would be good to have >>> views of how a pull mechanism could be implemented in the PAWS protocol. We >>> have had early discussions about this off-line, and I think the >>> alternatives are 1) to adapt one of the existing procedures >>> (SPECTRUM_USE_NOTIFY and "Device Validation" are possible candidates), and >>> 2) create a new, dedicated procedure. >>> >>> Thanks and regards, >>> Cesar >>> >>> >>> >>> ________________________________ >>> >>> ****************************************************************************************************************** >>> For more information visit www.ofcom.org.uk >>> >>> This email (and any attachments) is confidential and intended for the use >>> of the addressee only. >>> >>> If you have received this email in error please notify the originator of >>> the message and delete it from your system. >>> >>> This email has been scanned for viruses. However, you open any attachments >>> at your own risk. >>> >>> Any views expressed in this message are those of the individual sender and >>> do not represent the views or opinions of Ofcom unless expressly stated >>> otherwise. >>> ****************************************************************************************************************** >>> <EN301598v0018_MasterWSDupdate.docx>_______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >> >> _______________________________________________ >> paws mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
