Subject: Re: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt

From: Zhang Renhai <[email-masked]>
Date: Wed, 02 Nov 2005 11:29:19 +0800

Hi, Jean Louis

    Thanks your reply, see inline below.

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Zhang Renhai" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 31, 2005 6:27 PM
Subject: RE: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt

Hi Zhang,

Please see inline, 

> -----Message d'origine-----
> De : Zhang Renhai [mailto:[email-masked]] 
> Envoyé : lundi 29 août 2005 05:39
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]
> Objet : Re: [Pce] About the 
> presentationofdraft-zhang-pce-comm-app-model-01.txt
> 
> Hi, Jean Louis
> 
>  From what you said below, could I conclude that there is a 
> tradeoff on what we discussed:
> The two sides of the tradeoff are resource contentions and 
> receiving all requests for a PCE.
> And in my opinion, receiving and parsing packets consume much 
> less CPU capability than path computation which are becoming 
> more and more complex, So I think the path computation will 
> be the real bottleneck.To make maintaining of all requests 
> for a PCE easier, a priority for applying resources in the 
> request message may be enough.

I think that the number of requests to be handled by a PCE
is an important parameter when evaluating the scalability of a PCE architecture. 
What worries me in your proposal is that you distribute the computation load, which is a good point, but in return you introduce significant complexity on PCEs that will have to maintain a request table and exchange some significant amount of state (think about emergency conditions).
[ZRH]-->Perhaps there is a difference from my proposal here,  to clarify, in fact there is no exchange of state, the state is only maintained in each PCE based on the received requests. In my opinion, for a PCE, there should  not be  much consumption on the maintaining work, most of which will comprise                               receiving, recording of requests, changing state of during the servie.
.
Also think about the load you introduce on PCCs... 
[ZRH]-->only sending a request to multi PCEs

In some inter-area networks where ABRs are acting as PCEs you may several 10s of PCE in the backbone area, a PCC would have to send a request to all these PCEs for each TE-LSP to be computed...
[ZRH]-->Yes, so the proposal is not conformable for this environment, this is an application-oriented, not a protocol, so it can be decided if the methed can be employed for a specific environment.

I'm my view a better way to solve these race conditions could be to rely on a proxy PCE, that would actually receive requests from all PCCs, and would act as a path computation scheduler by appropriately sequencing requests and distributing requests to a set of PCEs. This would avoid sending requests to all PCEs, 
[ZRH]-->Another good idea, however, the same result occur on the proxy, that is to receive all the requests, why not the PCE have the same capability on receiving and handling the pachets, and I think it should.

and would avoid maintaining and synchronizing request tables between all PCEs.
[ZRH]-->but how to avoid the race conditions? done on the proxy? if so, it's fine.

> 
>  Another purpose of the proposal is to decrease the PCE 
> discovery's complexity. 
> Before a PCC decides to send a 
> request to a proper PCE, it must learn a lot of messages from 
> the different PCEs through PCE discovery protocol, analyse 
> all kinks of capabilities/policies contained in the messages, 
> do some maintaining work, these perhaps will make the PCC 
> fall into a painful situation which goes back on the 
> intention of PCE arch. 

The PCE discovery is done once, and not before each request. You are rithg detailed PCE discovery requires message exhange, but this is done once, and not per request. In your proposal a PCC has to send a message to all PCEs and maintain a transient state per message for each request,
[ZRH]-->To clarity, there is no maintaining work on the PCC, even there is no more work added to PCC in the proposal except the sending. I think the PCE should have a adequate  capability for these added maintaining work, shouldn't it?

 which is IMHO much more heavy than a capability discovery at PCC-PCE session setup. 
[ZRH]-->In fact, the PCC's work is lightened, before a request is sent from a PCC, the dicision which PCE to send is made roughly, the accurate dicision can be  done by any PCE. This will relax immense PCCs, even if the disvovery is done once on each PCC, but it will be maintained all the while, see your example  above, in a backbone area, a PCC perhaps must maintain volumes of capabilities messages for several 10s, even if it have very few request.

To relax the PCC's work, with this 
> proposal, just get the dicision of the exact PCE for a 
> request done in PCE.
> for the PCC, only generic capabilities of PCEs are learned, 

