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