Subject: [PCN] traffic matrix scenario

From: <[email-masked]>
Date: Tue, 30 Oct 2007 14:48:07 -0000

Hi

Ben & I have made some estimates, based on a future busy hour for a
national network with about 100 PCN-boundary-nodes. We assume that the
case of interest is where the traffic follows this normal pattern and
that the network is (becoming) pre-congested due to a massive surge of
traffic outside this traffic pattern. 

Our estimate is that 3/4 of ingress-egress-aggregates will have traffic
of less than 1.5 Erlang. The distribution is long-tailed, for example
there are several ingress-egress-aggregates with > 4000 Erlangs.

We have made some speculations about how this translates into traffic on
particular interfaces. The topology of the network has each
PCN-boundary-node attached to 2 different PCN-interior-nodes;
PCN-interior-nodes are more interconnected (> dual-homed). 

So for a particular PCN-boundary-node to PCN-interior-node interface, it
potentially has 50 ingress-egress-aggregates on it; we estimate that
actually 25 of these will not have a flow, 10 will have 1 and 15 will
have >1.

For a PCN-interior-node to PCN-interior-node interface, the topology
suggests potentially 300 ingress-egress-aggregates on it; the fractions
are the same as before, ie we estimate that actually 150 of these will
not have a flow, 60 will have 1 and 90 will have >1.

We re-iterate that these are very rough estimates. But they strongly
suggest that there are likely to be significant numbers of aggregates
with very few flows under nearly all circumstances.

Best wishes,

Phil & Ben

> -----Original Message-----

> From: Lars Eggert [mailto:[email-masked]]

> Sent: 25 October 2007 13:25

> To: Eardley,PL,Philip,CXR9 R

> Cc: [email-masked]; [email-masked]; [email-masked]

> Subject: Re: [PCN] Architecture draft - probing section & general
updates.

> On 2007-10-25, at 13:56, ext [email-masked] wrote:

> > Lars, I believe the guess is that there'll be many ingress-egress 

> > pairs with none or very few flows at a particular moment. Not a 

> > random distribution of calls onto all possible pairs. Basically 

> > there are many calls between London & Manchester and very few 

> > between truro and Shetland.

> I can agree with that. But note that that alone is not a problem yet.

> The problem occurs only when several of these "empty" ingress pairs 

> share a bottleneck *and* when single flows start simultaneously 

> sending across them at a combined rate that will push the bottleneck 

> directly into overload.

> I don't believe this can be very common. Wouldn't you provision your 

> network such that interior routers could handle at least one flow per 

> ingress/egress pair? In which case there is no issue unless there's a 

> failure. And why not let flow termination handle these rare cases?

> > I & Ben will try and extract some numbers from the [bt] predicted 

> > future traffic matrix.

> That'd be *very* useful! We're all guessing probabilities here, and 

> data would help.

> Lars

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Oct 2007 10:11:03 +0200

> with very few flows under nearly all circumstances.

But this only means that there is a *potential* for a problem.

Do you have an estimate on how likely it is that a sufficient number  
of new flows start transmitting over these empty aggregates at  
roughly the same time, such that they together can push the  
bottleneck straight into overload?

Lars

---

From: <[email-masked]>
Date: Wed, 31 Oct 2007 10:37:26 -0000

Lars, All 

> Do you have an estimate on how likely it is that a sufficient 
> number of new flows start transmitting over these empty 
> aggregates at roughly the same time, such that they together 
> can push the bottleneck straight into overload?

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.

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 31 Oct 2007 11:58:47 +0100

Ben,

thanks, your text nicely explains things.

On the dimension of the time lag, I'm not favouring to dimension the lag
for a situation where just admitting the new flow results in
pre-congestion marking. This will result in a rather long lag. I'd
rather like to make sure, that if there's congestion already and another
flow is admitted, then there should be no new admission. That would
assume that with the first packets of the admitted flow, pre congestion
marked packets are received.

It may be useful to have separate timers:
- absolutely no pre congestion indication on ingress or egress
  * the lag is rather short or zero
