Subject: RE: [PCN] LC-PCN version 01 uploaded

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 01 Nov 2007 07:03:38 +0000

Hi Phil

Thank you very much!
The answers to your questions included in this email are
already given in the reply that I have just sent to Anna some minutes ago!
<<Re: Questions on LC-PCN draft version 01>>

But please see in line!

On 10/26/2007, "[email-masked]" <[email-masked]> wrote:

>In-line
>Thanks
>Phil
>>
>> > 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')
>> 
>> Georgios: Yes, you are right. All other packets are marked
>> using the "PCN_Affected_marking" encoding.
>> 
>> >
>> > - 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]
>> 
>> 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.
>> 
>> > * 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]
>> 
>> 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!
>> 
>> > * 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]
>> 
>> 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.
>> 
>> 
>> > * 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.
>> 
>> 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.
>> 
>> 
>> > * 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
>> 
>> Georgios: Yes, but it is more complicated than that please see
>> 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?

Georgios: please see the abstract description of the LC-PCN algorithm
that I gave on the reply that I have sent to Anna some minutes ago!

>
>
>> >
>> > 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?
>> 
>> 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.
>
>[phil] ok.
>> 
>> > - 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
>> 
>> 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.
>
>[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. 

Georgios: please see the abstract description of the LC-PCN algorithm
that I gave on the reply that I have sent to Anna some minutes ago!
In particular, please check the paragraph denoted as "Setting the
thresholds at PCN_egress_nodes" in the reply that I have sent to Annas
email some minutes ago!

Furthermore, your above comment is not fair, since the example that you
gave can be considered as a corner case! Only in such cases the
multicongestion_error bound is needed.

Now, regarding your example:
>> > 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.

Are you assuming that ECMP occurs on the PCN domain and therefore flows
leaving from A and going towards D will not follow the same path.
If no ECMP is used I would expect that all flows belonging to the same
A/D aggregate, and leave from A and go towards D will
follow either A-B-X-D or will follow A-M-N-X-D, but they will not be
separated.

>> 
>> > - 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.
>> 
>> 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.
>
>[phil] ok, so you agree this is a problem. 

Georgios: The issue that I have described here is not a problem that
cannot be solved. Please see the abstract description of the LC-PCN
algorithm that I gave on the reply that I have sent to Anna some minutes
ago!

>> 
>> > - in the termination algorithm, S4.2.2, the
>"termination_offset_rate"
>> > factor makes no sense to me
>> 
>> Georgios: Why not?
>
>[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: This is explained in a detailed way in the reply that I have
sent to Annas comments some minutes ago!

>> 
>> > - 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)
>> 
>> Georgios: You are right, a conversion is needed to convert the latter
>> into a rate.
>
>[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?

Georgios: No, not everything is rate, please see my reply to Annas
comments and in particular the paragraph denoted as:
"Setting the thresholds at PCN_egress_nodes"

Best regards,
Georgios

>> 
>> 
>> >
>> > 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: Thu, 1 Nov 2007 08:52:02 -0500

Hi Phil, Anna and others,

We are also in the process of re-editing the draft to make things more
clear and less confusing.  We will upload the next 02 version ASAP (and
definitely by Nov 19, 2007).

BR,
-Anurag Bhargava, Ph.D.

>From: Georgios Karagiannis [mailto:[email-masked]] 
>Sent: Thursday, November 01, 2007 3:04 AM
>To: [email-masked]; Anurag Bhargava; [email-masked]
>Subject: RE: [PCN] LC-PCN version 01 uploaded
>
>Hi Phil
>
>Thank you very much!
>both adm 
>>> > ctrl & termination to indicate the excess traffic.
>marks all 
>>> > other pkts with another encoding ('affected marking')
>>> 
>>> > increasing number of pkts are marked (marking rate = excess rate 
>>> > divided by N) [adm ctrl state]
>>> 
>>> 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.
>>> 
>>> > * 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]
>>> 
>additional pkts 
>>> > are marked (additional marking rate = excess 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.
>>> 
>>> 
>>> > * 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.
>>> 
>>> 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.
>>> 
>>> 
>>> > * 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
>>> 
>>> Georgios: Yes, but it is more complicated than that please 
>see pseudo 
>>> code on page 14 and on page 23.
>>> 
>>
>Georgios: please see the abstract description of the LC-PCN 
>algorithm that I gave on the reply that I have sent to Anna 
>some minutes ago!
>
>
>>
>>
>>> >
>>> > Questions:
>>> > 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 
>>> > 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
>>> 
>>> calculation. Note that the calculation of this error bound can only 
>>> be estimated by off line tests in a predefined network scenario.
>Georgios: please see the abstract description of the LC-PCN 
>algorithm that I gave on the reply that I have sent to Anna 
>some minutes ago!
>In particular, please check the paragraph denoted as "Setting 
>the thresholds at PCN_egress_nodes" in the reply that I have 
>sent to Annas email some minutes ago!
>
>Furthermore, your above comment is not fair, since the example 
>that you gave can be considered as a corner case! Only in such 
>cases the multicongestion_error bound is needed.
>
>Are you assuming that ECMP occurs on the PCN domain and 
>therefore flows leaving from A and going towards D will not 
>follow the same path.
>If no ECMP is used I would expect that all flows belonging to 
>the same A/D aggregate, and leave from A and go towards D will 
>follow either A-B-X-D or will follow A-M-N-X-D, but they will 
>not be separated.
>
>
>
>>> 
>termination 
>>> > ctrl state - I don't think this works. Imagine that a 
>node [node-1] 
>>> > on
>>one
>>> > 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.
>>> 
>>> congested PCN_interior node. ECMP is one of the issues that are 
>>> associated with the fact that packets of a flow
>>can
>Georgios: The issue that I have described here is not a 
>problem that cannot be solved. Please see the abstract 
>description of the LC-PCN algorithm that I gave on the reply 
>that I have sent to Anna some minutes ago!
>
>>> 
>Georgios: This is explained in a detailed way in the reply 
>that I have sent to Annas comments some minutes ago!
>
>>> 
>Georgios: No, not everything is rate, please see my reply to 
>Annas comments and in particular the paragraph denoted as: