Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Radek, agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-) Cheers, Artur On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard-time and On-demand connection service.
Inder
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nsi-wg >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nsi-wg > > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/nsi-wg > >
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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
-- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801
All, I agree about deterministic behavior. That is what we are all shooting for :) I am thinking in terms of state machines as well. What I am hearing both of you state that "Start Time" is not really a "Start time"...it is ASAP after "Start time" in case things are not complete? This is fine for a data movement service without hard deadlines, how will you ensure this for a Video conf system that needs to start at a particular time? We have to think of all possible application services that can use NSI. Radek, maybe Guard-time is being misunderstood - I am merely suggesting a gap before which Advanced Reservation Requests are not processed by the domain. There is nothing non-deterministic and immeasurable about that. It is a fixed value, albeit arbitrary value. This reduces the chances of the provisioning system across domains from "thrashing" - i.e. reserving resources and maybe releasing them because the connection did not happen in time. Regardless of the decision on guard-time, for deterministic behavior for many error conditions including start time arriving and reservation is incomplete and start time arriving and provisioning is incomplete. Enjoying the discussion, Inder On Apr 13, 2010, at 5:26 AM, Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard-time and On-demand connection service.
Inder
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nsi-wg >> >> > > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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
-- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801
--- Inder Monga http://100gbs.lbl.gov imonga@es.net http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
Inder, What below you are referring to is "advanced reservation" not immediate reservation which I thought were two different behavior processes based on last week's call. 1) Immediate: If a user needs it right away, the best that can be done is ASAP (the user must be kept abreast of progress). 2) Advanced: If a user needs an advanced reservation then: 1. A confirmed reservation response can happen ASAP back to the user 2. The actual provisioning needs to start with enough of a lead time to assure accurate "start time"... maybe ten or fifteen minutes ahead of schedule. Does this make sense? Gigi Inder Monga wrote:
All,
I agree about deterministic behavior. That is what we are all shooting for :) I am thinking in terms of state machines as well.
What I am hearing both of you state that "Start Time" is not really a "Start time"...it is ASAP after "Start time" in case things are not complete? This is fine for a data movement service without hard deadlines, how will you ensure this for a Video conf system that needs to start at a particular time? We have to think of all possible application services that can use NSI.
Radek, maybe Guard-time is being misunderstood - I am merely suggesting a gap before which Advanced Reservation Requests are not processed by the domain. There is nothing non-deterministic and immeasurable about that. It is a fixed value, albeit arbitrary value. This reduces the chances of the provisioning system across domains from "thrashing" - i.e. reserving resources and maybe releasing them because the connection did not happen in time.
Regardless of the decision on guard-time, for deterministic behavior for many error conditions including start time arriving and reservation is incomplete and start time arriving and provisioning is incomplete.
Enjoying the discussion, Inder
On Apr 13, 2010, at 5:26 AM, Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl <mailto:radek.krzywania@man.poznan.pl> Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org <mailto:nsi-wg-bounces@ogf.org> [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard-time and On-demand connection service.
Inder
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 <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:nsi-wg@ogf.org> >> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:nsi-wg@ogf.org> >>>> <mailto: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 <mailto:vdham@uva.nl> >>>> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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 <mailto: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
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi, What is a hard deadline service? Any example? Is it synchronised with GPS? With what is it synchronised? What does it mean I want a reservation at 14:34 GMT? Is it 14:34 on requestor clock, atomic clock in e.g. Switzerland, synchronised GPS time (still ms of differences)? Different time zone, different clocks. If you not synchronise domain clocks you can’t talk about time in so exact manner as I feel you want to. Which clock are we referencing? Being honest – I am not really against “thrashing”, and especially not against race conditions. It will be an issue when number of request will be quite high and competition for resources will be high. For now, facing the current demand for dynamic services, it’s not an issue at all. Not in version 1. Besides, how to solve race conditions is more an implementation issue (out of scope then), not a protocol. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and <mailto:radek.krzywania@man.poznan.pl> radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 <http://www.man.poznan.pl> http://www.man.poznan.pl ________________________________________________________________________ From: Inder Monga [mailto:imonga@es.net] Sent: Tuesday, April 13, 2010 2:49 PM To: Artur Barczyk Cc: radek.krzywania@man.poznan.pl; nsi-wg@ogf.org; 'Guy Roberts' Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes) All, I agree about deterministic behavior. That is what we are all shooting for :) I am thinking in terms of state machines as well. What I am hearing both of you state that "Start Time" is not really a "Start time"...it is ASAP after "Start time" in case things are not complete? This is fine for a data movement service without hard deadlines, how will you ensure this for a Video conf system that needs to start at a particular time? We have to think of all possible application services that can use NSI. Radek, maybe Guard-time is being misunderstood - I am merely suggesting a gap before which Advanced Reservation Requests are not processed by the domain. There is nothing non-deterministic and immeasurable about that. It is a fixed value, albeit arbitrary value. This reduces the chances of the provisioning system across domains from "thrashing" - i.e. reserving resources and maybe releasing them because the connection did not happen in time. Regardless of the decision on guard-time, for deterministic behavior for many error conditions including start time arriving and reservation is incomplete and start time arriving and provisioning is incomplete. Enjoying the discussion, Inder On Apr 13, 2010, at 5:26 AM, Artur Barczyk wrote: Hi Radek, agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-) Cheers, Artur On 04/13/2010 02:15 PM, Radek Krzywania wrote: Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________ -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes) Hi Inder, I see, thanks for this clarification. I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line: On 04/12/2010 11:15 PM, Inder Monga wrote: Hi All, I feel there is a lot of confusion, so let me try to explain my case/understanding. 1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains. What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright. Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.) With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider. 2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait. Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter. Does this make more sense? I will answer specifics below. [...] 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. In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon. No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place. IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources. 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", I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used. Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one? but "a minute from now", which would lead to the same problem if the time to A minute from now actually becomes a "scheduled connection" and there is where the problem really starts. I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.) Is there other reasons? Cheers, Artur I feel we should support both Advanced Reservation with guard-time and On-demand connection service. Inder 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg --- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o) -- 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 -- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801 --- Inder Monga http://100gbs.lbl.gov imonga@es.net http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
Hi Inder, All, On 04/13/2010 02:48 PM, Inder Monga wrote:
All,
I agree about deterministic behavior. That is what we are all shooting for :) I am thinking in terms of state machines as well.
What I am hearing both of you state that "Start Time" is not really a "Start time"...it is ASAP after "Start time" in case things are not complete? This is fine for a data movement service without hard deadlines, how will you ensure this for a Video conf system that needs to start at a particular time? We have to think of all possible application services that can use NSI.
Exactly - if I need to start the VC in the next 5 minutes, it won't help me to wait for a guard time of 10 (as example). I would prefer to have it start as soon as possible. But if I have to schedule a VC in an hour from now, then there's no issue anyway (always assuming the resources are plenty). Cheers, Artur
Radek, maybe Guard-time is being misunderstood - I am merely suggesting a gap before which Advanced Reservation Requests are not processed by the domain. There is nothing non-deterministic and immeasurable about that. It is a fixed value, albeit arbitrary value. This reduces the chances of the provisioning system across domains from "thrashing" - i.e. reserving resources and maybe releasing them because the connection did not happen in time.
Regardless of the decision on guard-time, for deterministic behavior for many error conditions including start time arriving and reservation is incomplete and start time arriving and provisioning is incomplete.
Enjoying the discussion, Inder
On Apr 13, 2010, at 5:26 AM, Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl <mailto:radek.krzywania@man.poznan.pl> Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org <mailto:nsi-wg-bounces@ogf.org> [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard-time and On-demand connection service.
Inder
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 <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:nsi-wg@ogf.org> >> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:vdham@uva.nl> >>>> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> <mailto: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 <mailto:nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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 <mailto: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
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801
Artur, I thought that we had agreed on the two-phase-commit - like behavior .... where all reservation responses must be complete prior to and provisioning on any part of the path? Gigi Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard-time and On-demand connection service.
Inder
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nsi-wg >> >> >> > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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
Hi Gigi, reading up on some mails I missed earlier, I understood two-phase commit is left out for a later release (v2). Q (to all): when is v2 supposed to be released? Is v1 supposed to be of any importance as a standard? If so, then I'd expect v2 not to follow before ~2015? If v1 is just a working release, then we can experiment... Cheers, Artur On 04/13/2010 03:10 PM, Gigi Karmous-Edwards wrote:
Artur,
I thought that we had agreed on the two-phase-commit - like behavior .... where all reservation responses must be complete prior to and provisioning on any part of the path?
Gigi
Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard-time and On-demand connection service.
Inder
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> >>> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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
-- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801
On Apr 13, 2010, at 9:10 AM, Gigi Karmous-Edwards wrote:
Artur,
I thought that we had agreed on the two-phase-commit - like behavior .... where all reservation responses must be complete prior to and provisioning on any part of the path?
I think that the two phase commit could be just on each part of the path if notification is used to identify when the whole path is available. This would allow each segment to be provisioned independently. In the "now" case a segment could provision as soon as its reservation was complete. It would respond with reservation complete, then when provisioning is done it would notify provisioning done. This keeps reservation and provisioning orthogonal.
Gigi
Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non- deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http:// www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
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.
In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
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",
I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
but "a minute from now", which would lead to the same problem if the time to
A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard- time and On-demand connection service.
Inder
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> >>> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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... jeff On Apr 13, 2010, at 8:51 AM, John Vollbrecht wrote:
On Apr 13, 2010, at 9:10 AM, Gigi Karmous-Edwards wrote:
Artur,
I thought that we had agreed on the two-phase-commit - like behavior .... where all reservation responses must be complete prior to and provisioning on any part of the path?
I think that the two phase commit could be just on each part of the path if notification is used to identify when the whole path is available. This would allow each segment to be provisioned independently. In the "now" case a segment could provision as soon as its reservation was complete. It would respond with reservation complete, then when provisioning is done it would notify provisioning done. This keeps reservation and provisioning orthogonal.
Gigi
Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non- deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
Hi All,
I feel there is a lot of confusion, so let me try to explain my case/understanding.
1. Guard-time: This concept was proposed for Advanced Scheduling only. This can be a default value and it does not have to be an "exact" measurement of provisioning times. It only handles path computation and reservation times across domains.
What does it mean to a user? A user CANNOT ask for a advanced reservation connection with Tstart < Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + Guard-time, the scheduled request is rejected outright.
Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
With an ADvanced Scheduling function, provisioning initiation can happen from both the user or the provider.
2. On-Demand Service: In my opinion, Guard-time does not prevent an On-Demand service as specified by Jerry. They co-exist. An on-demand service, with Tstart = ASAP can be implemented very easily. The service starts when the "provisioning complete" message is received by the user. If the user does not receive that message, it continues to wait.
Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
Does this make more sense?
I will answer specifics below.
[...]
> 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. > In advanced reservation, the open question is what should a domain do if Tstart comes, and it has not got a reservation complete or provision message? Should it delete the connection or provision its own set of resources? Chin and I include this case in the error recovery document to be published soon.
No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
> 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", > I think the "now" case is actually, "as soon as possible" - which is the on-demand case. Then it just waits for the right message from the Provider Agent before it knows the connection is available to be used.
Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
> but "a minute from now", which would lead to the same problem > if the > time to > A minute from now actually becomes a "scheduled connection" and there is where the problem really starts.
I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
I feel we should support both Advanced Reservation with guard- time and On-demand connection service.
Inder
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>> _______________________________________________ >>>>> nsi-wg mailing list >>>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>> >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> >>>> >>>> >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/nsi-wg > --- Inder Monga http://100gbs.lbl.gov imonga@es.net <mailto:imonga@es.net> http://www.es.net (510) 499 8065 (c) (510) 486 6531 (o)
-- 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
_______________________________________________ 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
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...
This is a right Jeff. We have to assume that the "start time" is when the user wants the connection to be In-Service, and likewise that the connection will remain In-Service until the "end time". Any provisioning phase time that is required to meet those start and end constraints probably does need to be anticipated by the provider. But the provider is no better able to estimate an appropriate takeoff runway than the user except perhaps for those local network resources that the provider manages. And these will be an estimate as well. But if we do it right, we can probably build an estimate provisioning time from the NRM up thru the tree to the root RA. But whatever time the provider chooses as the takeoff runway, this needs to be considered at the Reservation phase: Unless there is a deterministic and predictable provisioning process, we must assume that any particular switch along the connection path may be reconfigured at anytime during that provisioning phase and that whatever previous connection was in place will be broken. If the provider begins provisioning 5 minutes prior to start time, then the provider may be cutting off a previous reservation. To insure this doesn't happen, the provider must /reserve/ the provisioning window 5 minutes before it was requested. In essence, we are now defining a provider specified /Provisioning start time/ in addition to just the user defined /In-service start time/. Even so, this issue is IMO very important to have it solved in a predictable reliable and deterministic fashion so that certain assurances can be provided to the RAs up the tree and ultimately to the original requester. The whole guarranteed resource model breaks if we cannot make this a deterministic bounded process. Perhaps we can pass the In-Service Start Time (from the user) down the tree in Reserve() requests, and the ReserveComplete() messages returns a Provisioning Start Time up the tree. On the way up the tree, each NSA reserves the resources for the Provisioning Start Time until the In-Service End Time. ??? I think there may still be some issues to consider, but I propose we think down this path. Jerry 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...
jeff
On Apr 13, 2010, at 8:51 AM, John Vollbrecht wrote:
On Apr 13, 2010, at 9:10 AM, Gigi Karmous-Edwards wrote:
Artur,
I thought that we had agreed on the two-phase-commit - like behavior .... where all reservation responses must be complete prior to and provisioning on any part of the path?
I think that the two phase commit could be just on each part of the path if notification is used to identify when the whole path is available. This would allow each segment to be provisioned independently. In the "now" case a segment could provision as soon as its reservation was complete. It would respond with reservation complete, then when provisioning is done it would notify provisioning done. This keeps reservation and provisioning orthogonal.
Gigi
Artur Barczyk wrote:
Hi Radek,
agree, but just to note, it's not about deterministic time, but deterministic behaviour I am worried about. I don't see a stable system where one part can be in provisioning while another in reservation. Guard time will not solve this by itself, even if you make it 2 months :-)
Cheers, Artur
On 04/13/2010 02:15 PM, Radek Krzywania wrote:
Hi, I tried to catch up the discussion, hope I did not missed anything. What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Artur Barczyk Sent: Tuesday, April 13, 2010 10:11 AM To: Inder Monga Cc: nsi-wg@ogf.org; Guy Roberts Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
Hi Inder,
I see, thanks for this clarification.
I still think we are introducing an artificial decision step here, which will just be confusing to the end-user (and make the whole system more complex), and I still wonder about the necessity of it. Please see in-line:
On 04/12/2010 11:15 PM, Inder Monga wrote:
> Hi All, > > I feel there is a lot of confusion, so let me try to explain my > case/understanding. > > 1. Guard-time: > This concept was proposed for Advanced Scheduling only. This can be a > default value and it does not have to be an "exact" measurement of > provisioning times. It only handles path computation and reservation > times across domains. > > What does it mean to a user? > A user CANNOT ask for a advanced reservation connection with Tstart < > Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + > Guard-time, the scheduled request is rejected outright. > Imagine I try to make a connection "NOW", and it gets refused after N minutes due to lack of resources. Then I try "2 minutes from now", and it gets rejected straight off. We shouldn't aim at having expert users who would understand this. I think the system should behave in the same (and deterministic) way, independent of what the user states in reservation time. (Btw - that the reservation and provisioning time might vary does not make it less deterministic.)
> With an ADvanced Scheduling function, provisioning initiation can happen > from both the user or the provider. > > 2. On-Demand Service: In my opinion, Guard-time does not prevent an > On-Demand service as specified by Jerry. They co-exist. > An on-demand service, with Tstart = ASAP can be implemented very easily. > The service starts when the "provisioning complete" message is received > by the user. If the user does not receive that message, it continues to > wait. > Exactly what I was aiming at - but the same logic can apply to any time between "NOW" and the guard time, or doesn't it? All you need to do, if the start time is reached before the reservation is complete, to wait for the latter.
> Does this make more sense? > > I will answer specifics below. > > [...]
>> 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. >> > In advanced reservation, the open question is what should a domain do if > Tstart comes, and it has not got a reservation complete or provision > message? Should it delete the connection or provision its own set of > resources? Chin and I include this case in the error recovery document > to be published soon. > No, no - simply wait for the reservation to complete. Only then will you know if it succeeded in the first place.
IMO, the provisioning and reservation systems cannot be completely decoupled. The provisioning stage should actually never be reached until a reservation is complete. It is dependent on the outcome of the path computation as well as resource reservation. Never go to provisioning before you know you can have the resources.
>> 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", >> > I think the "now" case is actually, "as soon as possible" - which is the > on-demand case. Then it just waits for the right message from the > Provider Agent before it knows the connection is available to be used. > Yes, absolutely agree - that's a discussion terminology, which I'd be happy to change :-) However, we need to be precise on what we mean. An "ASAP" reservation, from a user's point of view, could mean really "any time possible, starting from now", i.e. also in 2 hours, if the resources will only then become available. I am not sure BoD does mean that. Will in such a case a BoD reservation be converted into a scheduled one?
>> but "a minute from now", which would lead to the same problem if the >> time to >> > A minute from now actually becomes a "scheduled connection" and there is > where the problem really starts. > I am sorry I have missed large parts of this discussion, being kept off with other workload. Sorry if I am coming back to things which might be obvious to you by now. But I do not really understand where the problem really is. You mention the provisioning system to have to decide what to do if the reservation step is not complete - but I think the right design decision would be that the system should never actually be in such a state. (Sorry, I am falling into thinking in terms of state machines here, but well, that's what I start to believe would be good here.)
Is there other reasons?
Cheers, Artur
> I feel we should support both Advanced Reservation with guard-time and > On-demand connection service. > > Inder > > >> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nsi-wg@ogf.org> >>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>> _______________________________________________ >>>>>> nsi-wg mailing list >>>>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>> >>>>> _______________________________________________ >>>>> nsi-wg mailing list >>>>> nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> >>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg@ogf.org <mailto: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 <mailto:nsi-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nsi-wg >> > --- > Inder Monga http://100gbs.lbl.gov > imonga@es.net <mailto:imonga@es.net> http://www.es.net > (510) 499 8065 (c) > (510) 486 6531 (o) > > -- 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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto: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
participants (8)
-
Artur Barczyk -
Evangelos Chaniotakis -
Gigi Karmous-Edwards -
Inder Monga -
Jeff W.Boote -
Jerry Sobieski -
John Vollbrecht -
Radek Krzywania