Subject: [PCN] Questions on LC-PCN draft version 01

From: "Anna Charny (acharny)" <[email-masked]>
Date: Sun, 7 Oct 2007 15:39:43 -0400

Dear authors of the LC-PCN draft,

Am I right that there has been no response yet to Phil's questions
(attached at the end) on the new version of your draft below (I checked
the pcn list and it does not seem it went there)? If the response was
sent, can you resend it please?

I have many of the same questions, and also a few additional ones.  Here
are some of them.

1) I do not understand whether pcn-lower_rate_egress and pcn_upper_rate
ingress are expressed as a fraction of the total rate (a unitless
entity, analogous to CLE) or an absolute value (in bits or bytes per
second).  The text seems to be contradictory on this point:  

on page 8 it is a fraction:   

"PCN_lower_rate_egress = predefined percentage of received PCN_marking",

while on page 13 it is an absolute rate:

"If the incoming_PCN_marking_rate is higher than a preconfigured
   PCN_lower_rate_egress, ..." where the 

(Incoming_PCN_marking_rate is clearly defined as abslolue rate on page
12: "Where the "incoming_PCN_marking_rate" is calculated as follows:
incoming_PCN_marking_rate = (received number of "PCN_marking" DSCP
during T)* N)/T;)

2) Regarding the question above, 

   * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are absolute
rates, then how do you choose that abslolute rate value, given that the
rates of ingress-egress aggregates at the same ingress may be vastly
different in magnitude?

   *if, however, pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are
ratios,  then what is the guidance of setting these ratios so that the
egress can always tell admission state from the termination state, given
that the same marking is used for admission and termination marking?
Specifically, suppose at the bottleneck pcn_lower_threshold is set to X,
and pcn_upper_threshold to aX with some a>1 (assume for example a=1.5).
How does the egress node tell between the conditions when the total pcn
traffic on the bottleneck is 1.1X (which is the state wnen admission is
needed but termination is not, - in this case (1.1X-X)/X=0.1 traffic is
pcn-marked), and the case when the total traffic on the bottleneck is
1.1aX, which is the case when termination is needed, and
(1.1ax-ax)/ax=0.1), if in both cases the ratio between marked and total
traffic is the same value 0.1?

3) On page 9, multicongestion error error is introduced, but the text is
silent on how this error is defined and what is it set to (if it is a
configuration parameter), or how it is measured (if it is something that
is being measured). Can you explain, please?

