Hi John and everyone-

John has summarized our discussion quite well.  I add a couple comments just to make me a slight bit more happy with them:-)

Please see them inline...

Also, attached is a draft of what concerned me originally.  Guy had asked me to document my concerns and recommendations.  I think this docuement parallels John's summary below quite well - though I use some differnet terms.


John Vollbrecht wrote: 
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
I called these In-Service Time and Provisioning Start Time...but I think John's terms are better.
To further define these -

Available time 
- requested by the user for its application
- provided by the network.
Key Note:  This is a *Requested* available time, and not a guaranteed time.
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.
This is great John.  
-----------------
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 is correct in that we did indeed discuss these issues.  However, we have disagreements about whether such statistical averages really changes the fact that they are still just estimates - not deterministic, and not a guarranty.  I think trying to formulate estimates of how often we are likely to fail on a committed parameter misses a bigger elephant hiding in the room:  Why did we not make our commitment?   What needs to be fixed to insure that our guaranties are solid?   But intelligent folks can disagree on the value of estimates and averages, but IMO incorporating this information into the protocol will not be a good idea.

We did discuss the prospect of making these estimates available to the user via the Service Definition document, which then becomes the perogative of the service provider to offer- or not, and the user ot use it - or not.   They could give the user some idea of past performance.   I think the SD is a more appropriate way to do this.   But it is not something I believe the CS needs to deal with.

I think fundamentally the Connection Service should be a simple front end to the functional routines that make up the state machine.   And the state machine is dependent on a clear and closed set of events that transition the connection from state to state.  All service parameters are analyzed according to the Service Definition and the Path Finder and the various genre of resources in the ResourceDB.

I am happy if in the connection request that the "available time" be explicitly defined as a Requested AvailableTime, and when returned in a Reservation Confirmation that it is explicitly an Estimated Available Time - a preference, or estimate, a "hint".  The PA simply makes a best effort to meet it. 

Thanks John!
Jerry
John

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