Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
13 Apr
2010
13 Apr
'10
8:51 p.m.
I agree with these comments. At 08:42 AM 4/13/2010, Radek Krzywania wrote: >Hi, Indeed, I forgot about NTP. But still my >opinion is that we are unable to assure time >precision at the level of seconds. Yes, seconds in a metro area. >Minutes are far more probable. However, certainly in the near term (e.g., the next two years). minutes are to be expected. Furthermore, in part because of this timing issue, as I have noted previously, the distinction between "Immediate" and "Advanced" is artificial. *All* requests are for future resources. There is no reason to treat a request for resources required "as soon as possible" from other requests. The only difference is timing, and all the timing is in the future. These issues of timing belong to an external scheduler - not to the protocol, except possibly in terms of a time-to-live flag for the signal. > Regarding race conditions, it's not the role of the protocol to prevent it. I very much agree with this. There is a tendency in these types of initiatives to expand the scope of the standard. These tendencies should be resisted vigorously. > Protocol operates in the area of single > service definitions (how to request and process > the request), while software will deal with > simultaneous requests at different states and > distributed in time (also overlapping). That's > my opinion, unless someone will convince me > otherwise :) 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: Artur > Barczyk [mailto:Artur.Barczyk@cern.ch] > Sent: > Tuesday, April 13, 2010 3:28 PM > To: > radek.krzywania@man.poznan.pl > Cc: 'Inder > Monga'; nsi-wg@ogf.org; 'Guy Roberts' > > Subject: Re: [Nsi-wg] Immediate/Advance > reservation (Re: NSI conf call > > minutes) > > > > On 04/13/2010 03:14 PM, Radek > Krzywania wrote: > > 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? > > I think > it's not as bad as it sounds, NTP precision is > enough at the time > scales we will ever be > able to aim at reaching. :-) > > 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. > > Radek, > here I think you're wrong, sorry. In the > context of multi-domain, the > protocol has to > be defined in a way to avoid pitfalls such as > race > conditions. > (among other things) > > > Cheers, > Artur > > > > > > > > > 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 > > > > > ________________________________________________________________________ > > > > > > > > > *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 > <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 > > > > > 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 > > > > > > > > > > > > > > > > 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> > > > > > <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 > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > 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 > 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 > 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 > 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 > 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 > _______________________________________________ > nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg Joe Mambretti, Director tel 312.503.0735 International Center for Advanced Internet Research fax 312.503.0745 750 North Lake Shore Drive, Suite 600 www.icair.org Northwestern University, Chicago, Illinois 60611
14 Apr
14 Apr
11:58 a.m.
New subject: Immediate/Advance reservation (Re: NSI conf call minutes)
Well said Joe. Very good points, particularly about the similarities of advanced vs immediate. I agree completely. But we do run into some real protocol issues since previous protocols did not deal with a time constraints. In order to support the time constraint we need to understand what the "promise" is to the user within the NSI: If the promise is to provide a connection with certain characteristics (one being start time to end time) we need to anticipate the timing issues associated with resource reservation and provisioning as we change states. There are easy ways to punt the issue: For instance, we can state that provisioning begins at the start time. This is simple from the protocol and scheduling issues, but it means the user has no guarrantee of when the connection will actually be usable!... So I don't think in all fairness this is an appropriate way to handle it...we need to take Jeff's comments to heart: What does the user expect from these service interfaces? IMO, the start time should be the "In-Service start time", and if we need a "Provisioning start time" parameter someplace, then we figure out how to bound it authoritatively and do that. Jerry Joe Mambretti wrote: > I agree with these comments. > > At 08:42 AM 4/13/2010, Radek Krzywania wrote: >> Hi, Indeed, I forgot about NTP. But still my opinion is that we are >> unable to assure time precision at the level of seconds. > > Yes, seconds in a metro area. > >> Minutes are far more probable. > > However, certainly in the near term (e.g., the next two years). > minutes are to be expected. Furthermore, in part because of this > timing issue, as I have noted previously, the distinction between > "Immediate" and "Advanced" is artificial. *All* requests are for > future resources. There is no reason to treat a request for resources > required "as soon as possible" from other requests. The only > difference is timing, and all the timing is in the future. These > issues of timing belong to an external scheduler - not to the > protocol, except possibly in terms of a time-to-live flag for the signal. > >> Regarding race conditions, it's not the role of the protocol to >> prevent it. > > I very much agree with this. There is a tendency in these types of > initiatives to expand the scope of the standard. These tendencies > should be resisted vigorously. > >> Protocol operates in the area of single service definitions (how to >> request and process the request), while software will deal with >> simultaneous requests at different states and distributed in time >> (also overlapping). That's my opinion, unless someone will convince >> me otherwise :) 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 <http://www.man.poznan.pl/> >> ________________________________________________________________________ >> > -----Original Message----- > From: Artur Barczyk [ >> mailto:Artur.Barczyk@cern.ch] > Sent: Tuesday, April 13, 2010 3:28 PM >> > To: radek.krzywania@man.poznan.pl > Cc: 'Inder Monga'; >> nsi-wg@ogf.org; 'Guy Roberts' > Subject: Re: [Nsi-wg] >> Immediate/Advance reservation (Re: NSI conf call > minutes) > > > > >> On 04/13/2010 03:14 PM, Radek Krzywania wrote: > > 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? > > >> I think it's not as bad as it sounds, NTP precision is enough at the >> time > scales we will ever be able to aim at reaching. :-) > > 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. > > Radek, here I >> think you're wrong, sorry. In the context of multi-domain, the > >> protocol has to be defined in a way to avoid pitfalls such as race > >> conditions. > (among other things) > > Cheers, > Artur > > > > > > > >> > > 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 <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 < >> mailto:radek.krzywania@man.poznan.pl> > > >> Networking Center > > > > +48 61 858 20 >> 28 http://www.man.poznan.pl >> <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 <http://100gbs.lbl.gov/> > > > > >> imonga@es.net < mailto:imonga@es.net> < mailto:imonga@es.net> > >> > http://www.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 >> <http://100gbs.lbl.gov/> > > imonga@es.net < mailto:imonga@es.net> > >> > http://www.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 > > > Joe Mambretti, Director tel > 312.503.0735 > International Center for Advanced Internet Research fax 312.503.0745 > 750 North Lake Shore Drive, Suite 600 > _www.icair.org_ <http://www.icair.org/> > Northwestern University, Chicago, Illinois 60611 > > ------------------------------------------------------------------------ > > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg >
12:23 p.m.
New subject: Immediate/Advance reservation (Re: NSI conf call minutes)
I agree with your comments. These issues are design decisions. The protocol can be designed only as a request for resources, completely agnostic to any type of timing, including a time-to-live flag for the signal. Or it can be designed to include some type of "promised" service. Note that when you make a call, you have an high degree of expectation of completing the connection. However, sometimes, you receive a busy signal, a message indicating that "all circuits are busy" or the line is dropped. There are no absolutes in communications. One consideration with this protocol is that in general in the near term (next 3 years) these requests will be made for large scale resources that will be required for extended periods (hours, days, perhaps week). In these types of cases an initial delay in set up is generally expected and tolerated. At 06:58 AM 4/14/2010, Jerry Sobieski wrote: >Well said Joe. Very good points, particularly >about the similarities of advanced vs immediate. I agree completely. > >But we do run into some real protocol issues >since previous protocols did not deal with a >time constraints. In order to support the time >constraint we need to understand what the >"promise" is to the user within the NSI: If the >promise is to provide a connection with certain >characteristics (one being start time to end >time) we need to anticipate the timing issues >associated with resource reservation and provisioning as we change states. > >There are easy ways to punt the issue: For >instance, we can state that provisioning begins >at the start time. This is simple from the >protocol and scheduling issues, but it means the >user has no guarrantee of when the connection >will actually be usable!... So I don't think in >all fairness this is an appropriate way to >handle it...we need to take Jeff's comments to >heart: What does the user expect from these >service interfaces? IMO, the start time should >be the "In-Service start time", and if we need a >"Provisioning start time" parameter someplace, >then we figure out how to bound it authoritatively and do that. > >Jerry > > >Joe Mambretti wrote: >>I agree with these comments. >> >>At 08:42 AM 4/13/2010, Radek Krzywania wrote: >>>Hi, Indeed, I forgot about NTP. But still my >>>opinion is that we are unable to assure time >>>precision at the level of seconds. >> >>Yes, seconds in a metro area. >> >>>Minutes are far more probable. >> >>However, certainly in the near term (e.g., the >>next two years). minutes are to be expected. >>Furthermore, in part because of this timing >>issue, as I have noted previously, the >>distinction between "Immediate" and "Advanced" >>is artificial. *All* requests are for future >>resources. There is no reason to treat a >>request for resources required "as soon as >>possible" from other requests. The only >>difference is timing, and all the timing is in >>the future. These issues of timing belong to an >>external scheduler - not to the protocol, >>except possibly in terms of a time-to-live flag for the signal. >> >>> Regarding race conditions, it's not the role >>> of the protocol to prevent it. >> >>I very much agree with this. There is a >>tendency in these types of initiatives to >>expand the scope of the standard. These >>tendencies should be resisted vigorously. >> >>> Protocol operates in the area of single >>> service definitions (how to request and >>> process the request), while software will >>> deal with simultaneous requests at different >>> states and distributed in time (also >>> overlapping). That's my opinion, unless >>> someone will convince me otherwise :) 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 >>> ________________________________________________________________________ >>> > -----Original Message----- > From: Artur >>> Barczyk [ mailto:Artur.Barczyk@cern.ch] > >>> Sent: Tuesday, April 13, 2010 3:28 PM > To: >>> <mailto:radek.krzywania@man.poznan.pl>radek.krzywania@man.poznan.pl >>> > Cc: 'Inder Monga'; >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org; 'Guy >>> Roberts' > Subject: Re: [Nsi-wg] >>> Immediate/Advance reservation (Re: NSI conf >>> call > minutes) > > > > On 04/13/2010 03:14 >>> PM, Radek Krzywania wrote: > > 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? > > I think >>> it's not as bad as it sounds, NTP precision >>> is enough at the time > scales we will ever >>> be able to aim at reaching. :-) > > 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. > > Radek, here I think you're >>> wrong, sorry. In the context of multi-domain, >>> the > protocol has to be defined in a way to >>> avoid pitfalls such as race > conditions. > >>> (among other things) > > Cheers, > >>> Artur > > > > > > > > > Best regards > > > > >>> Radek > > > > > > > > >>> ________________________________________________________________________ >>> > > > > Radoslaw >>> Krzywania Network >>> Research and >>> Development > > > > >>> Poznan Supercomputing >>> and > > > > >>> <mailto:radek.krzywania@man.poznan.pl>radek.krzywania@man.poznan.pl >>> > > < >>> mailto:radek.krzywania@man.poznan.pl > >>> Networking Center > > > > +48 61 >>> 858 20 >>> 28 >>> http://www.man.poznan.pl > > > > >>> ________________________________________________________________________ >>> > > > > > > > > *From:* Inder Monga >>> [mailto:imonga@es.net ] > > *Sent:* Tuesday, >>> April 13, 2010 2:49 PM > > *To:* Artur >>> Barczyk > > *Cc:* >>> <mailto:radek.krzywania@man.poznan.pl>radek.krzywania@man.poznan.pl; >>> <mailto:nsi-wg@ogf.org>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 > > > > >>> <mailto:radek.krzywania@man.poznan.pl>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: >>> <mailto:nsi-wg-bounces@ogf.org>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: >>> <mailto:nsi-wg@ogf.org>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 > > > > > > > > > > > > > > > >>> Guy > > > > > > > > > > > > > > > > >>> -----Original >>> Message----- > > > > >>> From: Artur Barczyk [ >>> mailto:Artur.Barczyk@cern.ch] > > > > >>> Sent: 12 April 2010 >>> 17:28 > > > > To: >>> <mailto:nsi-wg@ogf.org>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 > > >>> 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; >>> <mailto:nsi-wg@ogf.org>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 > > > > > > > > > > > > > >>> 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; > > > > >>> <mailto:nsi-wg@ogf.org>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: >>> <mailto:nsi-wg@ogf.org>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 > > > > > > > >>> Tomohiro > > > > > > > > > > > > >>> On Thu, 08 Apr 2010 >>> 09:27:59 >>> +0200 > > > > >>> Jeroen van der Ham >>> <mailto:vdham@uva.nl><vdham@uva.nl > > >>> <mailto: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. > > > > > > > > > > > > > >>> Jeroen. > > > > > > > > > > > > > > > > > >>> ______________________________________________ >>> _ > > > > >>> nsi-wg mailing >>> list > > > > >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org < >>> mailto:nsi-wg@ogf.org> > > >>> < >>> mailto:nsi-wg@ogf.org> > > > > >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> http://www.ogf.org/mailman/listinfo/nsi-wg > > >>> > > > >>> ______________________________________________ >>> _ > > > > >>> nsi-wg mailing >>> list > > > > >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org < >>> mailto:nsi-wg@ogf.org> > > >>> < >>> mailto:nsi-wg@ogf.org> > > > > >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> http://www.ogf.org/mailman/listinfo/nsi-wg > > >>> > > > > > > >>> ______________________________________________ >>> _ > > > > nsi-wg >>> mailing >>> list > > > > >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org < >>> mailto:nsi-wg@ogf.org> > > >>> < >>> mailto:nsi-wg@ogf.org> > > > > >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> http://www.ogf.org/mailman/listinfo/nsi-wg > > >>> > > > > > > > > > > > > > > >>> _______________________________________________ >>> ______________________________________________ >>> _ > > > > nsi-wg >>> mailing >>> list > > > > >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org < >>> mailto:nsi-wg@ogf.org> > > >>> < >>> mailto:nsi-wg@ogf.org> > > > > >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> 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 > > > > >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org < >>> mailto:nsi-wg@ogf.org> > > < >>> mailto:nsi-wg@ogf.org> > > > > >>> http://www.ogf.org/mailman/listinfo/nsi-wg > >>> http://www.ogf.org/mailman/listinfo/nsi-wg > > >>> > > > > > > --- > > > > >>> Inder Monga >>> http://100gbs.lbl.gov > > > > >>> <mailto:imonga@es.net>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 > > > > >>> <mailto:nsi-wg@ogf.org>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 > > >>> <mailto:imonga@es.net>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 >>> <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org >>> http://www.ogf.org/mailman/listinfo/nsi-wg >> >> >>Joe Mambretti, >>Director tel 312.503.0735 >>International Center for Advanced Internet Research fax 312.503.0745 >>750 North Lake Shore Drive, Suite >>600 www.icair.org >>Northwestern University, Chicago, Illinois 60611 >> >> >> >> >>_______________________________________________ >>nsi-wg mailing list >><mailto:nsi-wg@ogf.org>nsi-wg@ogf.org >>http://www.ogf.org/mailman/listinfo/nsi-wg >> > > >Joe Mambretti, >Director tel 312.503.0735 >International Center for Advanced Internet Research fax 312.503.0745 >750 North Lake Shore Drive, Suite >600 www.icair.org >Northwestern University, Chicago, Illinois 60611
2:08 p.m.
New subject: Immediate/Advance reservation (Re: NSI conf call minutes)
This seems to be a very passionate topic for discussion and reminds me of discussions back in my equipment vendor days. Whenever we would be working through provisioning issues we would always ask the question "Is there any chance we could cross-connect the Playboy channel to the Disney subscribers?" This was a real fear for some of our customers, but more recently it had turned into an issue of data security. With the type of end-user controlled dynamic provisioning we are discussing here there will be a window of opportunity for improperly connecting services for a short period of time. Within a a single NRM area of control it could make sure all resources have been released from use by a previous schedule before re-using them in a new schedule that is being instantiated, however, this is no longer true when a circuit is spanning multiple NRM domains. There is now a window of chance where a slow to tear-down service in one domain could be joined to a fast to create new service in another domain. Something to consider. This e-mail chain had been dealing with guard time for start-up, but we also need to be careful about connection tear-down as well. With DRAC we implemented a guard-time mechanism to help scheduling account for technologies that had longer setup and tear-down times. When computing reservations we would then work guards into both ends of the schedules to make sure we would have sufficient time to tear down a service before the resources could be reused in another reservation. John. On 10-04-14 8:23 AM, Joe Mambretti wrote:
I agree with your comments. These issues are design decisions. The protocol can be designed only as a request for resources, completely agnostic to any type of timing, including a time-to-live flag for the signal. Or it can be designed to include some type of "promised" service. Note that when you make a call, you have an high degree of expectation of completing the connection. However, sometimes, you receive a busy signal, a message indicating that "all circuits are busy" or the line is dropped. There are no absolutes in communications. One consideration with this protocol is that in general in the near term (next 3 years) these requests will be made for large scale resources that will be required for extended periods (hours, days, perhaps week). In these types of cases an initial delay in set up is generally expected and tolerated.
At 06:58 AM 4/14/2010, Jerry Sobieski wrote:
Well said Joe. Very good points, particularly about the similarities of advanced vs immediate. I agree completely.
But we do run into some real protocol issues since previous protocols did not deal with a time constraints. In order to support the time constraint we need to understand what the "promise" is to the user within the NSI: If the promise is to provide a connection with certain characteristics (one being start time to end time) we need to anticipate the timing issues associated with resource reservation and provisioning as we change states.
There are easy ways to punt the issue: For instance, we can state that provisioning begins at the start time. This is simple from the protocol and scheduling issues, but it means the user has no guarrantee of when the connection will actually be usable!... So I don't think in all fairness this is an appropriate way to handle it...we need to take Jeff's comments to heart: What does the user expect from these service interfaces? IMO, the start time should be the "In-Service start time", and if we need a "Provisioning start time" parameter someplace, then we figure out how to bound it authoritatively and do that.
Jerry
Joe Mambretti wrote:
I agree with these comments.
At 08:42 AM 4/13/2010, Radek Krzywania wrote:
Hi, Indeed, I forgot about NTP. But still my opinion is that we are unable to assure time precision at the level of seconds.
Yes, seconds in a metro area.
Minutes are far more probable.
However, certainly in the near term (e.g., the next two years). minutes are to be expected. Furthermore, in part because of this timing issue, as I have noted previously, the distinction between "Immediate" and "Advanced" is artificial. *All* requests are for future resources. There is no reason to treat a request for resources required "as soon as possible" from other requests. The only difference is timing, and all the timing is in the future. These issues of timing belong to an external scheduler - not to the protocol, except possibly in terms of a time-to-live flag for the signal.
Regarding race conditions, it's not the role of the protocol to prevent it.
I very much agree with this. There is a tendency in these types of initiatives to expand the scope of the standard. These tendencies should be resisted vigorously.
5384
Age (days ago)
5385
Last active (days ago)
3 comments
3 participants
participants (3)
-
Jerry Sobieski -
Joe Mambretti -
John MacAuley