April 2010 - Nsi-wg - lists.ogf.org

FW: minutes from yesterday's NSI conf. call
by Guy Roberts 15 Apr '10

15 Apr '10

Hello All, The minutes from yesterday's call are available here: http://forge.gridforum.org/sf/go/doc15958?nav=1 I have attached the latest version of the architecture deliverable. This incorporates contributions and comments by Tomohiro Kudoh, Joan Garcia, John Vollbrecht as well as some contributions by myself. To bring some clarity to the complex discussions on advanced reservation, I have created the following table to try and summarize the questions that I think were raised in yesterday's discussion. 2 options as are proposed for each question. The solutions described in the existing architecture deliverable is also included. Guy Question Option 1 Option 2 Existing v1.0 solution as proposed by TK Comments 1 or 2 phase commit? 1PC 2PC 1PC 2PC is more deterministic for multiple network situation Is reservation guard-band required in 1PC? Yes No Yes For timer initiated provisioning with 1PC, the guard-band is required to prevent partial provisioning of a connection. Is reservation guard-band required in 2PC? Yes No NA In practice to improve reliability of service, 2 should be aware of the worst-case reservation times. Who adds Reservation guard-band? Added by Requester NSA Added by Provider NSA ? This decision affects how the StartTime field in message is interpreted. Also GB definition will change based on this usage. (see below) Is reservation guard-band (GB) implemented per-network, or for federation of networks? GB = worst case reservation time for local network GB = worst case reservation time for all participating networks ? If the GB is added by the Requester, then the GB should refer to the worst-case time for the federation of participating networks. Provider validation of guard-band? Validated Not validated Validated Provisioning advance time None Advance time added by Provider NSA None The advance time should be set to equal the worst case provisioning time. This is needed if the In-service time is to match the user requested time. Synchronization NTP GPS/radio ? NTP should be ok Separate command for immediate reservation? Yes No No How is immediate reservation distinguished from advanced? This can probably be done by using 'ASAP' in the startTime field. Allow ASAP as start-time? Yes No No How is provisioning initiated with ASAP startTime? Signalled from Requester NSA Initiated by timer on Provider NSA NA To get a fast result with ASAP then timer initiated provisioning could be used. (is this much faster than signalled?) How should provisioning be initiated for advanced reservations? Signalled from Requester NSA Initiated by timer on Provider NSA Both options supported In the case of 1PC and not guard-time, the outcome when initiated by timer on Provider may not be very deterministic. Does each Connection request need a field to indicate how to expect provisioning to be initiated? Provisioning type field No provisioning type field ? How does Provider know whether to wait for signal from Requester? ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

1 0

FW: 2PC and immediate
by Guy Roberts 14 Apr '10

14 Apr '10

Here is Tomohiro's analysis of 2pc. Guy -----Original Message----- From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] Sent: 14 April 2010 16:33 To: Guy Roberts Subject: 2PC and immediate Hi Guy, Here is a slide. Tomohiro

1 0

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by Jerry Sobieski 14 Apr '10

14 Apr '10

Hey Radak- Two points: 1) We should distinguish between "timing" issues, and "scheduling" issues. Most race conditions can be easily handled in the protocol, so I am not too worried about those other than to just be able to identify them all... 2) But where timing issues interact with scheduling we have this otehr problem of network time synchronization. And from todays protocol processing times, seconds difference may as well be days difference. For instance, if one NSA start unilateral provisioning of a connection and passes a Provision() or ProvisionComplete() message to its neighber NSA in the service tree, what if that neighbor has a clock that is different by 1 second? Is this an error? Should the later NSA wait for 1 second? does it ignore its own clock? what if the delta was 30 seconds? or 10 minutes? If we do not pin these issues down and bound them, then the protocol will not behave as we hope it well. To minimize these timing issues (not really race conditions) we could require a more accurate (GPS?) clock, but even this will not deterministically solve the issue, just reduce its likelyhood of occurance. As fast as processors are today, a clock would have to be synch'd to within a few milliseconds to make this a non-issue. We may be able to develop some sort of event timing easement as par tof the protocol...an event that occurs within some delta of anoterh event is considered simultaneous...these are not simple, but they could solve the protocol timing deterministics issue... I suspect we can solve some of these timing/scheduling interaction issues with simpler protocol assertions: e.g. "Provisioning begins at the Start Time". Some will be ok to do this, and others we'll want a more accomodating approach. (For the record, this example is IMO one we should be more accomodating with:-) Jerry 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. Minutes are far more probable. > > Regarding race conditions, it's not the role of the protocol to prevent it. 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(a)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(a)man.poznan.pl >> Cc: 'Inder Monga'; nsi-wg(a)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(a)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(a)man.poznan.pl; nsi-wg(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg >

