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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
