[Nsi-wg] time issue
Inder Monga
imonga at es.net
Wed Sep 29 03:10:50 CDT 2010
Radek
I agree with your statements;
> User is not interested in partial results, as he/she is not even aware/interested in which NSAs/domains are involved. User doesn’t care (if everything works fine ;) ).
The protocol should be designed with the user in mind. The user does not care about guard time values, differences in setup times for MPLS vs optical lambdas, and concern itself with choices an NSA/NRM will make in path-finding.
In my opinion,
a. the user should specify "Expected Start Time, Expected End Time". The NSAs/domains along the path determine resource availability and booking in their schedules based on their own configured guard time (guard times are not specified by NSI protocol. NSI connection service architecture should discuss them as a suggested concept).
b. Within reasonable limits, the connection should be up as close to the start time as possible. The user can set his own policy/configuration on how long to wait after the start time to accept a connection. Since the resources are guaranteed, this is a connection of setup/provisioning only. Hence, there is no protocol state transition when start time is passed other than the messages that indicate the circuit is established end to end or teardown message initiated by the client.
c. We should not design a protocol that depends on time synchronization to work. In my opinion, the start time, expected time to provision aka guard time is best handled/shared as a SLA/Service definition issue.
d. Similar semantics apply to the end-time as well.
Inder
On Sep 28, 2010, at 10:01 AM, Radek Krzywania wrote:
> Hi Jerry,
> IMHO setup and tear down times should be considered global (all NSA along a path). User is not interested in partial results, as he/she is not even aware/interested in which NSAs/domains are involved. User doesn’t care (if everything works fine ;) ).
>
> For tear down, it does not matter where you start to removing the configuration (end point, or any point along the path). Since you remove single configuration point – the service is not available any more. That the time where available time ends. We can discuss whether it should be synchronized or signaled, but I would even left it for v2 (or v1.1, or whatever we decide). Since ALL segments of connection has configuration removed, the resource time is ended. I agree that resource time is difficult to forecast, yet we need to fit that into calendar full of other reservations and synchronize them. Thus we need to estimate, guess, or use magic to get those values as realistic as possible. Overlapping is forbidden, and leaving gaps of unused resources will be waste of resources and money at the end.
>
> “Two minute warning” is not speaking to me. I don’t see a reason to warn a domain or user that the connection will be closed soon, while user knows what was requested and domain is tracking that with a calendar. We can discuss some internal notifiers, but that’s implementation.
>
> 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
> ________________________________________________________________________
>
> From: Jerry Sobieski [mailto:jerry at nordu.net]
> Sent: Tuesday, September 28, 2010 6:20 PM
> To: radek.krzywania at man.poznan.pl
> Cc: 'John Vollbrecht'; 'NSI WG'
> Subject: Re: [Nsi-wg] time issue
>
> 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
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
---
Inder Monga ANI Testbed
imonga at es.net ESnet Blog
(510) 499 8065 (c) (510) 486 6531 (o)
"Whatever your mind can conceive and believe it can achieve." - Napoleon Hill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100929/408549a6/attachment-0001.html
More information about the nsi-wg
mailing list