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

From: Steven Blake <[email-masked]>
Date: Fri, 14 Mar 2008 10:54:36 -0400

Greetings.

There were six concensus questions called during yesterday's PCN
meeting.  Before we call the questions on the list, I want to paraphrase
them and make sure that everyone agrees that this captures the sense of
the discussion.

Q1: As an initial standardization activity, should the PCN wg produce a
    standards-track PCN scheme that requires only two encoding states?
    (Note: this question does not presume that the solution is Single
    Marking).

Q2: Should the PCN wg produce an experimental-track extension to the
    standards-track PCN scheme that requires another encoding state (for
    a total of three encoding states)?

Q3: Does the working group have enough information to make a decision
    about the way forward for the standards-track PCN scheme?

Q4: Should the standards-track PCN scheme require (as a MUST implement
    feature) that interior PCN routers support Excess-Rate marking,
    according to the particular method of handling already marked 
    packets and drops described in Anna Charny's presentation?
    http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

Q5: Should the standards-track PCN scheme require (as a MUST implement
    feature) that interior PCN routers support Threshold marking (in
    addition to Excess-Rate marking), according to the particular method
    described in Philip Eardley's presentation on Tuesday?
    http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

Q6: If presented with sufficient evidence in a timely fashion, would
    the PCN wg entertain the option of modifying the interior router
    Excess-Rate marking behavior for the standards-track PCN scheme (as
    described in question 4)?

Please send comments to the list.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 14 Mar 2008 15:06:46 -0000

Mostly fine. 

Question 2 I believe we agreed to call it "one or more" extensions at
Georgios's request

Question 6 you need to highlight that we suggested IETF72 in Dublin as
being "in a timely fashion" for this new evidence.

Toby
____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven Blake
> Sent: 14 March 2008 14:55
> To: pcn
> Subject: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Greetings.
>

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 14 Mar 2008 11:18:25 -0400

Hi Steve,

Agreed with Toby's comments.  Fine with me otherwise.

Anna  

> Behalf Of [email-masked]
> Sent: Friday, March 14, 2008 11:07 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Mostly fine. 
> 
> Question 2 I believe we agreed to call it "one or more" 
> extensions at Georgios's request
> 
> Question 6 you need to highlight that we suggested IETF72 in 
> Dublin as being "in a timely fashion" for this new evidence.
> 
> Toby
> Toby Moncaster, <[email-masked]> Networks Research 
> Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
> 1473 648734 
> 
> 
> Behalf Of 
> > Steven Blake
> > meeting.  Before we call the questions on the list, I want to 
> > paraphrase them and make sure that everyone agrees that 
> this captures 
> > the sense of the discussion.
> > 
> >

---

From: Steven Blake <[email-masked]>
Date: Fri, 14 Mar 2008 11:27:32 -0400

> Question 2 I believe we agreed to call it "one or more" extensions at

Correct: I had "extensions" in my notes, but failed to type it
correctly.

> being "in a timely fashion" for this new evidence.

That wasn't part of the question specifically.  By my personal view, I
hope that we can make a decision one way or another much sooner than
Dublin.

Thanks,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 14 Mar 2008 18:29:18 +0000

Hi all

Before taking any decisions I would like to emphasize the following.

In my opinion preferential dropping of any kind increases the complexity
in the interior routers. Furthermore, when excess rate mechanisms are
used,
by preferentially dropping marked packets it severely decreases the
robustness of the PCN domain operation.
With robustness I mean, that due to a corner case or due to a
msiconfiguration the operation of the PCN domain will
completely collapse.
This is because the admission control trigger (CLE) at the egress is 
much more sensistive when marked packets are dropped than either the
situation that unmarked and marked packets are dropped randomly (current
implementation of routers) or the situation that unmarked packets are
dropped.
Therefore, as an initial step is better to do not change the current
router behaviour from the preferential dropping point of view.

Regarding LC-PCN and 3SM operation at the core, the only requirements
that have to be supported are:

* use current router behaviour from the preferential dropping point of
view.
Thus drop marked and unmarked packets randomly. Do not preferentially
drop marked packets.

* use a parameter N (or S) that should be equal in whole PCN domain.
The only change in the token bucket implementation will be that the token
bucket should mark N packet (or bytes) instead of marking one packet (or
byte). Note that if N = 1, then the token bucket operates the same as
described in the SM draft. If N > 1, then the SM scheme can operate in
the same way with the difference that the measured excess rate at the
egress should be multipleied with N.

All the other optimization features that are described in the LC-PCN
draft are optional.

Best regards,
Georgios

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 14 Mar 2008 17:58:01 -0400

Hello Georgios,

A few comments: 

> Behalf Of Georgios Karagiannis
> Sent: Friday, March 14, 2008 2:29 PM
> To: Steven Blake; pcn
> In my opinion preferential dropping of any kind increases the 
> complexity in the interior routers.

Yes, that is absolutely true

> Furthermore, when excess 
> rate mechanisms are used, by preferentially dropping marked 
> packets it severely decreases the robustness of the PCN 
> domain operation.
> This is because the admission control trigger (CLE) at the 
> egress is much more sensistive when marked packets are 
> dropped than either the situation that unmarked and marked 
> packets are dropped randomly (current implementation of 
> routers) or the situation that unmarked packets are dropped.

Georgios, I do believe this is really quite an exaggeration.  In SM, all
excess-rate packets will be dropped only if the bottleneck link has
admission threshold configured at the link speed.  This is certainly not
the expected configuration.  And SM does not care about absolute amount
of marked packets - it only needs to see a small percentage (~1%) of
excess rate marks to work, as all of our simulations show. 

> Therefore, as an initial step is better to do not change the 
> current router behavior from the preferential dropping point of view.
> 

The proposal as presented is that preferential drop is a SHOULD, not a
must.  Since it does not preclude interoperability,  that is OK.
If the preferential drop is not implemented,  SM will potentially
overterminate more in the case of multiple congested bottlenecks.

> Regarding LC-PCN and 3SM operation at the core, the only 
> requirements that have to be supported are:
> 
> * use current router behavior from the preferential dropping 
> point of view.

No, not really.  Performance of 3SM will be slowed down quite
substantially if large number of excess-marked packets are dropped.
Indeed 3SM is less sensitive to loss preference, however.  It does
however need 3 encoding states that we do not seem to have, and requires
other modifications to the "current router behavior".

As to LC-PCN,  in the slides you sent to me for the presentation on
Thursday you had the following for LC-PCN " [Loss preference] depends on
thres.[hold] set[tting]. Typically, prefer not to drop ex[cess]. Rate".
Did you change your mind and now believe it is wrong?  LC-PCN will also
need another modification to the "current router behavior" as it would
need to mark only a subset of excess rate packets, which requires a
modification to the token bucket. This as you say below is not an
optional optimization, but is required for LC-PCN to work.  The optional
optimization is there to make the algorithm not overterminate. It is to
the excitant equally optional as preferential drop for SM - as that too
is there to not let SM overterminate :-). 

> Thus drop marked and unmarked packets randomly. Do not 
> preferentially drop marked packets.
> 

Again, the proposed approach is to put a SHOULD in the preferential drop
requirement. 

Best,
Anna 

> The only change in the token bucket implementation will be 
> that the token bucket should mark N packet (or bytes) instead 
> of marking one packet (or byte). Note that if N = 1, then the 
> token bucket operates the same as described in the SM draft. 
> If N > 1, then the SM scheme can operate in the same way with 
> the difference that the measured excess rate at the egress 
> should be multipleied with N.
> 
> All the other optimization features that are described in the 
> LC-PCN draft are optional.
> 
> Best regards,
> Georgios
> 
> 
> 
> 
> >paraphrase them and make sure that everyone agrees that this 
> captures

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Sun, 16 Mar 2008 21:41:18 -0400

Hi Georgios,

A few clarification questions below: 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Sunday, March 16, 2008 11:03 AM
> To: Anna Charny (acharny); Steven Blake; pcn
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Hello Anna
> 
> Please see some comments in line!
> 
> 
> On 3/14/2008, "Anna Charny (acharny)" <[email-masked]> wrote:
> 
> >Hello Georgios,
> >
> >A few comments: 
> >
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Georgios Karagiannis
> >> rate mechanisms are used, by preferentially dropping 
> marked packets 
> >> it severely decreases the robustness of the PCN domain operation.
> >> msiconfiguration the operation of the PCN domain will completely 
> >> collapse.
> egress is 
> >> situation that unmarked and marked packets are dropped randomly 
> >> (current implementation of
> >Georgios, I do believe this is really quite an exaggeration.  In SM, 
> >all excess-rate packets will be dropped only if the 
> bottleneck link has 
> >admission threshold configured at the link speed.  This is certainly 
> >not the expected configuration.  And SM does not care about absolute 
> >amount of marked packets - it only needs to see a small percentage 
> >(~1%) of excess rate marks to work, as all of our simulations show.
> 
> Georgios: I will just give you an example:
> I will describe two situations:
> Situation 1:
> Consider that an ingress-egress-aggregate includes flows that 
> are passing from at least two paths.

Do you mean that a single ingress-egress aggregate is travercing two
different paths 0- that is, are we talking about ECMP case?

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

So you are considering the case when there is 16x overload on the
bottleneck after the failure - right?

> 
> 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), 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 routaer is preferentially 
> dropping marked packets.

So it seems to me that in this example the egress will see the
C-configured-admissible-rate of marked packets.  In order for this to be
less than 1% of the total traffic seen by this egress,
configured-admissible-rate should be set to above 99% of the link speed.
Right?  Do you believe it is a realistic setting?

Thank you,
Anna 

