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
