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@man.poznan.pl
Networking Center
+48 61 858 20 28
http://www.man.poznan.pl
________________________________________________________________________
-----Original Message-----
From: nsi-wg-bounces@ogf.org
[mailto:nsi-wg-bounces@ogf.org] On Behalf Of
Artur Barczyk
Sent: Tuesday, April 13, 2010 10:11 AM
To: Inder Monga
Cc: nsi-wg@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@cern.ch]
Sent: 12 April 2010 17:28
To: nsi-wg@ogf.org <mailto:nsi-wg@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@uva.nl]
Sent: 12 April 2010 08:19
To: Guy Roberts
Cc: John Vollbrecht; nsi-wg@ogf.org
<mailto:nsi-wg@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@internet2.edu]
Sent: 09 April 2010 17:28
To: Guy Roberts
Cc: John Vollbrecht; Tomohiro
Kudoh; Jeroen van der Ham;
nsi-wg@ogf.org <mailto:nsi-wg@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@aist.go.jp]
Sent: 09 April 2010 09:04
To: Jeroen van der Ham
Cc: nsi-wg@ogf.org <mailto:nsi-wg@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@uva.nl <mailto:vdham@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@ogf.org <mailto:nsi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@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@ogf.org <mailto:nsi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/nsi-wg
---
Inder Monga http://100gbs.lbl.gov
imonga@es.net <mailto:imonga@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@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