> 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 and that they are fully utilized.
> Assume also that path2 fails and that the path2 traffic is 
> rerouted on path1.
> Even if routers are misconfigured in path1 (i.e., from the 
> point of view of having wrongly too high 
> configured-admissible-rate value), now the CLE value will be 
> able for sure to reach the triggering value of 1%.
> This is because the routers in path1 will drop randomly 
> marked and unmarked packets.
> It is 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 15.
> Note that the routers in path1 will mark the excess rate above C, thus
> 15 * 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.
> 
> >
> >> router behavior from the preferential dropping point of view.
> >> 
> >
> Georgios: I think that the robustness of the PCN domain 
> operation, is more important than overtermination.
> 
> >
> >> * use current router behavior from the preferential 
> dropping point of 
> >> view.
> >
> >however need 3 encoding states that we do not seem to have, and 
> >requires other modifications to the "current router behavior".
> 
> Georgios: Please do not understand me wrong, I agree that 
> during the first step we should work on standardizing SM.
> But we should allow the possibility in the future to 
> implement as experimental RFC the CL-PHB, and the 
> specification of a scheme that is able to detect and handle 
> the admission control and flow termination at the 
> PCN-egress-node in another experimental RFC.
> 
> Now regarding the comment on 3SM, yes, I agree that it is 
> slower, but when the slowing down factor is implemented at 
> the core routers, a cleaver mechanism could be found later on 
> at the egress that uses this information and selects the 
> e.g., "big flows" first in order to increase the termination speed.
> 
> >
> >Thursday you had the following for LC-PCN " [Loss 
> preference] depends 
> >on thres.[hold] set[tting]. Typically, prefer not to drop 
> ex[cess]. Rate".
> >Did you change your mind and now believe it is wrong?  
> 
> Georgios: I did not change my mind, typically yes the LC-PCN 
> should not drop marked packets. However, due to the fact that 
> the admission control and flow termination triggers at the 
> egress, are based on the ratio of (marked/(marked + 
> unmarked), than dropping randomly marked and unmarked 
> packets, as is done today will operate okay.
> 
> >LC-PCN will also
> >modification to the token bucket.
> 
> Georgios: Yes, I agree, I think from the point of view of 
> Token bucket operation, SM will need less changes to router operation.
> The above listed comment by me on complexity increase, holds 
> only for implementing preferential dropping, instead of 
> implementing random dropping of marked and unmarked packets.
> 
> >This is you say below is not an
> >optional optimization, but is required for LC-PCN to work.  The 
> >optional optimization is there to make the algorithm not 
> overterminate. 
> >It is to the excitant equally optional as preferential drop 
> for SM - as 
> >that too is there to not let SM overterminate :-).
> 
> Georgios: Note that using N in LC-PCN is not an optional optimization.
> The LC-PCN needs a very small change in the current token 
> bucket implementation. This small change is that the token 
> bucket should mark N packet (or bytes) instead of marking one 
> packet (or byte). Note that if N = 1, then the token bucket 
> operates the same as described in the SM draft.
> Thus my proposal is to now standardise SM, and in addition, 
> the core router should allow, for the near future, the 
> specification of the CL-PHB behaviour in an experimental RFC 
> and the specification of a scheme that is able to detect and 
> handle the admission control and flow termination at the 
> PCN-egress-node in another experimental RFC.
> 
> 
> 
> Best regards,
> Georgios
> 
> 
> >
> >Again, the proposed approach is to put a SHOULD in the preferential 
> >drop requirement.
> >
> >Best,
> >Anna
> >
> >
> that the 
> >> token bucket should mark N packet (or bytes) instead of 
> marking one 
> >> packet (or byte). Note that if N = 1, then the token 
> bucket operates 
> >> the same as described in the SM draft.
> >> If N > 1, then the SM scheme can operate in the same way with the 
> >> difference that the measured excess rate at the egress should be 
> >> multipleied with N.
> >>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 06:13:00 +0000

Hi Anna

Please see in line!

>different paths 0- that is, are we talking about ECMP case?

Georgios: In the description of the example I had to say that after
rerouting the flows belonging to the two paths will be included in the
same ingress-egress-aggregate.
Before rerouting, path2 is part of another ingress-egress-aggregate.
However, it should be considered that both paths start from the same
ingress. After rerouting, the flows that were forwarded through path2
will be rerouted/forwarded through path1.

>bottleneck after the failure - right?
Georgios: Yes!

>Right?  Do you believe it is a realistic setting?

Georgios: If no misconfiguration occurs and if ECMP is not applied, then
you are right.
But in my statements, I was talking about corner cases and
misconfigurations. A corner case is the situation where at the same time
ECMP occurs, meaning that the egress router, for the same
ingress-egress-aggregate will receive more unmarked packets then the
ones received only from one path, i.e., path1 in this case. This will
mean that the value of the CLE at the egress can decrease dramatically,
depending on the value of the unmarked rate received from other paths
than path1.
Note that CLE = marked/(marked + unmarked).

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 06:39:11 +0000

Hi Anna

Please ignore the previous email!
Consider the answers to your previous email being the ones that
I send in this email!
Yes I was referring to an ECMP situation.

Please see in line!

>different paths 0- that is, are we talking about ECMP case?

Georgios: Yes, I am refering to an ECMP situation.

Georgios: Yes!

Best regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 17 Mar 2008 08:56:14 +0100

Georgios,

I'm sorry, this is not a serious discussion.

Stephen, could stuff like this be taken to another mailing list? 

Regards,

Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[email-masked]] 
| Sent: Sunday, March 16, 2008 4:03 PM
| To: Anna Charny (acharny); Steven Blake; pcn
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| Hello Anna
| 
| Please see some comments in line!
| 
| 
[snip]
| 
| Georgios: I will just give you an example:
| I will describe two situations:
| Situation 1:
| Consider that an ingress-egress-aggregate 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. 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 09:34:04 +0100

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

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: maandag 17 maart 2008 8:56
> To: [email-masked]
> Cc: [email-masked]
> | Consider that an ingress-egress-aggregate includes flows that are 
> | passing from at least two paths.
> that path2 
> | fails.
> | Now assume that all (maximum) traffic passing through path2 will be 
> | rerouted through path1.
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 17 Mar 2008 09:42:25 +0100

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:[email-masked]] 
| Sent: Monday, March 17, 2008 9:34 AM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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
|  
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: maandag 17 maart 2008 8:56
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > Georgios,
| > 
| > I'm sorry, this is not a serious discussion.
| > 
| > Stephen, could stuff like this be taken to another mailing list? 
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > | -----Original Message-----
| > | From: Georgios Karagiannis [mailto:[email-masked]]
| > | Sent: Sunday, March 16, 2008 4:03 PM
| > | To: Anna Charny (acharny); Steven Blake; pcn
| > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > | 
| > | Hello Anna
| > | 
| > | Please see some comments in line!
| > | 
| > | 
| > [snip]
| > | 
| > | Georgios: I will just give you an example:
| > | I will describe two situations:
| > | Situation 1:
| > | Consider that an ingress-egress-aggregate 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.
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 11:02:46 +0100

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!

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

> Sent: maandag 17 maart 2008 9:42
> 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
> 
> | 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.
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 17 Mar 2008 14:33:45 +0100

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:[email-masked]] 
| Sent: Monday, March 17, 2008 11:03 AM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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:[email-masked]] 
| > Sent: maandag 17 maart 2008 9:42
| > To: [email-masked]
| > Cc: [email-masked]
| > 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:[email-masked]]
| > | Sent: Monday, March 17, 2008 9:34 AM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 14:48:31 +0100

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

> Sent: maandag 17 maart 2008 14:34
> 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 
> 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
> 
>  
> 
> 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
> | 
> admission 
> | control and flow
> 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 
> misconfigured 
> | (i.e., from the point of view of having wrongly too high 
> | configured-admissible-rate value), or even if it is well 
> configured, 
> cannot reach 
> | 1%.
> | 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.
> | belonging to the same ingress-egress-aggregate and that are passing 
> | through another path,
> | 
> 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:
> | 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.
> | 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.
> | In this example it is assumed that the maximum bandwidth capacity 
> | supported by path2 is 15*C.
> path1, the 
> | ratio between marked packets and unmarked packets that are passing 
> | thorugh path1 can be equal or higher than 16.
> | 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
> | 
> | 
> | 
> | 
> | 
> | > 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
> | >

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 17 Mar 2008 15:25:30 +0100

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:[email-masked]] 
| Sent: Monday, March 17, 2008 2:49 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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:[email-masked]]
| > Sent: maandag 17 maart 2008 14:34
| > To: [email-masked]
| > Cc: [email-masked]
| > 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:[email-masked]]
| > | Sent: Monday, March 17, 2008 11:03 AM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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:[email-masked]]
| > | > Sent: maandag 17 maart 2008 9:42
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > 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:[email-masked]]
| > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 15:33:33 +0100

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

My statement is:

Situation 1:
that the maximum bandwdith capacity of path2 is C.

Situation 2:

by path2 is C. 
higher than 100%.
1*C (i.e., the rerouted traffic from path2) as marked.

Best regards,
Georgios

> Sent: maandag 17 maart 2008 15:26
> 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. 
> 
> from, if we discuss PCN. From there on, PCN is able to add value. 
> 
> 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
> 
> | Please note that the problem occurs also when path2 and path1 use 
> | exactly the same maximum capacity, say C!
> | 
> rate equal 
> | to at least C.
> | The rest of the explanation is identical to the one used during my 
> | previous example!
> | 
> | 
> | 
> | Best regards,
> | Georgios
> | 
> | 
> | 
> |  
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 17 Mar 2008 16:32:12 +0100

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:[email-masked]] 
| Sent: Monday, March 17, 2008 3:34 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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:[email-masked]]
| > Sent: maandag 17 maart 2008 15:26
| > To: [email-masked]
| > Cc: [email-masked]
| > 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:[email-masked]]
| > | Sent: Monday, March 17, 2008 2:49 PM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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:[email-masked]]
| > | > Sent: maandag 17 maart 2008 14:34
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > 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:[email-masked]]
| > | > | Sent: Monday, March 17, 2008 11:03 AM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | 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:[email-masked]]
| > | > | > Sent: maandag 17 maart 2008 9:42
| > | > | > To: [email-masked]
| > | > | > Cc: [email-masked]
| > | > | > 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:[email-masked]]
| > | > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: [email-masked]
| > | > | > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 16:38:25 +0100

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

