Re: [PCN] Concensus questions from Thursday's PCN meeting

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

Steven,

what Georgios is proposing is to optimise PCN so that it works 
properly if a catastrophic event coincides with a 
misconfigured router. 

If this is the main or even an important task of PCN, then I 
waste my time here.

The salary I obtain monthly depends on my companies backbone 
network providing good service to customers under regular 
operational conditions (which cover planned outages 
and expectable failures). The telephony or streaming services 
offered to our customers should experience a minimised network 
impact on the Quality of Experience perceived by the consumers 
under regular operational conditions. This includes the 
creation of a "Network Busy Indication", which however is a 
rare event. So my position on what PCN should be optimised 
for is to create this "network busy indication" for regular 
operational conditions, reliably and only if it is required. 
This should be done with the least possible complexity (like 
the least possible flow awareness, the least codepoint 
consumption, simple queuing/policing and measurement 
functions, utmost re-use of allready implemented features). 

To clarify what I mean by a rare event: a well engineered 
backbone creating a PCN network busy indication either during 
a main traffic hour or after a re-routing event. During ISDN 
times, engineering resulted in what Americans called 5ESS 
switches, aiming on a network busy indication probability of 
(100 - 99,999%, the 5 nines). We may see that a bit more 
relaxed for IP networks, but I don't think the customers 
of my company should experience the consequences of PCN 
behaviour more often than in (100 - 99,x)%.

I don't look at PCN as a replacement of network engineering, 
it is rather an add on to guarantee service quality of 
admitted users by stopping admission of new traffic once 
engineering reaches its limits. Under regular operational 
conditions.

If someone now answers to this mail: uhh, just that - easy!
Then lets move this easy thing to WGLC. Now. I can't see 
that.

If the PCN WG indeed has completely different aims, then 
I'm sorry for bothering you with my mails (but I wonder 
whether I'm the one having gotten things wrong).

By the way, I'm happy with the progress visible in the 
questions you / the WG has formulated. That looks like a 
constructive approach.

Regards,

Rudiger



| -----Original Message-----
| From: Steven Blake [mailto:[e-mail]] 
| Sent: Tuesday, March 18, 2008 3:19 PM
| To: Geib, Rüdiger
| Cc: [e-mail]
| Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
| 
| On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote:
| 
| > Hi Georgios,
| > 
| > in the situation you describe, packet losses occur. This 
| will result 
| > in bad press, as the customers using PCN based services 
| were promised 
| > another type of service.
| > 
| > In this situation it doesn't matter whether or not ECMP is deployed 
| > and it also doesn't matter whether termination is fair or not. The 
| > important event is: packet losses occur (in one of your examples 
| > several routers drop packets). The drops are the only 
| relevant issue.
| > Whether service resumes after 5 seconds due to extremly well 
| > engineered termination or after 10 seconds after a 
| sufficient number 
| > of customers hang up is not important.
| > I can't recall having read anytime in the news "Major 
| network outage - 
| > but termination was fair." I can only recall having seen the first 
| > part.
| > 
| > I'm sure you're happy in adapting your example, as you do all the 
| > time. I'm having work to do, but maybe someone else is 
| interested in 
| > continuing discusion. I think, I've made my point.
| 
| Ruediger,
| 
| If I follow this comment to its logical conclusion, then PCN 
| is superfluous in this network.  Is that what you are trying to say?
| 
| 
| Regards,
| 
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven Blake                <[e-mail]>
| Ericsson/Redback Networks               [phone]
| 
| 
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn