[Nsi-wg] time issue

Tue Sep 28 11:46:55 CDT 2010

I think this is useful discussion -- I would like to see an actual proposal for how time is carried in each of the possible request types [automatic or user initiated provisioning].  My musing/ wondering is whether it would be good to have both times at least potentially in the connection messages.  This might be done by carrying one in the Service Definition Instance field and one in the Path field.

At a minimum it seems that it is necessary to distinguish between the two times, either with some sort of flag or by carrying them in different fields.  Do others agree?

John

On Sep 28, 2010, at 12:20 PM, Jerry Sobieski wrote:

> Hi Radak-
> 
> Hmmm... some musings...
> 
> It seems to me that the guard times are local to each NSA - the only real desire is to have the circuit avalaible to the user at the desired time (or as close to it as our best effort can do), and to keep it available until the End TIme (or as close as we can manage.)   So each NSA down the tree will prepend their own estimated guard time to the Available Time and hope for the best.  I don't think there is a need to synchronize the times per se, just the state transitions.    In order for the protocol to be deterministic, the easiest way IMO is to always send a Provision Complete msg up the tree whenever we complete the setup.   This will attest that all children segments are in place and In Service. 
> 
> As for tear down time...  From the netwokr perspective, the tear down can (should be?) almost instantaneous as the only real thing that needs to be done is to shut off the ingress point.   Typically, there is no need to physically reconfigure the transit nodes back to some idle configuration - the ingress just gets shut and the resources marked as released.  The resources are officially no longer available to the user after the End Time has passed.   Even if *no reconfiguration* is done, and even if the ingress port is left open, the user's reservation has expired and they can no longer rely on its availability.   
> 
> The real question is "When will the End Time occur??" (I sound like a metephysical preacher:-)   While each NSA down the tree will want to shut their respective ingress points at the End Time, the only one that really counts from a user perspective is the first NSA to reach the End Time.   I.e. due to clock skew, a child NSA down the tree somewhere may reach the End Time before the top PA begins the 'proper' Release.   Unless the Release is triggered deterministically by one particular NSA there could be some unpredictable variance in the actual release time.  From the user's perspective, with a bit slower clock, the connection inexplicably goes away early...  
> 
> This is why I think messaging should be the primary means for managing the circuit.   I think the best way to handle this may be that each NSA sets a timer when their End Time is reached.  A "manual stop" Release message is expected within that timer window.   When that timer expires, the local NSA stops waiting for a manual stop and reverts to "auto stop" for the connection.    Auto-stop handling sends appropriate messages or notifications up the tree and drops the connection.   This End Time Release timer could be some locally defined safety (guard) time.     Even in this case, the user's reservation still expires at the End Time - they are no longer guarranteed the resources.  And there is no practical way to know when the first End Time Release timer may expire...if the clocks are skewed, and the release guard time small enough, the connection may still drop before the user expects it.   
> 
> For this reason, I think we should consider defining the End Time as a best effort Estimated End Time just like the best effort Estimated Start Time (or Requested Avalable Time).
> 
> In general, I think synchronizing a global network of NSAs to accurately reflect a common time is almost impossible, or at least out of scope. Accuracy and skew will always be an issue.   Therefore, the protocol / state machine must be able to function correctly in the face of skew, and this may prevent us from making hard guarranties on availability times.  (Did I explain this coherently?:-)  This why auto-start and auto-stop are tricky - the clocks among the NSAs will never be exactly the same and so we'll always risk skewed independent clocks jumping the gun.   But clock skew (as Radak suggests) is something we can handle, but it needs to be considered as part of the protocol/state machine, not just an implementation issue.
> 
> Auto-start and auto-stop capability will need to address protocol issues like this caused by clock skew.   Perhaps we need some protocol feature that insures a minimum maintained clock sync - and if an NSA's time/date clock is off by more than some standard minimum, that NSA is considered broken and not used.  Remember also, that skew can accuulate across multiple networks/nodes, so even a standard minimum may still accumulate to something unacceptable. 
> 
> Another alternative we may consider is a "Two Minute Warning"...I.e. whenever a connection End Time approaches, say, 2 minutes from now, a message is flooded along the service tree to notify the NSAs on the path that at least one NSA is going to drop the connection very soon.  The Prime Mover RA (the user) will ultimately get this message as well, notifying them that they should find a stopping point or risk losing connectivity abruptly.   Indeed, a two-minute warning could be a connection specific user specified value with some Service Definition default.
> 
> Ugh...this is interesting...
> 
> Best regards
> Jerry
> 
> Radek Krzywania wrote:
>> 
>> Hi,
>> Just a short comment on time definitions there - I kind of like them :) The case is that we should be able to estimate the difference between available and resource time - so in other words, to be able to estimate setup and tear down time. That is mostly for purposes of SLA, but not only. Also, since user is requesting only to give an available time, we need to map those times somehow, and keep them synchronised. This is implementation work here, but doable (if we are able to estimate setup/tear down times).
>> 
>> Best regards
>> Radek
>> 
>> ________________________________________________________________________
>> Radoslaw Krzywania                      Network Research and Development
>>                                            Poznan Supercomputing and  
>> radek.krzywania at man.poznan.pl                   Networking Center
>> +48 61 850 25 26                             http://www.man.poznan.pl
>> ________________________________________________________________________
>> 
>> 
>>   
>>> -----Original Message-----
>>> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf
>>> Of John Vollbrecht
>>> Sent: Monday, September 27, 2010 11:51 PM
>>> To: NSI WG
>>> Subject: [Nsi-wg] time issue
>>> 
>>> Hello all -
>>> 
>>> Jerry and I had a discussion last week about the time issue.  I think we
>>> developed a useful approach.
>>> 
>>> The idea is to define two times, which I think we all agree exist.
>>> 
>>> 1) available time - time a connection is available to the application to
>>> communicate between devices
>>> 2) resource time - time a resource is reserved to support available time
>>> 
>>> To further define these -
>>> 
>>> Available time
>>> - requested by the user for its application
>>> - provided by the network.
>>> 
>>> resource time
>>> - time a resource is allocated to a connection
>>> - includes setup and teardown time, if any
>>> - is time in reservation calendar for resource
>>> 
>>> Available time requested cannot be provided exactly by network because it
>>> cannot predict exactly length of setup and take down.  I believe we all agree
>>> with this.
>>> Therefore provided available time can at best approximate requested
>>> available time.
>>> 
>>> We agreed that when a user requests automatic start connection it would
>>> request available time and the provider would schedule resource time to get
>>> as close as possible.
>>> When a request is for user initiated connection the time would be for
>>> reserved time, and the user initiation can start anytime after the reserved
>>> time.  Available time depends on setup and take down times of equipment.
>>> 
>>> -----------------
>>> I think we agreed on the above definitions.  The definition of time seem
>>> useful in discussing what goes in connection service messages.  We also
>>> talked about some possible implications of this.
>>> 
>>> The difference between available and resource time is setup and takedown
>>> time.  While it is impossible to be sure exactly how long they will be, it may be
>>> possible to define something statistical.  For example setup takes an average
>>> of 17 sec with std deviation of N.  If this is can be defined for the resource,
>>> then one can make a prediction about when a connection will be available
>>> with a degree of confidence.
>>> 
>>> For example this would allow one to request an automatic connection, for
>>> example, at 5pm and have it available 99% of the time.  If the average setup
>>> time is 17 seconds and I add 10 seconds to be 99% sure, then the service
>>> would initiate the connection at 5:00:00 - 0:00:25, or 4:59:35.
>>> 
>>> We talked about including this "setup requirement" in the connection service
>>> definition of and NSA, and by implication including this in requests and
>>> replies.  I think this is worth talking about in the group.
>>> 
>>> John
>>> 
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>     
>> 
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100928/7b34f968/attachment.html 