I have some more questions, including sharing those asked by Phil in the
attached message), but I will stop now, as I hope clarifications on the
above (and Phil's) questions will help understand the draft better...

Thank you in advance for clarifying all this.

Anna 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 11:27 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [PCN] LC-PCN version 01 uploaded
> 
> Anurag
> 
> Thanks for the revised draft, I can understand it much 
> better. Here are some questions /misunderstandings.
> 
> Let me summarise to make sure I understand it right.
> 
> - two encodings are used. one ('PCN-marking') is used for 
> both adm ctrl & termination to indicate the excess traffic. 
> If a PCN-interior-node is PCN-marking some pkts, then it 
> marks all other pkts with another encoding ('affected marking')
> 
> - the 'PCN-marking' algorithm has several regimes:
> * when traffic rate is below PCN-lower-rate, no pkts are marked
> * as the traffic rate climbs above the PCN-lower-rate, an 
> increasing number of pkts are marked (marking rate = excess 
> rate divided by N) [adm ctrl state]
> * at some rate (PCN-lower-rate + adm-offset-rate), then pkts 
> are marked at the same rate, even if the traffic rate climbs 
> higher [adm ctrl state]
> * when the traffic rate reaches the PCN-upper-rate, 
> additional pkts are marked (additional marking rate = excess 
> rate above PCN-upper-rate divided by N) [termination ctrl state]
> * if pkts arrive already PCN-marked, then the node measures 
> the rate of pkts already marked & works out what excess rate 
> this corresponds to, and only marks additional pkts if its 
> own excess rate is even higher. 
> * the PCN-egress-node measures the rate of PCN-marked pkts 
> and determines whether the overloaded node is in adm ctrl 
> state or termination ctrl state
> 
> 
> Questions:
> - I don't understand the point of doing PCN-marking in the adm ctrl
> state. When it comes to making an adm decision, you send a (single)
> probe pkt - if it's PCN-marked or affected-marked then you block the
> call. So when a node's in the adm ctrl state, it could just do
> affected-marking of all pkts. Wouldn't that work just as well?
> - with you current algo, imagine there are two paths through the nw: 
> A-B-X-D
> A-M-N-X-D
> If B & N are both in adm ctrl state then they both will do 
> PCN-marking.
> At the PCN-egress-node the PCN-marking rate may be high enough that it
> believes termination is needed. Are there topologies/scenarios where
> this could happen? I think your multicongestion_error 
> parameter in S3.4
> is connected to this problem; I didn't find your discussion about it
> convincing
> - the 'affected marking' is claimed to solve ECMP issues. However, the
> same affected marking is used in both adm ctrl state & 
> termination ctrl
> state - I don't think this works. Imagine that a node [node-1] on one
> path is in adm ctrl state & a node [node-2] on another path is in
> termination ctrl state. Therefore flows are terminated, and only flows
> that are being PCN-marked or affected-marked are terminated. However
> this could lead to flows being terminated that go through 
> node-1; node-2
> will still be just as badly overloaded. 
> - in the termination algorithm, S4.2.2, the "termination_offset_rate"
> factor makes no sense to me
> - the parameters PCN_lower_rate_egress & PCN_upper_rate_egress are
> expressed in the wrong units (you have conditions like
> signalled_overload_rate > PCN_lower_rate_egress; the former is a rate,
> the latter a % so some tweaking is needed to convert the latter into a
> rate)
> 
> best wishes
> 
> phil/
> 
> > -----Original Message-----
> > From: Anurag Bhargava (RL/TNT) [mailto:[email-masked]]
> > Sent: 11 September 2007 12:36
> > To: pcn
> > Subject: [PCN] LC-PCN version 01 uploaded
> > 
> > Hello,
> >  FYI - We have uploaded a new version of the PCN draft. The major
> > changes are some clarification and adopting to the 
> Architecture draft
> > terminology.
> > 
> >  "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07,
> >    <draft-westberg-pcn-load-control-01.txt>
> > 
> > Please let me know if you have any questions.
> > 
> > Thanks,
> > -Anurag Bhargava, Ph.D.
> > 
> > 
> > _______________________________________________
> > PCN mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pcn
> 
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pcn
> 

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

---

From: "Anurag Bhargava" <[email-masked]>
Date: Tue, 9 Oct 2007 10:13:38 -0500

I apologize for the delay. Please bear with me. I am compiling
clarifications to Phil's and Anna's questions. I will send them to the
list ASAP. 

BR,
-Anurag Bhargava, Ph.D.

>From: Anna Charny (acharny) [mailto:[email-masked]] 
>Sent: Sunday, October 07, 2007 3:40 PM
>To: Anurag Bhargava; Georgios Karagiannis; Lars Westberg
>Cc: [email-masked]
>Subject: Questions on LC-PCN draft version 01
>
>Am I right that there has been no response yet to Phil's 
>questions (attached at the end) on the new version of your 
>draft below (I checked the pcn list and it does not seem it 
>went there)? If the response was sent, can you resend it please?
>
>I have many of the same questions, and also a few additional 
>ones.  Here are some of them.
>
>1) I do not understand whether pcn-lower_rate_egress and 
>pcn_upper_rate ingress are expressed as a fraction of the 
>total rate (a unitless entity, analogous to CLE) or an 
>absolute value (in bits or bytes per second).  The text seems 
>to be contradictory on this point:  
>
>incoming_PCN_marking_rate = (received number of "PCN_marking" 
>DSCP during T)* N)/T;)
>
>   * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are 
>absolute rates, then how do you choose that abslolute rate 
>value, given that the rates of ingress-egress aggregates at 
>the same ingress may be vastly different in magnitude?
>
>   *if, however, pcn_lower_rate_eggress (and 
>pcn_uppre-rate_egress) are ratios,  then what is the guidance 
>of setting these ratios so that the egress can always tell 
>admission state from the termination state, given that the 
>same marking is used for admission and termination marking?
>Specifically, suppose at the bottleneck pcn_lower_threshold is 
>set to X, and pcn_upper_threshold to aX with some a>1 (assume 
>for example a=1.5).
>How does the egress node tell between the conditions when the 
>total pcn traffic on the bottleneck is 1.1X (which is the 
>state wnen admission is needed but termination is not, - in 
>this case (1.1X-X)/X=0.1 traffic is pcn-marked), and the case 
>when the total traffic on the bottleneck is 1.1aX, which is 
>the case when termination is needed, and (1.1ax-ax)/ax=0.1), 
>if in both cases the ratio between marked and total traffic is 
>the same value 0.1?
>
>3) On page 9, multicongestion error error is introduced, but 
>the text is silent on how this error is defined and what is it 
>set to (if it is a configuration parameter), or how it is 
>measured (if it is something that is being measured). Can you 
>explain, please?
>
>I have some more questions, including sharing those asked by 
>Phil in the attached message), but I will stop now, as I hope 
>clarifications on the above (and Phil's) questions will help 
>understand the draft better...
>
>> Thanks for the revised draft, I can understand it much better. Here 
>> are some questions /misunderstandings.
>> 
>> - two encodings are used. one ('PCN-marking') is used for both adm 
>> ctrl & termination to indicate the excess traffic.
>> If a PCN-interior-node is PCN-marking some pkts, then it marks all 
>> other pkts with another encoding ('affected marking')
>> 
>> * as the traffic rate climbs above the PCN-lower-rate, an increasing 
>> number of pkts are marked (marking rate = excess rate divided by N) 
>> [adm ctrl state]
>> * at some rate (PCN-lower-rate + adm-offset-rate), then pkts are 
>> marked at the same rate, even if the traffic rate climbs higher [adm 
>> ctrl state]
>> * when the traffic rate reaches the PCN-upper-rate, additional pkts 
>> are marked (additional marking rate = excess rate above 
>PCN-upper-rate 
>> divided by N) [termination ctrl state]
>> * if pkts arrive already PCN-marked, then the node measures the rate 
>> of pkts already marked & works out what excess rate this corresponds 
>> to, and only marks additional pkts if its own excess rate is even 
>> higher.
>> * the PCN-egress-node measures the rate of PCN-marked pkts and 
>> determines whether the overloaded node is in adm ctrl state or 
>> termination ctrl state
>> 
>> 
>> Questions:
>> this could happen? I think your multicongestion_error parameter in 
>> S3.4 is connected to this problem; I didn't find your 
>discussion about 
>> it convincing
>> same affected marking is used in both adm ctrl state & termination 
>> ctrl state - I don't think this works. Imagine that a node 
>[node-1] on 
>> one path is in adm ctrl state & a node [node-2] on another 
>path is in 
>> this could lead to flows being terminated that go through node-1; 
>> node-2 will still be just as badly overloaded.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Oct 2007 09:03:58 +0000

Hi Phil, Hi all

Sorry for the delay!
Due to sad family circumstances I could not concentrate
on the PCN activities!

Thank you very muh for reading and commenting the LC-PCN draft.
Below I try to answer the questions associated with the LC-PCN draft.

Best regards,
Georgios

> Sent: donderdag 13 september 2007 17:27

Georgios: Yes, you are right. All other packets are marked
using the "PCN_Affected_marking" encoding.

> rate divided by N) [adm ctrl state]

