Subject: [PCN] CLE vs. admission state

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Oct 2009 08:39:59 -0400

The current versions of the edge behaviour drafts have stepped back slightly 
from the extreme of reporting only transitions in admission state. Now admission 
state is reported at regular intervals.

A fair amount of off-list discussion has been happening over the appropriateness 
of the current arrangement. For one, there is a certain amount of opposition to 
specifying exponential smoothing of the CLE. For another, Phil has raised the 
possibility of a CLE-dependent policy at the decision point, where more 
important flows are allowed in at higher CLE values than less important flows. 
That suggests that instead of admission state, the egress node should be 
reporting at least the CLE.

I believe the discussion should be happening on the list -- that's what it is for.

Michael Menth suggested an useful principle to which the present drafts adhere: 
actions at the decision point/ingress node should be exactly the same for CL and 
SM. He argued that the egress node unavoidably knows the difference between CL 
and SM in any case, so it might as well absorb all the differences.

It is true that at least one end has to know the difference, but it doesn't have 
to be the egress node. If the egress node simply reports rates of unmarked, 
threshold-marked, and excess-traffic-marked traffic each interval, the decision 
point/ingress node can apply the CL- or SM-specific algorithms and draw the 
correct conclusions.

It seems reasonable to design the system so one end is the same whether CL or SM 
is deployed. If we accept that, we have one-and-a-half questions really:

1) Which end should know that SM or CL is deployed?

1) a) If it is the egress node, should it report admission state or CLE? Either 
way, the egress node would have to report the estimated edge-to-edge supportable 
traffic rate whenever termination might possibly be required, and the decision 
point/ingress node would have to compare that with the admitted traffic rate to 
see if termination is really needed.

Tom

---

From: Michael Menth <[email-masked]>
Date: Thu, 29 Oct 2009 16:19:18 +0100

Hi all,

I summarize the issue I raised during the spec writing process. It would 
be good to keep either the PCN egress or the decision point / PCN 
ingress unaware of CL or SM is used. This automatically leads to the 
same signalling protocol for CL and SM, too. Benefits of such an 
approach are obvious (one signalling protocol for CL/SM, simplified 
migration from SM to CL). This can be achieved in two different ways.

A) egress-based-PCN-calculation

The egress calculates a PCN-admission-state (admit/block) as well as the 
edge-to-edge supportable rate (ETM traffic in CL, u*ThM traffic in SM) 
and sends these values to the decision node. The decision node can do 
its operation (admit/block traffic, measure ingress PCN traffic and 
possibly terminate PCN traffic) without knowing whether the PCN reports 
from the egress node are based on CL or SM.

B) decision-point-PCN-calculation

The decision-point (ingress) calculates the PCN-admission-state and the 
edge-to-edge supportable rate. To that end, the egress transmits the 
measured rates of NM, ThM, and ETM traffic in regular intervals.

Advantages of egress-based-PCN-calculation (A):

1) The PCN calculation algorithm can be exchanged locally at the egress 
node without changes to the signalling protocol and the ingress node. 
Example: the egress may send "block" immediately when it observes a 
marked packet. It is basically a different edge behavior that is able to 
work with smaller ingress-egress-aggregates. Reason: small 
ingress-egress-aggregates need long measurement intervals for meaningful 
rate estimates and then it is good when a block-message can be sent 
before the end of the measurement interval.

2) If the PCN-admission-state does not change at the egress and the 
edge-to-edge supportable rate is zero, regular reports which are usually 
carried every 100 ms from egress to ingress can be suppressed until the 
next change. The saved signalling overhead can be significant when the 
rate of ingress-egress-aggregates is small.

Advantage of decision-point-based-PCN-calculation (B):

3) In case of SM, the CLE increases proportionally with the load. It is 
possible to use different CLE-admission-thresholds for high- and 
low-priority traffic so that high priority traffic has a lower blocking 
probability than low priority traffic when the system is near to 
pre-congestion.

Below the line, the question whether A or B is better boils down to the 
issue what's more important for PCN under the assumption that we want to 
keep either the ingress or egress unaware of CL/SM:

i) Potential support for smaller ingress-egress-aggregates

ii) Differentiated blocking probabilities for low- and high-priority 
traffic (only for SM)

Basically we need to decide which of the two issues is more important 
for PCN.

Regards,

    Michael

Tom Taylor schrieb:
> The current versions of the edge behaviour drafts have stepped back 
> slightly from the extreme of reporting only transitions in admission 
> state. Now admission state is reported at regular intervals.
>
> A fair amount of off-list discussion has been happening over the 
> appropriateness of the current arrangement. For one, there is a 
> certain amount of opposition to specifying exponential smoothing of 
> the CLE. For another, Phil has raised the possibility of a 
> CLE-dependent policy at the decision point, where more important flows 
> are allowed in at higher CLE values than less important flows. That 
> suggests that instead of admission state, the egress node should be 
> Michael Menth suggested an useful principle to which the present 
> drafts adhere: actions at the decision point/ingress node should be 
> exactly the same for CL and SM. He argued that the egress node 
> unavoidably knows the difference between CL and SM in any case, so it 
> might as well absorb all the differences.
>
> It is true that at least one end has to know the difference, but it 
> doesn't have to be the egress node. If the egress node simply reports 
> rates of unmarked, threshold-marked, and excess-traffic-marked traffic 
> each interval, the decision point/ingress node can apply the CL- or 
> SM-specific algorithms and draw the correct conclusions.
>
> It seems reasonable to design the system so one end is the same 
> whether CL or SM is deployed. If we accept that, we have 
> one-and-a-half questions really:
>
> 1) a) If it is the egress node, should it report admission state or 
> CLE? Either way, the egress node would have to report the estimated 
> edge-to-edge supportable traffic rate whenever termination might 
> possibly be required, and the decision point/ingress node would have 
> to compare that with the admitted traffic rate to see if termination 
> is really needed.
>
> Tom
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 29 Oct 2009 13:12:03 -0400

Hi Michael,

I am not sure I understand the goal.  Why is it good to keep either the
ingress or the egress unaware o whether it is CL or SM used?   Usually
the egress and the ingress side is implemented in the same device, so I
am not sure why that requirement? 

I do understand that it is good to have the same signaling protocol for
SL mad CL, but I still do not see a clear connection between these two
statements.  What am I missing?

Anna 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Menth
Sent: Thursday, October 29, 2009 11:19 AM
To: pcn
Subject: Re: [PCN] CLE vs. admission state

Hi all,

Regards,

    Michael

--
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science Am Hubland,
D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Michael Menth <[email-masked]>
Date: Thu, 29 Oct 2009 18:27:46 +0100

Hi Anna,

> am not sure why that requirement? 
I don't say it's a requirement, but a nice feature. Moreover, the 
decision point can also be in a centralized node and then ingress and 
egress do not sit in the same device. Then it matters.

Regards,

    Michael