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

<toby.moncaster@bt.com> Thu, 20 March 2008 15:36 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 [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBCF28C20A; Thu, 20 Mar 2008 08:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.573
X-Spam-Level:
X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpcfqjYPF3DQ; Thu, 20 Mar 2008 08:36:34 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2445D28C6D4; Thu, 20 Mar 2008 08:36:19 -0700 (PDT)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A3228C55B for <pcn@core3.amsl.com>; Thu, 20 Mar 2008 08:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1151I48Uodu for <pcn@core3.amsl.com>; Thu, 20 Mar 2008 08:36:16 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 48E2D28C6C9 for <pcn@ietf.org>; Thu, 20 Mar 2008 08:36:10 -0700 (PDT)
Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 15:33:52 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 20 Mar 2008 15:33:53 -0000
Message-ID: <BAB4DC0CD5148948A86BD047A85CE2A705257078@E03MVZ4-UKDY.domain1.systemhost.net>
In-Reply-To: <BABC859E6D0B9A4D8448CC7F41CD2B07061F5E48@xmb-rtp-203.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: On pcn and overloads (was: Concensus questions fromThursday's PCN meeting)
Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQAAOsnCAAApwa4AAAcvqwAAKf8RA=
From: toby.moncaster@bt.com
To: acharny@cisco.com, Ruediger.Geib@t-systems.com
X-OriginalArrivalTime: 20 Mar 2008 15:33:52.0257 (UTC) FILETIME=[CCECE710:01C88A9F]
Cc: pcn@ietf.org
Subject: Re: [PCN] On pcn and overloads (was: Concensus questions fromThursday'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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

I get the impression that this is all just restating the ECMP problem that has been known and talked about for ages... It may highlight a particular case where the effects are especially bad but I don't see that it actually invalidates any of the PCN work. Nor do I see that it is an argument for or against any drop preference strategy (dropping marked, dropping unmarked or doing neither).

What it does highlight however is there is apparently still some uncertainty as to what is a realistic deployment scenario for PCN. This is obviously important and something that people need to make sure they agree on...

Toby

> -----Original Message-----
> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On 
> Behalf Of Anna Charny (acharny)
> Sent: 20 March 2008 14:22
> To: Geib, Ruediger
> Cc: pcn@ietf.org
> Subject: Re: [PCN] On pcn and overloads (was: Concensus 
> questions fromThursday's PCN meeting)
> 
> Hi Ruediger, 
> 
> > -----Original Message-----
> > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
> > Sent: Thursday, March 20, 2008 10:12 AM
> > To: Anna Charny (acharny)
> > Cc: pcn@ietf.org
> > Subject: RE: On pcn and overloads (was: [PCN] Concensus 
> > questions from Thursday's PCN meeting)
> > 
> > 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 must confess do not understand what is new in the ECMP issue either.
> 
> The point of my previous message however, was different and 
> unrelated to ECMP.  If indeed there are networks that can 
> only support 10% of some links for real-time traffic - 
> without any overload on SRLG failure - then it means that 
> if/when that becomes unacceptably low, you have two choices:
> 
> 1) do NOT fully provision against SRLG failure.  E.g. allow, 
> saw 50% of your link in question to carry real-time traffic. 
> Then if and when a failure occurs, your real time traffic 
> with overload the link potentially much higher than 5-10%. In 
> that case, pcn termination may be useful.
> 
> 2) Or, you can just upgrade your links so you can carry more 
> real time traffic on it AND have 100% bandwidth guarantee on 
> failures.  That may be expensive - and if it is, than pcn 
> termination might be a reasonable approach, and it might need 
> to deal with higher than 5-10% overloads.
> 
> That is all I tried to say.  Have a good vacation.
> Anna 
> 
> > I drop out for vacation now, will be back on 31st.
> > 
> > Regards,
> > 
> > Rudiger
> > 
> > | -----Original Message-----
> > | From: Anna Charny (acharny) [mailto:acharny@cisco.com]
> > | Sent: Thursday, March 20, 2008 2:28 PM
> > | To: Geib, Rüdiger
> > | Cc: pcn@ietf.org
> > | 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
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
> 
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn