[PCN] On pcn and overloads (was: 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
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn