Hi John-   (I'm back...:-)

These are all very important points, and regarding the temporal scheduling and timing issues these concern me too.    IMO, the solutions we have discussed do not sit well with folks generally speaking - I know I feel like we have created a complex monster to deal with what the user believes to be a relatvely simple request: I need a connection now, please.  (Meaning: I need a connection by any means you have currently avalaible and I only want to know if you have it completed or that your can't do it at the moment.)

I will contact a couple of you to catch up on the current state of the discussion before I comment more. 

Thanks
Jerry

John Vollbrecht wrote: 
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