[Pce] Re: Comments on draft-lee-pce-global-concurrent-optimization-03.txt

Hi Adrian,

On May 11, 2007, at 5:13 AM, Adrian Farrel wrote:

> [Tidied up from Digest response thread]
>
> <chair hat firmly OFF>
>

For the matter of that discussion, same here.

>
>>>> The authors requested the WG to adopt draft-lee-pce-global-
>>>> concurrent-optimization-03.txt as a PCE WG document but before
>>>> pooling the list, >>> I'd like to make a few comments/requests:
>>>>
>>>> This solution is indeed compliant with RFC4655 and as pointed  
>>>> out in the ID, PCEP already supports synchronized path  
>>>> computation requests through the use of the SVEC object.
>>>>
>>>> 1) The PCEP extensions defined in this document are quite
>>>> reasonable and do not substantially overload the protocol
>>>> itself. That being said, the exchange of a substantially large
>>>> amount of data will unavoidably stress the machinery in a  
>>>> significant way. Scalability of solutions trying to achieve
>>>> global optimization have been discussed in length so I won't  
>>>> propose to re-open a fairly old debate but it is well-understood
>>>> that such solutions do not scale well and the major bottleneck  
>>>> is not just the path computation itself but the bulk of data
>>>> that must be exchanged, synchronization issues, failures during
>>>> reoptimization and so on.
>
> Indeed, the path computation bottle-neck is clearly an algorithmic
> issue that is out of scope here, and I know some would argue that
> solutions exist that remove that bottle-neck.
>
> I think that the other items listed would valuably be the subject of
> health warnings in an applicability statement as JP suggests, but it
> should be noted that this does not limit the applicability based on
> the network size or the set of LSPs being reoptimized. Rather, it
> limits the applicability to how the reoptimization is being used and
> coordinated by a management plane.
>
> The difference between a global reoptimization and a bulk re-route
> are subtle. It may appear that for bulk re-route all existing
> services have failed and so the worst case is that connectivity is
> not restored, but in packet networks FRR may be in use, so bulk
> re-route failures are significant. The applicability in *that* case
> includes make-before-break to ensure no disruption to traffic.
>
> But it is also commonly accepted that restoration or re-route after
> failure has two problems. The first is system congestion which is
> at least as bad as global concurrent reoptimization because each
> LSP-to-be restored is the subject of a PCReq and a PCRep as well as
> signaling. The second is that the sequential nature of the path
> computations will almost inevitably lead to blocking.
>
> So, while I agree that the gco draft should have a very thorough
> applicability section that should highlight the potential problems,
> I don't think that there should be an assumption of non-applicability
> to specific networks or scenarios.

Well let's consider the example of a packet networks with 30,000 TE  
LSPs of which 15% are impact by a single
node failure (talking realistic number, as of today), considering  
that the 4,500 affected TE LSPs have say 50 different
head-ends. The question is now whether a centralized """""real- 
time""""" path computation system could reasonably
be used to handle such scenario as opposed to the well-known  
distributed path computation ? I do agree with you with
the blocking issue pointed out above (although there are techniques  
to reduce that blocking probability),
there are many other metrics to consider of course and I'm trying not  
to re-open the old debate here ;-)

But I think that it should be clearly spelled out somewhere that the  
algorithmic issue is not the only point of possible
contention.

>
>
>>>> Thus I'd suggest to add some applicability
>>>> section to this ID that would discuss the context in which such
>>>> solution would apply (e.g. network with thousands of packet LSPs
>>>> (hopefully not!), optical LSPs with a few hundreds of LSPs with  
>>>> multi-
>>>> constraints optimization problems where bandwidth fragmentation  
>>>> is a
>>>> real issue because of a limited number of discrete bandwidth  
>>>> values).
>>>>
>>> We can add applicability section to elaborate this request. We can
>>> indicate that this mechanism applies specifically to GMPLS  
>>> optical networks with a few hundreds of LSPs.
>
> I would be very concerned about that limitation.
> It is great to hear that you have specific intention to apply this  
> work
> to optical networks, but I do not see anything in the I-D or what  
> JP said
> that forces us to constrain the applicability in this way.
> By all means, cite optical networks with a limited number of nodes  
> as a
> good example of where you might use this technique, but otherwise, you
> should structure the applicability section with regard to the  
> potential
> problems, not the dataplane technology.
>
>
>>>> 2)
>>>>
>>>>     It is also envisioned that network operators might
>>>>     require a global concurrent path computation in the event of
>>>>     catastrophic network failures, where a set of TE LSPs need to
>>>>     be optimally rerouted in real-time.
>>>>
>>>> I do not think that such model could be used for "real-time"   
>>>> rerouting.
>>>>
>>>  I agree with you. We can remove this statement.
>
> Define "real-time".
>
> The applicability to the problem space is clear. A well-known set of
> LSP has been impacted by a network failure. Rather than compute new
> paths on demand from the head-end LSPs with the consequent resource-
> contention blocking problems, there may be considerable benefit in
> computing the paths of the LSPs as a set. (Of course, this assumes
> the availability of certain information, but an NMS might reasonably
> have access to this and make the bulk computation request.)
>
> Thus, if there is any modification to make, I suggest only deleting
> "in real-time".