Georgios: It is more complicated than that! Please check the
pseudocode on page 13. The packets are PCN-marking encoded
only if the incoming_PCN_marking_rate is smaller or equal to
the Admission_offset_rate. Where the incoming_PCN_marking_rate
is actualy the rate of incoming packets that are PCN_marked.

> are marked at the same rate, even if the traffic rate climbs

Georgios: No, if the incoming_PCN_marking_rate is higher than the
Admission_offset_rate than no anymore packets are PCN_marked.
They are however marked as PCN_Affected_marking!

> rate above PCN-upper-rate divided by N) [termination ctrl state]

Georgios: It is again more complicated than that, please
see the pseudocode on Page 20. Similar to the admission control state
the rate of packets to be marked also depends on
the incoming_PCN_marking_rate. Moreover, if the interior node is
in termination ctrl state
then the additional marking rate is using the sliding window
algorithm to overcome the undershooting issue, see page 19 and page 20.

> own excess rate is even higher.

Georgios: Well, it is more complicated than that. Please see pseudo
code onn page 13 and page 20, the
rate of the already PCN_marked packets is denoted in the pseudocode
as incoming_PCN_marking_rate.

> state or termination ctrl state

Georgios: Yes, but it is more complicated than that please see
pseudo code on page 14 and on page 23.

> affected-marking of all pkts. Wouldn't that work just as well?

Georgios: this algorithm can provide admission control even if
probing is not used. However, by using probing we ensure that the
flow that is requesting access is passing through the interior node
that is either in admission control state or flow termination state.

> is connected to this problem; I didn't find your discussion about it

Georgios: You are right, the multicongestion_error parameter in S3.4
is used to emphasize the multicongestion error bounds in this
calculation. Note that
the calculation of this error bound can only be estimated by off line
tests in a predefined network scenario.
Note that by using the dependency of the incoming_PCN_marking_rate
the multicongestion error bound can be decreased.

> will still be just as badly overloaded.

Georgios: In admission control state, probing is used to ensure that
the packets associated to a requesting flow are passing through the
congested PCN_interior node. ECMP is one
of the issues that are associated with the fact that packets of a flow can
follow a different path than the path followed by an aggregate of flows
(starting from the same ingress and ending at the same egress).
In order to accomplish this the probe packets should be marked using
either PCN_marking encoding or the PCN_Affected_marking encoding.
In flow termination state, both the PCN_marking and PCN_Affected_marking
encoded packets are used to ensure that the flows that are selected for
termination are indeed passing through a severely congested node.
Note that the issue that you described above is associated to the
multicongestion-error bounds. Therefore, this multicongestion-error bound
should be estimated as much as
accurate as possible.

> factor makes no sense to me

Georgios: Why not?

> the latter a % so some tweaking is needed to convert the latter into a

Georgios: You are right, a conversion is needed to convert the latter
into a rate.

---

From: <[email-masked]>
Date: Fri, 26 Oct 2007 10:11:19 +0100

In-line
Thanks
Phil
> pseudo code on page 14 and on page 23.

[phil] I'm now confused whether I understand your algo.
I should have said: my first bullets were all assuming that no pkts
arrived already PCN-marked, ie incoming_PCN_marking_rate = 0. Is my
summary correct with this assumption?

Also, the pcn-egres-node determining what state it's in. I was reading
the description on page 21-22. pges 14 & 23 don't seem to have relevant
pseudocode?

> that is either in admission control state or flow termination state.

[phil] ok.
> the multicongestion error bound can be decreased.

[phil] ok. I don't like this. the idea of PCN is to be a
measurement-based approach so don't have to do these kind of off-line
tests. In particular, there'll be wrong when the network is suffering
from failures - the strength of a measurement-based approach should
exactly be that it gracefully adapts despite network failures. 

> should be estimated as much as

[phil] ok, so you agree this is a problem. 
> > factor makes no sense to me

[phil] well I don't understand what the point of it is. I thought I
understood the point of the *admission* offset_rate and I couldn't see
why anything similar was needed for termination. But maybe I
misunderstood the adm-offset-rate as well!
> Georgios: You are right, a conversion is needed to convert the latter

[phil] ok. So everything is rate. Note this raises Anna's qu:
   * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are absolute
rates, then how do you choose that abslolute rate value, given that the
rates of ingress-egress aggregates at the same ingress may be vastly
different in magnitude?