[Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)

Artur Barczyk Artur.Barczyk at cern.ch
Tue Apr 13 08:26:11 CDT 2010 

Hi Inder, All,

On 04/13/2010 02:48 PM, Inder Monga wrote:
> All,
> 
> I agree about deterministic behavior. That is what we are all shooting
> for :) I am thinking in terms of state machines as well. 
> 
> What I am hearing both of you state that "Start Time" is not really a
> "Start time"...it is ASAP after "Start time" in case things are not
> complete? This is fine for a data movement service without hard
> deadlines, how will you ensure this for a Video conf system that needs
> to start at a particular time? We have to think of all possible
> application services that can use NSI.

Exactly - if I need to start the VC in the next 5 minutes, it won't help
me to wait for a guard time of 10 (as example). I would prefer to
have it start as soon as possible.
But if I have to schedule a VC in an hour from now, then there's no
issue anyway
(always assuming the resources are plenty).

Cheers,
Artur

> 
> Radek, maybe Guard-time is being misunderstood - I am merely suggesting
> a gap before which Advanced Reservation Requests are not processed by
> the domain. There is nothing non-deterministic and immeasurable about
> that. It is a fixed value, albeit arbitrary value. This reduces the
> chances of the provisioning system across domains from "thrashing" -
> i.e. reserving resources and maybe releasing them because the connection
> did not happen in time.
> 
> Regardless of the decision on guard-time, for deterministic behavior for
> many error conditions including start time arriving and reservation is
> incomplete and start time arriving and provisioning is incomplete. 
> 
> 
> Enjoying the discussion,
> Inder
> 
> 
> 
> On Apr 13, 2010, at 5:26 AM, Artur Barczyk wrote:
> 
>> Hi Radek,
>>
>> agree, but just to note, it's not about deterministic time, but
>> deterministic
>> behaviour I am worried about.
>> I don't see a stable system where one part can be in provisioning
>> while another in reservation. Guard time will not solve this by itself,
>> even if you make it 2 months :-)
>>
>> Cheers,
>> Artur
>>
>>
>> On 04/13/2010 02:15 PM, Radek Krzywania wrote:
>>> Hi,
>>> I tried to catch up the discussion, hope I did not missed anything.
>>> What is hard for me to understand is why are we trying to define
>>> measurable parameters (connection activation time) basing on
>>> non-deterministic, immeasurable parameters (guard time). Even if we
>>> measured how much time it takes to reserve and activate connection in
>>> a domain, we have only statistical view on how much time it MAY
>>> (SHOULD) take. Any change to the network, NSI architecture, HW, or
>>> even SF may extend this time unexpectedly, without prior
>>> notification. This is not something we can measure (or we need to do
>>> that constantly, changing guard time value every time, which in fact
>>> does not solve everything). IMHO we can't promise something we could
>>> not prove or be sure of. I am happy to measure guard time, add safe
>>> value (e.g. res + activation takes 4 minutes, + 2 minutes safe time =
>>> 6 minutes) and say to we SHOULD deliver a connection in less than 6
>>> minutes. If we say we MUST provide it in less than 6 minutes, we have
>>> an issue.
>>> I am rather more familiar with the option where connection is
>>> delivered as soon as possible, which means each domain performs
>>> reservation, then signalling is initialized immediately after
>>> resources are booked. Does user care if he gets it now = current
>>> time, or = current time + "gurad time or whatever"? I suppose not. If
>>> I want a circuit now, I expect to get it ASAP, which does not means
>>> it's deterministic. I am fine with knowledge I will get it around 6
>>> minutes (statistically), but I must be immediately notified about
>>> activation. If we want to go into time details, we will get into very
>>> funny things like GPS synchronisation between users, NSA agents,
>>> networks, and domains. This is not a real-time system, not everything
>>> is deterministic, and not everything can be guaranteed. We can
>>> reconsider naming of the service, and change it from immediate to ASAP.
>>> I am not sure if we should focus on this small issue, while facing
>>> resources guarantee in advance reservation mode. Try to guarantee
>>> there anything for 100% in 2 months time period:) Even if you assume
>>> no network/HW failures.
>>>
>>> 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 858 20 28                             http://www.man.poznan.pl
>>> ________________________________________________________________________
>>>
>>>
>>>> -----Original Message-----
>>>> From: nsi-wg-bounces at ogf.org <mailto:nsi-wg-bounces at ogf.org>
>>>> [mailto:nsi-wg-bounces at ogf.org] On Behalf Of
>>>> Artur Barczyk
>>>> Sent: Tuesday, April 13, 2010 10:11 AM
>>>> To: Inder Monga
>>>> Cc: nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>; Guy Roberts
>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call
>>>> minutes)
>>>>
>>>> Hi Inder,
>>>>
>>>> I see, thanks for this clarification.
>>>>
>>>> I still think we are introducing an artificial decision step here, which
>>>> will just be confusing to the end-user (and make the whole system
>>>> more complex), and I still wonder about the necessity of it.
>>>> Please see in-line:
>>>>
>>>>
>>>> On 04/12/2010 11:15 PM, Inder Monga wrote:
>>>>> Hi All,
>>>>>
>>>>> I feel there is a lot of confusion, so let me try to explain my
>>>>> case/understanding.
>>>>>
>>>>> 1. Guard-time:
>>>>> This concept was proposed for Advanced Scheduling only. This can be a
>>>>> default value and it does not have to be an "exact" measurement of
>>>>> provisioning times. It only handles path computation and reservation
>>>>> times across domains.
>>>>>
>>>>> What does it mean to a user?
>>>>> A user CANNOT ask for a advanced reservation connection with Tstart <
>>>>> Tnow + Guard-time. If a user asks with a Tstart lower that Tnow +
>>>>> Guard-time, the scheduled request is rejected outright.
>>>>
>>>> Imagine I try to make a connection "NOW", and it gets refused after
>>>> N minutes due to lack of resources. Then I  try "2 minutes from
>>>> now", and
>>>> it gets rejected straight off.
>>>> We shouldn't aim at having expert users who would understand this.
>>>> I think the system should behave in the same (and deterministic) way,
>>>> independent of what the user states in reservation time.
>>>> (Btw - that the reservation and provisioning time might vary does not
>>>> make it less deterministic.)
>>>>
>>>>>
>>>>> With an ADvanced Scheduling function, provisioning initiation can
>>>>> happen
>>>>> from both the user or the provider.
>>>>>
>>>>> 2. On-Demand Service: In my opinion, Guard-time does not prevent an
>>>>> On-Demand service as specified by Jerry. They co-exist.
>>>>> An on-demand service, with Tstart = ASAP can be implemented very
>>>>> easily.
>>>>> The service starts when the "provisioning complete" message is received
>>>>> by the user. If the user does not receive that message, it continues to
>>>>> wait.
>>>>
>>>> Exactly what I was aiming at - but the same logic can apply to any time
>>>> between "NOW" and the guard time, or doesn't it?
>>>> All you need to do, if the start time is reached before the reservation
>>>> is complete, to wait for the latter.
>>>>
>>>>>
>>>>> Does this make more sense?
>>>>>
>>>>> I will answer specifics below.
>>>>>
>>>> [...]
>>>>
>>>>>> What I meant is that if that time has passed by the time the provider
>>>>>> NSA gets notified of the reservation acceptance along the path, it
>>>>>> should proceed directly to provisioning.
>>>>>
>>>>> In advanced reservation, the open question is what should a domain
>>>>> do if
>>>>> Tstart comes, and it has not got a reservation complete or provision
>>>>> message? Should it delete the connection or provision its own set of
>>>>> resources? Chin and I include this case in the error recovery document
>>>>> to be published soon.
>>>>
>>>> No, no - simply wait for the reservation to complete. Only then will
>>>> you know if it succeeded in the first place.
>>>>
>>>> IMO, the provisioning and reservation systems cannot be completely
>>>> decoupled. The provisioning stage should actually never be reached
>>>> until a reservation is complete. It is dependent on the outcome of the
>>>> path computation as well as resource reservation. Never go to
>>>> provisioning
>>>> before you know you can have the resources.
>>>>
>>>>>
>>>>>>
>>>>>> You have to do this anyway, to protect against the guard time being
>>>>>> set too short. In which case you can just as well set the guard
>>>>>> time to 0.
>>>>>>
>>>>>> That's just common sense, IMO, what it means when I would ask for
>>>>>> immediate
>>>>>> circuit provisioning. "Please give it to me as soon as you're able to,
>>>>>> I'm waiting."
>>>>>>
>>>>>> The thing not to forget is that someone can ask for a circuit not only
>>>>>> "now",
>>>>>
>>>>> I think the "now" case is actually, "as soon as possible" - which
>>>>> is the
>>>>> on-demand case. Then it just waits for the right message from the
>>>>> Provider Agent before it knows the connection is available to be used.
>>>>
>>>> Yes, absolutely agree - that's a discussion terminology, which I'd be
>>>> happy to change :-)
>>>> However, we need to be precise on what we mean. An "ASAP" reservation,
>>>> from a user's point of view, could mean really "any time possible,
>>>> starting
>>>> from now", i.e. also in 2 hours, if the resources will only then become
>>>> available.
>>>> I am not sure BoD does mean that.
>>>> Will in such a case a BoD reservation be converted into a scheduled one?
>>>>
>>>>>
>>>>>> but "a minute from now", which would lead to the same problem if the
>>>>>> time to
>>>>>
>>>>> A minute from now actually becomes a "scheduled connection" and
>>>>> there is
>>>>> where the problem really starts.
>>>>
>>>> I am sorry I have missed large parts of this discussion, being kept
>>>> off with
>>>> other workload. Sorry if I am coming back to things which might be
>>>> obvious
>>>> to you by now.
>>>> But I do not really understand where the problem really is.
>>>> You mention the provisioning system to have to decide what to do
>>>> if  the reservation step is not complete - but I think the right design
>>>> decision
>>>> would be that the system should never actually be in such a state.
>>>> (Sorry, I am falling into thinking in terms of state machines here, but
>>>> well,
>>>> that's what I start to believe would be good here.)
>>>>
>>>> Is there other reasons?
>>>>
>>>> Cheers,
>>>> Artur
>>>>
>>>>>
>>>>> I feel we should support both Advanced Reservation with guard-time and
>>>>> On-demand connection service.
>>>>>
>>>>> Inder
>>>>>
>>>>>> process the reservation is longer than a minute (as it most probably
>>>>>> will be
>>>>>> in the next future).
>>>>>> So the "now" string as in your option 2) would only work for a
>>>>>> singular
>>>>>> subset of the
>>>>>> problem.
>>>>>>
>>>>>> Cheers,
>>>>>> Artur
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Guy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Artur Barczyk [mailto:Artur.Barczyk at cern.ch]
>>>>>>> Sent: 12 April 2010 17:28
>>>>>>> To: nsi-wg at ogf.org <mailto:nsi-wg at ogf.org> <mailto:nsi-wg at ogf.org>
>>>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf
>>>>>>> call minutes)
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think guard time is a shaky concept, as who can tell how long
>>>>>>> it should
>>>>>>> be - it can/will depend on the number of domains the circuit
>>>>>>> contains, the
>>>>>>> speed of each reservation/provisioning system as well as the load
>>>>>>> on the
>>>>>>> system, and will be variable over time (hoping for faster
>>>>>>> reservation/provisioning
>>>>>>> systems in the future).
>>>>>>>
>>>>>>> But: if in step 5, the "wait for start time" means t_start <=
>>>>>>> t_current,
>>>>>>> then the
>>>>>>> provider will immediately pass on to provisioning.
>>>>>>> What needs to be done however is to have the duration of the
>>>>>>> reservation
>>>>>>> reflect the time difference between desired start time and the
>>>>>>> effective
>>>>>>> one.
>>>>>>>
>>>>>>> I am sure I am missing something..?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Artur
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 04/12/2010 11:12 AM, Guy Roberts wrote:
>>>>>>>> Jeroen,
>>>>>>>>
>>>>>>>> Yes, that is correct.  But the mechanism will be the same for
>>>>>>>> advance reservations, just a later start time.
>>>>>>>>
>>>>>>>> Guy
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jeroen van der Ham [mailto:vdham at uva.nl]
>>>>>>>> Sent: 12 April 2010 08:19
>>>>>>>> To: Guy Roberts
>>>>>>>> Cc: John Vollbrecht; nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>>>>>>>> <mailto:nsi-wg at ogf.org>
>>>>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf
>>>>>>>> call minutes)
>>>>>>>>
>>>>>>>> To sum this up, this describes a situation where there is no prior
>>>>>>>> reservation and provisioning is started immediately because the
>>>>>>>> startTime is meant as a "now"?
>>>>>>>>
>>>>>>>> Jeroen.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/04/2010 18:56, Guy Roberts wrote:
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> My thinking of how it could work is as follows (though the details
>>>>>>>>> are really part of the protocol definition group's work):
>>>>>>>>>
>>>>>>>>> StartTime= time when the provisioning is begun.  This is the only
>>>>>>>>> possible meaning for StartTime since we have no way of knowing how
>>>>>>>>> long the provisioning will take in advance of the provisioning
>>>>>>>>> being performed. i.e provisioning completion time is
>>>>>>>>> non-deterministic.  For consistency as an asynchronous system, the
>>>>>>>>> completion of provisioning (in-service) is pushed by the NRM to the
>>>>>>>>> Provider which in turn sends this to the Requestor as a
>>>>>>>>> notification.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Locally initiated provisioning:
>>>>>>>>> 1. The Requester NSA creates a request with a start time
>>>>>>>>> (StartTime).  StartTime= NSAs current time  + Requester guard time.
>>>>>>>>> Eg 12:00pm + 5 minutes = 12:05pm.
>>>>>>>>> 2. Provider validates the start time as being at least the provider
>>>>>>>>> guard time away from now. (note requester and provider guard times
>>>>>>>>> could be a little different to allow for transmission delay of
>>>>>>>>> request)
>>>>>>>>> 3. Provider begins the reservation process (12:01pm)
>>>>>>>>> 4. Provider completes the reservation (12:02pm)
>>>>>>>>> 5. Provider waits for the startTime (12:05pm)
>>>>>>>>> 6. Provider starts provisioning locally (12:05pm)
>>>>>>>>> 7. Provider waits for confirmation of provisioning from NRM
>>>>>>>>> (12:06pm)
>>>>>>>>> 8. Provider sends a notification to the requestor NSA to notify
>>>>>>>>> that the connection is in-service (12:06pm)
>>>>>>>>>
>>>>>>>>> Provisioning signalled by Requester:
>>>>>>>>> 1. The Requester NSA creates a request with a start time
>>>>>>>>> (StartTime).  StartTime= NSAs current time  + Requester guard time.
>>>>>>>>> Eg 12:00pm + 5 minutes = 12:05pm.
>>>>>>>>> 2. Provider validates the start time as being at least the provider
>>>>>>>>> guard time away from now. (note requester and provider guard times
>>>>>>>>> could be a little different to allow for transmission delay of
>>>>>>>>> request)
>>>>>>>>> 3. Provider begins the reservation process (12:01pm)
>>>>>>>>> 4. Provider completes the reservation (12:02pm)
>>>>>>>>> 5. Provider waits for the startTime (12:05pm)
>>>>>>>>> 6. Provider waits for the signal to provision (12:10pm)
>>>>>>>>> 7. Provider initiates provisioning of the Connection (12:10pm)
>>>>>>>>> 7. Provider waits for confirmation of provisioning from NRM
>>>>>>>>> (12:11pm)
>>>>>>>>> 8. Provider sends a notification to the requestor NSA to notify
>>>>>>>>> that the connection is in-service (12:11pm)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: John Vollbrecht [mailto:jrv at internet2.edu]
>>>>>>>>> Sent: 09 April 2010 17:28
>>>>>>>>> To: Guy Roberts
>>>>>>>>> Cc: John Vollbrecht; Tomohiro Kudoh; Jeroen van der Ham;
>>>>>>>>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org> <mailto:nsi-wg at ogf.org>
>>>>>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf
>>>>>>>>> call minutes)
>>>>>>>>>
>>>>>>>>> I am still a bit confused.  Perhaps someone could do a timing
>>>>>>>>> diagram
>>>>>>>>> like the one Tomohiro did a while ago when we were discussing 2
>>>>>>>>> phase
>>>>>>>>> commits.
>>>>>>>>>
>>>>>>>>> I will try to explain my confusion.  My understanding has been that
>>>>>>>>> we
>>>>>>>>> agreed that provisioning would never be done without prior
>>>>>>>>> reservation.  So it would seem that the question being discussed is
>>>>>>>>> "what is the time being requested in a reservation".  If the
>>>>>>>>> reservation succeeds then provisioning can happen.
>>>>>>>>>
>>>>>>>>> It seems to me one question is how to define the start time being
>>>>>>>>> requested.  The options seem to be that is is either 1) the
>>>>>>>>> time the
>>>>>>>>> circuit is actually provisioned and ready to use or 2) the time
>>>>>>>>> that
>>>>>>>>> provisioning of the circuit starts.  In one case the previous
>>>>>>>>> connection may terminate sooner by the guard time and in the latter
>>>>>>>>> it
>>>>>>>>> may start later by the guard time.    If it is (1) then a
>>>>>>>>> connection
>>>>>>>>> scheduled for now must have been started at [now - (start time)].
>>>>>>>>>
>>>>>>>>> A second question is whether is is possible to request a connection
>>>>>>>>> that starts "now".  This implies reserving a connection and
>>>>>>>>> initiating
>>>>>>>>> it as soon as it is reserved.  Assume that start time is when
>>>>>>>>> provisioning a circuit starts (case 2 above).  It seems that main
>>>>>>>>> issue with this is whether the time to reserve a connection is
>>>>>>>>> longer
>>>>>>>>> than the requestor is willing to wait.  The time it takes
>>>>>>>>> depends on
>>>>>>>>> how many NSAs are "chained" to satisfy the request and how long
>>>>>>>>> each
>>>>>>>>> NSA takes to reserve the connection.  This time is "authorization
>>>>>>>>> time" not guard time as I understand it.
>>>>>>>>>
>>>>>>>>> There is another issue with defining authorization as "now" instead
>>>>>>>>> of
>>>>>>>>> a specific time.  The problem is that each NSA in a chain will
>>>>>>>>> think
>>>>>>>>> authorization happens at a slightly different time.  I am not sure
>>>>>>>>> how
>>>>>>>>> important this is - it doesn't seem too important to me, but
>>>>>>>>> perhaps I
>>>>>>>>> am wrong.  If provisioning starts after the reservation is
>>>>>>>>> complete,
>>>>>>>>> then everything should be reserved, if at a slightly different
>>>>>>>>> time.
>>>>>>>>> ----------------------------------
>>>>>>>>>
>>>>>>>>> I think Guy is suggesting that start time is when provisioning
>>>>>>>>> starts
>>>>>>>>> (case 2) above.  That seems simplest to me.
>>>>>>>>> I am not sure the provisioning time is important, and if not I
>>>>>>>>> would
>>>>>>>>> think it good to include "immediate" reservation
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 9, 2010, at 11:15 AM, Guy Roberts wrote:
>>>>>>>>>
>>>>>>>>>> Tomohiro,
>>>>>>>>>>
>>>>>>>>>>> In this case, only some parts of inter-network connection will be
>>>>>>>>>>> provisioned.
>>>>>>>>>>
>>>>>>>>>> Right, I forgot about this reason - it is a good point.  Again, I
>>>>>>>>>> think we are not complicating things too much if we have a
>>>>>>>>>> rule that
>>>>>>>>>> the Requester NSA cannot send a start time sooner than
>>>>>>>>>> now+guardtime.
>>>>>>>>>>
>>>>>>>>>> I think we can solve the chain issue by not forcing any value for
>>>>>>>>>> the guard time.  This can be a policy decision to suit the service
>>>>>>>>>> type, equipment and number of networks involved.
>>>>>>>>>>
>>>>>>>>>> Guy
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Tomohiro Kudoh [mailto:t.kudoh at aist.go.jp]
>>>>>>>>>> Sent: 09 April 2010 09:04
>>>>>>>>>> To: Jeroen van der Ham
>>>>>>>>>> Cc: nsi-wg at ogf.org <mailto:nsi-wg at ogf.org> <mailto:nsi-wg at ogf.org>
>>>>>>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf
>>>>>>>>>> call minutes)
>>>>>>>>>>
>>>>>>>>>> Hi Jeroen,
>>>>>>>>>>
>>>>>>>>>> There is a problem for inter-network connection. During the
>>>>>>>>>> discussions
>>>>>>>>>> in some calls, the problem of synchronizing networks (managed by
>>>>>>>>>> different NSAs) was discussed.
>>>>>>>>>>
>>>>>>>>>> If you use the "now" type request for inter-network connection
>>>>>>>>>> (without
>>>>>>>>>> complicated coordination), the actual provisioning time of
>>>>>>>>>> networks
>>>>>>>>>> may
>>>>>>>>>> be different. Moreover, some networks may provision resources
>>>>>>>>>> before
>>>>>>>>>> some other networks reply to the request, and such networks
>>>>>>>>>> might deny
>>>>>>>>>> the request. In this case, only some parts of inter-network
>>>>>>>>>> connection
>>>>>>>>>> will be provisioned.
>>>>>>>>>>
>>>>>>>>>> The guard time is one of the simple solutions to solve this
>>>>>>>>>> problem. I
>>>>>>>>>> understand there can be multiple ways to cope with this, but
>>>>>>>>>> all of
>>>>>>>>>> them
>>>>>>>>>> will introduce some complication to some part (note that we
>>>>>>>>>> decided
>>>>>>>>>> not
>>>>>>>>>> to use 2PC for the v1.0). This is a design choice matter.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Tomohiro
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 08 Apr 2010 09:27:59 +0200
>>>>>>>>>> Jeroen van der Ham <vdham at uva.nl <mailto:vdham at uva.nl>
>>>>>>>>>> <mailto:vdham at uva.nl>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 07/04/2010 15:02, Tomohiro Kudoh wrote:
>>>>>>>>>>>> If a requester wants resources to be provisioned as soon as
>>>>>>>>>>>> possible, it
>>>>>>>>>>>> can set the start time parameter in a advance request to:
>>>>>>>>>>>> (current time + guard time + a certain time required for message
>>>>>>>>>>>> delivery).
>>>>>>>>>>>>
>>>>>>>>>>>> In this way, immediate provisioning can be requested by an
>>>>>>>>>>>> advance
>>>>>>>>>>>> reservation request.
>>>>>>>>>>>
>>>>>>>>>>> The procedure above seems overly complicated and if I really am
>>>>>>>>>>> pressed
>>>>>>>>>>> for time, and I miscalculate the (current time + guard time +
>>>>>>>>>>> delivery
>>>>>>>>>>> time) by a few seconds. Denying the request means that I have
>>>>>>>>>>> to do
>>>>>>>>>>> it
>>>>>>>>>>> all over again, making me even more pressed for time.
>>>>>>>>>>>
>>>>>>>>>>> Why not keep things simple and always interpret a start time
>>>>>>>>>>> in the
>>>>>>>>>>> past
>>>>>>>>>>> as "now" ? (provided the end-time is in the future too)
>>>>>>>>>>> Would there be any problems associated with that?
>>>>>>>>>>>
>>>>>>>>>>> Jeroen.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> nsi-wg mailing list
>>>>>>>>>> nsi-wg at ogf.org <mailto: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> <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> <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> <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
>>>>>> _______________________________________________
>>>>>> nsi-wg mailing list
>>>>>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org> <mailto:nsi-wg at ogf.org>
>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>>>
>>>>> ---
>>>>> Inder Monga http://100gbs.lbl.gov
>>>>> imonga at es.net <mailto:imonga at es.net> <mailto:imonga at es.net>
>>>>> http://www.es.net
>>>>> (510) 499 8065 (c)
>>>>> (510) 486 6531 (o)
>>>>>
>>>>
>>>> --
>>>> Dr Artur Barczyk
>>>> California Institute of Technology
>>>> c/o CERN, 1211 Geneve 23, Switzerland
>>>> Tel:    +41 22 7675801
>>>> _______________________________________________
>>>> 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
> 
> ---
> Inder Monga http://100gbs.lbl.gov
> imonga at es.net <mailto:imonga at es.net> http://www.es.net
> (510) 499 8065 (c)
> (510) 486 6531 (o)
> 

-- 
Dr Artur Barczyk
California Institute of Technology
c/o CERN, 1211 Geneve 23, Switzerland
Tel:    +41 22 7675801

More information about the nsi-wg mailing list