> Sent: maandag 17 maart 2008 16:32
> 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
> 
> | Please note that typical IP networks (thus not MPLS/GMPLS based 
> | domains) can recover from failures by using rerouting.
> 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
> rerouted on 
> due to the 
> | supported by path2 is C.
> | thorugh path1 can be equal or higher than 100%.
> above C, thus 
> | 1*C (i.e., the rerouted traffic from path2) as marked.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 17 Mar 2008 17:09:39 +0100

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:[email-masked]] 
| Sent: Monday, March 17, 2008 4:38 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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:[email-masked]]
| > Sent: maandag 17 maart 2008 16:32
| > To: [email-masked]
| > Cc: [email-masked]
| > 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:[email-masked]]
| > | Sent: Monday, March 17, 2008 3:34 PM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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:[email-masked]]
| > | > Sent: maandag 17 maart 2008 15:26
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > 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:[email-masked]]
| > | > | Sent: Monday, March 17, 2008 2:49 PM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | 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:[email-masked]]
| > | > | > Sent: maandag 17 maart 2008 14:34
| > | > | > To: [email-masked]
| > | > | > Cc: [email-masked]
| > | > | > 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:[email-masked]]
| > | > | > | Sent: Monday, March 17, 2008 11:03 AM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: [email-masked]
| > | > | > | 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:[email-masked]]
| > | > | > | > Sent: maandag 17 maart 2008 9:42
| > | > | > | > To: [email-masked]
| > | > | > | > Cc: [email-masked]
| > | > | > | > 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:[email-masked]]
| > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | Cc: [email-masked]
| > | > | > | > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 18 Mar 2008 00:10:53 +0800

Hi, both and all,

Even you discuss the problem in a model,
would you please notice the typical model of communication system 
performance.

For a communication system, suppose the output capacity is C;
when the input rate is much bigger than C, the switch node is in congestion,
the output did not kept give the maximum throuput, i.e. C.
The output is much less than C. It decreses sharply.

When the input is 16 times of output, or 2 times of input, the output is not 
stable.
The number of marked or unmarked packets you count might be undetermined.

Gengyu

----- Original Message ----- 
From: "Georgios Karagiannis" <[email-masked]>
To: "'Geib, Ruediger'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 17, 2008 10:33 PM
Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting

Hi Ruediger

My statement is:

Situation 1:

Situation 2:

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Mar 2008 17:36:15 +0100

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

> Sent: maandag 17 maart 2008 17:10
> 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
> 
> 
> | 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:
> | 
> redirect lots 
> | of

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 18 Mar 2008 08:29:40 +0100

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:[email-masked]] 
| Sent: Monday, March 17, 2008 5:36 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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:[email-masked]]
| > Sent: maandag 17 maart 2008 17:10
| > To: [email-masked]
| > Cc: [email-masked]
| > 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:[email-masked]]
| > | Sent: Monday, March 17, 2008 4:38 PM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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:[email-masked]]
| > | > Sent: maandag 17 maart 2008 16:32
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > 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:[email-masked]]
| > | > | Sent: Monday, March 17, 2008 3:34 PM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | 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:[email-masked]]
| > | > | > Sent: maandag 17 maart 2008 15:26
| > | > | > To: [email-masked]
| > | > | > Cc: [email-masked]
| > | > | > 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:[email-masked]]
| > | > | > | Sent: Monday, March 17, 2008 2:49 PM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: [email-masked]
| > | > | > | 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:[email-masked]]
| > | > | > | > Sent: maandag 17 maart 2008 14:34
| > | > | > | > To: [email-masked]
| > | > | > | > Cc: [email-masked]
| > | > | > | > 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:[email-masked]]
| > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM
| > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | Cc: [email-masked]
| > | > | > | > | 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:[email-masked]]
| > | > | > | > | > Sent: maandag 17 maart 2008 9:42
| > | > | > | > | > To: [email-masked]
| > | > | > | > | > Cc: [email-masked]
| > | > | > | > | > 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:[email-masked]]
| > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | Cc: [email-masked]
| > | > | > | > | > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 18 Mar 2008 11:17:01 +0100

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.

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 

> Sent: dinsdag 18 maart 2008 8:30
> 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. 
> 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
> 
> | 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
> | 
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 18 Mar 2008 11:36:02 +0100

Hi Georgios 

see in line.

Regards, Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[email-masked]] 
| Sent: Tuesday, March 18, 2008 11:17 AM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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:[email-masked]]
| > Sent: dinsdag 18 maart 2008 8:30
| > To: [email-masked]
| > Cc: [email-masked]
| > 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:[email-masked]]
| > | Sent: Monday, March 17, 2008 5:36 PM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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:[email-masked]]
| > | > Sent: maandag 17 maart 2008 17:10
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > 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:[email-masked]]
| > | > | Sent: Monday, March 17, 2008 4:38 PM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | 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:[email-masked]]
| > | > | > Sent: maandag 17 maart 2008 16:32
| > | > | > To: [email-masked]
| > | > | > Cc: [email-masked]
| > | > | > 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:[email-masked]]
| > | > | > | Sent: Monday, March 17, 2008 3:34 PM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: [email-masked]
| > | > | > | 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:[email-masked]]
| > | > | > | > Sent: maandag 17 maart 2008 15:26
| > | > | > | > To: [email-masked]
| > | > | > | > Cc: [email-masked]
| > | > | > | > 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:[email-masked]]
| > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM
| > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | Cc: [email-masked]
| > | > | > | > | 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:[email-masked]]
| > | > | > | > | > Sent: maandag 17 maart 2008 14:34
| > | > | > | > | > To: [email-masked]
| > | > | > | > | > Cc: [email-masked]
| > | > | > | > | > 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:[email-masked]]
| > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM
| > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | Cc: [email-masked]
| > | > | > | > | > | 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:[email-masked]]
| > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42
| > | > | > | > | > | > To: [email-masked]
| > | > | > | > | > | > Cc: [email-masked]
| > | > | > | > | > | > 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:[email-masked]]
| > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | > | Cc: [email-masked]
| > | > | > | > | > | > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 18 Mar 2008 11:42:53 +0100

Hi Ruediger

What is not realistic?
Is it not realistic to use ECMP routing?
Is it not realistic that one path fails and its 
traffic is rerouted to another path?

Best regards,
Georgios

> Sent: dinsdag 18 maart 2008 11:36
> | 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.
> | 
> | 
> | When ECMP routing is used, it means that flows that are associated 
> | with the same ingress-egress-aggregate can follow different paths.
> 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.
> 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 +
> | 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.
> | 
> applied then 
> | CLE = marked_1 /(unmarked_1 + unmarked_2 +
> reach 1% 
> | when marked packets are preferentially dropped, since 
> marked_1 can be 
> | smaller than 1% * (unmarked_1 +

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 18 Mar 2008 11:57:54 +0100

Hi Georgios,

on the configuration and operation of ECMP you may want to read 
the documentation provided by backbone router vendors or 
other publications.

Regards,

Rudiger 

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[email-masked]] 
| Sent: Tuesday, March 18, 2008 11:43 AM
| To: Geib, Rüdiger
| Cc: [email-masked]
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| Hi Ruediger
| 
| What is not realistic?
| Is it not realistic to use ECMP routing?
| Is it not realistic that one path fails and its traffic is 
| rerouted to another path?
| 
| Best regards,
| Georgios
| 
| 
| 
|  
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: dinsdag 18 maart 2008 11:36
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > Hi Georgios
| > 
| > see in line.
| > 
| > Regards, Rudiger
| > 
| > | -----Original Message-----
| > | From: Georgios Karagiannis [mailto:[email-masked]]
| > | Sent: Tuesday, March 18, 2008 11:17 AM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | 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:[email-masked]]
| > | > Sent: dinsdag 18 maart 2008 8:30
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > 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:[email-masked]]
| > | > | Sent: Monday, March 17, 2008 5:36 PM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | 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:[email-masked]]
| > | > | > Sent: maandag 17 maart 2008 17:10
| > | > | > To: [email-masked]
| > | > | > Cc: [email-masked]
| > | > | > 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:[email-masked]]
| > | > | > | Sent: Monday, March 17, 2008 4:38 PM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: [email-masked]
| > | > | > | 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:[email-masked]]
| > | > | > | > Sent: maandag 17 maart 2008 16:32
| > | > | > | > To: [email-masked]
| > | > | > | > Cc: [email-masked]
| > | > | > | > 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:[email-masked]]
| > | > | > | > | Sent: Monday, March 17, 2008 3:34 PM
| > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | Cc: [email-masked]
| > | > | > | > | 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:[email-masked]]
| > | > | > | > | > Sent: maandag 17 maart 2008 15:26
| > | > | > | > | > To: [email-masked]
| > | > | > | > | > Cc: [email-masked]
| > | > | > | > | > 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:[email-masked]]
| > | > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM
| > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | Cc: [email-masked]
| > | > | > | > | > | 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:[email-masked]]
| > | > | > | > | > | > Sent: maandag 17 maart 2008 14:34
| > | > | > | > | > | > To: [email-masked]
| > | > | > | > | > | > Cc: [email-masked]
| > | > | > | > | > | > 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:[email-masked]]
| > | > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM
| > | > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | > | Cc: [email-masked]
| > | > | > | > | > | > | 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:[email-masked]]
| > | > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42
| > | > | > | > | > | > | > To: [email-masked]
| > | > | > | > | > | > | > Cc: [email-masked]
| > | > | > | > | > | > | > 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:[email-masked]]
| > | > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | > | > | > | > | > | To: Geib, Rüdiger
| > | > | > | > | > | > | > | Cc: [email-masked]
| > | > | > | > | > | > | > | 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Tue, 18 Mar 2008 10:18:39 -0400

> in continuing discusion. I think, I've made my point.

Ruediger,

If I follow this comment to its logical conclusion, then PCN is
superfluous in this network.  Is that what you are trying to say?

Regards,

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Mar 2008 11:37:24 +0100

Steven,

what Georgios is proposing is to optimise PCN so that it works 
properly if a catastrophic event coincides with a 
misconfigured router. 

If this is the main or even an important task of PCN, then I 
waste my time here.

The salary I obtain monthly depends on my companies backbone 
network providing good service to customers under regular 
operational conditions (which cover planned outages 
and expectable failures). The telephony or streaming services 
offered to our customers should experience a minimised network 
impact on the Quality of Experience perceived by the consumers 
under regular operational conditions. This includes the 
creation of a "Network Busy Indication", which however is a 
rare event. So my position on what PCN should be optimised 
for is to create this "network busy indication" for regular 
operational conditions, reliably and only if it is required. 
This should be done with the least possible complexity (like 
the least possible flow awareness, the least codepoint 
consumption, simple queuing/policing and measurement 
functions, utmost re-use of allready implemented features). 

