Re: [PCN] traffic matrix scenario

[Lars Eggert <[e-mail]>]

Hi,

On 2007-10-31, at 15:51, ext [e-mail] wrote:
> 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.

I think this (how "OK" flow termination is) is the root cause of our  
argument about PCN.

I see PCN as a "best-effort" sort of QoS. A PCN has a load range in  
which it operates well. You increase load by admitting flows, you get  
signals about the load from the markings, and then you react to it.  
If you over-admitted a bit, you stop admission until load abates. If  
you over-admitted a lot, you need to terminate flows to get the  
domain back into a stable state. Flow admission is how you ramp up  
the load, stopping admission is the "light" mechanism to reduce load  
over time, flow termination is the "heavy" mechanism to reduce load  
quickly. You can be optimistic about admitting flows, because you can  
always recover from wrong admission decisions.

If flow termination is to be avoided at all costs, the properties of  
the architecture fundamentally change. All of a sudden, you need to  
be a *lot* more careful about when and what you admit, because all  
you have left to react to overload is the "light" stop-admission  
mechanism. You must not over-admit, so other mechanisms are needed to  
make sure you don't over-admit, i.e., probing.

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

I believe that it will be very difficult to design a simple  
architecture that can handle such cases with just stop-admission as a  
permitted reaction mechanism.

How likely are these scenarios?

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

After reading through your scenario, I believe that PCN (as I  
understand it) is the wrong tool for the job. You really want firm  
guarantees that the domain can sustain a flow before admitting it,  
and you never want to terminate flows unless a catastrophic event  
occurs. In other words, you want path-signaled QoS reservations,  
maybe using RSVP or NSIS. We have protocols and an architecture for  
path-coupled QoS, and I see no need and no benefit in PCN attempting  
to solve the same problem in a different way.

(And if there is no other problem for PCN to solve, maybe we're done...)

Lars

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