[Nsi-wg] time issue

[Radek Krzywania]

Hi,

Well, it require discussion and „wording” but in general I would agree. There will be now question should we cancel the reservation if start is delayed, or keep best effort.  I would insist on best effort for v1, however. IMHO we should say explicitly it’s best effort, we try our best, we can’t guarantee service timing. It may be delayed, but still delivered. What we should guard is the duration of the connection as requested by user (so if start delayed, we should finish delayed), and timeouts (so connection not ready in 20 minutes is out). We need to have those “buffers” counted in calendars for resources booking, preventing resources to overlap. Setting up a connection in advance (as I said before e.g. 20 minutes) should solved most of the issues here, at least for now.

 

I would like to see in practice how the protocol and agents works, and then decide (basing on user comments maybe) if it’s fine or needs to be tuned. 

 

 

 

Best regards

Radek

 

________________________________________________________________________

Radoslaw Krzywania                      Network Research and Development

                                           Poznan Supercomputing and  

 <mailto:radek.krzywania at man.poznan.pl> radek.krzywania at man.poznan.pl                   Networking Center

+48 61 850 25 26                              <http://www.man.poznan.pl> http://www.man.poznan.pl

________________________________________________________________________

 

From: Jerry Sobieski [mailto:jerry at nordu.net] 
Sent: Thursday, September 30, 2010 8:02 PM
To: radek.krzywania at man.poznan.pl
Cc: nsi-wg at ogf.org
Subject: Re: [Nsi-wg] time issue

 

Hi Radak-

Good post.  I concur with it pretty well also.   See comments in line...

Radek Krzywania wrote: 

Hi,

It’s getting hard to solve everything here, so let’s don’t try to solve everything here at once. So how about defining a start time as a best effort for v1? 

I suggest the both the Start Time and End Time are "best effort" times.    We can bound a delayed start -  see below.




So we promise to deliver the service, yet we are unable to guarantee the exact start time in precision of seconds. If user want connection to be available at 2pm, it will be around that time, but we can’t guarantee when exactly (1:50, 2:01, 2:15). Let’s take a quite long time as a timeout (e.g. 20 minutes), and start booking the circuit in 5 or 10 minutes in advance (no discussion for v1, just best feeling guess) . The result will be that in most cases we will deliver the service at AROUND specified time. 

I suggest we word it something like this: 

"The Reserved Time should precede the Start Time sufficiently to allow auto-start provisioning to complete successfully at or before the committed Start Time.   An auto-start Provisoning process that exceeds the Start Time by <<1 minute>> constitutes a failed provisioning process and a Provision Fault error is generated."

This will bound the problem - the network will deliver within one minute of the scheduled start time, or declare a fault condition and fall on its sword.   We can discuss if this is adequate for V1.0.   And what the recovery action should be:   release the connection and notify the user? notify the user and continue provisioning? ...?

Likewise, in order to prevent a premature Release (:-), we should say something like this:

"Upon receiving a calandar alarm indicating that the Stop Time for a connection has been reached, the NSA shall wait for <<1 minute>> grace period before initiating auto-stop Release processing for the connection.   However, upon receipt of a valid Release message from another NSA, the local NSA shall cancel the grace period and immediately proceed with Release processing.   The Reservation Stop Time shall  succeed the In Service Stop Time sufficiently to properly and completely bring local resources to a known idle and secure state, including the grace period."


Thoughts?
Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100930/72645fee/attachment-0001.html