Subject: [PCN] [Fwd: Nomcom 2007-8: Nominations Close on Sep 10, 2007]

From: Steven Blake <[email-masked]>
Date: Fri, 07 Sep 2007 18:48:18 -0400

FYI

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

Subject: Nomcom 2007-8: Nominations Close on Sep 10, 2007
From: Lakshminath Dondeti <[email-masked]>
To: [email-masked], [email-masked], IESG IESG <[email-masked]>, IAB IAB <[email-masked]>
Date: Fri, 07 Sep 2007 12:52:33 -0700
List-Id: Working Group Chairs <wgchairs.ietf.org>

WGchairs, IESG and IAB members

Please forward this request to the lists you manage and request feedback 
and nominations.

All,

Here is the link to nominate: 
https://tools.ietf.org/group/nomcom/07/nominate

You may also send nominations or comments via email to [email-masked] 
or [email-masked].

We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and 
even fewer accepted (1-2 people in each area, IAB acceptances is 4 at 
last count).

I request the community to provide feedback on the incumbents (send 
email or send notes via the web page).

1) If you think that the incumbent is doing a good job
     a) provide feedback AND
     b) nominate similar people just in case there is strong negative 
feedback on the incumbent

2) If you think the incumbent can do somethings better
    a) provide feedback AND
    b) nominate someone who you think might do better

Candidates, if time commitment is the only issue, please indicate that 
to the nomcom and accept the nominations.

thanks,
Lakshminath

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

---

From: "Anurag Bhargava (RL/TNT)" <[email-masked]>
Date: Tue, 11 Sep 2007 06:36:22 -0500

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.

---

From: <[email-masked]>
Date: Thu, 13 Sep 2007 16:27:15 +0100

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,