- pre-congestion indicated on the ingress or egress, but 
  not for the lately admitted flow
  * the lag is somewhat bigger
- pre-congestion indicated (no matter which amount) for the 
  lately admitted flow
  * no new admission prior to a full PCN pre congestion 
    feedback cycle on that flows ingress/egress relation.

Regards,

Rudiger

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Wednesday, October 31, 2007 11:37 AM
|To: [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] traffic matrix scenario
|
|
|Lars, All 
|
|> But this only means that there is a *potential* for a problem.
|> 
|> Do you have an estimate on how likely it is that a sufficient 
|> number of new flows start transmitting over these empty 
|> aggregates at roughly the same time, such that they together 
|> can push the bottleneck straight into overload?
|
|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.
|
|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
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 31 Oct 2007 12:12:58 +0100

Phil,

I'd like to return to my point, that probing is only required if there's
any pre-congestion in the network.

The question now is, what's the probability, that two end points try to
set up a first flow between them and none of both is aware of
pre-congestion, which is already on one of the links to be crossed by
that flow. The congestion isn't on the boundary to interior links (then
either ingress or egress node receive pre-congestion marked packets or
receive feedback on them). Hence you look for a pre-congested interior
link which isn't crossed by any flow to or from the boundary nodes
trying to set up a new flow. As this link is pre-congested, there's a
heavy demand between many other end points, but the link is not used by
a single flow of the end points trying to set up the new flow. That's
the situation when you may admit a flow on a link which is already in
pre congestion mode. 

As mentioned in my other mail, I don't think we should try to measure
whether a new flow would push an aggregate to pre-congestion mode. I
regard this case as standard operation, the decision should always be:
admit.

Regards,

Rudiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 30, 2007 3:48 PM
To: [email-masked]
Subject: [PCN] traffic matrix scenario

Hi

Best wishes,
Phil & Ben
updates.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Oct 2007 13:48:34 +0200

Hi,

> 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

---

From: <[email-masked]>
Date: Wed, 31 Oct 2007 13:51:42 -0000

Hi Lars

> 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.

Broadly speaking I think our objective is that flow termination should
only be necessary in the case of an unexpected decrease in core
capacity.  We generally do not expect an Admission Control system to
admit calls and then later terminate them in the absence of internal
network problems such as link failure.

My scenario mentioned the failure of an exchange really only as an
example of the sort of extreme scenarios we consider.  The real examples
I had in mind were simply flash crowds: widespread and unexpected
increases in call request rates with an unusual (e.g. regionally
focussed) traffic matrix.

The sort of scenario that might be particularly testing for this
particular probing issue, would be an initial anomalous traffic pattern
consisting of very heavy traffic on a few aggregates causing
pre-congestion on just a few links, followed by a subsequent widespread
increase in demand which also focuses on those links.  It is easy to
construct reasonable (though not necessarily probable) sequences of
external events that could cause this sort of traffic pattern: for
example, news reporting initially being local and progressing to
national coverage.

We would expect an Admission Control system to do a good job of
rejecting requests in this scenario.  Though this is not completely cut
and dried: it's possible a very small amount of flow termination might
be acceptable.
 
> If we aren't in agreement, then I wonder under what 
> circumstances you'd consider flow termination to be appropriate?

As I say, only really when there is a sudden and significant decrease in
core capacity.  Even then, we would normally expect to be provisioned to
deal with all but the most serious failures.

Ben Strulo

---

From: <[email-masked]>
Date: Wed, 31 Oct 2007 16:11:21 -0000

Lars
I agree flow termination may be ok if sudden, unanticipated overload.
But then it would be good if flows weren't admitted that would go over
the overloaded link(s) - even if new flow is on an
ingress-egress-aggregate that currently has no traffic (and therefore
can't tell that flow termination is happening).

Sorry, I've jumped beyond the scope of your comment...
Phil/ 

> Sent: 31 October 2007 11:49
> To: Strulo,B,Ben,CXR9 R
> Cc: [email-masked]
> Subject: Re: [PCN] traffic matrix scenario
> 
> Hi,
>