Hi,
[snip]
2- We need to exapnd this part. Cooperation between PCEs
can take one of two forms, which we refer to as model-based and
ad hoc.
In model-based cooperation (the case described here), PCEs have
information on other domains (aggregate or detailed, available a
priori or upon request), and the path (or a section of the path) is
decided by one PCE at the end.
There is another way the PCEs can cooperate, where they do not
share any information, and they find the end-to-end path in an ad
hoc fashion (similar to DSR). In this case, we have a distributed
path computation.
In your second case, how is the route known by the PCC? Isn't it the
case
that the PCEs share the computed route fragments?
[PT] Yes and no- they share route fragments, but these fragments
are
not
limited to each domain , rather they end at destination. Suggest
looking
at
DSR ad hoc routing. With -zero- topology information shared between
PCEs, a
complete end-to-end path can be computed in a distributed fashion.
This sounds like we're going round in circles.
Recall, we are in section 5.4 (Multiple PCE Path Computation with
Inter-PCE Communication).
You imply that the model described assumes that "PCEs have
information on
other domains (aggregate or detailed) availabel a priori or upon
request."
This is not the case. I think you are confused by the text...
Multiple PCE path computation with inter-PCE communication involves
coordination between distinct PCEs such that the result of the
computation performed by one PCE depends on information supplied by
other PCEs.
You assume that the "information supplied" is TE information. But it
doesn't say that. Perhaps we should clarify what this information
is since
it is less than clear.
We will update this to indicate that the information is "path fragment
information".
Agree, Adrian, this should be clarified since this is apparently not
clear.
Payam, in the case of inter-Provider it is more than likely that no
TE information will be shared at all but rather computed (loose) path
along with their respective cost.
But maybe you will still class this as aggregate TE information and
say
that this is model-based cooperation. That's OK, but let's look at
where
ad hoc routing fits in. There are two cases:
1. The routing progresses in step with the signaling. That is, each
segment
is computed and signaled, then the next segment is computed and
signaled, and so on. In this case the each PCE is invoked
independently
and there is no cooperation or communication between PCEs. This is
the model shown in section 5.3.
2. The alternative is that all of the routing is done before any
signaling
is
started. In this case, each PCE computes a segment of the path and
passes the request on to the next PCE to compute the next segment.
The segment paths are returned to the initial PCE which is able to
pass the full path to the PCC.
But this is exactly the case described in 5.4.
Clearly there are variables.
- Does the initial PCE send requests to more than one other PCE?
- Does the initial PCE suggest multiple border nodes?
- Do the downstream PCEs return multiple paths with different
qualities to allow the initial PCE to choose?
If the answer to these and other questions is "no" then you
have ad
hoc
routing.
Payam, does this explanation close the point ?
- Section 6.3: "Conversely, the PCC may issue a single request to
the PCE asking for all of the paths to be computed in a
synchronized
manner. The PCE will then perform simultaneous computation of the
set of requested path. Such synchronized computation can often
provide more optimal results."
The distinction is clearly important in computation and algorithms,
however, this is not an attribute that can be exposed to or
requested
by the user - user should have a more descriptive requirement
(e.g.,
two full disjoint paths with total cost of less than x - how the
answer
is derived, through simultaneous or sequential processing is not
something the user should ask for (it is like the user asks for
Dijkstra's
algorithm to be used).
When you say "user" do you mean the PCC?
In the first instance the PCC MUST be responsible for this level of
determinism. That is, if it makes two separate requests for paths,
simultaneous computation cannot be performed. But nevertheless the
requests
would be valid...
1. Compute me a path from A to B with least cost.
2. Compute be a path from A to B that is disjoint from the
previous
path
and which has least cost.
Thus, the PCC already has some control over whether simultaneous
computation is requested.
[PT] Not true. As described above PCE may choose to batch process the
requests and process these two requests (and possibly many more in
the
queue) together. We should not assume any correlation between how the
requests are sent and how they are processed.
With respect, this is tosh.
If I send request number one and do not send request number two
until I
see the response to request number one then I have complete control
over
the requests being processed separately and the PCE (unless psychic)
cannot do anything about it.
I think you have this on its head and should re-read 6.3.
Here you will find that the PCC does not have the power to force
the PCE
to process requests separately except by withholding the subsequent
requests.
OTOH the PCC does have the power to require that the PCE process
requests
simultaneously.
The middle option is that the PCC can say that the PCE is free to
process
the requests separately if it chooses.
Fully agree, as pointed out in my previous email.
Therefore, the starting
paragraph in Section 6.3 also needs to be modified, as multiple PCC
requests
does not necessarily mean non-synchronized path computation (unless
explicitly requested, which we'll address in the next bullet).
OK. I can change "will" to "may" to read...
In this case of non-synchronized path computation, the PCE may make
multiple individual path computations to generate the paths and the
ok
Now, many people have told us that they *do* want to be able to
specify
which algorithm is used. And this may be very valid because cheap
(small,
local, easily accessed) PCEs might not be able to perform
simultaneous
computation of very many paths at the same time. It would then be
necessary
for these PCEs to reject the request (so that the PCC could
redirect it
to a
more sophisticated PCE) or redirect the request itself.
[PT] This is a sad point that kills the black box elegance of this
work.
What happens if I come up with a modified or original algorithm in my
PCE
that outperforms existing algorithms?
What if you do?
1. I do not have to exert control, just because I have control. I can
leave the choice to the PCE.
2. However, if I don't trust your new algorithm, I should be able to
select a different one.
In reality all algorithms have positive and negative points.
- Some are more accurate at the cost of being slower
- Some optimise for one feature ahead of other features
- Some are newly developed and untrusted
- Some work poorly in certain network contditions
To say that the user is unable to select the algorithm, is like saying
that the user is not allowed to set the constraints.
See previous email.
It may never get called because its
algorithm is not listed in the PCC list of algorithms. Since this
is a
dangerous issue, let's be clear: Algorithm opacity is fundamental
to the
value of this work, and if someone is interested in specifying an
algorithm,
they are in fact interested in one or more high-level requirements
that
are
addressed by that algorithm. These high-level requirements can be
negotiated
at the time of discovery, which is a much better time than in the
middle
of
making a request and getting disappointed by a cheap PCE. I
suggest we
spell
this out in the document.
I think it is late to revisit this argument.
However, if the WG wants to change its mind, I guess that's fine.
Anyone else want to support Payam on this point?
So, is synchronized vs. non-synchronized an algorithmic
requirement, or
a
high-level requirement? My view is that it is a (poorly defined)
algorithmic
requirement. I can think of a high-level requirement but believe
it is
outside the scope (e.g., total cost should be within x% of the
solution
that
is found by processing n requests at the same time).
Hmmm.
Suppose I set up an unprotected service.
Now I change the service to desire protection.
This can only be achieved by non-synchronized computation (unless I
always
assume that all services might one day need all features!)
But, again, I think you have it on its head. The requirement that is
presented in the draft is that the PCC must be able to constrin the
PCE to
do synchronized computation. That is, the PCC must be able to say
"I know
this is more work for you, and I know it will chew up your CPU, and
I know
it requires you to implement a more clever algorithm, but I insist
that
you use synchronized computation because I want the better quality
result
that will be produced."
In sync with Adrian as per my previous email.
The point is we should drop the whole idea of asking for
synchronized or
non-synchronized computation. The better approach is to have the PCC
learn
the PCE capabilities at the time of discovery and decide not to
choose a
PCE
because it cannot satisfy a more high-level requirement.
And how will you describe the PCC capabilities? Presumably you will
indicate that the PCE can or cannot perform synchronized computation.
But suppose a PCE says "I can do fast unsynchronized computation,
or slow
synchronized computation" That is, the PCE has two algorithms
available.
So the PCC chooses this PCE to service its request. How will the
PCE know
which algorithm to use?
Note that this belongs to the requirements IDs ... To be discussed in
this context.
- Section 6.6: Perhaps reliability instread of level of robustness?
Oooh!
Having spent some time with Mr. Webster, I conclude that
Reliable and
Robust are adequate synonyms.
[PT] Sorry about being picky for certain words, but there are
tons of
material on assigning reliability functions (standard term in
reliability
engineering with clear definition based on the resource failure
rate and
resource age) to network elements/resources, and using reliability
as a
metric in path computation- Suggest you do a search for "computing
the
most
reliable path".
You are welcome to be picky about the use of English; I am all the
time.
Will you settle for the text suggested to Dimitri...
- the levels of resiliency, reliability and robustness of the path
resources
Thanks.
JP.
Cheers,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
