RE: [PCN] traffic matrix scenario

["Geib, Ruediger" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
|Sent: Thursday, November 01, 2007 1:25 PM
|To: [e-mail]
|Cc: [e-mail]
|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:[e-mail]] 
|> Sent: 01 November 2007 11:15
|> To: Strulo,B,Ben,CXR9 R
|> Cc: [e-mail]
|> Subject: Re: [PCN] traffic matrix scenario
|> 
|> 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
|


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