[Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Guy Roberts
Guy.Roberts at dante.net
Mon Apr 12 11:34:38 CDT 2010
Artur,
>I think guard time is a shaky concept
Agreed, it is not an elegant engineering solution in any way, so I would like to find a way to avoid it if we can. Hence the survey proposal that I have just sent out in my last email.
> "wait for start time"
This is intended to mean that once the reservation has been accepted, the realtime-clock in the provider NSA should wait until it reaches the value held in the 'start time' field of the reservation request sent by the requester NSA.
Guy
-----Original Message-----
From: Artur Barczyk [mailto:Artur.Barczyk at cern.ch]
Sent: 12 April 2010 17:28
To: nsi-wg at ogf.org
Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi,
I think guard time is a shaky concept, as who can tell how long it should
be - it can/will depend on the number of domains the circuit contains, the
speed of each reservation/provisioning system as well as the load on the
system, and will be variable over time (hoping for faster
reservation/provisioning
systems in the future).
But: if in step 5, the "wait for start time" means t_start <= t_current,
then the
provider will immediately pass on to provisioning.
What needs to be done however is to have the duration of the reservation
reflect the time difference between desired start time and the effective
one.
I am sure I am missing something..?
Cheers,
Artur
On 04/12/2010 11:12 AM, Guy Roberts wrote:
> Jeroen,
>
> Yes, that is correct. But the mechanism will be the same for advance reservations, just a later start time.
>
> Guy
>
> -----Original Message-----
> From: Jeroen van der Ham [mailto:vdham at uva.nl]
> Sent: 12 April 2010 08:19
> To: Guy Roberts
> Cc: John Vollbrecht; nsi-wg at ogf.org
> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
>
> To sum this up, this describes a situation where there is no prior
> reservation and provisioning is started immediately because the
> startTime is meant as a "now"?
>
> Jeroen.
>
>
> On 09/04/2010 18:56, Guy Roberts wrote:
>> John,
>>
>> My thinking of how it could work is as follows (though the details are really part of the protocol definition group's work):
>>
>> StartTime= time when the provisioning is begun. This is the only possible meaning for StartTime since we have no way of knowing how long the provisioning will take in advance of the provisioning being performed. i.e provisioning completion time is non-deterministic. For consistency as an asynchronous system, the completion of provisioning (in-service) is pushed by the NRM to the Provider which in turn sends this to the Requestor as a notification.
>>
>>
>> Locally initiated provisioning:
>> 1. The Requester NSA creates a request with a start time (StartTime). StartTime= NSAs current time + Requester guard time. Eg 12:00pm + 5 minutes = 12:05pm.
>> 2. Provider validates the start time as being at least the provider guard time away from now. (note requester and provider guard times could be a little different to allow for transmission delay of request)
>> 3. Provider begins the reservation process (12:01pm)
>> 4. Provider completes the reservation (12:02pm)
>> 5. Provider waits for the startTime (12:05pm)
>> 6. Provider starts provisioning locally (12:05pm)
>> 7. Provider waits for confirmation of provisioning from NRM (12:06pm)
>> 8. Provider sends a notification to the requestor NSA to notify that the connection is in-service (12:06pm)
>>
>> Provisioning signalled by Requester:
>> 1. The Requester NSA creates a request with a start time (StartTime). StartTime= NSAs current time + Requester guard time. Eg 12:00pm + 5 minutes = 12:05pm.
>> 2. Provider validates the start time as being at least the provider guard time away from now. (note requester and provider guard times could be a little different to allow for transmission delay of request)
>> 3. Provider begins the reservation process (12:01pm)
>> 4. Provider completes the reservation (12:02pm)
>> 5. Provider waits for the startTime (12:05pm)
>> 6. Provider waits for the signal to provision (12:10pm)
>> 7. Provider initiates provisioning of the Connection (12:10pm)
>> 7. Provider waits for confirmation of provisioning from NRM (12:11pm)
>> 8. Provider sends a notification to the requestor NSA to notify that the connection is in-service (12:11pm)
>>
>>
>> Guy
>>
>>
>>
>> -----Original Message-----
>> From: John Vollbrecht [mailto:jrv at internet2.edu]
>> Sent: 09 April 2010 17:28
>> To: Guy Roberts
>> Cc: John Vollbrecht; Tomohiro Kudoh; Jeroen van der Ham; nsi-wg at ogf.org
>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
>>
>> I am still a bit confused. Perhaps someone could do a timing diagram
>> like the one Tomohiro did a while ago when we were discussing 2 phase
>> commits.
>>
>> I will try to explain my confusion. My understanding has been that we
>> agreed that provisioning would never be done without prior
>> reservation. So it would seem that the question being discussed is
>> "what is the time being requested in a reservation". If the
>> reservation succeeds then provisioning can happen.
>>
>> It seems to me one question is how to define the start time being
>> requested. The options seem to be that is is either 1) the time the
>> circuit is actually provisioned and ready to use or 2) the time that
>> provisioning of the circuit starts. In one case the previous
>> connection may terminate sooner by the guard time and in the latter it
>> may start later by the guard time. If it is (1) then a connection
>> scheduled for now must have been started at [now - (start time)].
>>
>> A second question is whether is is possible to request a connection
>> that starts "now". This implies reserving a connection and initiating
>> it as soon as it is reserved. Assume that start time is when
>> provisioning a circuit starts (case 2 above). It seems that main
>> issue with this is whether the time to reserve a connection is longer
>> than the requestor is willing to wait. The time it takes depends on
>> how many NSAs are "chained" to satisfy the request and how long each
>> NSA takes to reserve the connection. This time is "authorization
>> time" not guard time as I understand it.
>>
>> There is another issue with defining authorization as "now" instead of
>> a specific time. The problem is that each NSA in a chain will think
>> authorization happens at a slightly different time. I am not sure how
>> important this is - it doesn't seem too important to me, but perhaps I
>> am wrong. If provisioning starts after the reservation is complete,
>> then everything should be reserved, if at a slightly different time.
>> ----------------------------------
>>
>> I think Guy is suggesting that start time is when provisioning starts
>> (case 2) above. That seems simplest to me.
>> I am not sure the provisioning time is important, and if not I would
>> think it good to include "immediate" reservation
>>
>> John
>>
>>
>> On Apr 9, 2010, at 11:15 AM, Guy Roberts wrote:
>>
>>> Tomohiro,
>>>
>>>> In this case, only some parts of inter-network connection will be
>>>> provisioned.
>>>
>>> Right, I forgot about this reason - it is a good point. Again, I
>>> think we are not complicating things too much if we have a rule that
>>> the Requester NSA cannot send a start time sooner than now+guardtime.
>>>
>>> I think we can solve the chain issue by not forcing any value for
>>> the guard time. This can be a policy decision to suit the service
>>> type, equipment and number of networks involved.
>>>
>>> Guy
>>>
>>> -----Original Message-----
>>> From: Tomohiro Kudoh [mailto:t.kudoh at aist.go.jp]
>>> Sent: 09 April 2010 09:04
>>> To: Jeroen van der Ham
>>> Cc: nsi-wg at ogf.org
>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf
>>> call minutes)
>>>
>>> Hi Jeroen,
>>>
>>> There is a problem for inter-network connection. During the
>>> discussions
>>> in some calls, the problem of synchronizing networks (managed by
>>> different NSAs) was discussed.
>>>
>>> If you use the "now" type request for inter-network connection
>>> (without
>>> complicated coordination), the actual provisioning time of networks
>>> may
>>> be different. Moreover, some networks may provision resources before
>>> some other networks reply to the request, and such networks might deny
>>> the request. In this case, only some parts of inter-network connection
>>> will be provisioned.
>>>
>>> The guard time is one of the simple solutions to solve this problem. I
>>> understand there can be multiple ways to cope with this, but all of
>>> them
>>> will introduce some complication to some part (note that we decided
>>> not
>>> to use 2PC for the v1.0). This is a design choice matter.
>>>
>>> Regards,
>>>
>>> Tomohiro
>>>
>>>
>>> On Thu, 08 Apr 2010 09:27:59 +0200
>>> Jeroen van der Ham <vdham at uva.nl> wrote:
>>>
>>>> On 07/04/2010 15:02, Tomohiro Kudoh wrote:
>>>>> If a requester wants resources to be provisioned as soon as
>>>>> possible, it
>>>>> can set the start time parameter in a advance request to:
>>>>> (current time + guard time + a certain time required for message
>>>>> delivery).
>>>>>
>>>>> In this way, immediate provisioning can be requested by an advance
>>>>> reservation request.
>>>>
>>>> The procedure above seems overly complicated and if I really am
>>>> pressed
>>>> for time, and I miscalculate the (current time + guard time +
>>>> delivery
>>>> time) by a few seconds. Denying the request means that I have to do
>>>> it
>>>> all over again, making me even more pressed for time.
>>>>
>>>> Why not keep things simple and always interpret a start time in the
>>>> past
>>>> as "now" ? (provided the end-time is in the future too)
>>>> Would there be any problems associated with that?
>>>>
>>>> Jeroen.
>>>
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
--
Dr Artur Barczyk
California Institute of Technology
c/o CERN, 1211 Geneve 23, Switzerland
Tel: +41 22 7675801
_______________________________________________
nsi-wg mailing list
nsi-wg at ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg
More information about the nsi-wg
mailing list