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

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Tue, 18 March 2008 10:37 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 03BDB28C2C1; Tue, 18 Mar 2008 03:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.693
X-Spam-Level:
X-Spam-Status: No, score=-100.693 tagged_above=-999 required=5 tests=[AWL=-0.256, 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 7SJnxppWA5Vj; Tue, 18 Mar 2008 03:37:02 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F86B28C475; Tue, 18 Mar 2008 03:37:02 -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 2248828C475 for <pcn@core3.amsl.com>; Tue, 18 Mar 2008 03:37:02 -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 1ffRIeIQkmn1 for <pcn@core3.amsl.com>; Tue, 18 Mar 2008 03:36:59 -0700 (PDT)
Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id CF02E28C2C1 for <pcn@ietf.org>; Tue, 18 Mar 2008 03:36:58 -0700 (PDT)
Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 18 Mar 2008 11:34:40 +0100
Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 11:34:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 18 Mar 2008 11:36:02 +0100
Message-Id: <1B6169C658325341A3B8066E23919E1CF647C5@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <000701c888e1$37a68c20$810c5982@dynamic.ewi.utwente.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting
Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnAAHn88IAAGS18AAADxzSA=
References: <BABC859E6D0B9A4D8448CC7F41CD2B0706181835@xmb-rtp-203.amer.cisco.com> <RrmbUrJK.1205679770.1867150.karagian@ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> <000701c888e1$37a68c20$810c5982@dynamic.ew i.utwent e.nl>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
X-OriginalArrivalTime: 18 Mar 2008 10:34:40.0458 (UTC) FILETIME=[ABFE42A0:01C888E3]
Cc: pcn@ietf.org
Subject: Re: [PCN] 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

Hi Georgios 

see in line.

Regards, Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] 
| Sent: Tuesday, March 18, 2008 11:17 AM
| To: Geib, Rüdiger
| Cc: pcn@ietf.org
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| Hi Ruediger
| 
| The problem that I have explained it does not have to do with 
| slow reaction time but it has to do with complete collapse of 
| the PCN domain operation. 
| This occurs when the admission control/flow termination 
| triggers at the egress are not activated when they should be 
| activated.
| 
| 
| Here is a more concrete example:
| 
| When ECMP routing is used, it means that flows that are 
| associated with the same ingress-egress-aggregate can follow 
| different paths. 
| Assume that there are 5 such paths that are carrying flows 
| associated with the same ingress-egress-aggregate.
| 
| Consider now that one of the 5 paths fails and it is rerouted 
| to one of the other paths.
| Assume that path1 is becoming congested and the other 3 
| remaining paths are not congested.
| I am also assuming in this case that the thresholds are well 
| configured.

This is not realistic.


