[Nsi-wg] time issue

[Jerry Sobieski]

Hi Inder-   I am not sure I agree with all of this...

Inder Monga wrote:
> 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. 
>
The protocol designers can keep the user in mind, but /the protocol is 
between the RA and the PA/ and and has a specific purpose: to reserve 
and instantiate a connection across the globe.  We need to keep in mind 
that the RA is not always the end user - it is by definition another NSA 
and could be an NSA in the tree/chain somewhere.  If we want to 
differentiate between the user and the network, then we can create a 
simplified User to Network API, and a different Network to Network 
API...but I don't think thats what we want to do (:-)   We need to IMO 
*not* think about the user, but to think about the Requesting Agent - 
regardless of who it represents.

Perhaps once the RA-PA protocol is tightly defined in all its nuances, 
we can develop/recommend an end user API that simplifies the the 
application's required interactions ??   This would allow an application 
to embed an RA in a runtime library/module and the application itself 
would only have to deal with the basic connection requirements....  just 
a thought.
> 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).
While the guard times may be network specific, we do need to at least 
consider what we would like an NSA to do if for instance a provisioning 
guard time pushes a reservation forward into a previous reservation:   
Do we  1) reject the request since we can't prepend our guard time and 
still make the Requested Start Time?   OR  2)  Do we retard the 
Estimated Start Time to allow for the guard time?   OR 3) do we reduce 
the guard time to fit the available lead time?

I think we now agree that the Start Time is just an estimate, due 
primarily to the guard time itself being just an estimate.  So none of 
these times are etched in stone...So which option do we recommend or 
require?   The protocol is sensitive to these various times - they cause 
timers to go off, messages to be sent, error handling to kick in...   If 
they are adjusted during scheduling or provisioning, we MUST understand 
what impact they will have to the protocol and how that will be carried 
through the service tree.
> 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.
Ah, but the rub here is that the "user" is an RA...but not all RAs are 
the end user.  We are defining the actions of an RA, regardless of 
whether it is a user NSA or an network NSA.  So we must insure that if 
the RA gets tired of waiting for provisioning to complete, that whatever 
actions it is allowed to take will be consistent and predictable through 
out the service tree for all the RA/PA interactions.    So the "user" 
actions are not irrelevant to the protocol.

> 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.
I agree:  We cannot expect perfectly/exactly synchronized clocks 
anywhere in the network.  And therefore we cannot depend upon clock 
synchronization for any part of the protocol to work.   Which implies 
that the protocol must work when the clocks are NOT synchronized.   How 
do we insure this?   --> rigorous protocol analysis.

While the values of certain timers may be left to the Service 
Definition/SLA, as I state before, we must make sure that the protocol 
can function predictably and consistently in the face of all possible 
timing permutations that are possible among NSAs.  This rapidly gets 
very complex if we allow too many variables for the SD/SLA to define.  
Sometimes, its ok to identify constants that the protocol must use so 
that we can validate the protocol and simplify implementation and 
deployment.  Indeed, often times when clocks are only slightly skewed 
they introduce race conditions that become more likely to occur 
requiring more careful consideration.
>
> d. Similar semantics apply to the end-time as well.
Pretty much.  Across the board,  things like clock events, estimates, 
and service specific choices will create situations where we need to 
insure  the protocol and state machines will function properly across 
the full range of possible permuted values.   This is in general why 
protocol designers say "make it only as complex as it needs to be, and 
no more" - options breed complexity.

br
Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100929/99d156e8/attachment.html