[Nsi-wg] time issue

[Jerry Sobieski]

Hi Artur-

Artur Barczyk wrote:
> Hi Jerry,
>
>   
>> This will bound the problem - the network will deliver within one 
>> minute of the scheduled start time, or declare a fault condition and 
>> fall on its sword.   We can discuss if this is adequate for V1.0.   
>> And what the recovery action should be:   release the connection and 
>> notify the user? notify the user and continue provisioning? ...?
>>     
>
> I think a related, just as important question is, do you extend the 
> termination time? For an application which
> has to transfer N TBs of data, starting 20 minutes late might be useless 
> if the requested reservation time
> is shortened by that... I admit a videoconferencing app will prefer to wait.
>
>   
This is IMO first a policy question - who is following you in the 
resource schedule?   Are you  more important than they are?

 From a purely technical point, the reservation only reserved the 
resources for the prearranged time.  To extend that reservation would 
require changing the resource reservation all up and down the tree.   
Even if I said "sure give him extra time" another NSA may say "whooaa 
hold on! - I did my part- I was on time...why should I extend his 
reservation just because some chump NSA downstream couldn't meet their 
commitment? "

For this reason, I would say the simple thing is to NOT extend the 
reservation.  At least in V1.0.    The fact is that probably the vast 
majority of our Start Times will be met successfully, and that the very 
few that miss will probably only miss by a relative "little bit" and the 
cost of extending will not be worth the complexity and arguments we will 
have to figure out how to do it:-).
Frankly, I would recommend to users that if they need to transfer a 
known data quantity, they should add some buffer to handle such 
contingencies - some of which may not be network related at all.

Another policy option is to try to encourage users to reserve MORE time 
than they need and Relesae early if they get done early.    We all know 
better than to plan things too tightly - especially in complex 
interdependet systems.  Always have some room to manuver!
>  From the protocol point of view, terminating would be the cleanest 
> thing to do. With the right configuration
> of provisioning times in each domain, a timeout of a minute, say, would 
> indicate a deeper problem, so waiting might
> be pointless.
>   
Exactly.
> However, an alternative would be to keep the user (agent/application) in 
> wait state until provisioning successful or
> termination time - whatever comes first. The user app can then abort if 
> it thinks it's beyond repair, and try to
> reschedule. But this implies that there is always a status (change) 
> notification to the user agent. Then we can get rid
> of the timeout, actually.
> (Note that's not contradicting my earlier statements - the goal remains 
> to provision at the requested time.)
>
>   
Yeah, a timeout is useful for the protocol more generally.    You never 
leave a protocol in a non-terminal state.  There should always be a way 
for the state machine to terminate.  If we issue a Provision down the 
tree and nothing ever comes back...at some point we have to assume 
something is wrong (!)   And we have to be able to recover if nothings 
is ever EVER going to come back (the NSA died some how...)   The timeout 
does this.   When we wake up and realize nothings happened from below, 
we can eitehr check on progress, or just bail out.   So, we can either 
issue a query() request down "Are we there yet?" "Nope, still working", 
or we can issue a notify up "Working, please stand by." "ok, thanks"  
after which the RA waits some more or bails out with a Release.

This why we need a timeout value for all transient states Reserving, 
Provisioning, Releasing so that we don't hang indefinately on some delay 
from below.  The other states will have the calandar alarm to kick them 
out of Scheduled and In Service.   Each state's timeout may be 
different, and the action may be differnet.
But this gets into error conditions...

BR
Jerry
> Cheers,
> Artur
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100930/8df80f4f/attachment.html