Subject: [paws] Clock drift problem against SpectrumSchedule start times

From: Chris Lowe <[email-masked]>
Date: Tue, 12 Feb 2013 17:09:30 +0000

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

---

From: Vincent Chen <[email-masked]>
Date: Tue, 12 Feb 2013 09:24:39 -0800

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Nancy Bravin <[email-masked]>
Date: Tue, 12 Feb 2013 11:40:20 -0800

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".
> 
> The intent of this field is, indeed, for the device to determine any clock skew.
> 
> 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.
> 
>  
>

---

From: Vincent Chen <[email-masked]>
Date: Tue, 12 Feb 2013 14:22:27 -0800

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-masked]>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

-- 
-vince

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Feb 2013 10:15:34 -0500

> The intent of this field is, indeed, for the device to determine any clock skew.

Great! But I'm a little confused as to what I, as a poor little device actually *does* with this information…

I wake up one morning and look at my clock. it is now 9:34AM on Feb 13th, 2013…
Being a good and diligent little radio I contact the WSDB and ask if I can pretty please have some spectrum.

I get back a response that says:
protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP']
responseInfo: [ big blob-o-stuff ]
deviceId: [me! Hey, thats me!]
spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth': '10000', 'frequencyRange': '14420000' …]

What do I do?
Do I assume that the WSDB must know what time it is better than me and adjust my clock?
Do I say "Hang on a tick, thats in the past, can't be right, I'll just assume his clock is 42 years, 1 month, 12 days off and automagically add that to all times from him…"?  
Do I only allow offsets of X minutes and Y seconds?
Do I care if the messages are coming to my from the future (instead of the past)?
Nasal Demons?

So, lets assume we have a "This allocation is for now" concept. What do I do if the allocation starts "now", but ends yesterday?
Hmmm... Maybe absolute times are not the answer -- so, what if we just make allocations be: start "now", end in "now"+8h.

This looks potentially much simpler, but what happens if a messages is somehow delayed for a long time… Still seems better, but….

W

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

---

From: Vincent Chen <[email-masked]>
Date: Wed, 13 Feb 2013 08:40:52 -0800

Actually, the response says (added the missing timestamp parameter)

protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP']
timestamp: '1971-01-01T14:00:00'
responseInfo: [ big blob-o-stuff ]
deviceId: [me! Hey, thats me!]
spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth':
'10000', 'frequencyRange': '14420000' …]

There's a timestamp for the response, so it can be used as reference for
the times in the Schedule.

The device can choose to do either:
 - Notice that the event start time is 22 minutes after the response
timestamp, so decide to turn on 22 minutes later
 - Decide to trust the DB's clock and update its own internal  clock to
match, then use the absolute event time values.

On Wed, Feb 13, 2013 at 7:15 AM, Warren Kumari <[email-masked]> wrote:

> Do I say "Hang on a tick, thats in the past, can't be right, I'll just
> assume his clock is 42 years, 1 month, 12 days off and automagically add
> that to all times from him…"?
> So, lets assume we have a "This allocation is for now" concept. What do I
> do if the allocation starts "now", but ends yesterday?
> Hmmm... Maybe absolute times are not the answer -- so, what if we just
> make allocations be: start "now", end in "now"+8h.
>
> This looks potentially much simpler, but what happens if a messages is
> somehow delayed for a long time… Still seems better, but….
>
> W
>
>
> >
> WSDBs to be repeatedly queried.
> >
> >
> >
> significant duration without hitting the servers.
> >
> >
> >
> in the future.  We have seen this phenomenon in the wild.
> >
> >
> >
> as a trigger to adjust its internal clock, perhaps using NTP.
> >
> >
> >
>  EventTime structure.
> In all the worlds graced by their presence, it is suspected that they can
> talk but choose not to do so in case humans put them to work, possibly in
> the television industry. In fact they can talk. It's just that they talk in
> Orang-utan. Humans are only capable of listening in Bewilderment.
> -- Terry Practhett
>
>
>

-- 
-vince