RE: [PCN] LC-PCN version 01 uploaded

[<[e-mail]>]

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?


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

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