Re: [PCN] Comments about CL and SM edge behavior

[<[e-mail]>]

what are proposals 2a & 2b ? [sorry, must be the jet lag!}
 
3 i have a lot of sympathy for. issue raised before was that policy info is most likely at the ingress - [i guess this is the most logical place] - and you need to check policy info eg to check the importance of the flow taht could be about to be terminated.
 
thanks
phil

________________________________

From: [e-mail] on behalf of Michael Menth
Sent: Sun 22/03/2009 23:52
To: pcn
Subject: [PCN] Comments about CL and SM edge behavior



Hi all,

as I cannot participate in this IETF meeting, I would like to stimulate
some discussion regarding the issues I find important. The PCN WG has
currently two edge behaviors: SM and CL.
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/draft-charny-pcn-single-marking-edge-behaviour-00.txt
http://tools.ietf.org/html/draft-taylor-pcn-cl-edge-behaviour-00

I would like to propose the following changes to both of them:
1) In CL and SM, the PCN egress node currently signals rates of marked
and unmarked traffic periodically to  the PCN ingress node which takes
the AC decision based on this marking information.
Proposal: Calculate new AC state (block/admit) locally at the PCN egress
node and signal only changes to PCN ingress node.
Reason: a) This reduces unnecessary signalling. b) It allows simple
integration of other AC methods. Is that needed? Yes! CLE-based AC
cannot block empty ingress-egress aggregates (IEAs) and there will be
many of them. Probing for IEAs helps and is simple: explicit probes are
periodically sent from ingress to egress (not per flow!). The AC state
is set to block when a marked probe packet is received  and set back to
admit after some time. More on these options see Section VI.B of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

2) I think the current flow termination mechanisms of CL and SM have the
following two shortcomings:
* The PCN egress node measures rates of marked and umarked traffic,
calculates the edge-to-edge supportable rate (ESR), and sends it to the
PCN ingress node. The PCN ingress node measures the ingress rate (IR)
and calculates the termination rate TR=IR-ESR. This requires that the
values for IR and ESR must timely correspond each other to avoid
potential overtermination. You may call that a measurement bias. See
Section IV.C of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf
* The current flow termination mechanism requires preferential dropping
of marked packets to avoid overtermination. When a PCN domain uses both
upgraded PCN nodes and legacy nodes that are not aware of this packet
dropping strategy, then overtermination occurs if legacy nodes drop
unmarked packets in case of congestion. This case is not in charter but
still relevant.

Proposal 2.a) solves only the first problem:
So far, the FT entity chooses a set of flows such that their overall
rate equals the termination rate, and terminates these flows. Proposed
change: the FT entity chooses a set of flows such that their overall
rate equals the edge-to-edge supportable rate and terminates the
remaining flows. This makes the correlation of correct measurement
values to calculate the termination rate obsolete.
More on these options see Section VII.A.1 and VII.B of:
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

Proposal 2.b) solves both problem, but works only for CL:
Measure only marked traffic and take it as direct estimate for the
termination rate.
More on these options see Section VII.B.1.a of:
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf
Advantage: the above problems are solved as this mechanism is not prone
to overtermination due to measurement bias or dropping of special packets.
Disadvantage: the proposed method requires several termination steps in
case of very large overload when marked packets are lost.

3) Currently, PCN ingress nodes terminate flows when necessary.
Proposal: let the PCN egress nodes terminate the flows.
Reason: a) This makes termination signalling obsolete. b) The PCN egress
node can track for which flows marked packets were recently received
(marked flows). When only marked flows are terminated, CL's FT mechanism
takes correct termination decisions and SM's FT mechanism takes better
termination decisions in case of multipath routing. To support multipath
routing, the alternative is to signal the information about marked flows
from the PCN egress to the ingress. This principle can be applied to any
termination mechanism. More on these options see Section VII.A of:
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

I would be happy to see discussion about these architectural
modifications that do not change the heart of SM and CL but obviously
improve them.

Regards,

    Michael

--
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn

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