Re: [PCN] traffic matrix scenario

On 2007-11-1, at 14:25, ext ben.strulo@bt.com wrote:
> I am not particularly convinced that probing is a good route to go  
> down,
> and I suspect that PCN will have a great deal of difficulty in working
> well with ECMP.

I'm happy to hear I'm not alone on this :-)

> On the other hand I think that there can be reasonable scenarios where
> PCN can be engineered to make flow termination (caused by
> over-admission) extremely unlikely without completely changing the
> architecture.  I have in mind scenarios where the safety margin is
> large, and the admission process is carefully managed (and aggregation
> levels are large).  The question that most interests me then is how  
> well
> does PCN perform?  How large does the safety margin need to be?  How
> tightly capped does admission control need to be?

These are exactly the right questions to ask. When we chartered PCN,  
the intuition was that flow admission and termination combined with a  
sufficient degree of over-provisioning and the right marking behavior  
result in a simple and useful system that would establish a degree of  
QoS.

The question is now how exactly we need to define the parameters to  
derive such a system for a given network scenario.

> I do not have complete answers, but the work we have done so far leads
> me to believe that there are credible scenarios in which (some version
> of) PCN is an appropriate and reasonably efficient solution.

I'm happy to hear folks are working on this - I believe that  
understanding which scenarios are appropriate for solving with PCN  
techniques (vs. other techniques such as path-coupled reservations)  
is important.

> My chief concern then is to ensure that the PCN WG chooses options  
> that
> work as well as possible in as many scenarios as possible.

If you add "while remaining architecturally simple and robust", I  
completely agree.

Lars

Re: [PCN] traffic matrix scenario

Attachment: smime.p7s