To clarify what I mean by a rare event: a well engineered 
backbone creating a PCN network busy indication either during 
a main traffic hour or after a re-routing event. During ISDN 
times, engineering resulted in what Americans called 5ESS 
switches, aiming on a network busy indication probability of 
(100 - 99,999%, the 5 nines). We may see that a bit more 
relaxed for IP networks, but I don't think the customers 
of my company should experience the consequences of PCN 
behaviour more often than in (100 - 99,x)%.

I don't look at PCN as a replacement of network engineering, 
it is rather an add on to guarantee service quality of 
admitted users by stopping admission of new traffic once 
engineering reaches its limits. Under regular operational 
conditions.

If someone now answers to this mail: uhh, just that - easy!
Then lets move this easy thing to WGLC. Now. I can't see 
that.

If the PCN WG indeed has completely different aims, then 
I'm sorry for bothering you with my mails (but I wonder 
whether I'm the one having gotten things wrong).

By the way, I'm happy with the progress visible in the 
questions you / the WG has formulated. That looks like a 
constructive approach.

Regards,

Rudiger

| -----Original Message-----
| From: Steven Blake [mailto:[email-masked]] 
| Sent: Tuesday, March 18, 2008 3:19 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
| 
| On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote:
| 
| > 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.
| 
| Ruediger,
| 
| If I follow this comment to its logical conclusion, then PCN 
| is superfluous in this network.  Is that what you are trying to say?
| 
| 
| Regards,
| 
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven Blake                <[email-masked]>
| Ericsson/Redback Networks               +1 919-472-9913
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 12:37:51 +0100

Hi Rudeiger

What I am proposing is how to achieve a robust/stable PCN operation 
when the PCN domain uses ECMP routing and when a catastrophic event occurs.

Best regards,
Georgios

> Behalf Of Geib, Ruediger
> Sent: woensdag 19 maart 2008 11:37
> To: [email-masked]
> Cc: [email-masked]
> what Georgios is proposing is to optimise PCN so that it 
> works properly if a catastrophic event coincides with a 
> misconfigured router. 
> 
> operational conditions (which cover planned outages and 
> expectable failures). The telephony or streaming services 
> offered to our customers should experience a minimised 
> network impact on the Quality of Experience perceived by the 
> consumers under regular operational conditions. This includes 
> the creation of a "Network Busy Indication", which however is 
> a rare event. So my position on what PCN should be optimised 
> relaxed for IP networks, but I don't think the customers of 
> my company should experience the consequences of PCN 
> engineering reaches its limits. Under regular operational conditions.
> 
> Then lets move this easy thing to WGLC. Now. I can't see that.
> 
> If the PCN WG indeed has completely different aims, then I'm 
> sorry for bothering you with my mails (but I wonder whether 
> I'm the one having gotten things wrong).
> 
> | If I follow this comment to its logical conclusion, then PCN is 
> | superfluous in this network.  Is that what you are trying to say?
> | 
> | 
> | Regards,
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Mar 2008 13:06:05 +0100

Hi Georgios,

with how many operator representatives involved into backbone 
traffic engineering including activation of ECMP did you 
talk prior to proposing your solution on this mailing list?  

Regards,

Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[email-masked]] 
| Sent: Wednesday, March 19, 2008 12:38 PM
| To: Geib, Rüdiger; [email-masked]
| Cc: [email-masked]
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| Hi Rudeiger
| 
| What I am proposing is how to achieve a robust/stable PCN 
| operation when the PCN domain uses ECMP routing and when a 
| catastrophic event occurs.
| 
| Best regards,
| Georgios
| 
| 
| 
|  
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of 
| > Geib, Ruediger
| > Sent: woensdag 19 maart 2008 11:37
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > Steven,
| > 
| > what Georgios is proposing is to optimise PCN so that it works 
| > properly if a catastrophic event coincides with a misconfigured 
| > router.
| > 
| > If this is the main or even an important task of PCN, then 
| I waste my 
| > time here.
| > 
| > The salary I obtain monthly depends on my companies 
| backbone network 
| > providing good service to customers under regular operational 
| > conditions (which cover planned outages and expectable 
| failures). The 
| > telephony or streaming services offered to our customers should 
| > experience a minimised network impact on the Quality of Experience 
| > perceived by the consumers under regular operational 
| conditions. This 
| > includes the creation of a "Network Busy Indication", which 
| however is 
| > a rare event. So my position on what PCN should be 
| optimised for is to 
| > create this "network busy indication" for regular operational 
| > conditions, reliably and only if it is required.
| > This should be done with the least possible complexity 
| (like the least 
| > possible flow awareness, the least codepoint consumption, simple 
| > queuing/policing and measurement functions, utmost re-use 
| of allready 
| > implemented features).
| > 
| > To clarify what I mean by a rare event: a well engineered backbone 
| > creating a PCN network busy indication either during a main traffic 
| > hour or after a re-routing event. During ISDN times, engineering 
| > resulted in what Americans called 5ESS switches, aiming on 
| a network 
| > busy indication probability of (100 - 99,999%, the 5 nines). We may 
| > see that a bit more relaxed for IP networks, but I don't think the 
| > customers of my company should experience the consequences of PCN 
| > behaviour more often than in (100 - 99,x)%.
| > 
| > I don't look at PCN as a replacement of network engineering, it is 
| > rather an add on to guarantee service quality of admitted users by 
| > stopping admission of new traffic once engineering reaches 
| its limits. 
| > Under regular operational conditions.
| > 
| > If someone now answers to this mail: uhh, just that - easy!
| > Then lets move this easy thing to WGLC. Now. I can't see that.
| > 
| > If the PCN WG indeed has completely different aims, then 
| I'm sorry for 
| > bothering you with my mails (but I wonder whether I'm the 
| one having 
| > gotten things wrong).
| > 
| > By the way, I'm happy with the progress visible in the 
| questions you / 
| > the WG has formulated. That looks like a constructive approach.
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > 
| > 
| > | -----Original Message-----
| > | From: Steven Blake [mailto:[email-masked]]
| > | Sent: Tuesday, March 18, 2008 3:19 PM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
| > | 
| > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote:
| > | 
| > | > 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.
| > | 
| > | Ruediger,
| > | 
| > | If I follow this comment to its logical conclusion, then PCN is 
| > | superfluous in this network.  Is that what you are trying to say?
| > | 
| > | 
| > | Regards,
| > | 
| > | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| > | Steven Blake                <[email-masked]>
| > | Ericsson/Redback Networks               +1 919-472-9913
| > | 
| > | 
| > _______________________________________________
| > PCN mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/pcn
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 13:35:13 +0100

Hi Ruediger

It is not a new solution! What I describe are problems that are in my
opinion occuring when 
the PCN domain uses ECMP routing, AND when a catastrophic event occurs AND
when marked 
packets are preferentially dropped.
The only thing that I am trying to say, is PLEASE DO NOT mandate the
preferentially 
dropping of  marked packets, such that we can avoid such difficult and nasty
problems.

I am not proposing here another solution.

Best regards,
Georgios 

> Sent: woensdag 19 maart 2008 13:06
> traffic engineering including activation of ECMP did you talk 
> prior to proposing your solution on this mailing list?  
> 
> Regards,
> 
> Rudiger
> 
> 
> | What I am proposing is how to achieve a robust/stable PCN operation 
> | when the PCN domain uses ECMP routing and when a catastrophic event 
> | occurs.
> | 
> | Best regards,
> | Georgios
> | 
> | 
> | 
> |  
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Mar 2008 14:17:29 +0100

Hi Georgios,

could you give us an estimate of the propability that this problem 
occurs? How often within a year?

Regards,

Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[email-masked]] 
| Sent: Wednesday, March 19, 2008 1:35 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| 
|  Hi Ruediger
| 
| It is not a new solution! What I describe are problems that 
| are in my opinion occuring when the PCN domain uses ECMP 
| routing, AND when a catastrophic event occurs AND when marked 
| packets are preferentially dropped.
| The only thing that I am trying to say, is PLEASE DO NOT 
| mandate the preferentially dropping of  marked packets, such 
| that we can avoid such difficult and nasty problems.
| 
| I am not proposing here another solution.
| 
| 
| Best regards,
| Georgios 
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: woensdag 19 maart 2008 13:06
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > Hi Georgios,
| > 
| > with how many operator representatives involved into 
| backbone traffic 
| > engineering including activation of ECMP did you talk prior to 
| > proposing your solution on this mailing list?
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > 
| > | -----Original Message-----
| > | From: Georgios Karagiannis [mailto:[email-masked]]
| > | Sent: Wednesday, March 19, 2008 12:38 PM
| > | To: Geib, Rüdiger; [email-masked]
| > | Cc: [email-masked]
| > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > | 
| > | Hi Rudeiger
| > | 
| > | What I am proposing is how to achieve a robust/stable PCN 
| operation 
| > | when the PCN domain uses ECMP routing and when a 
| catastrophic event 
| > | occurs.
| > | 
| > | Best regards,
| > | Georgios
| > | 
| > | 
| > | 
| > |  
| > | 
| > | > -----Original Message-----
| > | > From: [email-masked] [mailto:[email-masked]] On
| > | Behalf Of
| > | > Geib, Ruediger
| > | > Sent: woensdag 19 maart 2008 11:37
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > Subject: Re: [PCN] Concensus questions from Thursday's 
| PCN meeting
| > | > 
| > | > Steven,
| > | > 
| > | > what Georgios is proposing is to optimise PCN so that it works 
| > | > properly if a catastrophic event coincides with a misconfigured 
| > | > router.
| > | > 
| > | > If this is the main or even an important task of PCN, then
| > | I waste my
| > | > time here.
| > | > 
| > | > The salary I obtain monthly depends on my companies
| > | backbone network
| > | > providing good service to customers under regular operational 
| > | > conditions (which cover planned outages and expectable
| > | failures). The
| > | > telephony or streaming services offered to our customers should 
| > | > experience a minimised network impact on the Quality of
| > Experience
| > | > perceived by the consumers under regular operational
| > | conditions. This
| > | > includes the creation of a "Network Busy Indication", which
| > | however is
| > | > a rare event. So my position on what PCN should be
| > | optimised for is to
| > | > create this "network busy indication" for regular operational 
| > | > conditions, reliably and only if it is required.
| > | > This should be done with the least possible complexity
| > | (like the least
| > | > possible flow awareness, the least codepoint 
| consumption, simple 
| > | > queuing/policing and measurement functions, utmost re-use
| > | of allready
| > | > implemented features).
| > | > 
| > | > To clarify what I mean by a rare event: a well engineered
| > backbone
| > | > creating a PCN network busy indication either during a
| > main traffic
| > | > hour or after a re-routing event. During ISDN times, 
| engineering 
| > | > resulted in what Americans called 5ESS switches, aiming on
| > | a network
| > | > busy indication probability of (100 - 99,999%, the 5
| > nines). We may
| > | > see that a bit more relaxed for IP networks, but I don't
| > think the
| > | > customers of my company should experience the 
| consequences of PCN 
| > | > behaviour more often than in (100 - 99,x)%.
| > | > 
| > | > I don't look at PCN as a replacement of network
| > engineering, it is
| > | > rather an add on to guarantee service quality of admitted
| > users by
| > | > stopping admission of new traffic once engineering reaches
| > | its limits. 
| > | > Under regular operational conditions.
| > | > 
| > | > If someone now answers to this mail: uhh, just that - easy!
| > | > Then lets move this easy thing to WGLC. Now. I can't see that.
| > | > 
| > | > If the PCN WG indeed has completely different aims, then
| > | I'm sorry for
| > | > bothering you with my mails (but I wonder whether I'm the
| > | one having
| > | > gotten things wrong).
| > | > 
| > | > By the way, I'm happy with the progress visible in the
| > | questions you /
| > | > the WG has formulated. That looks like a constructive approach.
| > | > 
| > | > Regards,
| > | > 
| > | > Rudiger
| > | > 
| > | > 
| > | > 
| > | > | -----Original Message-----
| > | > | From: Steven Blake [mailto:[email-masked]]
| > | > | Sent: Tuesday, March 18, 2008 3:19 PM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [email-masked]
| > | > | Subject: Re: [PCN] Concensus questions from Thursday's
| > PCN meeting
| > | > | 
| > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote:
| > | > | 
| > | > | > 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.
| > | > | 
| > | > | Ruediger,
| > | > | 
| > | > | If I follow this comment to its logical conclusion, 
| then PCN is 
| > | > | superfluous in this network.  Is that what you are
| > trying to say?
| > | > | 
| > | > | 
| > | > | Regards,
| > | > | 
| > | > | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| > | > | Steven Blake                <[email-masked]>
| > | > | Ericsson/Redback Networks               +1 919-472-9913
| > | > | 
| > | > | 
| > | > _______________________________________________
| > | > PCN mailing list
| > | > [email-masked]
| > | > https://www.ietf.org/mailman/listinfo/pcn
| > | > 
| > | 
| > | 
| > | 
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 14:21:11 +0100

Hi Ruediger

I do not know, but when such an event occurs, what are then the costs
involved associated with the financial losses 
and customer losses for an operator of a large network with a huge number of
subscribers?

Best regards,
Georgios

> Sent: woensdag 19 maart 2008 14:17
> could you give us an estimate of the propability that this 
> problem occurs? How often within a year?
> 
> Regards,
> 
> Rudiger
>  
> 
> are in my 
> | opinion occuring when the PCN domain uses ECMP routing, AND when a 
> | catastrophic event occurs AND when marked packets are 
> preferentially 
> | dropped.
> mandate the 
> | preferentially dropping of  marked packets, such that we can avoid 
> | such difficult and nasty problems.
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Mar 2008 14:41:38 +0100

Hi Georgios,

I assume the costs to marginal as compared to the expenditure 
required to avoid these losses. We face tough regulation and 
can't stay in business if we engineer networks for resilience 
during catastrophic outages. These times are gone.

During catastrophic outages, my operational staff will require 
good OAM tools to enable return to bearable operation as soon 
as possible. To me, OAM is the only section in PCN drafts 
I'd like to be addressed to deal with catastrophic outages.

Regards

Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[email-masked]] 
| Sent: Wednesday, March 19, 2008 2:21 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| Hi Ruediger
| 
| I do not know, but when such an event occurs, what are then 
| the costs involved associated with the financial losses and 
| customer losses for an operator of a large network with a 
| huge number of subscribers?
| 
| Best regards,
| Georgios
| 
| 
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: woensdag 19 maart 2008 14:17
| > To: [email-masked]
| > Cc: [email-masked]
| > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > Hi Georgios,
| > 
| > could you give us an estimate of the propability that this problem 
| > occurs? How often within a year?
| > 
| > Regards,
| > 
| > Rudiger
| >  
| > 
| > | -----Original Message-----
| > | From: Georgios Karagiannis [mailto:[email-masked]]
| > | Sent: Wednesday, March 19, 2008 1:35 PM
| > | To: Geib, Rüdiger
| > | Cc: [email-masked]
| > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > | 
| > | 
| > |  Hi Ruediger
| > | 
| > | It is not a new solution! What I describe are problems that
| > are in my
| > | opinion occuring when the PCN domain uses ECMP routing, 
| AND when a 
| > | catastrophic event occurs AND when marked packets are
| > preferentially
| > | dropped.
| > | The only thing that I am trying to say, is PLEASE DO NOT
| > mandate the
| > | preferentially dropping of  marked packets, such that we 
| can avoid 
| > | such difficult and nasty problems.
| > | 
| > | I am not proposing here another solution.
| > | 
| > | 
| > | Best regards,
| > | Georgios
| > | 
| > | > -----Original Message-----
| > | > From: Geib, Ruediger [mailto:[email-masked]]
| > | > Sent: woensdag 19 maart 2008 13:06
| > | > To: [email-masked]
| > | > Cc: [email-masked]
| > | > Subject: RE: [PCN] Concensus questions from Thursday's 
| PCN meeting
| > | > 
| > | > Hi Georgios,
| > | > 
| > | > with how many operator representatives involved into
| > | backbone traffic
| > | > engineering including activation of ECMP did you talk prior to 
| > | > proposing your solution on this mailing list?
| > | > 
| > | > Regards,
| > | > 
| > | > Rudiger
| > | > 
| > | > 
| > | > | -----Original Message-----
| > | > | From: Georgios Karagiannis [mailto:[email-masked]]
| > | > | Sent: Wednesday, March 19, 2008 12:38 PM
| > | > | To: Geib, Rüdiger; [email-masked]
| > | > | Cc: [email-masked]
| > | > | Subject: RE: [PCN] Concensus questions from Thursday's
| > PCN meeting
| > | > | 
| > | > | Hi Rudeiger
| > | > | 
| > | > | What I am proposing is how to achieve a robust/stable PCN
| > | operation
| > | > | when the PCN domain uses ECMP routing and when a
| > | catastrophic event
| > | > | occurs.
| > | > | 
| > | > | Best regards,
| > | > | Georgios
| > | > | 
| > | > | 
| > | > | 
| > | > |  
| > | > | 
| > | > | > -----Original Message-----
| > | > | > From: [email-masked] [mailto:[email-masked]] On
| > | > | Behalf Of
| > | > | > Geib, Ruediger
| > | > | > Sent: woensdag 19 maart 2008 11:37
| > | > | > To: [email-masked]
| > | > | > Cc: [email-masked]
| > | > | > Subject: Re: [PCN] Concensus questions from Thursday's
| > | PCN meeting
| > | > | > 
| > | > | > Steven,
| > | > | > 
| > | > | > what Georgios is proposing is to optimise PCN so that
| > it works
| > | > | > properly if a catastrophic event coincides with a
| > misconfigured
| > | > | > router.
| > | > | > 
| > | > | > If this is the main or even an important task of PCN, then
| > | > | I waste my
| > | > | > time here.
| > | > | > 
| > | > | > The salary I obtain monthly depends on my companies
| > | > | backbone network
| > | > | > providing good service to customers under regular 
| operational 
| > | > | > conditions (which cover planned outages and expectable
| > | > | failures). The
| > | > | > telephony or streaming services offered to our
| > customers should
| > | > | > experience a minimised network impact on the Quality of
| > | > Experience
| > | > | > perceived by the consumers under regular operational
| > | > | conditions. This
| > | > | > includes the creation of a "Network Busy Indication", which
| > | > | however is
| > | > | > a rare event. So my position on what PCN should be
| > | > | optimised for is to
| > | > | > create this "network busy indication" for regular 
| operational 
| > | > | > conditions, reliably and only if it is required.
| > | > | > This should be done with the least possible complexity
| > | > | (like the least
| > | > | > possible flow awareness, the least codepoint
| > | consumption, simple
| > | > | > queuing/policing and measurement functions, utmost re-use
| > | > | of allready
| > | > | > implemented features).
| > | > | > 
| > | > | > To clarify what I mean by a rare event: a well engineered
| > | > backbone
| > | > | > creating a PCN network busy indication either during a
| > | > main traffic
| > | > | > hour or after a re-routing event. During ISDN times,
| > | engineering
| > | > | > resulted in what Americans called 5ESS switches, aiming on
| > | > | a network
| > | > | > busy indication probability of (100 - 99,999%, the 5
| > | > nines). We may
| > | > | > see that a bit more relaxed for IP networks, but I don't
| > | > think the
| > | > | > customers of my company should experience the
| > | consequences of PCN
| > | > | > behaviour more often than in (100 - 99,x)%.
| > | > | > 
| > | > | > I don't look at PCN as a replacement of network
| > | > engineering, it is
| > | > | > rather an add on to guarantee service quality of admitted
| > | > users by
| > | > | > stopping admission of new traffic once engineering reaches
| > | > | its limits. 
| > | > | > Under regular operational conditions.
| > | > | > 
| > | > | > If someone now answers to this mail: uhh, just that - easy!
| > | > | > Then lets move this easy thing to WGLC. Now. I 
| can't see that.
| > | > | > 
| > | > | > If the PCN WG indeed has completely different aims, then
| > | > | I'm sorry for
| > | > | > bothering you with my mails (but I wonder whether I'm the
| > | > | one having
| > | > | > gotten things wrong).
| > | > | > 
| > | > | > By the way, I'm happy with the progress visible in the
| > | > | questions you /
| > | > | > the WG has formulated. That looks like a constructive
| > approach.
| > | > | > 
| > | > | > Regards,
| > | > | > 
| > | > | > Rudiger
| > | > | > 
| > | > | > 
| > | > | > 
| > | > | > | -----Original Message-----
| > | > | > | From: Steven Blake [mailto:[email-masked]]
| > | > | > | Sent: Tuesday, March 18, 2008 3:19 PM
| > | > | > | To: Geib, Rüdiger
| > | > | > | Cc: [email-masked]
| > | > | > | Subject: Re: [PCN] Concensus questions from Thursday's
| > | > PCN meeting
| > | > | > | 
| > | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote:
| > | > | > | 
| > | > | > | > 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.
| > | > | > | 
| > | > | > | Ruediger,
| > | > | > | 
| > | > | > | If I follow this comment to its logical conclusion,
| > | then PCN is
| > | > | > | superfluous in this network.  Is that what you are
| > | > trying to say?
| > | > | > | 
| > | > | > | 
| > | > | > | Regards,
| > | > | > | 
| > | > | > | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| > | > | > | Steven Blake                <[email-masked]>
| > | > | > | Ericsson/Redback Networks               +1 919-472-9913
| > | > | > | 
| > | > | > | 
| > | > | > _______________________________________________
| > | > | > PCN mailing list
| > | > | > [email-masked]
| > | > | > https://www.ietf.org/mailman/listinfo/pcn
| > | > | > 
| > | > | 
| > | > | 
| > | > | 
| > | > 
| > | 
| > | 
| > | 
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 14:49:37 -0000

Georgios

- it would have been very useful to have raised this last week at IETF. Progress is so much easier face to face.
- are you talking about admission or termination? I got confused; your emails didn't seem consistent.
- I haven't read all the emails in detail, but I don't understand what are you saying that's different from http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt ?  eg Table 8.1 extract:
    -------------------------------------------------------------------|
   |Comparison    |      SM       |       3SM        |      CL         |
   |criteria      |               |                  |                 |
   |--------------------------------------------------------------------
   |-------------------------------------------------------------------|
   |ECMP support  |no;   only     |     yes          | no;  but full   |
   |for           |partial support|                  | support with    |
   |Termination   |with additional|                  | additional      |
   |              | complexity at |                  | complexity at   |
   |              | the edge +    |                  | the edge +      |
   |              | signaling flow|                  | plus signalling |
   |              | flow IDs from |                  | flow IDs from   |
   |              | egress to     |                  | egress to       |
   |              | ingress       |                  | ingress         |
   |-------------------------------------------------------------------|
   |ECMP support  |no w/out probes| no w/out probing | no w/out probing|
   |for Admission |yes with probes| yes with probing | yes with probing|
   |              |but needs many |(needs one probe, |(needs one probe,|
   |              |probes; use of |can use RSVP as   | can use RSVP    |
   |              |RSVP as probes |probe)            | as probe)       |
   |              |not understood |                  |                 |
   |-------------------------------------------------------------------|

- you seem to be saying that preferential dropping of excess-rate-marking pkts in your view can lead to problems - and proposing instead random dropping, but saying this can also lead to the same problem (but maybe not as often). Is that right?

best wishes,
phil

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Geib, Ruediger
> Sent: 19 March 2008 13:42

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 15:56:29 +0100

Hi Phil

Actually the problem is that when ECMP routing is used, then 
the stability/robustness during a catastrophic event (thus flow termination)
of the PCN domain operation is decreased.  Therefore, we should not mandate 
to preferentially drop marked packets.

Please note that I have identified this problem after the 
IETF meeting.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: woensdag 19 maart 2008 15:50
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> - it would have been very useful to have raised this last 
> week at IETF. Progress is so much easier face to face.
> - are you talking about admission or termination? I got 
> confused; your emails didn't seem consistent.
> - I haven't read all the emails in detail, but I don't 
> understand what are you saying that's different from 
> http://www.ietf.org/internet-drafts/draft-charny-pcn-compariso
n-00.txt ?  eg Table 8.1 extract:
>    |criteria      |               |                  |        
>    |              | ingress       |                  | 
> ingress         |
>    |              |not understood |                  |        
> - you seem to be saying that preferential dropping of 
> excess-rate-marking pkts in your view can lead to problems - 
> and proposing instead random dropping, but saying this can 
> also lead to the same problem (but maybe not as often). Is that right?
> 
> best wishes,
> phil
> 
> > I assume the costs to marginal as compared to the 
> expenditure required 
> > to avoid these losses. We face tough regulation and can't stay in 
> > business if we engineer networks for resilience during catastrophic 
> > outages. These times are gone.
> > 
> > During catastrophic outages, my operational staff will require good 
> > OAM tools to enable return to bearable operation as soon as 
> possible. 
> > To me, OAM is the only section in PCN drafts I'd like to be 
> addressed 
> > to deal with catastrophic outages.
> > 
> > Regards
> > 
> > Rudiger
> > 
> > | I do not know, but when such an event occurs, what are then the 
> > | costs involved associated with the financial losses and customer 
> > | losses for an operator of a large network with a huge number of 
> > | subscribers?
> > |
> > | Best regards,
> > | Georgios
> > |
> > |
> > |
> > | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN 
> > | > | meeting
> > | > |
> > | > |
> > | > |  Hi Ruediger
> > | > |
> > | > | > | > From: [email-masked] 
> [mailto:[email-masked]] 
> > | > | > | > On
> > | > | > | Behalf Of
> > | > | > | > includes the creation of a "Network Busy Indication", 
> > | > | > | > which
> > | > | > | however is
> > | > | > | > | > in the situation you describe, packet losses occur. 
> > | > | > | > | > This
> > | > | > | > | > in bad press, as the customers using PCN based 
> > | > | > | > | > services
> > | > | > | > | > In this situation it doesn't matter whether or not 
> > | > | > | > | > ECMP
> > | > | > | > is deployed
> > | > | > | > | > important event is: packet losses occur (in one of 
> > | > | > | > | > your
> > | > | > | examples
> > | > | > | > | > but termination was fair." I can only recall having 
> > | > | > | > | > seen
> > | > | > | > the first
> > | > | > | > | > part.
> > | > | > | > | >

---

From: Steven Blake <[email-masked]>
Date: Wed, 19 Mar 2008 11:16:42 -0400

Georgios,

Let me try to paraphrase the scenario you are describing:

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

Does this description accurately capture your scenario?

Regards,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 16:24:37 +0100

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

Best regards,
Georgios

> From: Steven Blake [mailto:[email-masked]] 
> Sent: woensdag 19 maart 2008 16:17
> To: Georgios Karagiannis
> Cc: [email-masked]

---

From: Steven Blake <[email-masked]>
Date: Wed, 19 Mar 2008 11:42:37 -0400

> 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,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 16:49:09 +0100

Hi Steven

Okay, I will have to spend some time on this!

Best regards,
Georgios

> Sent: woensdag 19 maart 2008 16:43
> To: Georgios Karagiannis
> Cc: [email-masked]
> >   the same ingress-egress-aggregate that will be unmarked.>> Marked 
> > packets are
> >   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,
>

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 16:07:05 -0000

Georgios,

I notice you refer to CLE below. Note that for termination the relevant
parameter is the Sustainable rate, that is the rate of unmarked pkts
(or, if SM being used, this rate is multiplied by the domain-wide
parameter U). 

phil

> Sent: 19 March 2008 15:49
> To: 'Steven Blake'
> Cc: [email-masked]

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Mar 2008 17:10:02 +0100

Hi Phil

But in order to trigger the admission control and flow termination, 
the situation CLE > 1% has to be first triggered.

Best regards,
Georgios

> Sent: woensdag 19 maart 2008 17:07
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I notice you refer to CLE below. Note that for termination 
> the relevant parameter is the Sustainable rate, that is the 
> rate of unmarked pkts (or, if SM being used, this rate is 
> multiplied by the domain-wide parameter U). 
> 
> phil
> 
> > > 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 
> > > 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,
> > >

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 16:15:48 -0000

Ok - you'd forgotten to remind us of that!
Note that you're making the assumption of SM [for CL (is excess rate
marking just for termination) the requirement is to see one mark.]

> Sent: 19 March 2008 16:10
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Cc: [email-masked]
> > > > >   router(s). As a consequence, not enough marked traffic
arrives
> > at

---

From: <[email-masked]>
Date: Wed, 19 Mar 2008 16:19:46 -0000

Hi Georgios,

Just trying to get my head round this scenario a bit better. I take it
you are envisaging the severely congested path having several points of
congestion so that at some routers early on the path packets are being
marked and at some point later on the path some packets are then having
to be dropped?

I have always sort of assumed (quite possibly wrongly) that the point at
which routers are so congested they need to be doing preferential drop
is significantly above the termination threshold and thus even with the
drop there should still be a strong enough termination signal reaching
the egress...

Toby 

> > > > >   router(s). As a consequence, not enough marked 
> traffic arrives
> > at

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 19 Mar 2008 12:42:50 -0400

Georgios,
 
Please see below:

> Sent: Wednesday, March 19, 2008 11:25 AM
> To: 'Steven Blake'
> Cc: [email-masked]
> - There is an ingress-egress aggregate whose traffic is split 
> across multiple paths via ECMP.
> - <<Due to the ECMP routing not congested paths will forward 
> packets belonging to
>   the same ingress-egress-aggregate that will be unmarked.>> 

But these rerouted and previously unmarked packets will be marked on the
congested interface, would they not?

Anna 

> Marked packets are
> arrives at the egress router to drive the CLE for the 
> ingress-egress aggregate above the threshold needed to 
> trigger a response (termination, say).
> 
> 
> Best regards,
> Georgios
> 
> 
> 
>  
> 
> arrives at

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 19 Mar 2008 16:33:22 -0400

Hi Georgios,

I must confess that I do not really see the examples you are presenting
as arguments for having (or for that matter not having) preferential
drop that I can understand.  While I may certainly be missing the points
you are making, I want to point out that quite regardless of all these
examples, if all you are trying to achieve is that the standard does not
force a particular preferential drop policy,  I believe the current
proposal already does that, as it has a SHOULD, not a MUST in the
preferential drop clause.  So perhaps that means that this does not need
to be argued so intensely?

On the examples themselves, I also reread your recent emails (and
assuming I understand correctly which of the multiple examples you
actually are referring to in your exchange with Steve and Phil), I
realized that the problem you are referring to may have nothing to do
with dropping marked or unmarked packets.  It has simply to do with a
well-recognized problem of dilution of marking signal received by the
egress in the case when traffic of a given on any particular ECMP path
is drastically smaller than the combined traffic of this IEA on other
(uncongested) ECMP paths.

Let us consider what seems to be a rather aggressive example.  Let us
assume that we have a bottleneck link, and - for the moment- assume it
is the only bottleneck in the network, so in fact there is no marking
occurring anywhere but on this link.  Just using this assumption to
demonstrate that marking preference is irrelevant for the problem you
seem to be referring to.

Suppose now you have an IEA on this link and you have other ECMP paths
shared by this aggregate.  Let us assume that the total amount of
traffic of this IEA on the link of interest is K. Suppose now that the
total traffic on the IEA aggregate is M*K,  and assume that M is large.
I doubt it will ever be more than 16 - so let us take 16 for the moment.

Assume now that the link in question has a very high overload.  I would
assume is 5X overload is quite large (Rudiger I am sure will agree :)),
so let us just take 5.  That means that approximately 80% of traffic of
this IEA is dropped at the input, so we end up having only 0.2K actually
leaving this link.  

Now assume that the admission threshold is set to 80% of your link
(picking a high value to make things worse). And assume we are running
SM - or LC-PCN (or whatever other alg that uses excess marking).  Now
that means that ~20% of our remaining traffic of the IEA aggregate gets
marked. The egress now sees:  0.2*0.2K=0.04K of marked traffic and
(M-1)K+0.2*0.8K unmarked traffic.  The CLE now is now ~0.04K/15K~0.002.
If you need a larger CLE than that, then neither SM, nor, for that
matter, LC-PCN, would trigger admission stop on that aggregate (without
probing added).

As it happens, the CLE setting with which the vast majority of SM
simulations were done was actually 0.001 (less than the above) - so in
fact for this particular set of the parameters (even though I think
quite aggressive)  this would not actually cause SM a problem. 

But obviously if you increase either M to be greater than 16 or the
overload on the link to be even greater than 5 times the links capacity,
you may indeed get into the situation when the actual amount of marked
traffic that gets through to the egress is small compared to the total
rate of other uncongested ECMP paths for this aggregate. While I
personally believe that the parameters I chose are probably overly
conservative and in practice things will look dramatically better -
nevertheless in principle this problem does in fact exist in theory.  In
for sufficiently large overloads and ratio M this problem theoretically
exists even for threshold marking - although you would need even more
aggressive parameters to see the problem then.

The point however is that all of this seems to have little to do with
what you prefer to drop. In particular, in the example above there were
no packets at all that were marked before the bottleneck.  The same
example will remain even if in fact some packets were previously marked,
and all of them were dropped at the entry to the bottleneck.  What
matters is what percentage of the traffic gets through the tightest
bottleneck and how much of it gets marked at *this* bottleneck.  So I
just can't get why all of these examples show the point about
preferential drop you are trying to make...

Anna 

> Sent: Wednesday, March 19, 2008 12:10 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> But in order to trigger the admission control and flow 
> termination, the situation CLE > 1% has to be first triggered.
> 
> Best regards,
> Georgios
>  
> 
> > I notice you refer to CLE below. Note that for termination the 
> > relevant parameter is the Sustainable rate, that is the rate of 
> > unmarked pkts (or, if SM being used, this rate is multiplied by the 
> > domain-wide parameter U).
> > 
> > phil
> > 
> > Marked

---

From: "Wei Gengyu" <[email-masked]>
Date: Thu, 20 Mar 2008 14:05:28 +0800

Hi, all,

No matter what you want to express,
the explanation of your assumed model is incorrect.

Also, see comments inline.

Gengyu

----- Original Message ----- 
From: "Anna Charny (acharny)" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 20, 2008 4:33 AM
Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting

> this IEA is dropped at the input, so we end up having only 0.2K actually

It is wrong.
You can not get 0.2K ACTUALLY!
And because of this, the following calculation is inredible.

> matter, LC-PCN, would trigger admission stop on that aggregate (without

Strongly suggest people refer to textbook about throughput performance of 
congested node.
The throughput of the congested will be different in case the input is 5*X 
and 16*X.

Gengyu

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 20 Mar 2008 10:00:07 +0100

Hi Anna

 Please see in line!

> From: Anna Charny (acharny) [mailto:[email-masked]] 
> Sent: woensdag 19 maart 2008 17:43
> To: Georgios Karagiannis; Steven Blake
> Cc: [email-masked]
> But these rerouted and previously unmarked packets will be 
> marked on the congested interface, would they not?

Georgios: If they are not passing throug the severely congested node, they
will not be marked!

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 20 Mar 2008 10:36:21 +0100

Hi Phil

Indeed I am refering to SM!

Best regards,
Georgios 

> Sent: woensdag 19 maart 2008 17:16
> Note that you're making the assumption of SM [for CL (is 
> excess rate marking just for termination) the requirement is 
> to see one mark.]
> 
> > > > > > above the threshold needed to trigger a response 
> (termination,
> > > say).
> > > > >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 20 Mar 2008 10:42:44 +0100

Hi Anna

What I was trying to say is that we should not mandate to preferential drop
marked packets,
because then the PCN domain operation can become more instable than in the
situations that either 
random dropping of marked and unmmarked packets is used or when unmarked
packets are preferentially dropped.

I think that the method of dropping should not be mandated.

Best regards,
Georgios

> Sent: woensdag 19 maart 2008 21:33
> To: Georgios Karagiannis; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> I must confess that I do not really see the examples you are 
> presenting as arguments for having (or for that matter not 
> having) preferential drop that I can understand.  While I may 
> certainly be missing the points you are making, I want to 
> point out that quite regardless of all these examples, if all 
> you are trying to achieve is that the standard does not force 
> a particular preferential drop policy,  I believe the current 
> proposal already does that, as it has a SHOULD, not a MUST in 
> the preferential drop clause.  So perhaps that means that 
> this does not need to be argued so intensely?
> 
> On the examples themselves, I also reread your recent emails 
> (and assuming I understand correctly which of the multiple 
> examples you actually are referring to in your exchange with 
> Steve and Phil), I realized that the problem you are 
> referring to may have nothing to do with dropping marked or 
> unmarked packets.  It has simply to do with a well-recognized 
> problem of dilution of marking signal received by the egress 
> in the case when traffic of a given on any particular ECMP 
> path is drastically smaller than the combined traffic of this 
> IEA on other
> Let us consider what seems to be a rather aggressive example. 
>  Let us assume that we have a bottleneck link, and - for the 
> moment- assume it is the only bottleneck in the network, so 
> in fact there is no marking occurring anywhere but on this 
> link.  Just using this assumption to demonstrate that marking 
> preference is irrelevant for the problem you seem to be referring to.
> 
> Suppose now you have an IEA on this link and you have other 
> ECMP paths shared by this aggregate.  Let us assume that the 
> total amount of traffic of this IEA on the link of interest 
> is K. Suppose now that the total traffic on the IEA aggregate 
> is M*K,  and assume that M is large.
> Assume now that the link in question has a very high 
> overload.  I would assume is 5X overload is quite large 
> (Rudiger I am sure will agree :)), so let us just take 5.  
> That means that approximately 80% of traffic of this IEA is 
> dropped at the input, so we end up having only 0.2K actually 
> leaving this link.  
> 
> Now assume that the admission threshold is set to 80% of your 
> link (picking a high value to make things worse). And assume 
> we are running SM - or LC-PCN (or whatever other alg that 
> uses excess marking).  Now that means that ~20% of our 
> remaining traffic of the IEA aggregate gets marked. The 
> egress now sees:  0.2*0.2K=0.04K of marked traffic and 
> If you need a larger CLE than that, then neither SM, nor, for 
> that matter, LC-PCN, would trigger admission stop on that 
> aggregate (without probing added).
> 
> As it happens, the CLE setting with which the vast majority 
> of SM simulations were done was actually 0.001 (less than the 
> above) - so in fact for this particular set of the parameters 
> (even though I think quite aggressive)  this would not 
> actually cause SM a problem. 
> 
> But obviously if you increase either M to be greater than 16 
> or the overload on the link to be even greater than 5 times 
> the links capacity, you may indeed get into the situation 
> when the actual amount of marked traffic that gets through to 
> the egress is small compared to the total rate of other 
> uncongested ECMP paths for this aggregate. While I personally 
> believe that the parameters I chose are probably overly 
> conservative and in practice things will look dramatically 
> better - nevertheless in principle this problem does in fact 
> exist in theory.  In for sufficiently large overloads and 
> ratio M this problem theoretically exists even for threshold 
> marking - although you would need even more aggressive 
> parameters to see the problem then.
> 
> The point however is that all of this seems to have little to 
> do with what you prefer to drop. In particular, in the 
> example above there were no packets at all that were marked 
> before the bottleneck.  The same example will remain even if 
> in fact some packets were previously marked, and all of them 
> were dropped at the entry to the bottleneck.  What matters is 
> what percentage of the traffic gets through the tightest 
> bottleneck and how much of it gets marked at *this* 
> bottleneck.  So I just can't get why all of these examples 
> show the point about preferential drop you are trying to make...
> 
> Anna 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 20 Mar 2008 12:18:05 +0100

Hi Gengyu, hi Anna 

please don't argue over this. It doesn't matter whether it is 80%, 90% 
or 70% loss. Voice customers will hang up and people watching a video 
will turn off. This will reduce the catastrophic overload within 
10-60 seconds. Standard operation can resume then to the extent 
possible after a catastrophy. 

