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@man.poznan.pl                   Networking Center
+48 61 850 25 26                             http://www.man.poznan.pl
________________________________________________________________________

-----Original Message-----
From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@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@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg


_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg