Re: [PCN] On pcn and overloads (was: Concensus questions from Thursday's PCN meeting)

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

Hi Anna,

5-10% overload doesn't look as a catastrophy scenario to me. A 10% 
overload following the loss of an SRLG and then meeting ECMP 
routing will be evenly distributed on the multiple paths. How much 
head ache does this cause, if there the congestion one single link 
is no more than 5% (keeping in mind, that the traffic of origins 
not impacted by the SRLG loss soon decays)? I still have a hard 
time to understand what's 'new' on the problem that's claimed 
to be caused by ECMP.

I drop out for vacation now, will be back on 31st.

Regards,

Rudiger

| -----Original Message-----
| From: Anna Charny (acharny) [mailto:[e-mail]] 
| Sent: Thursday, March 20, 2008 2:28 PM
| To: Geib, Rüdiger
| Cc: [e-mail]
| Subject: On pcn and overloads (was: [PCN] Concensus questions 
| from Thursday's PCN meeting)
| 
| Hi Ruediger,
| > 
| > Anna: yes, "5% congestion" is a reasonable assumption for a link 
| > congested under regular network conditions for engineered carrier 
| > backbones (i.e.
| > including single outages).
| > 
| > Regards,
| > 
| > Rudiger
| > 
| 
| You know, I keep wondering about this statement that you 
| cannot really have larger overloads.  We did, a few years 
| ago, a study of bandwidth requirements for MPLS FRR on a 
| relatively large set of actual networks of some of our 
| reputable customers with their expected traffic matrices, as 
| provided by them.  We looked specifically at bandwidth 
| requirements for real-time traffic only - so we assumed that 
| we actually just need to protect traffic that is using 
| priority queue.  We found that if you just wanted to protect 
| against individual link failures, then capacity requirements 
| were quite reasonable.  These capacity requirements were also 
| not too bad if we wanted to protect against individual node 
| failures. However, as soon as it came to SRLGs,  the 
| bandwidth requirements necessary to ensure that on any 
| individual SRLG failure real time traffic did not overload 
| any link, we discovered that in a surprisingly large number 
| of (real) networks (of reputable providers) we looked at, the 
| requirement to fully protect real-time traffic against a 
| single SRLG failure could not take more than ~10% of the link 
| bandwidth on some links before failure. And that does seem 
| too low for many networks.
| 
| Which seems to argue that unless  10% is an acceptable limit 
| for real-time traffic, then in the rare cases on SRLG 
| failures one *could* expect a fair amount of overload even 
| for real-time traffic. And in those cases pcn (and 
| specifically its termination function) could serve as a means 
| to allow graceful flow termination in such cases - as an 
| alternative to build up capacity to deal with rare events.  
| 
| Indeed, to make it useful, this termination should work at a 
| timescale that is smaller than the time when all users on 
| that link hang up. Which is why it seemed that a fast - even 
| if not quite accurate or fair - termination process might be 
| preferable to a slow but more accurate one.
| 
| So it does appear that there could be useful applications of 
| pcn termination that would have to deal with more than 5% 
| overload of real-time traffic. That is not to say that this 
| is necessarily the case for your network :-).
| 
| Anna 
| 
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn