[Nsi-wg] time issue

[Jerry Sobieski]

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 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/20100927/f1ae8f61/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Concerns regarding start time.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.documen
Size: 161204 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20100927/f1ae8f61/attachment-0001.bin