| The egress will calculate CLE in the following way:
| CLE = marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarked_4 +
| marked_1)
| 
| I think that typcially the above calculated CLE will not 
| reach 1% when marked packets are preferentially dropped.
| This problem is due to the fact that ECMP routing is used and 
| flows that are not participating at the congestion are 
| contributing to the calculation of the CLE. The flows that 
| are not passing through congested nodes will actually forward 
| unmarked packets to the egress node.
| 
| When marked packets are preferentially dropped than marked_1 
| can easily be smaller than 1% * (unmarked_1 + unmarked_2 + 
| unmarked_3 + unmarled_4 + marked_1). 
| In this case the admission control situation is not triggered 
| and a complete collapse of the PCN domain operation can occur!
| 
| Thus:
| If no ECMP routing would have been used than for the same 
| situation CLE = marked_1/unmarked_1 + marked_1), which can go 
| easily to 1%, if the C-A-R is well configured.
| 
| But when ECMP routing is used and the above scenario is 
| applied then CLE = marked_1 /(unmarked_1 + unmarked_2 + 
| unmarked_3 + unmarled_4 + marked_1), which probaly will not 
| reach 1% when marked packets are preferentially dropped, 
| since marked_1 can be smaller than 1% * (unmarked_1 + 
| unmarked_2 + unmarked_3 + unmarled_4 +
| marked_1)
| 
| I hope that you now understand the problem!
| 
| Best regards,
| Georgios 
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
| > Sent: dinsdag 18 maart 2008 8:30
| > To: karagian@cs.utwente.nl
| > Cc: pcn@ietf.org
| > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > 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.
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > | -----Original Message-----
| > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
| > | Sent: Monday, March 17, 2008 5:36 PM
| > | To: Geib, Rüdiger
| > | Cc: pcn@ietf.org
| > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > | 
| > | Hi Ruediger
| > | 
| > | Please note that what I have described holds also for the 
| situation 
| > | that the routers are well configured, but a catastrophic
| > event occur
| > | and at the same time ECMP routing is used.
| > | 
| > | Best regards,
| > | Georgios
| > | 
| > | 
| > | > -----Original Message-----
| > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
| > | > Sent: maandag 17 maart 2008 17:10
| > | > To: karagian@cs.utwente.nl
| > | > Cc: pcn@ietf.org
| > | > Subject: RE: [PCN] Concensus questions from Thursday's 
| PCN meeting
| > | > 
| > | > Hi Georgios,
| > | > 
| > | > what I say is if PCN decides to deal with catastrophic 
| events in 
| > | > combination with misconfigured routers, then it will end up 
| > | > standardising solutions for academic problems.
| > | > 
| > | > Regards,
| > | > 
| > | > Rudiger
| > | > 
| > | > 
| > | > | -----Original Message-----
| > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
| > | > | Sent: Monday, March 17, 2008 4:38 PM
| > | > | To: Geib, Rüdiger
| > | > | Cc: pcn@ietf.org
| > | > | Subject: RE: [PCN] Concensus questions from Thursday's
| > PCN meeting
| > | > | 
| > | > | Hi Ruediger
| > | > | 
| > | > | I do not understand what you try to say. Please note 
| that flow 
| > | > | termination is used for the below explained reason, see
| > | below text
| > | > | taken from the PCN architecture draft:
| > | > | 
| > | > | o  The termination mechanism complements admission 
| control.  It
| > | > |       allows the network to recover from sudden
| > | unexpected surges of
| > | > |       PCN-traffic on some links, thus restoring QoS to
| > | the remaining
| > | > |       flows.  Such scenarios are expected to be rare but not 
| > | > | impossible.
| > | > |       They can be caused by large network failures that
| > | > redirect lots
| > | > | of
| > | > |       admitted PCN-traffic to other links, or by
| > | malfunction of the
| > | > |       measurement-based admission control in the presence
| > | > of admitted
| > | > |       flows that send for a while with an atypically low
| > | > rate and then
| > | > |       increase their rates in a correlated way.
| > | > | 
| > | > | Best regards,
| > | > | Georgios
| > | > | 
| > | > |  
| > | > | 
| > | > | > -----Original Message-----
| > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
| > | > | > Sent: maandag 17 maart 2008 16:32
| > | > | > To: karagian@cs.utwente.nl
| > | > | > Cc: pcn@ietf.org
| > | > | > Subject: RE: [PCN] Concensus questions from Thursday's
| > | PCN meeting
| > | > | > 
| > | > | > Hi Georgios,
| > | > | > 
| > | > | > QoS on redundant links means, that one link is able to
| > | > | carry the QoS
| > | > | > traffic of the other. This may not hold for non QoS
| > | > | traffic. This is,
| > | > | > what typical carrier backbones providing QoS are
| > engineered for
| > | > | > (commonly known as traffic engineering).
| > | > | > 
| > | > | > Should a misconfiguration occur, things may go wrong. 
| > | > | > Operational staff corrects this a soon as the
| > | misconfiguration is
| > | > | > identified.
| > | > | > 
| > | > | > The engineering of carrier backbones is often done with
| > | automated
| > | > | > tools, leaving little room for human errors.
| > | > | > However maintenance work may result in humanne system
| > | > | interference. I
| > | > | > doubt that Telekom's engineering department is willing to
| > | > | accept extra
| > | > | > protocol and router complexitiy to deal with operator
| > | > configuration
| > | > | > errors. While I time and again hear of the worst
| > | > | misconfigs, I can't
| > | > | > recall that my colleagues try to adapt standardisation
| > | afterwards.
| > | > | > 
| > | > | > Regards,
| > | > | > 
| > | > | > Rudiger
| > | > | > 
| > | > | > | -----Original Message-----
| > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
| > | > | > | Sent: Monday, March 17, 2008 3:34 PM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: pcn@ietf.org
| > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's
| > | > PCN meeting
| > | > | > | 
| > | > | > | Hi Ruediger
| > | > | > | 
| > | > | > | Please note that typical IP networks (thus not
| > | MPLS/GMPLS based
| > | > | > | domains) can recover from failures by using rerouting.
| > | > | > | Or do you know another standardized mechanism in 
| typical IP
| > | > | > networks
| > | > | > | (thus not MPLS/GMPLS based) that can provide another kind
| > | > | > of recovery
| > | > | > | from failures.
| > | > | > | 
| > | > | > | Furthermore, I will just explain the example again
| > | with maximum
| > | > | > | capacity of
| > | > | > | pathh2 being equal
| > | > | > | to maximum capacity of path1 = C.
| > | > | > | Please explain what you do not understand in this example!
| > | > | > | 
| > | > | > | Here are the assumptions:
| > | > | > | * In the PCN domain we assume that ECMP routing 
| is possible!
| > | > | > | * ingress-eggress-aggregate can contain flows that are
| > | > | > passing through
| > | > | > | one path or more paths (when ECMP routing is used).
| > | > | > | 
| > | > | > | * routers are currently dropping packets randomly. Thus
| > | > | marked and
| > | > | > | unmarked packets will be
| > | > | > |   dropped randomly
| > | > | > | 
| > | > | > | * When excess rate measurements are used, the 
| triggering of
| > | > | > admission
| > | > | > | control and flow
| > | > | > |   termination are done at the egress by using the CLE. One
| > | > | > example of
| > | > | > | this trigger is:
| > | > | > |   CLE > 1%. Note that CLE = marked/(unmarked + marked). 
| > | > | This means
| > | > | > | that if this trigger is not activated while a severe
| > | > | > |   congestion occurs in the PCN domain, then the operation
| > | > | > of the PCN
| > | > | > | domain will completely collapse.
| > | > | > | 
| > | > | > | 
| > | > | > | My statement is:
| > | > | > | If the routers do not preferentially drop marked packets
| > | > | > then the PCN
| > | > | > | domain operation, even in corner case and misconfiguration
| > | > | > situations,
| > | > | > | is more robust and more stable than in the situation that
| > | > | > the router
| > | > | > | is preferentially dropping marked packets.
| > | > | > | 
| > | > | > | The below example show such a corner case!
| > | > | > | 
| > | > | > | 
| > | > | > | I will describe two situations:
| > | > | > | 
| > | > | > | Situation 1:
| > | > | > | Consider that an ingress-egress-aggregate due to ECMP
| > | > routing it
| > | > | > | includes flows that are passing from at least two paths.
| > | > | > | Assume that path1 supports a maximum bandwidth
| > capacity of C. 
| > | > | > | Now consider that the maximum bandwdith capacity of
| > | path2 is C.
| > | > | > | Consider also that both paths are fully utilized.
| > | > | > | 
| > | > | > | Consider that preferentially marked packets are 
| dropped and
| > | > | > that path2
| > | > | > | fails.
| > | > | > | Now assume that all (maximum) traffic passing through
| > | > | path2 will be
| > | > | > | rerouted through path1.
| > | > | > | If a bottleneck router located in path1, say Rbott, is
| > | > | > misconfigured
| > | > | > | (i.e., from the point of view of having wrongly too high 
| > | > | > | configured-admissible-rate value), or even if it is well
| > | > | > configured,
| > | > | > | then it can be possible that CLE measured at the egress
| > | > | > cannot reach
| > | > | > | 1%.
| > | > | > | Note that
| > | > | > | CLE = marked packets/ (marked packets + unmarked packets).
| > | > | > | This is because Rbott will just allow an excess rate to
| > | > | > pass through
| > | > | > | that is
| > | > | > | 
| > | > | > | equal to: C - configured-admissible-rate. The rest of
| > | > the marked
| > | > | > | packets, so the rest of the excess rate, will be dropped
| > | > | by Rbott,
| > | > | > | since this router is preferentially dropping 
| marked packets.
| > | > | > | Furthermore, note that due to the ECMP routing
| > flows that are
| > | > | > | belonging to the same ingress-egress-aggregate and that
| > | > | are passing
| > | > | > | through another path,
| > | > | > | 
| > | > | > | than path1, which is not congested, will forward traffic
| > | > | > towards the
| > | > | > | egress node that will be unmarked.
| > | > | > | This will mean that the CLE > 1% will not be triggered,
| > | > | > this will mean
| > | > | > | that the flow termination will not be triggered and that
| > | > | > the operation
| > | > | > | of the PCN domain will collapse completely.
| > | > | > | 
| > | > | > | 
| > | > | > | Situation 2:
| > | > | > | Now consider that the router just operates as
| > | > currently, i.e., no
| > | > | > | preferential drop, randomly dropping marked and
| > | > unmarked packets.
| > | > | > | Consider also that the two paths described in Situation 1
| > | > | above are
| > | > | > | used, ECMP routing is used, and that they are fully
| > utilized.
| > | > | > | Assume also that path2 fails and that the path2 traffic is
| > | > | > rerouted on
| > | > | > | path1.
| > | > | > | Now the CLE value will have a higher probability of
| > | > reaching the
| > | > | > | triggering value of 1%.
| > | > | > | 
| > | > | > | This is because the routers in path1 will drop randomly
| > | > | marked and
| > | > | > | unmarked packets.
| > | > | > | It is more certain that in this case the CLE will reach 1%
| > | > | > due to the
| > | > | > | following reason.
| > | > | > | In this example it is assumed that the maximum
| > | > bandwidth capacity
| > | > | > | supported by path2 is C.
| > | > | > | This means that after rerouting the traffic from 
| path2 into
| > | > | > path1, the
| > | > | > | ratio between marked packets and unmarked packets that
| > | > | are passing
| > | > | > | thorugh path1 can be equal or higher than 100%.
| > | > | > | Note that the routers in path1 will mark the excess rate
| > | > | > above C, thus
| > | > | > | 1*C (i.e., the rerouted traffic from path2) as marked.
| > | > | > | The above observation holds also for the situation that
| > | > | the routers
| > | > | > | are preferentially dropping unmarked packets.
| > | > | > | 
| > | > | > | Thus when routers are preferentially dropping marked
| > | > packets the
| > | > | > | robustness of the PCN domain operation is 
| decreasing and in
| > | > | > some cases
| > | > | > | it severely decreases, which could cause the complete
| > | > | > collapse of the
| > | > | > | PCN domain operation.
| > | > | > | 
| > | > | > | Best regards,
| > | > | > | Georgios
| > | > | > | 
| > | > | > | 
| > | > | > |  
| > | > | > | 
| > | > | > | > -----Original Message-----
| > | > | > | > From: Geib, Ruediger 
| [mailto:Ruediger.Geib@t-systems.com]
| > | > | > | > Sent: maandag 17 maart 2008 15:26
| > | > | > | > To: karagian@cs.utwente.nl
| > | > | > | > Cc: pcn@ietf.org
| > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's
| > | > | PCN meeting
| > | > | > | > 
| > | > | > | > Hi Georgios,
| > | > | > | > 
| > | > | > | > Unfortunately you missed my point.
| > | > | > | > 
| > | > | > | > No such thing as you describe has been, is or 
| will for the
| > | > | > | foreseeable
| > | > | > | > future be engineered in the IP backbone of the company
| > | > | > I'm working
| > | > | > | > for.
| > | > | > | > 
| > | > | > | > My expectation on the backbone of any carrier offering
| > | > | > | transport QoS
| > | > | > | > is, that it is engineered to survive probable failures
| > | > | > (like single
| > | > | > | > link losses) without impact on the performance of QoS
| > | > | > | traffic. This is
| > | > | > | > where we should start from, if we discuss PCN. 
| From there
| > | > | > | on, PCN is
| > | > | > | > able to add value.
| > | > | > | > 
| > | > | > | > Links without traffic engineering followed by
| > | > | > misconfigured routers
| > | > | > | > aren't the arguments which will convince either product
| > | > | > | management or
| > | > | > | > backbone engineering of the company I work for to
| > | deploy PCN.
| > | > | > | > 
| > | > | > | > As a general comment: I don't regard PCN as a plug and
| > | > | > play toy for
| > | > | > | > the operational equivalent of a 'script 
| kiddie'. If others
| > | > | > | share that
| > | > | > | > view and our documents don't state that, we
| > should add text.
| > | > | > | > 
| > | > | > | > Regards,
| > | > | > | > 
| > | > | > | > Rudiger
| > | > | > | > 
| > | > | > | > | -----Original Message-----
| > | > | > | > | From: Georgios Karagiannis
| > [mailto:karagian@cs.utwente.nl]
| > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM
| > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | Cc: pcn@ietf.org
| > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's
| > | > | > PCN meeting
| > | > | > | > | 
| > | > | > | > | Hi Ruediger
| > | > | > | > | 
| > | > | > | > | You missed my point!
| > | > | > | > | The explanation applies to all types of IP networks.
| > | > | > | > | Please note that the problem occurs also when 
| path2 and
| > | > | > path1 use
| > | > | > | > | exactly the same maximum capacity, say C!
| > | > | > | > | 
| > | > | > | > | In this case, if pathh2 fails then path1 will see
| > | an excess
| > | > | > | > rate equal
| > | > | > | > | to at least C.
| > | > | > | > | The rest of the explanation is identical to 
| the one used
| > | > | > | during my
| > | > | > | > | previous example!
| > | > | > | > | 
| > | > | > | > | 
| > | > | > | > | 
| > | > | > | > | Best regards,
| > | > | > | > | Georgios
| > | > | > | > | 
| > | > | > | > | 
| > | > | > | > | 
| > | > | > | > |  
| > | > | > | > | 
| > | > | > | > | > -----Original Message-----
| > | > | > | > | > From: Geib, Ruediger
| > | [mailto:Ruediger.Geib@t-systems.com]
| > | > | > | > | > Sent: maandag 17 maart 2008 14:34
| > | > | > | > | > To: karagian@cs.utwente.nl
| > | > | > | > | > Cc: pcn@ietf.org
| > | > | > | > | > Subject: RE: [PCN] Concensus questions from 
| Thursday's
| > | > | > | PCN meeting
| > | > | > | > | > 
| > | > | > | > | > Hi Georgios,
| > | > | > | > | > 
| > | > | > | > | > What you describe isn't backbone traffic 
| engineering. 
| > | > | > What you
| > | > | > | > | > describe may happen in corporate VPNs, where a
| > | DSL access
| > | > | > | > | is used to
| > | > | > | > | > back up a WAN Fast Ethernet access or the
| > like. I don't
| > | > | > | > | object to have
| > | > | > | > | > standards on PCN for VPNs, but I'm not
| > | interested in this
| > | > | > | > issue for
| > | > | > | > | > now.
| > | > | > | > | > 
| > | > | > | > | > If you know any carrier who's operating his
| > | network with a
| > | > | > | > | > 16:1 load balancing for QoS traffic on any
| > | particular link
| > | > | > | > | set, please
| > | > | > | > | > publish the name, we are all interested in 
| hearing it.
| > | > | > | > | > 
| > | > | > | > | > Regards,
| > | > | > | > | > 
| > | > | > | > | > Rudiger
| > | > | > | > | > 
| > | > | > | > | >  
| > | > | > | > | > 
| > | > | > | > | > | -----Original Message-----
| > | > | > | > | > | From: Georgios Karagiannis
| > | > [mailto:karagian@cs.utwente.nl]
| > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM
| > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | Cc: pcn@ietf.org
| > | > | > | > | > | Subject: RE: [PCN] Concensus questions from
| > Thursday's
| > | > | > | > PCN meeting
| > | > | > | > | > | 
| > | > | > | > | > | Hi Ruediger
| > | > | > | > | > | 
| > | > | > | > | > | I will try to explain this more clearly.
| > | > | > | > | > | Here are the assumptions:
| > | > | > | > | > | * In the PCN domain we assume that ECMP routing
| > | > | is possible!
| > | > | > | > | > | * ingress-eggress-aggregate can contain
| > flows that are
| > | > | > | > | > passing through
| > | > | > | > | > | one path or more paths (when ECMP routing 
| is used).
| > | > | > | > | > | 
| > | > | > | > | > | * routers are currently dropping packets
| > | randomly. Thus
| > | > | > | > | marked and
| > | > | > | > | > | unmarked packets will be
| > | > | > | > | > |   dropped randomly
| > | > | > | > | > | 
| > | > | > | > | > | * When excess rate measurements are used, the
| > | > | triggering of
| > | > | > | > | > admission
| > | > | > | > | > | control and flow
| > | > | > | > | > |   termination are done at the egress by using
| > | > the CLE. One
| > | > | > | > | > example of
| > | > | > | > | > | this trigger is:
| > | > | > | > | > |   CLE > 1%. Note that CLE = marked/(unmarked
| > | + marked). 
| > | > | > | > | This means
| > | > | > | > | > | that if this trigger is not activated 
| while a severe
| > | > | > | > | > |   congestion occurs in the PCN domain, then the
| > | > operation
| > | > | > | > | > of the PCN
| > | > | > | > | > | domain will completely collapse.
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | My statement is:
| > | > | > | > | > | If the routers do not preferentially drop
| > | marked packets
| > | > | > | > | > then the PCN
| > | > | > | > | > | domain operation, even in corner case and
| > | > misconfiguration
| > | > | > | > | > situations,
| > | > | > | > | > | is more robust and more stable than in the
| > | > situation that
| > | > | > | > | > the router
| > | > | > | > | > | is preferentially dropping marked packets.
| > | > | > | > | > | 
| > | > | > | > | > | The below example show such a corner case!
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | I will describe two situations:
| > | > | > | > | > | 
| > | > | > | > | > | Situation 1:
| > | > | > | > | > | Consider that an ingress-egress-aggregate
| > due to ECMP
| > | > | > | > routing it
| > | > | > | > | > | includes flows that are passing from at least
| > | two paths.
| > | > | > | > | > | Assume that path1 supports a maximum bandwidth
| > | > | > capacity of C. 
| > | > | > | > | > | Now consider
| > | > | > | > | > | that the maximum bandwdith capacity of
| > path2 is 15*C.
| > | > | > | > | > | Consider also that both paths are fully utilized.
| > | > | > | > | > | 
| > | > | > | > | > | Consider that preferentially marked packets are
| > | > | dropped and
| > | > | > | > | > that path2
| > | > | > | > | > | fails.
| > | > | > | > | > | Now assume that all (maximum) traffic
| > passing through
| > | > | > | > | path2 will be
| > | > | > | > | > | rerouted through path1.
| > | > | > | > | > | If a bottleneck router located in path1,
| > say Rbott, is
| > | > | > | > | > misconfigured
| > | > | > | > | > | (i.e., from the point of view of having wrongly
| > | > too high
| > | > | > | > | > | configured-admissible-rate value), or even if
| > | it is well
| > | > | > | > | > configured,
| > | > | > | > | > | then it can be possible that CLE measured at
| > | the egress
| > | > | > | > | > cannot reach
| > | > | > | > | > | 1%.
| > | > | > | > | > | Note that
| > | > | > | > | > | CLE = marked packets/ (marked packets +
| > | > unmarked packets).
| > | > | > | > | > | This is because Rbott will just allow an
| > | excess rate to
| > | > | > | > | > pass through
| > | > | > | > | > | that is
| > | > | > | > | > | 
| > | > | > | > | > | equal to: C - configured-admissible-rate. 
| > The rest of
| > | > | > | > the marked
| > | > | > | > | > | packets, so the rest of the excess rate, will
| > | be dropped
| > | > | > | > | by Rbott,
| > | > | > | > | > | since this router is preferentially dropping
| > | > | marked packets.
| > | > | > | > | > | Furthermore, note that due to the ECMP routing
| > | > | > flows that are
| > | > | > | > | > | belonging to the same
| > | ingress-egress-aggregate and that
| > | > | > | > | are passing
| > | > | > | > | > | through another path,
| > | > | > | > | > | 
| > | > | > | > | > | than path1, which is not congested, will
| > | forward traffic
| > | > | > | > | > towards the
| > | > | > | > | > | egress node that will be unmarked.
| > | > | > | > | > | This will mean that the CLE > 1% will not be
| > | triggered,
| > | > | > | > | > this will mean
| > | > | > | > | > | that the flow termination will not be
| > | triggered and that
| > | > | > | > | > the operation
| > | > | > | > | > | of the PCN domain will collapse completely.
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | Situation 2:
| > | > | > | > | > | Now consider that the router just operates as
| > | > | > | > currently, i.e., no
| > | > | > | > | > | preferential drop, randomly dropping marked and
| > | > | > | > unmarked packets.
| > | > | > | > | > | Consider also that the two paths described in
| > | > Situation 1
| > | > | > | > | above are
| > | > | > | > | > | used, ECMP routing is used, and that they 
| are fully
| > | > | > utilized.
| > | > | > | > | > | Assume also that path2 fails and that the path2
| > | > traffic is
| > | > | > | > | > rerouted on
| > | > | > | > | > | path1.
| > | > | > | > | > | Now the CLE value will have a higher 
| probability of
| > | > | > | > reaching the
| > | > | > | > | > | triggering value of 1%.
| > | > | > | > | > | 
| > | > | > | > | > | This is because the routers in path1 will
| > | drop randomly
| > | > | > | > | marked and
| > | > | > | > | > | unmarked packets.
| > | > | > | > | > | It is more certain that in this case the CLE
| > | > will reach 1%
| > | > | > | > | > due to the
| > | > | > | > | > | following reason.
| > | > | > | > | > | In this example it is assumed that the maximum
| > | > | > | > bandwidth capacity
| > | > | > | > | > | supported by path2 is 15*C.
| > | > | > | > | > | This means that after rerouting the traffic from
| > | > | path2 into
| > | > | > | > | > path1, the
| > | > | > | > | > | ratio between marked packets and unmarked
| > packets that
| > | > | > | > | are passing
| > | > | > | > | > | thorugh path1 can be equal or higher than 16.
| > | > | > | > | > | Note that the routers in path1 will mark the
| > | excess rate
| > | > | > | > | > above C, thus
| > | > | > | > | > | 16 * C (i.e., the rerouted traffic from path2)
| > | > as marked.
| > | > | > | > | > | The above observation holds also for the
| > | situation that
| > | > | > | > | the routers
| > | > | > | > | > | are preferentially dropping unmarked packets.
| > | > | > | > | > | 
| > | > | > | > | > | Thus when routers are preferentially 
| dropping marked
| > | > | > | > packets the
| > | > | > | > | > | robustness of the PCN domain operation is
| > | > | decreasing and in
| > | > | > | > | > some cases
| > | > | > | > | > | it severely decreases, which could cause
| > the complete
| > | > | > | > | > collapse of the
| > | > | > | > | > | PCN domain operation.
| > | > | > | > | > | 
| > | > | > | > | > | Best regards,
| > | > | > | > | > | Georgios
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | > -----Original Message-----
| > | > | > | > | > | > From: Geib, Ruediger
| > | > | [mailto:Ruediger.Geib@t-systems.com]
| > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42
| > | > | > | > | > | > To: karagian@cs.utwente.nl
| > | > | > | > | > | > Cc: pcn@ietf.org
| > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from
| > | Thursday's
| > | > | > | > | PCN meeting
| > | > | > | > | > | > 
| > | > | > | > | > | > Hi Georgios,
| > | > | > | > | > | > 
| > | > | > | > | > | > PCN is designed for deployment in traffic
| > engineered
| > | > | > | > networks. 
| > | > | > | > | > | > Please decribe, how to engineer a high 
| performance
| > | > | > | > | > carrier backbone
| > | > | > | > | > | > and then review the assumptions your discussion
| > | > | > is based on.
| > | > | > | > | > | > 
| > | > | > | > | > | > Regards,
| > | > | > | > | > | > 
| > | > | > | > | > | > Rudiger
| > | > | > | > | > | > 
| > | > | > | > | > | > | -----Original Message-----
| > | > | > | > | > | > | From: Georgios Karagiannis
| > | > | > [mailto:karagian@cs.utwente.nl]
| > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | > | Cc: pcn@ietf.org
| > | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from
| > | > Thursday's
| > | > | > | > | > PCN meeting
| > | > | > | > | > | > | 
| > | > | > | > | > | > | Hi Ruediger
| > | > | > | > | > | > | 
| > | > | > | > | > | > | What do you mean?
| > | > | > | > | > | > | Do you mean that you do not want to discuss
| > | > | corner cases
| > | > | > | > | > | > (ECMP related
| > | > | > | > | > | > | cases) that could collapse the PCN domain 
| > | > | > | > | > | > | operation?
| > | > | > | > | > | > | What I am saying is that if the routers do not
| > | > | > | > | > | preferentially drop
| > | > | > | > | > | > | marked packets then the PCN domain 
| operation is
| > | > | > | more robust
| > | > | > | > | > | > and more
| > | > | > | > | > | > | stable than in the situation that the 
| router is
| > | > | > | > | preferentially
| > | > | > | > | > | > | dropping marked packets.
| > | > | > | > | > | > | 
| > | > | > | > | > | > | Are you saying that this statement is 
| not right?
| > | > | > | > | > | > | 
| > | > | > | > | > | > | 
| > | > | > | > | > | > | Best regards,
| > | > | > | > | > | > | Georgios
| > | > | > | > | > | > |  
| > | > | > | > | > | >
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > | 
| > | > | > | > | > 
| > | > | > | > | 
| > | > | > | > | 
| > | > | > | > | 
| > | > | > | > 
| > | > | > | 
| > | > | > | 
| > | > | > | 
| > | > | > 
| > | > | 
| > | > | 
| > | > | 
| > | > 
| > | 
| > | 
| > | 
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn