Subject: Re: [PCN] traffic matrix scenario

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Nov 2007 13:14:31 +0200

Hi,

On 2007-10-31, at 15:51, ext [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Thu, 1 Nov 2007 12:25:07 -0000

Hi,

Interestingly, I mostly agree with you.

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.

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?

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.

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.

Ben

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: 01 November 2007 11:15
> To: Strulo,B,Ben,CXR9 R
> Cc: [email-masked]
> Subject: Re: [PCN] traffic matrix scenario
> 
> Hi,
> 
> 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 
> 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.
> 
> > examples I had in mind were simply flash crowds: widespread and 
> > unexpected increases in call request rates with an unusual (e.g. 
> > regionally
> > pattern consisting of very heavy traffic on a few 
> aggregates causing 
> > 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.
> 
> architecture that can handle such cases with just 
> stop-admission as a permitted reaction mechanism.
> 
> > 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.
> 
> 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.
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Nov 2007 14:48:43 +0200

> and I suspect that PCN will have a great deal of difficulty in working

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

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

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

> work as well as possible in as many scenarios as possible.

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

Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 1 Nov 2007 16:19:31 +0100

Ben,

I appreciate your work on scenarios and safety margins for PCN 
solutions working without probing. I further share your views 
on ECMP. 

Lars, having some text in a document describing different 
scenarios where probing isn't required, where probing could 
make sense and when reservations are useful could make 
sense. I assume, investigations like those of Ben are 
sufficient, i.e it is not expected that the standards must 
define quantified operational and planning conditions under 
which probing free PCN works? If we want to keep the WGs 
Milestone schedule, a qualitative scenario description as 
part of standards should do.

Regards,

Rudiger

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Thursday, November 01, 2007 1:25 PM
|To: [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] traffic matrix scenario
|
|
|Hi,
|
|Interestingly, I mostly agree with you.
|
|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.
|
|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?
|
|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.
|
|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.
|
|Ben
|
|
|> -----Original Message-----
|> From: Lars Eggert [mailto:[email-masked]] 
|> Sent: 01 November 2007 11:15
|> To: Strulo,B,Ben,CXR9 R
|> Cc: [email-masked]
|> Subject: Re: [PCN] traffic matrix scenario
|> 
|> Hi,
|> 
|> On 2007-10-31, at 15:51, ext [email-masked] 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
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|