Anna>  Assume now that the link in question has a very high overload.  I 
| > would assume is 5X overload is quite large (Rudiger I am sure will 
| > agree :)), so let us just take 5.  That means that approximately 80% 
| > of traffic of this IEA is dropped at the input, so we end up having 
| > only 0.2K actually leaving this link.
| 
Genyu| It is wrong.
| You can not get 0.2K ACTUALLY!
| And because of this, the following calculation is inredible.

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

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 20 Mar 2008 07:49:14 -0400

Hi Gengyu,

Can you clarify please?

If you have 5x congestion overall on a link, (which means you have 5
times more traffic than your link can carry),  would you not expect to
lose 4/5 of your traffic?

You may have misunderstood that in this example the IEA in question
itself only has K amount of traffic arriving to this link, not 16K. I am
assuming then that approximately 4/5 of k will be lost. This clearly
assumes that the loss is proportionally spread among all IEAs, which is
indeed not always the case - but seems like a fair approximation for
this level of discussion.

If I am missing something fundamental, can you explain? 

Anna 

> From: Wei Gengyu [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 2:05 AM
> To: Anna Charny (acharny); Georgios Karagiannis; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> >  Assume now that the link in question has a very high overload.  I 
> > would assume is 5X overload is quite large (Rudiger I am sure will 
> > agree :)), so let us just take 5.  That means that 
> approximately 80% 
> > of traffic of this IEA is dropped at the input, so we end up having 
> > only 0.2K actually leaving this link.
> 
> It is wrong.
> > that means that ~20% of our remaining traffic of the IEA aggregate 
> > gets marked. The egress now sees:  0.2*0.2K=0.04K of marked traffic 
> > and (M-1)K+0.2*0.8K unmarked traffic.  The CLE now is now 
> ~0.04K/15K~0.002.
> > matter, LC-PCN, would trigger admission stop on that aggregate 
> > (without probing added).
> >
> >
> > Anna
> >
> 
> Strongly suggest people refer to textbook about throughput 
> performance of congested node.
> The throughput of the congested will be different in case the 
> input is 5*X and 16*X.
> 
> Gengyu 
> 
>

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 20 Mar 2008 09:27:38 -0400

Hi Ruediger,
> 
> Anna: yes, "5% congestion" is a reasonable assumption for a 
> link congested under regular network conditions for 
> engineered carrier backbones (i.e. 

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 20 Mar 2008 15:12:08 +0100

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 drop out for vacation now, will be back on 31st.

Regards,

Rudiger

| -----Original Message-----
| From: Anna Charny (acharny) [mailto:[email-masked]] 
| Sent: Thursday, March 20, 2008 2:28 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 20 Mar 2008 10:22:27 -0400

Hi Ruediger, 

> Sent: Thursday, March 20, 2008 10:12 AM
> To: Anna Charny (acharny)
> Cc: [email-masked]
> 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 

> | Subject: On pcn and overloads (was: [PCN] Concensus questions from 
> | Thursday's PCN meeting)
> | 
> | Hi Ruediger,
> | > 
> 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 
> 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
> | 
>

---

From: <[email-masked]>
Date: Thu, 20 Mar 2008 15:33:53 -0000

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

> Behalf Of Anna Charny (acharny)
> Sent: 20 March 2008 14:22
> To: Geib, Ruediger
> Cc: [email-masked]
> Subject: Re: [PCN] On pcn and overloads (was: Concensus 
> questions fromThursday's PCN meeting)
> 
> Hi Ruediger, 
> 
> 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.
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 20 Mar 2008 18:50:13 +0100

Hi Steven

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 20 Mar 2008 18:59:52 +0100

Hi Steven

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

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.

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

                                                     N -2
                                                      ---   

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

                                                        N -2
                                                        ---   

Example:

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

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

Best regards,
Georgios

---

From: <[email-masked]>
Date: Tue, 25 Mar 2008 15:07:24 -0000

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-----
> Sent: 20 March 2008 18:00
> To: 'Steven Blake'
> Cc: [email-masked]
> Thus after failure, one path failed, one path is congested and N-2
paths
Marked

---

From: Steven Blake <[email-masked]>
Date: Tue, 25 Mar 2008 11:19:44 -0400

On Thu, 2008-03-20 at 18:59 +0100, Georgios Karagiannis wrote:

[snip]

Georgios,

If I assume that C1 = C2 = C3 = C4 = C5, then

PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * C1) = 0.95 * C1

whereas

PCN_lower_threshold(2) < C1

I think you will agree that this is not a significant difference.

Regards,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Mar 2008 09:59:56 +0100

Hi Steven

Please see in line!

> Sent: dinsdag 25 maart 2008 16:20
> To: Georgios Karagiannis
> Cc: [email-masked]
> > When router is dropping marked and unmarked packets are with equal 
> > probability p:
> > 
> > 
> > Therefore, the second scheme (2) can be considered more robust and 
> > more stable then the first scheme.
> 
> Georgios,
> 

Georgios: For this example, yes, but note that not all links in the 
PCN domain will support equal bandwidth!
Consider that the following situation occurs:

C2=C3=C4=C5= 10*C1
Thenn (1) will be:

PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * 10 *C1) 
PCN_lower_thhershold (1) < C1 (0.99 - 0.4)
PCN_lower_thhershold (1) < C1 * 0.54

Whereas:

PCN_lower_threshold (2) < C1

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Mar 2008 10:49:37 +0100

Hi Steven

The comments that I have sent in the previous email cannot be clearly seen.
Please see again in line:

> Sent: woensdag 26 maart 2008 10:00
> To: 'Steven Blake'
> Cc: [email-masked]
> with equal 

Georgios: For this example, yes, but note that not all links 
in the PCN domain will support equal bandwidth!
Consider that the following situation occurs:
 
 C2=C3=C4=C5= 10*C1
 Thenn (1) will be:

 PCN_lower_thhershold (1) < C1 * 0.59

 Whereas:

 Best regards,
 Georgios

---

From: Michael Menth <[email-masked]>
Date: Tue, 01 Apr 2008 00:42:23 +0200

Hi,

sorry for being late ...

>     (Note: this question does not presume that the solution is Single

Yes, it seems necessary due to missing approved alternatives. However, I 
find the new encoding proposal in
http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html
quite appealing as it achieves both admission control and flow 
termination with a single DSCP. I think it is worthwhile to be discussed 
as an alternative for an encoding scheme requiring a single DSCP which 
seems to be our major constraint.

>     a total of three encoding states)?

Yes, it seems to allow for significantly improved PCN performance.

>     about the way forward for the standards-track PCN scheme?

Yes - after 
http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html only partly.

It seems to be consensus that
* AC based on excess rate marking with regard to the admissible rate 
cannot reliably deal with small ingress-egress aggregates in the order 
of 10 flows
* We will have many small ingress-egress aggregates in the future that 
are even smaller
http://www.ietf.org/mail-archive/web/pcn/current/msg00831.html
* FT based on excess rate marking with regard to the admissible rate 
does not reliably work with ECMP
   - FT cannot always detect when strong pre-congestion occurs 
(u*admissible rate due to signal dilution)
   - FT cannot tear down only the right flows such that the termination 
process requires several termination steps
   - This issue is a matter of traffic distribution under failure 
conditions and cannot be solved by overprovisioning unless making the 
need for FT obsolete.
* ECMP is a reality in many of today's networks to achieve fast reroute 
for ingress-egress pairs that have multiple paths.

However, I feel that there is not yet a clear idea what the standards 
track PCN with two codepoints is used for:
* admission control (AC) and flow termination (FT) based on excess 
marking with regard to an admissible rate
* only admission control with threshold marking with regard to an 
admissible rate

The new encoding proposal in
http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html
seems to allow both AC based on threshold marking and FT based on excess 
marking at the expense of requiring probe packets to support admission 
decisions.

>     http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

Yes. But it ALSO requires the option for preferential dropping of marked 
packets and an option for random drops with equal importance. As long as 
the edge behavior is not clear yet, no decision about preferential 
dropping can be made. Furthermore, packet size independent marking 
(PSIM) as described in
http://tools.ietf.org/wg/pcn/draft-menth-pcn-emft-00.txt
is useful to implement because the fairness of any flow termination 
scheme making use of marked packets to indicate flows to be terminated 
profits from this feature. Evidence for that is documented in
http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt
or
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf 

This also applies to potential improvements of SM.

>     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf
Yes.

>     described in question 4)?
Yes.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Michael Menth <[email-masked]>
Date: Tue, 01 Apr 2008 01:03:09 +0200

I mean

http://www.ietf.org/mail-archive/web/pcn/current/msg01387.html

instead of

See inline!

> http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html
I mean http://www.ietf.org/mail-archive/web/pcn/current/msg01387.html

> http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html
I mean http://www.ietf.org/mail-archive/web/pcn/current/msg01387.html

>  only partly.

---

From: <[email-masked]>
Date: Tue, 1 Apr 2008 11:02:22 +0100

> packets and an option for random drops with equal importance. 

I believe we need to decide. A standard for marking behaviour with 3
options about dropping is not acceptable. 

As long as
> is useful to implement 

suggestion in Philadelphia is that this is a SHOULD (for excess rate
marking).

because the fairness of any flow termination
> http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08
-
> PCN-MFT.pdf

---

From: Michael Menth <[email-masked]>
Date: Tue, 01 Apr 2008 17:44:04 +0200

Hi Phil,

[email-masked] wrote:
>>> Q4: Should the standards-track PCN scheme require (as a MUST
>>>       
> implement
>   
>> Yes. But it ALSO requires the option for preferential dropping of
>>     
> marked
>   

I want to point out that preferential dropping of marked packets makes 
indirect measured rate termination work well while direct measured rate 
termination does not work any more with packet loss as it would require 
preferential dropping of unmarked packets. Thus, not supporting 
preferential dropping of unmarked packets as another option already 
rules out possible edge behaviors. Therefore, this decision about 
preferential dropping is already a decision about possible edge behaviors.

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 1 Apr 2008 16:55:09 +0100

"does not work" is over-stating it, I think Michael.

But yes, which edge behaviour is most naturally supported (or which ones
are slightly less well supported) does depend on the dropping behaviour
(which we said would be a SHOULD) 

phil

> From: Michael Menth [mailto:[email-masked]]
> Sent: 01 April 2008 16:44
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]; [email-masked]