Yes, this is in sync with the PCE discovery  req ID, 
Note that we distinguish two types of information to be discovered: general information (location, scopes...) and detailed information (constraints, objective functions...). 
The PCE discovery protocol could be limited to general information. This would not require maintaining a lot of information (a set of bit flags per PCE). 
Detailed capabilities could be discovered thanks to the PCC-PCE communcation protocol, at PCC-PCE session setup.
This information is quite static, and discovery would be done once at session setup.
[ZRH]-->It's fine, a good solution. What about the detailed capabilities after a request is done? to maintain or to discard? I think it should be maintained,right?

> based on which PCCs will hopfully choose the right PCE, in 
> case of failure of the choice, PCE can get it done. 

Of course sending the request to all PCEs avoid detailed PCE discovery. but Frankly speaking IMHO this introduces much more complexity than it tries to reduce...
[ZRH]-->Indeed, there are some complexity, but also get rid of some complexity, I think it may be a tradeoff in some environments.

Think about the number of messages and transient states (one per message) a PCC would have to maintain, 
[ZRH]-->See my clarification above.

Best wishes,
Zhang

particularly under network failure condition, compared to a simple discovery as part of the PCC-PCE session setup...

Best Regards,

JL

> 
> Cheers,
> Zhang
> 
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN" 
> <[email-masked]>
> To: "Zhang Renhai" <[email-masked]>; <[email-masked]>
> Sent: Friday, August 26, 2005 5:16 PM
> Subject: RE: [Pce] About the 
> presentationofdraft-zhang-pce-comm-app-model-01.txt
> 
> 
> Hi Zhang
> 
> Sorry for replying so late...
> 
> Please see inline, 
> 
> > -----Message d'origine-----
> > De : Zhang Renhai [mailto:[email-masked]] 
> > Envoyé : lundi 8 août 2005 10:10
> > À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
> > Objet : Re: [Pce] About the 
> > presentationofdraft-zhang-pce-comm-app-model-01.txt
> > 
> > Hi, Jean Louis
> > 
> >   Nice to see your question again in mailing list. Please 
> see inline.
> > 
> > 
> > ----- Original Message -----
> > From: "LE ROUX Jean-Louis RD-CORE-LAN" 
> > <[email-masked]>
> > To: "Zhang Renhai" <[email-masked]>; <[email-masked]>
> > Sent: Friday, August 05, 2005 6:14 PM
> > Subject: RE: [Pce] About the presentation 
> > ofdraft-zhang-pce-comm-app-model-01.txt
> > 
> > 
> > Hi Zhang
> > 
> > Please see inline 
> > 
> > > -----Message d'origine-----
> > > De : [email-masked] 
> > > [mailto:[email-masked]] De la part de Zhang Renhai
> > > Envoyé : mercredi 3 août 2005 15:28
> > > À : [email-masked]
> > > Objet : [Pce] About the presentation 
> > > ofdraft-zhang-pce-comm-app-model-01.txt
> > > 
> > > Hi, all
> > >  
> > >  Sorry for not all clear about some questions asked to me at 
> > > the meeting.
> > > I really appreciate that someone can repeat the question and 
> > > we can discuss more here.
> > 
> > Sure, here it is:
> > 
> > JL->The problem you raise is valuable, race condition issues 
> > will increase in case of distributed-PCE computation with 
> > external PCEs, as the delay between path computation and path 
> > setup will increase. But I have some scalability concerns 
> > with your proposed solution: Basically one objective of PCE 
> > distribution would be to reduce the number of requests to be 
> > handled by PCEs, as this could be the bottleneck, and here 
> > actually your proposal requires sending requests to all PCEs. 
> > Hence all PCEs will support the whole PCCs' requests load.
> > 
> > ZRH---->Sending requests to all PCEs is a method to make it 
> > possible that each PCE can know the current resources 
> > application status, 
> 
> Yes I understand this point, but the issue is that the 
> request messages load is no longer distributed, a PCE will 
> reveive all requests, and IMHO this may significantly 
> diminish the benefits of PCE distribution.
> This may be OK in steady state but let's take an emergency 
> condition: For instance let's take a Link/node failure in the 
> core, which impacts a large number of TE-LSPs. Many PCCs are 
> going to simultaneously send a request to all PCEs. 
> This raises a scalability issue regarding the number of 
> messages to be handled by each PCE and also regarding the 
> size of the request table to be maintained on each PCE (# 
> failed LSPs).
> 
> 
> and accordingly
> > can sort order for the requests which may be computed in 
> > different PCEs, for example, req1 and req2 are send 
> > repectively to PCE1, PCE2, and req1 has
> > a lower priority than req2, but if PCE1 doesn't know that 
> > there is another req with a higher priority(req2 is sent to 
> > PCE2),  it may take the resource that req2
> > may also need and only suffice one request. 
> 
> Yes I clearly agree that your proposal would help solving the 
> race condition issue, but to my mind the complexity 
> introduced significantly  reduces the benefits of this aproach.
> 
> 
> Then when PCE2 is 
> > computing the path for req2 later, what about the result? 
> > teardown the first path computed 
> > for req1? or reply the failure of the computation for req2?
> > So if both the PCE1 and PCE2 know the all the current 
> > requests, based on some policies configured by operator, PCE1 
> > can delay the computation for req1,
> 
> > to get the computation orderly and make sure the resources 
> > distributed reasonably.
> > 
> > 
> > JL->IMHO this may significantly disminish the benefits of PCE 
> > distribution.
> > 
> > ZRH--->Each PCE knowing all the requests doesn't means to add 
> > the load of computation to each PCE, it's just give each PCE 
> > enough information to make the PCEs working cooperatively. 
> 
> The issue is that the bootleneck does not only rely on the 
> load of computation, but also, and above all, on the load of 
> messages to be handled and on the amount of information to be 
> maintained...
> 
> > See the example again, PCE1 knows there are being two 
> > requests but only computes req1, PCE2 knows there are being two but 
> > only computes req2.
> 
> Yes I clearly understand that, but it has at least to parse 
> req1 message and store related information. In some emergency 
> conditions this may lead to a large number of request to be 
> handled and a huge amount of information to be maintained...
> 
> Anyway the race condition problem you raised is highly 
> valuable, but IMHO we need more discussions on the way to 
> address it...
> 
> Thanks,
> 
> JL
> 
> > 
> > Thanks and Regards,
> > Zhang
> > 
> > 
> > 
> > JL->Anyway thanks for higlighting this problem, and for 
> > initiating discussion. 
> > 
> > Regards,
> > 
> > JL
> > 
> > 
> > > 
> > >  Actually, what I proposed surely is just applied to some 
> > > kind of circumstances. For example, if three PCEs are serving 
> > > all requests in a domain, and these PCEs are coupled closely, 
> > > for instance, they may be located in different box but in the 
> > > same tank or room, or located in different place remote to 
> > > each other and connected by a high speed line, so based on my 
> > > proposal, even only one request is sent to one of these PCE, 
> > > and the PCE can forward the request to other two PCEs quickly 
> > > to make the two PCEs maintain the request table,and this 
> > > delation of transmittion may be ignoed  by some tradeoff.
> > > The essential goal of the draft is just to use the table to 
> > > solve some known question.
> > >  I don't know how the communication for the detailed 
> > > discovery will be because the detailed capability is still 
> > > not specified now, how complicated a detailed capability 
> > > could be for a special request? Can a tradeoff be made 
> > > between below two choice for some special application:
> > >  
> > >   -saving the detailed discovery communication, 
> > > correspondingly sending 
> > >    the same request to all PCEs(or just one of these PCEs 
> > > like what I mentioned above)
> > >   -performing the detailed discovery communication for each PCC?
> > > 
> > >   Certainly,this proposal is not intent to became part of the 
> > > PCE communication protocol.
> > > 
> > >  Another concern of this draft is to make the requests 
> > > distributed to different PCE more *reasonable*, for example, 
> > > three PCEs in a domain, PCE1, PCE2, PCE3, and now PCE3 is 
> > > congested with too much requests or other reason, for the PCC 
> > > originating the request, which PCE else should it choose? 
> > > PCE1 or PCE2? what information should be used to help to 
> > > select again more reasonable? Based on the Global Computing 
> > > Table, the congesting PCE(PCE3) will know the number of 
> > > requests that other PCE is now dealing with, although PCE1 and
> > > PCE2 both are not congested now, based on the mentioned 
> > > information, PCE3 can select other PCE with least number of 
> > > requests and appropriate capability to make sure the PCC can 
> > > get the computation result asap, and I think the time from 
> > > sending request to receiving the computing result may be a 
> > > important consideration for some application.
> > > 
> > > Cheers,
> > > Zhang
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Pce mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pce
> > >
> >
>

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce