Hi Guy,

On 04/12/2010 06:34 PM, Guy Roberts wrote:

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.

That part of the problem I believe I understood :-)
What I meant is that if that time has passed by the time the provider
NSA gets notified of the reservation acceptance along the path, it
should proceed directly to provisioning.

You have to do this anyway, to protect against the guard time being
set too short. In which case you can just as well set the guard time to 0.

That's just common sense, IMO, what it means when I would ask for immediate
circuit provisioning. "Please give it to me as soon as you're able to,
I'm waiting."

The thing not to forget is that someone can ask for a circuit not only
"now",

but "a minute from now", which would lead to the same problem if the time to

process the reservation is longer than a minute (as it most probably will be
in the next future).
So the "now" string as in your option 2) would only work for a singular
subset of the
problem.

Cheers,
Artur

Guy

-----Original Message-----

From: Artur Barczyk [mailto:Artur.Barczyk@cern.ch]

Sent: 12 April 2010 17:28

To: nsi-wg@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@uva.nl]

Sent: 12 April 2010 08:19

To: Guy Roberts

Cc: John Vollbrecht; nsi-wg@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@internet2.edu]

Sent: 09 April 2010 17:28

To: Guy Roberts

Cc: John Vollbrecht; Tomohiro Kudoh; Jeroen van der Ham; nsi-wg@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@aist.go.jp]

Sent: 09 April 2010 09:04

To: Jeroen van der Ham

Cc: nsi-wg@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@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@ogf.org

http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________

nsi-wg mailing list

nsi-wg@ogf.org

http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________

nsi-wg mailing list

nsi-wg@ogf.org

http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________

nsi-wg mailing list

nsi-wg@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@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg