Hi Vincent, It is an important issue, and one that could cause issues at the approval level of the draft, and for potential users should we not have something there. Is it possible to add to this revision? Even a reference to JSON 6.5.2 ? Sincerely, N
On Feb 12, 2013, at 9:24 AM, Vincent Chen wrote: > Chris, > > Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and > AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that is the > "Generated time". > > Looks like I forgot to add them to the data models in Section 4. > > The intent of this field is, indeed, for the device to determine any clock > skew. > > I will add the field to the next draft. > > -vince > > > On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe <[email protected]> wrote: > We have recently come across a problem with a similar system to PAWS, where a > small amount of clock drift between the WSD and the WSDB affects the validity > of channel allocations. In some cases the problem causes the WSDBs to be > repeatedly queried. > > > > WSDBs might return allocations which have a start time set to the WSDB’s > current time, i.e. starting immediately. Start times on allocations are a > good thing, since a device can receive a frequency plan for the a significant > duration without hitting the servers. > > > > But if the device’s internal clock is running behind the WSDB’s clock, there > is a potential problem: the WSDB is likely to serve up allocations which, > from the device’s point of view, are in the future. If the discrepancy is > small, then the device might sensibly remain silent until its clock has > caught up with the SpectrumSchedule’s start time. Or more pathologically, the > device might query the WSDB repeatedly in the hope of a better allocation, > each time receiving allocations that seem to always be in the future. We > have seen this phenomenon in the wild. > > > > A possible solution to this problem would be to somehow indicate that the > allocation is for ‘now’. > > > > This could be handled with a ‘Generated’ timestamp on the > AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB’s > clock disagrees with the its own clock, and can see that a SpectrumSchedule > is valid with immediate effect. The device could use the clock discrepancy > as a trigger to adjust its internal clock, perhaps using NTP. > > > > Another possible change: any SpectrumSchedules that start with immediate > effect should be reported as “valid immediately” by a new flag in the > EventTime structure. > > > > Would it make sense to alter the PAWS spec in light of this problem? > > > > Cheers, > > > > Chris Lowe. > > > > -- > > Chris Lowe > > Neul Ltd. > > Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambridge, CB4 > 0EY, UK > > http://www.neul.com > > Tel: 01223 437022 > > > > > _______________________________________________ > 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
