[Nsi-wg] time issue
Artur Barczyk
Artur.Barczyk at cern.ch
Thu Sep 30 11:18:10 CDT 2010
Why the rush?
As I pointed out in the previous mail, there will not be many
applications which will
be able to benefit from this way of circuit scheduling. At least the one
I have in mind
won't...
Cheers,
Artur
On 09/30/2010 06:06 PM, Guy Roberts wrote:
>
> I support Radek’s approach on this one – in the absence of
> deterministic setup times, let’s take a heuristic approach and rely on
> the operating experience gained from systems such as AutoBAHN. As we
> gain more operating experience we may be able to find a better
> solution for future NSI versions.
>
> Guy
>
> *From:* Radek Krzywania [mailto:radek.krzywania at man.poznan.pl]
> *Sent:* 30 September 2010 16:52
> *To:* 'Artur Barczyk'
> *Cc:* nsi-wg at ogf.org
> *Subject:* Re: [Nsi-wg] time issue
>
> Hi,
>
> There is no, and will be no such mechanism to define static, constant
> or even predictable connection activation time in distributed
> environment. What we do is estimates. You have a VC at 2pm, ask for
> circuit available at 1:40, as you were warned connection setup time
> may take up to 20 minutes. Then you have a guarantee. Please mind, v1
> can’t solve everything. Let’s just create something and improve it
> step by step.
>
> Yes, in above case you extend reservation time, which means you pay
> more (in theory, depending on pay model). But think in reverse
> direction – how do you know how long do you need a connection? You
> usually guess and adds something just in case. So you don’t use it in
> optimal way anyway. For v1 – I would not care much. If we try to
> restrict it in details, we will stack in discussion and complexity of
> the protocol and its mechanisms. I would rather keep it simple in
> contrary.
>
> 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
>
> ________________________________________________________________________
>
> *From:* Artur Barczyk [mailto:Artur.Barczyk at cern.ch]
> *Sent:* Thursday, September 30, 2010 5:25 PM
> *To:* radek.krzywania at man.poznan.pl
> *Cc:* 'Jerry Sobieski'; 'Jeff W.Boote'; nsi-wg at ogf.org
> *Subject:* Re: [Nsi-wg] time issue
>
> Hi Radek, All,
>
> hmmmm, I for my part would be quite annoyed (to put it mildly), if I
> miss the first
> 15 minutes of todays HD conf call just because I reserved the
> resources a week
> in advance. "Around" has no place in a well defined protocol. No fuzzy
> logic, please :-)
> Consider also the "bored child in a car" scenario:
> RA: are we there yet? PA: no... RA: are we there yet? PA: nooo.... RA:
> are we there yet? PA: NO! etc.
>
> Be aware that users complaining are users quite quickly lost. You
> don't want that.
>
> So let's consider two example users:
> - high volume data transfers through a managed system: a data movement
> scheduler has
> reserved some bandwidth at a given time. This time comes, the
> application will just
> throw data on the network, it might use connection-less protocol, or
> not, but it will
> result in an error. It cannot wait "around" 15 minutes, as it will
> bring the transfer schedule
> in complete disorder. Such a "service" is just useless.
> - video conferencing/streaming. You reserve the network resource for
> 3pm because your
> meeting starts then. How do you explain to the video conference
> participant that the
> network prevented the conference to start for "around" 15 minutes?
> (Well, you can, but
> this will be the last time you'll see the user using your network :-) )
>
> In short, the only reasonable thing to do is to put the right
> mechanism in place to
> guarantee the service is up when the user requested it (and you
> confirmed it).
> The only acceptable reason for failing this is an error condition like
> network down (and we'll
> talk about protection in v2 :-) )
>
> I also think it is very dangerous to use "providing a service" as
> argument while the underlying
> protocols are not yet correctly specified. This is not theoretical,
> the service needs to be useful
> to the end-user, if you want some uptake. Fuzzy statements make it
> useless. The very reason people
> are interested in this is that it's deterministic - you know what you
> get and when. Otherwise use the
> routed network. :-)
>
> Cheers,
> Artur
>
>
>
> On 09/30/2010 03:37 PM, 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? 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. For v1 is
> enough, as we will be able to deliver a service, while in v2 we can
> discuss possible upgrades (unless our engineering approach discovers
> it’s fine enough :) ).
>
> For #1 – it may a problem for instant reservations. Here user want a
> circuit ASAP. We define ASAP as (see above approach) less than 20
> minutes (typically 5-10 minutes probably, but that’s my guess), or not
> at all. Users may or may not complain on that. In the first case we
> are good. For the second case we will need to design an upgrade for v2.
>
> Synchronization IMHO is important, and out of scope at the same time.
> We can make an assumption that agents times are synchronized with
> precision of let say 10 seconds, which should be far enough. The
> agents will use system clocks, so they need to be synchronized at the
> end (NTP or whatever), but that not even implementation but deployment
> issue. So let put into specification: “NSI protocol requires time
> synchronization with precision not less than 10seconds”. If we
> discover it’s insufficient, let’s upgrade it for v2.
>
> We already have some features to implement, just to see if it works
> fine (works at all, actually). If user is booking a circuit a week in
> advance, I guess he will not mind if we set it up 15 minutes after
> start time (user IS aware of that as we specify this in the protocol
> description). We can’t however deliver the service shorter than user
> defined time. So we can agree (by voting, not discussing) the fixed
> time values. My proposal is as above:
>
> 20 minutes for reservation as set up time
>
> Service availability time (e.g. 13 h)
>
> Service tear down time (it’s not important from user perspective, as
> since any segment of connection is removed, the service is not
> available any more, but let’s say 15 minutes)
>
> In that way, calendar booking needs to have reserve resources for 13h
> 35 minutes. IMHO we can agree on that by simply vote for v1 (doodle
> maybe), and collect more detailed requirements for v2 later on. I get
> the feeling we started quite theoretical discussion based on
> assumptions and guessing “what if”, instead of focusing on delivering
> any service (event with limited guarantee).
>
> 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
>
> ________________________________________________________________________
>
> *From:* nsi-wg-bounces at ogf.org <mailto:nsi-wg-bounces at ogf.org>
> [mailto:nsi-wg-bounces at ogf.org] *On Behalf Of *Jerry Sobieski
> *Sent:* Wednesday, September 29, 2010 9:33 PM
> *To:* Jeff W.Boote
> *Cc:* nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
> *Subject:* Re: [Nsi-wg] time issue
>
> Ok. I can buy this approach of #1. The Requested Start Time is
> immutable as the request goes down the tree (which disallows #2) - it
> is still a Requested Start Time, but NSAs are not allowed to change
> requested start time as the request goes down the tree. But you
> can't prevent #3 if thats what an NSA somewhere down the tree decides
> to do. The result would be a promise he may not be able to keep -
> but thats acceptable because the Estimated Start Time is just an
> estimate, its not binding.
>
> The point is, the local NSA cannot tell whether a remote NSA is using
> #1 or #3 since its totally up to the remote NSA to select the guard
> time appropriate for that request. Likewise, even if the remote NSA
> misses the Estimated Start Time, the requesting RA has no recourse
> other than to a) just wait until the provisioning completes or b) give
> up and release the connection. An SLA might influence the bad NSA
> to not low ball his provisioning guard time in the future, or it may
> provide a rebate for the jilted user, but these are not a protocol or
> a standards issue.
>
> This goes to John's comment on the call today about what happens
> inside the NSA between the PA role and the RA role... These actions
> are captured in "state routines" that are invoked when protocol events
> occur. These actions are generalized in the standard, but any
> heuristics like these approaches to guard time cannot always be
> mandated. In a protocol standard, what ever components are
> "required" or "must" items, must be verifiable in a conformance
> test. I.e. if someone comes up with an NSI imlementation, we should
> be able to put the reference implementation against the test
> implementation and we should be able to tell via protocol operation if
> the implementation under test is doing all the "must" items. If we
> say an NSA must use #1 above, there is no way to test it and confirm
> that it is doing so. If the test implementation uses #3, the only
> outward sign is that it may miss the start time on some connection(s),
> but it could have as easily just been a poor judgment call on the
> provisioning time - which is ok.
>
> So, in the standard, we can only recommend #1 be used. Or we can say
> the NSA "should" use #1. But we cannot require it.
>
> my $.02
> Jerry
>
> Jeff W.Boote wrote:
>
> On Sep 29, 2010, at 7:31 AM, Gigi Karmous-Edwards wrote:
>
>
>
> Jerry,
>
> For your question : " 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?"
>
> In my opinion, I think the answer here has to be # 1) each NSA must
> reject the request if their process to establish the connection
> requested can not meet the Start time. In my opinion an NSA should NOT
> be allowed to change the requested start time (this will cause all
> types of problems for other NSAs), so # 2) is not an option. The guard
> time for each NSA will most likely be vastly different and very
> dependent on the tools used by that network domain to configure the
> network elements for the requested path, so an individual guard time
> of an NSA is also nonnegotiable, so option # 3) is not an option.
>
> I agree #1 seems the most deterministic.
>
>
>
>
> I agree with Radek, ONLY Start times and End times should be used in
> the protocol and that guard times are only private functions of each
> individual NSA.
>
> I agree with this. The guard times are not additive across each NSA.
> The guard time from the perspective of the user will effectively be
> the maximum of each NSAa guard time in the chain. But, the user
> doesn't care as long as provisioning is accomplished by the users
> requested start time. That time would be in the protocol and would
> remain unchanged through each step of the chain. And, it shouldn't
> matter how long it takes to tear down the circuit either as long as
> the circuit is available until their requested end time.
>
> As to how to manage this time synchronization... I think it is totally
> reasonable to depend upon existing protocols. There are other
> protocols that already depend upon time synchronization, and many of
> them use NTP. We are not talking about needing very tight
> synchronization anyway. 1 second or even 10 seconds is plenty close
> enough. It is more about bounding that error.
>
> jeff
>
>
>
>
> Kind regards,
> Gigi
>
> On 9/29/10 8:45 AM, Jerry Sobieski wrote:
>
> 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
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> --
> Dr Artur Barczyk
> California Institute of Technology
> c/o CERN, 1211 Geneve 23, Switzerland
> Tel: +41 22 7675801
--
Dr Artur Barczyk
California Institute of Technology
c/o CERN, 1211 Geneve 23, Switzerland
Tel: +41 22 7675801
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100930/40aecf7b/attachment-0001.html
More information about the nsi-wg
mailing list