I can create a new draft -03. I'll try to upload that later today.
On Tue, Feb 12, 2013 at 11:40 AM, Nancy Bravin <[email protected]>wrote: > 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 > > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
