[Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)

[Evangelos Chaniotakis]

I will agree with Jeff on this.


Generally I would say that there are several styles of time-related  
parameters that the client can provide to the NSI.

Let's say desired start time is T, duration is D, bandwidth is B.

And let me have a new parameter X represents a hard "expiration date"  
of the request i.e. the time by which provisioning MUST have happened  
otherwise the reservation should be failed.

I assume that each NSI agent would know at least roughly how long it  
takes it to provision its own network, so if it receives a request  
that arrives too close to time X to provision, it will reject it.

Here are a couple of use cases:
- Video conference at a known time: would have an X very close to T

- Bulk data transfer: could have a large difference between X and T.  
(we could also express the duration - bandwidth parameters as their  
product with floor & ceiling constraints for B and D.. but I digress)

- Immediately-or-fail reservation: would have an X very close to now()

- As-soon-as-possible reservation: would have an X that is somewhat in  
the future


The main idea I think should be that we let the user expressly define  
user-related constraints, and not hard-wire them in the protocol. Not  
that we shouldn't provide reasonable default values, of course..


On Apr 13, 2010, at 9:11 AM, Jeff W.Boote wrote:

> I'd like to encourage everyone to consider this more from the client  
> perspective instead of from the provisioning perspective... The  
> reason to make a circuit reservation is not in isolation. The client  
> is doing this because they want to make some kind of data transfer  
> that certainly involves other resources that also need to be  
> scheduled.
>
> In that context, I think the required semantics become more clear.  
> Give the two-phase commit cycle that is happening anyway, I would  
> expect something like:
>
> 1) Reservation request is for a given time T, and duration D. The  
> semantics of this request from the client perspective should be, I  
> would like to use the circuit at time T. (After all, the client is  
> trying to reserve other resources to use the circuit at that same  
> time.)
>
> 2) The provider determines how 'close' to time T they can actually  
> provision the circuit (after requesting down-stream if chaining).  
> The response should be: you can have reservation time T+delta.  
> (Where delta MUST be as small as the provider can make it.) If  
> T=='now' that would likely produce a greater 'delta' than a T in the  
> more distant future.
>
> When developing the actual protocol, it may also be necessary to  
> also return another time indicating how quickly the client must  
> initiate the second phase of the commit or the reservation  
> automatically nullifies...
>