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

[<[e-mail]>]

 

________________________________

From: Michael Menth [mailto:[e-mail]]
Sent: Mon 23/03/2009 14:37
To: Eardley,PL,Philip,CXR9 R
Cc: [e-mail]
Subject: Re: [PCN] Comments about CL and SM edge behavior



Hi Phil and all,


> what are proposals 2a & 2b ? [sorry, must be the jet lag!}
>  
The current CL and SM drafts implement MRT-ITR, see Section VII.B.3 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

Proposal 2a is MRT-ESR, see Section VII.B.2 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

Proposal 2b is MRT-DTR, see Section VII.B.1 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

The proposed changes make the FT mechanism simpler and more robust
against overtermination.

> 
> 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.
>  
That's the question. If this is given as a hard constraint, it should be
mentioned because that eliminates some nice design options. What I've
proposed is an approach to make measured rate termination work with
multipath. If this is killed by the assumptions, only marked-packet
based flow termination methods (MPT, aka marked flow termination MFT
which is not an exact name) are able to work with multipath, see Section
VII.D of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf


[phil] well, "not work" is inaccurate - rather you'd have to report marked flows to the ingress [as these go through the right one of the  multiple paths].

perhaps the answer would be to make the decision at the egress, as that seems the most logical place. but if necessary, due to policy info which is only avialble at the ingress, then you report teh proposed decision to the ingress which then checks its policy about whether this flow is allowed to be terminated?

phil


Regards,

    Michael


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

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