3 2

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by Joe Mambretti 14 Apr '10

14 Apr '10

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(a)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(a)man.poznan.pl > Cc: 'Inder > Monga'; nsi-wg(a)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(a)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(a)man.poznan.pl; nsi-wg(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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

3 3

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by Artur Barczyk 14 Apr '10

14 Apr '10

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(a)man.poznan.pl Networking Center > +48 61 858 20 28 http://www.man.poznan.pl > ________________________________________________________________________ > > >> -----Original Message----- >> From: nsi-wg-bounces(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>>>> _______________________________________________ >>>>>>>> nsi-wg mailing list >>>>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nsi-wg mailing list >>>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nsi-wg mailing list >>>>>> nsi-wg(a)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(a)ogf.org <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> --- >>> Inder Monga http://100gbs.lbl.gov >>> imonga(a)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(a)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

8 10

Naming Issues -Nets, INJ, STP, Port
by John Vollbrecht 13 Apr '10

13 Apr '10

Attached is a doc that describes Nets, INJs, STPs and Ports and how they interact. Hopefully it can help discussion tomorrow. John

1 0

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by Freek Dijkstra 13 Apr '10

13 Apr '10

Radek Krzywania wrote: > Regarding race conditions, it's not the role of the protocol to prevent it. Most protocol purists argue that a protocol is defined as a state machine and a message format that change the state. If race conditions are part of the state machine, it is part of the protocol. In practice there are plenty of protocol specification which only define the message formate. Most IETF protocols do not specify a state machine. That said, race conditions is not an issue right now. If it should be considered from the start or if it is better to add it later as an afterthought, I don't know. Regards, Freek

1 0

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by John Vollbrecht 13 Apr '10

13 Apr '10

On Apr 13, 2010, at 9:42 AM, 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. Minutes are > far more probable. > > Regarding race conditions, it's not the role of the protocol to > prevent it. 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 :) > We agreed that a provider will notify a requestor when provisioning is complete. This seems like it solves the problem of not knowing when provisioning is complete. If one needs to be sure a circuit is provisioned by a certain time it seems that scheduling ahead is a good idea. Knowing how far ahead is necessary might be a good idea, but probably not necessary for version 1. John > Best regards > Radek > > ________________________________________________________________________ > Radoslaw Krzywania Network Research and > Development > Poznan Supercomputing and > radek.krzywania(a)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(a)man.poznan.pl >> Cc: 'Inder Monga'; nsi-wg(a)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(a)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(a)man.poznan.pl; nsi-wg(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)ogf.org <mailto:nsi- >>> wg(a)ogf.org> >>> <mailto:nsi-wg@ogf.org> >>> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> >> _______________________________________________ >>> >>> nsi-wg mailing list >>> >>> nsi-wg(a)ogf.org <mailto:nsi- >>> wg(a)ogf.org> >>> <mailto:nsi-wg@ogf.org> >>> >>> http://www.ogf.org/mailman/listinfo/nsi-wg >>> >>> >>> >>> >>> _______________________________________________ >>> >>> nsi-wg mailing list >>> >>> nsi-wg(a)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(a)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(a)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(a)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(a)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(a)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(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg

1 0

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by Artur Barczyk 13 Apr '10

13 Apr '10

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(a)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(a)man.poznan.pl; nsi-wg(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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

2 1

Fwd: NSI service instantiation or provisioning signalling
by John Vollbrecht 13 Apr '10

13 Apr '10

I apparently didn't send this to the NIS group by accident. Begin forwarded message: > From: ""Joan A. García-Espín"" <jage(a)i2cat.net> > Date: April 13, 2010 5:05:49 AM GMT-04:00 > To: John Vollbrecht <jrv(a)internet2.edu> > Subject: Re: NSI service instantiation or provisioning signalling > > Hi John, > > I am very sorry but somehow I missed your email. My apologises. > >> A- Some points that I think we agree on (I could be wrong) - >> 1) An NSA will have a state machine (or equivalent). That state >> machine will have a set of states including reserved and active. >> The issue we are talking about has to do with going between the >> reserved and active state. > Right, agreed. > >> 2) A triggering event of some sort will be what causes the NSA to >> change states (and perhaps do some other things). > Right also. > >> B- The discussion of ways to instantiate a connection seems to me >> to have aspects >> 1) who generates the signal to the state machine >> 2) what other actions does the signal cause to happen > Exactly, depending on who signals the instantiation, the service > workflow may be affected in one way or another. The discussion is > about which option is the best for being included in v1.0. > >> C- There are questions about how to signal state between NSAs >> 1) is there a "master" that initiates the signal or is it >> independently done >> 2) if one NSA fails how do others know and keep in sync > Right. > >> Of A, B and C - I hope we agree about A. >> I think B maybe needs some discussion, but I think we could agree >> pretty quickly >> C is harder, and I think needs more discussion of how NSAs keep >> state. Some of this might be put off till after A and B are done >> and in the doc (in my opinion). > > Right also > > fully aligned! > -- > Joan A. García-Espín > CTX, i2CAT Foundation > > > > > > El 06/04/2010, a las 23:59, John Vollbrecht escribió: > >> I am a bit confused by the discussion on this. So I suggest >> abstracting out the issues bit to see where we agree or disagree. >> >> A- Some points that I think we agree on (I could be wrong) - >> 1) An NSA will have a state machine (or equivalent). That state >> machine will have a set of states including reserved and active. >> The issue we are talking about has to do with going between the >> reserved and active state. >> 2) A triggering event of some sort will be what causes the NSA to >> change states (and perhaps do some other things). >> >> B- The discussion of ways to instantiate a connection seems to me >> to have aspects >> 1) who generates the signal to the state machine >> 2) what other actions does the signal cause to happen >> >> C- There are questions about how to signal state between NSAs >> 1) is there a "master" that initiates the signal or is it >> independently done >> 2) if one NSA fails how do others know and keep in sync >> >> Of A, B and C - I hope we agree about A. >> I think B maybe needs some discussion, but I think we could agree >> pretty quickly >> C is harder, and I think needs more discussion of how NSAs keep >> state. Some of this might be put off till after A and B are done >> and in the doc (in my opinion). >> >> Does this make any sense? >> >> John >> >> >> >> On Apr 6, 2010, at 9:57 AM, Joan A. García-Espín wrote: >> >>> Hi Jerry, thanks for your comments! >>> >>> I've extracted some of your comments and added my view (just for >>> avoiding large in-line discussion). >>> >>>> By definition, #3 above is out of scope for the NSI protocol. >>>> If some other agent (or control plane) wants to initiate the >>>> provisioning, it does so thru a mechanism that is defined within >>>> the NSI protocol. I expect #1 will suffice if some external >>>> agent needs to kick it off. >>> >>> As for #3, I was thinking of an scenario where the NRM >>> automatically (internally) triggers the provisioning. In this >>> case, the service plane could consider letting the NSA in charge >>> of that NRM polling it for the reservation status, and notifying >>> the rest of NSAs in the provisioning tree later on (upwards >>> approach). >>> >>>> Hmm...I think I have to disagree strongly. >>> >>> Good :) >>> >>>> When we expect these NSAs to start based on independent clocks >>>> and without verification that the service/control plane >>>> associated with this connection is even functioning, I think we >>>> introduce a myriad of complexities that need to be discussed in >>>> detail. Mostly, blind provisioning is different in a tree >>>> structured service plane than in OSCARS or AutoBahn or a GMPLS >>>> style service plane. We need to understand these issues better >>>> before we wave our hands and say its simple. >>> >>> My view: the Service Plane is an abstract layer where NSAs >>> interact for allowing network service provisioning (we all agree >>> on this). One of the key factors here is that NSI aims at >>> supporting not only reservations (time dimension is desirable >>> here), but also advance reservations or book ahead (time dimension >>> is compulsory). Therefore, time synchronisation is something that >>> we know, sooner or later, will appear on stage. The NSI cannot >>> force implementers to use a given time sync method, but we can >>> recommend its use as a way for precise service provisioning and >>> for lowering the rate of unsatisfied services (error handling >>> gains importance). >>> >>>> - The start time may be weeks or months after the request was >>>> reserved. How do we know if the service tree for that connection >>>> is still functioning? For instance, if the service tree is >>>> broken, how do we expect the provisioning to complete? (At least >>>> with requester initiated provisioning we get a request sent down >>>> the tree that verifies the service tree is still in place.) >>> >>> NS status query is a primitive, afaik. An NSA can use it for >>> periodically/punctually verify the service tree. Which NSA? I'd >>> say the one who first initiated the service provisioning (root NSA). >>> >>>> - With independent provisioning, i.e. independent state changes, >>>> we don't have any means of determining the state of the >>>> connection unless we communicate that state up and down the >>>> service tree. We know what our state is, but we have no way of >>>> predicting the state of our parent/child NSAs and so we have no >>>> way to validate that the protocol is functioning properly. >>> >>> For the sake of a good functioning, people implementing option #3 >>> must implement a robust notification mechanism. I agree with you >>> that independent and not-notified changes at a given point in the >>> tree produce undesired situations. I don't think we have to worry >>> about future implementations, just provide a flexible interface >>> for doing so. >>> >>>> - If we flood Provision() requests up and/or down the tree to >>>> communicate to our parent/children NSAs that we auto-induced a >>>> state transition for a connection, how do we handle collisions of >>>> Provision() requests? Are there any race conditions or hysteresis? >>> >>> Again, I think this is an implementation problem and is useful for >>> the people working on error handling. >>> >>>> -If we send Provision() requests up the tree...is that any >>>> different than sending them down the tree? Are they handled any >>>> differently? If not, would it simplify the protocol if only the >>>> root initiated the Provision() requests based on a timer? i.e. >>>> does having all NSAs independently kick off timers cause >>>> unnecessary complexity? >>> >>> We faced this problem in the Phosphorus project time ago, when >>> designing Inter-Domain Broker communication protocol for our >>> Harmony tool. After long discussions, we concluded this could be >>> easily handled by a proper security infrastructure. Any NSA should >>> be able to know who its neighbours are and what are they allowed >>> to request. In the case of managing a GMPLS control plane with >>> manual instantiation of the connection at the UNI, we needed a >>> mechanism to notify the service plane the connection was >>> provisioned, and thus we implemented the notification service. >>> Alternatively, if notification not available, we could use a >>> polling mechanism and latter flooding of the reservation state >>> among all service plane entities involved. I agree that it adds >>> complexity, but I mentioned it basing on a use case from Phosphorus. >>> >>>> - if we do have a protocol that handles mid-tree flooding of >>>> state changes, could this also be useful for the release() >>>> function or for possible error or failure mode handling scenarios? >>> >>> In my mind, I was not considering mid-tree, only changes flooded >>> from root NSA or network-attached NSA. >>> >>>> - What happens if the wall clocks in the NSA are not "adequately" >>>> synchronized. Can we assume that wall clock synchronization is >>>> a non-issue? If not, what does "adequate" mean in this context? >>> >>> As I mentioned before, since we are considering calendars to be >>> used in a per network (in general, per resource) for advance >>> reservations, we should recommend that time sync is used, at least. >>> >>>> - How does a requester determine if/when a connection is in- >>>> service? Do we simply fire data at it until we see it pop out >>>> the other end? How do we know that? What can we say >>>> definitively about the connection state form the user's service >>>> perspective as we move from reserved to inservice..? (Even a few >>>> milliseconds could result in megabytes of information being >>>> leaked out or lost from a connection. This is both very poor >>>> service quality as well as a security risk.) >>> >>> This problem is present at *any* provision strategy and should be >>> discussed. The trivial solution (inject and expect it be >>> transmitted) is something that can cause severe data losses, as >>> you mention. From my past experience, when using a provisioning >>> system, one cannot be 100% sure the path is provisioned until data >>> plane is tested (i.e. ping). Assuming the network hardware works >>> well, we need the NRM to control path set up. Then we have several >>> options, but the most typical are (i) implement a way the NRM >>> tells its parent NSA the connection is UP, and the let the NSA >>> propagate this information along the service tree upwards or (ii) >>> implement a polling loop in the NSA in charge of the NRM, until >>> "connection UP" is obtained, and proceed with the flooding. In any >>> of these cases, "connection UP" messages from NRM should be >>> aggregated for building up "path segment UP", until a whole "path >>> UP" is ready. Then, the original requester can be notified. Please >>> note these are only some options, many others can be designed. NSI >>> protocol should not stick to any of them, but consider them for >>> making NSI flexible enough (=> will ease adoption). >>> >>>> - Is it adequate to have provisioned() segments in-service before >>>> all segments are in-service? Does this cause a timing issue in >>>> the tree that could result in mis-routed data? Do we need to >>>> stipulate some atomic function that allows data to begin flowing >>>> that is different than simply configuring the path? >>> >>> This can happen, given that networks cooperating in the connection >>> provisioning are independent. Thinking on this, I get the >>> impression we need some message from the service plane to the app >>> where we say the whole path is in-service. >>> >>>> Finally, I assert that there is no significant legacy application >>>> base that should dictate how NSI protocol functions just so that >>>> they don't have to change. If there are some requirements that >>>> those application need that NSI needs to support, ok...but I >>>> don't think its a good idea to make a future protocol act in some >>>> way just because thats the way we've always done it. (That logic >>>> says lets not change anything...:-) >>> >>> I fully agree Jerry, hope you did not understand otherwise, sorry >>> if I expressed wrongly myself. >>> My comments were two-fold: >>> - First, we should make the first release of the NSI implement >>> the options we think are easier to adopt, but in any case limit it >>> to them. >>> - Second, future-proofed NSI protocol needs firstly to be present- >>> proof. Bad early adoption means hard future adoption. >>> >>>> My proposal: >>>> 1) I think we should do a "requester initiated provisioning" >>>> request down the tree as a first simplest provisioning initiation >>>> process. 2a) If we can work through the mid-tree messaging and >>>> state transition in a prompt manner, we could include that also >>>> in V1.0, but I think it may be more complex. 2b)A simple interim >>>> solution would be to have the first PA that sees a "provider >>>> initiated provisioning" request to assume that responsibility and >>>> passes a "requester initiated provisioning" request to all >>>> children. Then that first PA sends provision() requests down the >>>> tree to start the process just as with a requester initiated >>>> provisioning. >>> >>> If we go for requester-initiated provisioning, we need to control >>> both reservation and provisioning calendars, don't we? I mean, >>> reservation requests will only serve as a "medium access control" >>> mechanism, purely signalling, not really influencing in the >>> provisioning. In this case, the user has to mind about both >>> reservation and instantiation. >>> What about the time lapse between user requesting provisioning and >>> data plane effectively up...? >>> >>>> I know I can be a bit brusque with some of this - hope it all >>>> make sense and was not too curt. >>> >>> >>> It all makes sense. Please mind I always want to broaden the >>> applicability of the NSI and to strength its flexibility, since >>> for me they're the key for easy adoption (of course, without >>> running to generic). >>> >>> My best regards, >>> -- >>> Joan A. García-Espín >>> CTX, i2CAT Foundation >>> >>> >>> >>> >>> >>> El 02/04/2010, a las 22:39, Jerry Sobieski escribió: >>> >>>> Hi Joan- >>>> >>>> I have some reservations to what you suggest below...please let >>>> me know what you think... >>>> >>>> Joan A. García-Espín wrote: >>>>> >>>>> <<Some long discussions on how best to initiate the >>>>> ‘provisioning’ phase of operation. Several methods were >>>>> discussed, but none agreed: >>>>> >>>>> 1. Provisioning initiated by signal i.e. a message on the >>>>> NSI interface. >>>>> 2. Provisioning initiated by a timer local to the provider NSA >>>>> 3. Provisioning initiated by a signal not on the NSI >>>>> interface e.g on a separate control plane >>>>> >> >>>> By definition, #3 above is out of scope for the NSI protocol. >>>> If some other agent (or control plane) wants to initiate the >>>> provisioning, it does so thru a mechanism that is defined within >>>> the NSI protocol. I expect #1 will suffice if some external >>>> agent needs to kick it off. >>>>> >>>>> My vision is that ANY of the procedures should be supported in >>>>> the NSI. Therefore, NSI must implement the required flag(s) in >>>>> the service characterisation or specific signalling message(s) >>>>> for automatic activation, but all of them might be considered >>>>> optional for allowing either one or the other model to be used >>>>> by requester. >>>> The remaining #1 and # 2 amount to "Requester initiated" and >>>> "Provider initiated". And either could be initiated via a timer >>>> expiring, or by some other event in a work flow, etc. It seems >>>> to me the *simplest* thing to do is to have the requester >>>> initiate the provisioning. This is just like we have always done >>>> it with UNIs or RSVP or any other protocol, so it is well >>>> understood. Because it is initiated at the root of the request >>>> tree, it flows down the tree and back up in a very determinitic >>>> fashion. We know when each segment is fully provisioned. There >>>> is no special handling, it does not add complexity to have the >>>> provision request slide down the request tree just like the >>>> reservation() request did initially. >>>> So, it is my proposal that we have at least #1 in version1: the >>>> connection is provisioned on requester sending a "provision()" >>>> request/command to the provider. And when a >>>> "ProvisionComplete()" message is received, the connection is >>>>> >>>>> From a pragmatic viewpoint, option 2 is the best candidate for >>>>> NSI release 1.0, since does not assume that either the requester >>>>> app or the control plane have the capability to perform an >>>>> automatic activation/instantiation of the connection. Basically, >>>>> this means that legacy compatibility is ensured in early >>>>> implementations, although having to implement time sync in the >>>>> NSA. This is a good point in general because: (i) most of the >>>>> apps/middlewares are not used to deal with generic GMPLS UNI and >>>>> thus don't implement automatic signalling in the app <-> control >>>>> plane interface, and secondly (ii) not all control planes or >>>>> provisioning/management systems implement calendars and >>>>> consequently cannot natively support advance reservations (that >>>>> would be emulated at the service plane). >>>> Hmm...I think I have to disagree strongly. >>>> When we expect these NSAs to start based on independent clocks >>>> and without verification that the service/control plane >>>> associated with this connection is even functioning, I think we >>>> introduce a myriad of complexities that need to be discussed in >>>> detail. Mostly, blind provisioning is different in a tree >>>> structured service plane than in OSCARS or AutoBahn or a GMPLS >>>> style service plane. We need to understand these issues better >>>> before we wave our hands and say its simple. >>>> >>>> Here is a list of some issues in no particular order: >>>> >>>> - The start time may be weeks or months after the request was >>>> reserved. How do we know if the service tree for that connection >>>> is still functioning? For instance, if the service tree is >>>> broken, how do we expect the provisioning to complete? >>>> (At least with requester initiated provisioning we get a request >>>> sent down the tree that verifies the service tree is still in >>>> place.) >>>> >>>> - With independent provisioning, i.e. independent state changes, >>>> we don't have any means of determining the state of the >>>> connection unless we communicate that state up and down the >>>> service tree. We know what our state is, but we have no way of >>>> predicting the state of our parent/child NSAs and so we have no >>>> way to validate that the protocol is functioning properly. >>>> >>>> - If we flood Provision() requests up and/or down the tree to >>>> communicate to our parent/children NSAs that we auto-induced a >>>> state transition for a connection, how do we handle collisions of >>>> Provision() requests? Are there any race conditions or hysteresis? >>>> -If we send Provision() requests up the tree...is that any >>>> different than sending them down the tree? Are they handled any >>>> differently? If not, would it simplify the protocol if only the >>>> root initiated the Provision() requests based on a timer? i.e. >>>> does having all NSAs independently kick off timers cause >>>> unnecessary complexity? >>>> >>>> - if we do have a protocol that handles mid-tree flooding of >>>> state changes, could this also be useful for the release() >>>> function or for possible error or failure mode handling scenarios? >>>> >>>> - What happens if the wall clocks in the NSA are not "adequately" >>>> synchronized. Can we assume that wall clock synchronization is >>>> a non-issue? If not, what does "adequate" mean in this context? >>>> >>>> - How does a requester determine if/when a connection is in- >>>> service? Do we simply fire data at it until we see it pop out >>>> the other end? How do we know that? What can we say >>>> definitively about the connection state form the user's service >>>> perspective as we move from reserved to inservice..? (Even a few >>>> milliseconds could result in megabytes of information being >>>> leaked out or lost from a connection. This is both very poor >>>> service quality as well as a security risk.) >>>> >>>> - Is it adequate to have provisioned() segments in-service before >>>> all segments are in-service? Does this cause a timing issue in >>>> the tree that could result in mis-routed data? Do we need to >>>> stipulate some atomic function that allows data to begin flowing >>>> that is different than simply configuring the path? >>>> >>>> We do not have currently any notion of what these NSI protocol >>>> requirements entail. >>>> >>>> I do not differentiate between a timer event kicking off >>>> provisioning or some other non-calendar related event (say a work >>>> flow task completing) that defines the kickoff point. Whatever >>>> event occurs generates a Provision() request within that NSA >>>> which causes the state machine to transition. >>>> Finally, I assert that there is no significant legacy application >>>> base that should dictate how NSI protocol functions just so that >>>> they don't have to change. If there are some requirements that >>>> those application need that NSI needs to support, ok...but I >>>> don't think its a good idea to make a future protocol act in some >>>> way just because thats the way we've always done it. (That logic >>>> says lets not change anything...:-) >>>> >>>> My proposal: >>>> 1) I think we should do a "requester initiated provisioning" >>>> request down the tree as a first simplest provisioning initiation >>>> process. 2a) If we can work through the mid-tree messaging and >>>> state transition in a prompt manner, we could include that also >>>> in V1.0, but I think it may be more complex. 2b)A simple interim >>>> solution would be to have the first PA that sees a "provider >>>> initiated provisioning" request to assume that responsibility and >>>> passes a "requester initiated provisioning" request to all >>>> children. Then that first PA sends provision() requests down the >>>> tree to start the process just as with a requester initiated >>>> provisioning. >>>> >>>> I know I can be a bit brusque with some of this - hope it all >>>> make sense and was not too curt. >>>> >>>> Glad påsk! >>>> Jerry >>>>> >>>>> Best regards and have a nice Easter holidays, >>>>> -- >>>>> Joan A. García-Espín >>>>> Network Technologies Cluster (CTX) >>>>> i2CAT Foundation >>>>> C/ Gran Capità 2-4, office 203, Nexus I building >>>>> 08034 Barcelona, Catalonia (Spain) >>>>> >>>>> T: +34 93 553 2518 >>>>> F: +34 93 553 2520 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> >

1 0