I guess that we can agree on the fact that centralized system provide  
more qualitative output in term of path
quality but are typically fairly slow and not appropriate for "real  
time" processing. Now of course, we could argue
for ever on:
* More qualitative: by how much ?
* What do we mean by path quality or optimality ?
* What does "slow" mean ?
We could certainly find scenarios where the delta in term of  
optimality is fairly negligible and centralized systems
are extremely slow, and vice versa.
So my point was to not "promote" such system for "real-time" processing.

>
>>>> 3)
>>>>
>>>>     The main focus of this document is to highlight the PCC-PCE
>>>>     communication needs in support of a concurrent path  
>>>> computation application and to define protocol extensions to
>>>>     meet those needs.
>>>>
>>>> You may want to stress the fact that in your ID the PCC is an NMS
>>>> system and this is key. Indeed, one can define models where the  
>>>> PCCs are LSRs and the PCE is used to provide globally optimal
>>>> solutions ... Such models suffers from drastic scalability and
>>>> robustness issues.
>>>
>>> The PCE GCO is primarily an NMS based solution. In section 3.3
>>> (Application of PCE architecture) of the current draft clearly   
>>> spells out that GCO is NMS based solution.  With GCO, a PCC has
>>> to know all LSP requests, hence this cannot be a LSR.
>>
>> Well that could be done with PCC=LSR thanks to complex   
>> synchronization (which I'm NOT advocating of course)
>> hence my comment. Could you restate in the abstract/Introduction  
>> that in your proposal the PCC is indeed an NMS.
>
> Why would the procedures not be applicable to a head-end LSR
> requesting bulk reoptimization of the set of LSPs for which it acts
> as ingress? (I.e. a subset of all LSPs in the system.)
>
> We already accept that such an LSR should be allowed to issue
> individual LSP reoptimization requests. And we already accept that
> a PCReq may contain multiple computation requests that are 'linked'.
>
> So, if JP's request is that an LSR should not issue an optimization
> request for an LSP for which it is not the head-end, I can see the
> point. Although I might want to rephrase this because the important
> question is what use is made of the computation response - that is,
> if the PCC is unable to make use of the computed path, there is no
> value in performing the computation.
>
> Clearly, NMS is a primary application of this work, but it is not
> the only application. Another key use would be the VNT Manager
> component discussed in the multi-layer PCE drafts.

This is an important point, on which we may not 100% agree. If now  
one want to use this model
where each LSR is a PCC so as to globally optimize the path  
computation of a set of TE LSPs,
that clearly requires very significant synchronizations between the  
PCE and each of those PCCs
(which is not the base with synchronized path computation request  
such as diverse path computations
originated by a single LSR). In other words, consider the case where  
a PCC requires to resize one of
its TE LSPs and sends a request to the PCE, which in turn triggers  
the reroute of hundreds of TE LSPs
to satisfy that demand. See the number of synchronizations that this  
does require between the PCE and
all PCCs. And there are many other scenarios where such model could  
have limitations that the draft
should point out.

Are we agreeing ?

>
>>>> 4) Green field: not sure to buy this argument since as soon as
>>>> the TE LSPs are set up, the network is no longer in this green
>>>> field state
>>>>
>>>  OK.  The main use of GCO application is re-optimization of an   
>>> existing network.
>
> Well, I would be very worried if you deleted the green-field
> applicability. But I do agree that it should be put lower down the
> list (although I guess it comes first in the list because it comes
> first in time). And it should be rephrased, because it is not
> "reoptimization" since (as JP points out) you can't reoptimize LSPs
> that don't exist, and once the LSPs do exist it is not a green field.

So it is a green field for a very short period of time.

>
>
> But noting that the draft is titled "PCE Global Concurrent
> Optimization" not "PCE Global Concurrent Re-optimization" I have zero
> problem with the existence of this section, and I believe that
> network planners will want to make use of computation servers to plan
> the LSPs that they will provision in their network. This might arise
> either in the green field condition or when rolling out a new
> customer on top of an existing network.
>
>>>> 5)
>>>>
>>>>     Note that sequential re-
>>>>     optimization of such TE LSPs is unlikely to produce  
>>>> substantial improvements in overall network optimization
>>>>     except in very sparsely utilized networks.
>>>>
>>>> Well, that DEPENDS ! I could show you distributed algorithms where
>>>> sequential reoptimization allows for a significant improvements. I
>>>> would suggest to remove that statement.
>
> Actually, I think that the sequential algorithms that JP refers to
> are actually *global* reoptimization. That is, they sequence through
> the set of LSPs making optimization improvements. The fact that the
> algorithms are distributed is neither here nor there.

