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

"Georgios Karagiannis" <karagian@cs.utwente.nl> Thu, 20 March 2008 18:02 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 9DECC28C701; Thu, 20 Mar 2008 11:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.332
X-Spam-Level:
X-Spam-Status: No, score=-100.332 tagged_above=-999 required=5 tests=[AWL=0.105, 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 nFqgq2IrTtRh; Thu, 20 Mar 2008 11:02:25 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909063A6D3A; Thu, 20 Mar 2008 11:02:25 -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 73C883A6CA3 for <pcn@core3.amsl.com>; Thu, 20 Mar 2008 11:02:24 -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 TViRToM4LYn0 for <pcn@core3.amsl.com>; Thu, 20 Mar 2008 11:02:20 -0700 (PDT)
Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C264828C701 for <pcn@ietf.org>; Thu, 20 Mar 2008 11:02:19 -0700 (PDT)
Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2KHxvcH025084; Thu, 20 Mar 2008 19:00:00 +0100 (MET)
From: Georgios Karagiannis <karagian@cs.utwente.nl>
To: 'Steven Blake' <steven.blake@ericsson.com>
References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> <1205941357.3021.18.camel@neutrino>
Date: Thu, 20 Mar 2008 18:59:52 +0100
Message-ID: <000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <1205941357.3021.18.camel@neutrino>
Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQA2+AJQ
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Mar 2008 19:00:01 +0100 (MET)
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

Hi Steven

<<Please ignore previous email associated with the below described
solution!>>
The EXAMPLE contained an error>>
The below EXAMPLE is okay!


I have tried to work out this problem!

This is what I have found!
I assume that N * ECMP paths are carrying packets that are belonging to the
same Ingress-egress-aggregate.
I assume that one of the paths fails and one of the routers in only one of
the other N-1 paths will become congested.
Thus after failure, one path failed, one path is congested and N-2 paths are
not congested.

I assume that Ci is the minimum capacity (per PHB) supported on a path i.
The maximum capacity (per PHB) on the congested router is denoted as
Ci_cong.

In situation (1) when preferential dropping is used then I find the
following PCN_lower_threshold(1):


                                                     N -2
                                                      ---   
PCN_lower_th(1) < Ci_cong*(1- CLE_thres)-CLE_thres *  \Ci
                                                      /   
                                                      ---
                                                      i=1 

The value of PCN_lower_threshold it mainly depends on the value of the total
unmarked rate (of the 
congested and uncongested paths) that is arriving at the egress. The higher
this total unmarked rate 
Value, the smaller PCN_lower_th(1) must be.


In the situation (2) when marked and unmarked packets are dropped with equal
probability p, 
then I found the following equation:
Note that dropping probability can be defined as:


    rt - Ci_cong
P = ------------
       rt

Where rt = total rate (per PHB) that is seen by the congested
PCN_interior_node, 
that supports the maximum capacity (per PHB) equal to Ci_cong. Then the 
PCN_lower_th (2) can be found as:

PCN_lower_th(2) < MINIMUM(Ci_cong ; SECOND_PART), where

                                                        N -2
                                                        ---   
                      CLE_thres* Ci_cong - CLE_thres    \Ci
 SECOND_PART = rt  -  -----------------------------  *  /     )
                                          (1-p)        /
                                                       ---
                                                        i=1 


The value of PCN_lower_threshold in this case, it has to mainly be smaller 
than the maximum capacity supported by the congested router. This situation
can 
always be supported.

Example:

Use  N = 6, CLE_th = 1%, p = 50%, 
Suppose that path6 fails and path1 is the one that becomes congested, 
rt = C1 + C6, because p = 50% it means that C6 = C1;
The thresholds on these tw situations can be then calculated as:

When router is preferentially dropping marked packets:

PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) 




-----------------------------------------------------

When router is dropping marked and unmarked packets are 
with equal probability p: 


PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where:

                [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]}
 SECOND_PART=                 ----------------------------
                                    50%

PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where:

              [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]}
SECOND_PART =            --------------------------------
                            50%

=> PCN_lower_threshold (2) < C1


Therefore, the second scheme (2) can be considered more robust and more 
stable then the first scheme.

Best regards,
Georgios 

> -----Original Message-----
> From: Steven Blake [mailto:steven.blake@ericsson.com] 
> Sent: woensdag 19 maart 2008 16:43
> To: Georgios Karagiannis
> Cc: pcn@ietf.org
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote:
> 
> > Hi Steven
> > 
> > Please see that I have included some information into the 
> last bullet:
> > 
> > - There is an ingress-egress aggregate whose traffic is 
> split across 
> > multiple paths via ECMP.
> >  - Traffic is admitted along this split path.
> >  - One (or more) of the paths fails.
> >  - One (or more) of the remaining paths becomes severely 
> congested (for
> >    example because there is traffic from other ingress-egress  
> > aggregates flowing along that path).
> > - <<Due to the ECMP routing not congested paths will 
> forward packets 
> > belonging to
> >   the same ingress-egress-aggregate that will be unmarked.>> Marked 
> > packets are
> >   preferentially dropped at the severely congested
> >   router(s). As a consequence, not enough marked traffic arrives at 
> > the egress router to drive the CLE for the ingress-egress aggregate 
> > above the threshold needed to trigger a response (termination, say).
> 
> Ok.  To be specific, the egressrouter  will see some fraction 
> of packets from the severely congested router(s), some of 
> which will be marked, and will see a larger fraction of 
> un-marked packets from the un-pre-congested routers.
> 
> So let me now ask you this: given N ECMP paths (after a path 
> failure), with one being severely congested and the rest 
> being un-pre-congested, and given a CLE threshold CLE_thresh 
> at the egress router, can you solve for the minimum 
> PCN_lower_threshold value at the severely congested router, 
> where PCN still works (e.g., CLE crosses the threshold), for 
> the two cases where (1) marked packets are preferentially 
> dropped, and (2) marked packets are dropped with equal 
> probability with un-marked packets?
> 
> 
> 
> Regards,
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Steven Blake                <steven.blake@ericsson.com>
> Ericsson/Redback Networks               +1 919-472-9913
> 


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn