[Nsi-wg] time issue

Tue Sep 28 16:40:04 CDT 2010

Hi Radak - see comment below...

Radek Krzywania wrote:
>
> Hi Jerry,
>
> IMHO setup and tear down times should be considered global (all NSA 
> along a path). 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 ;) ).
>
But we cannot expect all NSAs clocks to be exactly synchronized.    
Clocks are critical to bookahead scheduling, and independent 
quasi-synchronized clocks (however slightly skewed) will cause 
problems.    Some of those problems are evident in this discussion.

Open issue for discussion:  How do we address the issue of clock skew 
across a scheduled network?
>
>  
>
> For tear down, it does not matter where you start to removing the 
> configuration (end point, or any point along the path). Since you 
> remove single configuration point – the service is not available any 
> more. That the time where available time ends.
>
Actually, I would assert that the "available" time ends when the End 
Time elapses.  The "End Time" is by definition when the connection is no 
longer available, and the user should therefore not assume they are 
usable past that time.   Maybe the path resources will stay in place, 
but maybe not.  During reconfiguration, the state of cross connects 
along the path is indeterminate, and if /when they are reconfigured, 
then user data can be [mis]routed to 3rd parties, and 3rd party data may 
be [mis]routed to the egress STP.   

The real issue in my mind is "when is the actual End Time?"  Given that 
we cannot guarantee exactly when each NSA may reach their repective End 
Time, the End Time should be (IMHO:-) an Estimated End Time "plus or 
minus", and the user should consider the ramifications of this.  

We do not know which NSA will reach End Time first and begin to tear 
down the connection.  Nor do we know the delta between this first NSA's 
clock and the user's clock.  

I think the ideal situation is that the user sees the Estimated End Time 
approaching (via their own clock) and stops sending some user defined 
time prior to End Time.  The user lets the connection drain - still 
prior to End TIme.    Once the user traffic is drained, the user RA 
issues a Release Request.  We can, I think, assume that if the user 
issues the manual Release Request before the scheduled availability has 
ended, then the user has verified that no important data remains in the 
pipe.    But due to clock skew and due to the estimated End Time, the 
user's estimate of how much time is remaining may be substantially 
under-estimated.   This is why I think maybe a 2-minute warning might be 
useful - the user can request a warning of "n" seconds, and that warning 
will bubble up from the NSA who's clock is most advanced.  The user can 
then throttle down their traffic accordingly and then issue a Release 
Request.    While this might be nice, it is not fundamentally necessary 
for the protocol.  It helps the user, but the protocol must still be 
able to deterministically handle a user that ignores the warning and 
drives off the cliff.

Fundamentally, we want to make sure the user isn't surprised by an 
earlier than expected release due to clock skew.    And we won't know 
until close to the End Time who's clock is going to trigger the Release 
first.  The warning announces reveals that NSA and gives the user fair 
warning.

Whatever the method for initiating the release,  the network should 
insure that any user data accepted at the ingress prior to the End Time 
is not misrouted - even after the end time.    The network's only 
options are to try to deliver in-flight data properly or drop it.   
Since the End Time has been reached, the network can no longer assume 
that any segments are still usable, so delivering it is not really an 
option either.  The network must drop any stranded traffic.   Thus, we 
need to have some means of blocking new ingress data, and insuring bytes 
in flight get dropped asap. 

One might take a different view if we hold the connection in place for 
some safety/guard time past the local End Time.  This would do several 
things:  1) it would make sure the End Time has elapsed for all NSAs 
especially the user RA thus allowing full use during the available 
timeframe, and b) wait a few mils longer (latency time) so that any data 
in flight is delivered.  At this point (after all NSAs have reached the 
end time plus a latency factor) any remaing data in flight was 
definately sent after the reservation.  Bad user, bad user.   In this 
case, any data in flight is no longer the network's concern.   Then, we 
can reconfigure without regard to securing the user information.

Finally, we might consider how to insure that the connection is not torn 
down until *all* NSAs have reached the End Time.   THis could be 
indicated by flooding a "End Time Alert" notification  or some simlar 
message along the tree.   When that message is acknowledge by all NSAs 
in the connection, then a Release can begin.   Of course, here again, if 
an acknowledge is not received in a finite time, the connection is torn 
down unilaterally.  

I do however, think we need to address End Time processing in V1.0   
This is important - we need to have a clearly defined lifecycle and 
primitievs that do not promise something the protocol cannot deliver.   
 From this discussion, we cannot clearly state when the availability of 
the connection ends.

These are some very interesting and challenging nuances.   I hope this 
was useful musings...
br
Jerry
>
> We can discuss whether it should be synchronized or signaled, but I 
> would even left it for v2 (or v1.1, or whatever we decide). Since ALL 
> segments of connection has configuration removed, the resource time is 
> ended. I agree that resource time is difficult to forecast, yet we 
> need to fit that into calendar full of other reservations and 
> synchronize them.  Thus we need to estimate, guess, or use magic to 
> get those values as realistic as possible. Overlapping is forbidden, 
> and leaving gaps of unused resources will be waste of resources and 
> money at the end.
>
>  
>
> “Two minute warning” is not speaking to me. I don’t see a reason to 
> warn a domain or user that the connection will be closed soon, while 
> user knows what was requested and domain is tracking that with a 
> calendar. We can discuss some internal notifiers, but that’s 
> implementation.
>
>  
>
> Best regards
>
> Radek
>
>  
>
> ________________________________________________________________________
>
> Radoslaw Krzywania                      Network Research and Development
>
>                                            Poznan Supercomputing and 
>
> radek.krzywania at man.poznan.pl 
> <mailto:radek.krzywania at man.poznan.pl>                   Networking Center
>
> +48 61 850 25 26                             http://www.man.poznan.pl
>
> ________________________________________________________________________
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100928/1e122a23/attachment.html 