But you can't really do "stateless" and have registration. That's state. You can't serve an unregistered device. Slowly changing state, but then again, most location is slowly changing (mobile devices on the move excepted).
I agree that maintaining 60 second polling is very challenging, and I agree the mechanism we discussed of having a much longer period and temporarily lowering the period when needed is an appropriate mechanism. I will remind everyone that if a device is moving, a faster poll is needed due to the motion (every hour, or when you move more than x meters). This affects the proposed rules. Brian On Apr 17, 2013, at 6:36 PM, Vincent Chen <[email protected]<mailto:[email protected]>> wrote: All, For scalability and redundancy reasons, a "stateless" system is much preferred. That means not having answers depend on priory history of queries. This allows running many server instances to service requests. It also means that each request can go to any serving machine. There also may be reasons why caching might not work: - The answer is not totally dependent on only the device characteristics. In the US, for example, there are dynamic registrations, so the Database might have to run through most of the computation anyways to determine whether anything has changed. - For devices that use GPS, the location might jitter just a bit from time to time, so the difference might cause cache misses To keep the API simple, I wouldn't recommend adding another call when the existing one already works. ---------------------- Query Volume ---------------------- As for the polling period. I think we should look at what this actually means: - At 60-seconds polling period for only 1 million devices.....that's almost 1.5 Billion queries per day! Note that a large search engine like Baidu only handles 5B queries per day. So....I would be very cautious about trying to set the polling period too low. It would be requiring a significant amount of resources to provide a capability that would be used rarely, perhaps 0.001% of the time (once a month)? At the F2F, there was a suggestion that actual management could be a staged process, e.g., - By default the required update period is 1 or 2 hours - When needed, the update period for devices within a specified geographic region could be lowered to 60 seconds, allowing investigation - When investigation is complete (and/or after a timeout), update period is reset to default This seems more reasonable to me (IMHO), and the current proposed protocol with expiry will handle this just fine, I think. -vince On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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]<mailto:[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<http://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]<mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/paws >> >> _______________________________________________ >> paws mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
