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

"Anna Charny (acharny)" <acharny@cisco.com> Thu, 20 March 2008 13:30 UTC

Return-Path: <pcn-bounces@ietf.org>
X-Original-To: ietfarch-pcn-archive@core3.amsl.com
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id AB2B128C31D; Thu, 20 Mar 2008 06:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.742
X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id EXTMU0Yw3K6f; Thu, 20 Mar 2008 06:30:13 -0700 (PDT)
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id C420C28C258; Thu, 20 Mar 2008 06:30:13 -0700 (PDT)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 23CA53A6A28 for <pcn@core3.amsl.com>; Thu, 20 Mar 2008 06:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3V81q0x7oSe3 for <pcn@core3.amsl.com>; Thu, 20 Mar 2008 06:30:03 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id B4D6E3A6892 for <pcn@ietf.org>; Thu, 20 Mar 2008 06:30:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,531,1199682000"; d="scan'208";a="2407836"
Received: from rtp-dkim-1.cisco.com ([]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2008 09:27:39 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com []) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2KDRdYr001526; Thu, 20 Mar 2008 09:27:39 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com []) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2KDRdaI001901; Thu, 20 Mar 2008 13:27:39 GMT
Received: from xmb-rtp-203.amer.cisco.com ([]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 09:27:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 20 Mar 2008 09:27:38 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B07061F5DF0@xmb-rtp-203.amer.cisco.com>
In-Reply-To: <1B6169C658325341A3B8066E23919E1CFC834B@S4DE8PSAANK.mitte.t-com.de>
Thread-Topic: On pcn and overloads (was: [PCN] Concensus questions from Thursday's PCN meeting)
Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQAAOsnCA=
From: "Anna Charny (acharny)" <acharny@cisco.com>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
X-OriginalArrivalTime: 20 Mar 2008 13:27:39.0545 (UTC) FILETIME=[2B3CC090:01C88A8E]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2421; t=1206019659; x=1206883659; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20<acharny@cisco.c om> |Subject:=20On=20pcn=20and=20overloads=20(was=3A=20[PCN]=20 Concensus=20questions=20from=20Thursday's=20PCN=20meeting) |Sender:=20 |To:=20=22Geib,=20Ruediger=22=20<Ruediger.Geib@t-systems.co m>; bh=eShZsV54jF9NBb9yuH2tLp8y78CbkFvFp0m6U7zJsVE=; b=LQZOxxt25LwVxNjQn12xn0CrRcHVZqnjuW2qh6mxUNAA3FhFq7QYkImdtR DgoFKcbJHHPEsavD4zj6t02CB/sCtOVbI5NgFKWUkAG8898T7TTgEmP3ikEI GsZj0bpQ18;
Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: pcn@ietf.org
Subject: [PCN] On pcn and overloads (was: Concensus questions from Thursday's PCN meeting)
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

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

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

PCN mailing list