We keep facing that terminology issue with the word "distributed"  
where this could apply to the
algorithm itself or the fact that path computations may be performed  
by different engine (e.g. case
where each LSR is its own PCE). I was referring to the "unlikely to  
produce substantial ..." statement.
Techniques exist that produce good results with sequential re- 
optimization, thus my suggestion to
delete that statement, or please refine it.

>
>> Yes, it actually depends on the topology, the traffic matrix, the   
>> online algorithm used, etc. We will delete this statement.
>
> So rather than deleting the statement, I suggest qualifying it.
> Of course, the potential for network-wide gains from reoptimization
> of LSPs one-by-one is dependent on the network usage and size of the
> LSPs being reoptimized. But the key point remains: if you only
> compute the reoptimized path of one LSP at a time, and if you give
> no consideration to the other LSPs in the network when you do it,
> you run the risk of significant devaluation of the process.
>

See it is always difficult to avoid "significant", ... That really  
depends. For example, dynamic preemption
schemes based on LSP size can be designed to get close to the results  
given by a global
CSPF applied by placing TE LSPs in decreasing sizes, which itself can  
be fairly close to some centralized
algorithms.

> This may be far more visible in networks with a low ratio of potential
> LSPs per link (such as in an optical network), and far less visible in
> packet networks with micro-flow LSPs.
>

Yes unless you use dynamic preemption to avoid blocking issue. You  
could also use head-end
driven dynamic splitters to reduce that ratio.

> [SNIP]
>
>>>> 7) A word of cautious here
>>>>
>>>>           During a reoptimization it may be required to move a LSP
>>>>           several times so as to avoid traffic disruption.  The  
>>>> response message must allow indicating the path sequence
>>>>           for each request.
>>>
>>> We all know that in some cases, traffic disruption may be avoided
>>> thanks to a multi-step rerouting approach where some TE LSP may be
>>> rerouted N times. This is another example where such model may have
>>> significant impact on the network and even when traffic disruption
>>> can be avoided, there is still an impact in term of control plane,
>>> traffic shift (=> jitter) although this can be another constraint
>>> taken in to account when computing the various rerouting steps. For
>>> example, would you want to add a paragraph listing the drawbacks of
>>> such approach (e.g. trade-off between optimization gain and network
>>> impact, ....) ?
>>>
>>> We can add a paragraph to indicate the potential impact by this   
>>> feature.
>>> By the way the trade-off is not optimization vs. network impact. It
>>> is traffic disruption vs. network impact. If we want to avoid  
>>> traffic disruption, we need this multiple rerouting, which is the
>>> price to pay at the expense of network impact.
>>
>> OK let me restate my comment here: the point I was trying to make  
>> is  the following: even if the set of TE LSPs can be reoptimized  
>> with no
>> traffic loss for example, the need for multiple reroutes has a
>> cost in term of traffic impact (jitter, ...) + control plane  
>> stress.  It may be worth mentioning that aspect also, this is why  
>> I mentioned
>> a trade-off between optimization versus network impact. Indeed, if  
>> you can reoptimize the set of TE LSPs in order to reduce the max  
>> link  utilization by 5% but this requires to reroute two hundreds  
>> TE LSPs with on the average 4 reroutes per TE LSP, this may not be  
>> a good idea.
>
> Well, that would depend, wouldn't it? If the network is unable to  
> place
> any more LSPs, one might think that retrieving 5% was pretty cool :-)

Ah I was referring to a reoptimization case (not failure): " if you  
can reoptimize the set of
TE LSPs in order to reduce the max link  utilization by 5% ..."

>
> But I *do* think that a paragraph warning about the risks of re- 
> routing
> LSPs is valuable. It is often assumed that make-before-break is  
> hitless,
> and it is not.

That was my point indeed.

> As JP points out, even in packet networks where the re-
> route can occur between packets, there may be a momentary jitter  
> impact
> at the point of switch-over.

+  potential control plane stress !

> This applies to *all* reoptimization and
> re-route activities including FRR.
>
> So obviously there is a trade-off to be highlighted and put under
> policy control. Maybe only some LSPs are subject to re-routing -  
> others
> need to preserve their QoS.
>
> And clearly, multiple "shuffling" of LSPs to make space is going to
> increase the impact on the network. This means both that there should
> be cost-benefit analysis of the reoptimization, and that such
> reoptimization is unlikely to be a continuous process.
>
>>>> 8) Objective functions should be moved to PCEP,
>>
>> I typed too fast: I indeed meant to refer to the objective  
>> function draft, as agreed with Jerry since I was pushing myself  
>> for not adding
>> more to PCEP.
>
> [SNIP]
>
> JP, are you saying that all objective function definitions should go
> into the one objective function I-D?

Just the 6 ones defined in RFC4657, not all.

> Or should that I-D define the
> functions that we have in hand, create the code point registry, and
> leave the definition of new objective functions for future I-Ds?
>
> But still, the requirements for the objective functions need to stay
> in the gco draft. So it is just a question of where the objective
> functions are described in detail.

In sync,

Cheers.

JP.

>
> [SNIP]
>
> Thanks,
> Adrian
>