Brian,
On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Brian <[email protected]>wrote: > 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). > Yes, you're right. I'll just note that there is still a difference between read (of a registration record) vs read-modify-write to update some information associated with the registration with each query. > 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]> > 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]>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]> >> 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 >> > > > > -- > -vince > > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
