RE: [PCN] LC-PCN version 01 uploaded

["Georgios Karagiannis" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: donderdag 13 september 2007 17:27
> To: [e-mail]; [e-mail]
> 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')

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.

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

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

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

> - in the termination algorithm, S4.2.2, the "termination_offset_rate"
> factor makes no sense to me

Georgios: Why not?

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


>
> best wishes
>
> phil/
>
> > -----Original Message-----
> > From: Anurag Bhargava (RL/TNT) [mailto:[e-mail]]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/pcn
>
>
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pcn


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