Re: [Netconf] Updated draft-mm-netconf-time-capability-01

[Tal Mizrahi <[e-mail]>]

Hi Joe,

Thanks again for the comments.

> I don't get this.  If I schedule something to run in one hour, I have to wait an hour for the rpc-reply?  That doesn't seem right.

Okay, so this goes back to our comment that the current draft focuses on soft-real time scheduling (http://www.ietf.org/mail-archive/web/netconf/current/msg08549.html), but I should probably explain it a bit further. In this context there is an implicit assumption that RPCs are scheduled to a *near future* time. Here is an example (the numbers are just an example, so they do not necessarily represent a real-life scenario).  Let's say we have a client and two servers, and let's say that every RPC the client sends (a normal RPC, not a scheduled one) is executed within 3 seconds with a probability .999, i.e., the client receives an rpc-reply within 3 seconds. The client can send a *scheduled* RPC to the two servers, with a <scheduled-time> that is 3 seconds into the future; consequently, each of the two servers performs the RPC exactly 3 seconds afterwards with a probability .999 (each). The client has to wait 3 seconds to get the rpc-reply, but that is not so bad, since in the non-scheduled RPC the client may need to wait 3 seconds anyway. And we should note that in this example each of the servers has a probability of .001 not to perform the RPC on time, which is why we are emphasizing that we have focused on addressing soft-real time scheduling.

Indeed, the rpc-reply is received only after the RPC was scheduled, but we are assuming that the scheduling time is not too far into the future (which is one of the reasons this draft includes the <sched-max-future>).

I think the current draft is less targeted at far-future scheduling (e.g., an hour in your example). Our thoughts were that approaches such as draft-kwatsen-conditional-enablement are a better fit for far-future scheduling. However, if we come to the conclusion that we *do* need to address far-future scheduling, it is possible to add the following functionality (this is a tweak to something Andy suggested a couple of months ago): (i) When a server receives a scheduled RPC, it can send a notification to the client, indicating that the scheduled RPC was received and added to the server's schedule. The rpc-reply itself is sent after the RPC was executed at the scheduled time. (ii) The client can send a cancellation message if it does not receive a notification, or if it receives an rpc-error from one of the servers. 

So an open question here is whether we should add the 2 features above (notification, cancellation) that would enable far-future scheduling as well.

Regards,
Tal.


-----Original Message-----
From: Joe Marcus Clarke [mailto:[e-mail]] 
Sent: Monday, January 20, 2014 1:45 AM
To: Tal Mizrahi; Tal Mizrahi; [e-mail]
Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01

On 1/19/14, 8:57 AM, Tal Mizrahi wrote:
> Hi Joe,
>
> Thanks for the comments.
>
>> However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC.  How would I go about ensuring that an RPC completed (or not) at the scheduled time?
>
> If the client gets an rpc-reply with an <ok> element it knows the scheduled operation was performed successfully.
> If the client wants to know whether the RPC was performed *on time* it needs to include the <get-time> element in the RPC (in addition to including the <scheduled-time> element), causing the server to include the <execution-time> element in the rpc-reply. This allows the client to receive feedback about the actual execution time of the RPC. This behavior is described in section 3.1 of the draft.

I don't get this.  If I schedule something to run in one hour, I have to wait an hour for the rpc-reply?  That doesn't seem right.

My understanding from the initial read was that I would get an rpc-reply right away to indicate the request was scheduled successfully.

>
>> I think there should be a way to query the server's current time to make sure the client and server agree.
>
> One way to do this is to use the <get-time> element; the client can send (any kind of) an RPC to the server which includes the <get-time> element. Consequently, the server includes the <execution-time> in its rpc-reply. It should be noted that this method allows a *very* rough indication about whether the client and server are synchronized.
> However, I believe the correct way to inquire about whether the server is synchronized or not is at the clock synchronization protocol layer. For example, the NTP MIB (RFC 5907) includes a set of objects that allow you to check the current status of NTP, including the offset to the current reference time source. The PTP MIB (draft-ietf-tictoc-ptp-mib-05) also includes similar objects.
> [One may ask whether NTP and PTP have a YANG module for NETCONF, but 
> that is a completely different story...:) ]

In terms of this draft should there be some text that explain this as a potential concern with suggestions?

Joe

>
> Thanks,
> Tal Mizrahi.
>
>
> -----Original Message-----
> From: Netconf [mailto:[e-mail]] On Behalf Of Joe 
> Marcus Clarke
> Sent: Tuesday, January 14, 2014 8:03 PM
> To: Tal Mizrahi; [e-mail]
> Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01
>
> On 1/2/14, 10:56 AM, Tal Mizrahi wrote:
>>
>> Hi,
>>
>> We have posted an updated draft:
>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-01
>>
>> Thanks to all the people who reviewed and sent comments about draft 00.
>> Here is a summary of the changes compared to draft 00:
>> -    We have added discussion about the scheduling tolerance: an upper
>> bound on how far into the future/past an RPC can be scheduled.
>> -    The scheduled time now refers to the *start* time of the operation,
>> rather than to its completion.
>> -    The time format has been changed to date-and-time.
>
> I read through the draft, Tal, and I have a few comments.
>
> Section 3.1:
>
> I think there should be a way to query the server's current time to make sure the client and server agree.  This should be part of the overall dialogue between the two when scheduling will be done.  Even though the client may be configured to use NTP, the server may not have had a chance to sync to its clock source.  You talk about time sync, but I think this extra level of checking will assure that the server doesn't do something the client didn't expect.  At the very least, the client may decide to abort the scheduled operation.
>
> This goes outside of the time tolerance you define in Section 3.5.  I 
> could, for example, say I have a 10 second tolerance in either 
> direction of time 2015-10-21T04:29:00.235.  The server gets a chance 
> to execute at
> 2015-10-21T04:38:00.235 and does, but the actual time on the client is 2015-10-21T05:29:00.235.
>
> Section 3.4:
>
> You introduce time-interval here without really saying how it will be used.  You do this later, but it seemed a bit disjointed to me.  Maybe swap sections 3.4 and 3.5 and mention time-interval in the new section 3.4.
>
> Section 4.5
>
> You define the element <schedule> but you reference it as <scheduled>:
>
> OLD TEXT:
>
> ...operation. Every <rpc> message MAY include the <scheduled>...
>
> NEW TEXT:
>
> ...operation. Every <rpc> message MAY include the <schedule>...
>
> NIT: I would swap the order of <get-time> and <execution-time> as the former references the latter.
>
> Section 4.5.1:
>
> You have two leaf nodes with the name sched-max-past.  They have two different descriptions.  I think the first should be sched-max-future.
>
>> At this point, draft 01 is soft-real-time-oriented. We are interested 
>> to hear feedback about whether there is an interest in the working 
>> group to develop the hard real-time functionality as well.
>
> I think soft time is fine.  However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC.  How would I go about ensuring that an RPC completed (or not) at the scheduled time?
>
> Joe
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>