[PCN] Georgios's example

[<[e-mail]>]

Georgios,

(1) again, I need to remind myself of the context: this is termination
control, assuming Single Marking is being used

(2) the term PCN_lower_threshold(1) is unexplained

(3) the term CLE_thres is unexplained.

(4) Since this is just the first equation of many, at this point I give
up trying to follow your email

(5) I actually don't want you to tell me what the two terms above mean.
At this stage I don't care. 

(6) Instead, I want to understand what the point you're making is and
whether it has any importance. 

(7) My impression is that Anna managed to explain what the general point
was that you'd been attempting to make in her email
http://www.ietf.org/mail-archive/web/pcn/current/msg01350.html 

(8) Anna in the same email also heroically added some estimated size of
parameters, showing that in practice this won't ever be a real problem.

(9) I believe you haven't answered this email of Anna's, so I assume you
agree with it - and your email below agrees with it whilst trying to add
some equations to further support it. 

(10) it would be good if you could confirm you do agree with anna's
email. 

(11) if you basically agree with anna, but think the issue is more
significant in scale (anna's parameters need to be changed), please
present reasonable arguments for a different set of parameters.

(12) if you actually mean a different problem from the one explained by
anna in msg1350, then you need to explain it in clear, short English
(maths such as below is just a hindrance)

(13) I believe this whole discussion is already covered by the
architecture draft (which says, paraphrasing a lot, ECMP is nasty).
However I can add some more detail (whilst remembering that, as the
architecture draft says in S6'Design goals and challenges', "NOTE:
Potential solutions are out of scope for this document."

Best wishes
phil

 -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Georgios Karagiannis
> Sent: 20 March 2008 18:00
> To: 'Steven Blake'
> Cc: [e-mail]
> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
> 
> 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:[e-mail]]
> > Sent: woensdag 19 maart 2008 16:43
> > To: Georgios Karagiannis
> > Cc: [e-mail]
> > 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                <[e-mail]>
> > Ericsson/Redback Networks               [phone]
> >
> 
> 
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn