Re: [PCN] traffic matrix scenario

[Lars Eggert <[e-mail]>]

Hi,

On 2007-10-31, at 12:37, ext [e-mail] wrote:
> We cannot really give any measure of likelihood.  In this deployment
> scenario, at least, we design our network so PCN almost never rejects
> calls unless the traffic matrix is highly anomalous.  Such  
> anomalies are
> inherently unpredictable.  For example, a scenario we sometimes  
> consider
> is an event which simultaneously destroys an exchange building and
> causes a surge of traffic to and from the affected exchange region
> consisting of emergency traffic mixed with concerned relatives calling
> up to see what has happened.  We cannot tell you how likely this
> scenario is.  But it is essential to us that PCN operates correctly in
> this scenario, regardless of the scenario's precise likelihood.

my definition of "operates correctly" includes the possibility of  
flow termination. I see flow termination as the appropriate measure  
if the domain gets into a state of sudden, unanticipated overload.

I'd like to check if we are in agreement on this, because it is  
important for understanding the rest of your email (which for this  
reason I won't comment on yet).

If we aren't in agreement, then I wonder under what circumstances  
you'd consider flow termination to be appropriate?

Lars

> So, what do we need to do to ensure that PCN does operate correctly in
> the presence of extreme anomalous events?
> We have a few parameters to play with.  One is the margin between
> pre-congestion and actual congestion.  Another is provided by a cap on
> the rate of admitting new flows.
>
> What the statistics we gave before imply is that this rate must be  
> quite
> tightly capped, at least in the case of ingress-egress aggregates with
> no flows, because the size of the pulse of flows we admit before we  
> get
> good feedback could be being multiplied across many other  
> ingresses, and
> together this chunk of admissions must be reliably limited to below  
> our
> safety margin.  If the rate of admission is being capped on a per
> ingress basis, then the multiplication factor cannot reliably be  
> assumed
> to be much smaller than the total number of ingresses, 100 in our  
> case.
> If the rate of admission is being capped on a per aggregate basis then
> our traffic matrix information suggests that we could have a situation
> where many aggregates (a few thousand) are all ramping up into the  
> same
> bottleneck.  So the multiplication factor needs to be of that order.
>
> We can do the sums: given the safety margin, the time lag before
> feedback becomes reliable, and the multiplication factor we can  
> directly
> compute the maximum rate of admission per ingress and per aggregate.
> Alternatively, given a desirable minimum size for this maximum rate of
> admission we can compute the needed safety margin.
>
> What should we take to be the time lag before the feedback becomes
> reliable?  One component is the amount of time between admission  
> control
> decision and data actually reaching the ingress.  Can we assume  
> this to
> be reliably bounded?  The other components are then propagation and
> queueing delay, alongside the time needed for the bottleneck queues to
> grow and the congestion estimates to grow.  Do we have good estimates
> for these times?
>
> Ben Strulo

_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn