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

From: Michael Menth <[email-masked]>
Date: Mon, 23 Mar 2009 00:52:46 +0100

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: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Mon, 23 Mar 2009 03:49:37 -0000

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: [email-masked] 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,

Regards,

    Michael

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

---

From: Michael Menth <[email-masked]>
Date: Mon, 23 Mar 2009 15:37:16 +0100

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

Regards,

    Michael

---

From: <[email-masked]>
Date: Mon, 23 Mar 2009 21:27:25 -0000

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

Hi Phil and all,

[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

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Mar 2009 01:02:35 +0100

Hi Phil and all,

Issue: is egress an alternative location of the flow termination entity?
> 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…
If all the policy info and measured per-flow rates (i think they are 
also required, aren't they?) are available only at the ingress, it seems 
necessary that the ingress chooses the flows. Is it a fact or just a 
speculation or assumption? We should be 100% sure that collocating the 
flow termination entity with the egress doesn't work since that would 
make the design much simpler. Can you check please? If it is a fact, 
then it should be pointed out as a hard constraint. Maybe even in the 
architecture draft. For me, this was not so obvious. And then 
termination must be done at the ingress.

Proposal 2a and 2b are independent of this issue and bring more 
robustness and simplicity to the system.

Regards,

    Michael

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 15:23:51 +0200

Hi Tom,

thanks to you and the other authors for starting the discussion on edge behaviours. Two questions for clarification:

---------------------------

Section 3.2.2 Estimating amount of traffic to terminate

If I understand correctly, no smoothing is applied (eg. EWMA). This of course speeds up reaction, but may also introduce statistically triggered under/over termination. Is that correct?

---------------------------

After consulting a tutorial on EWMA and reading the edge behaviour drafts please confirm whether the following is correct:

- The constant "a" in section 3.2.3 Flow Admission Decisions (CL draft, formula also part of SM draft) must be chosen 0 < a < 1.
- The draft proposes EWMA measurement intervals D > 1000 ms or 3000 ms respectively then.

If I understood that correctly, I'd appreciate an explicite statement on how to determine "D" in the text.

Please also add a statement, if the reported measurement period duration "D" is related to the measurement period defined in section 3.1 "Measurement requirements" (there, no formula letter is given for the measurement period, but a value for that period is suggested by 100 ms to 500 ms, which, if inserted as "D" in the 3.2.3 formula for picking "a" results in invalid values for "a" - if my tutorial on EWMA is correct).
----------------------------

Regards,

Rudiger

Deutsche Telekom Netzproduktion GmbH 
Zentrum Technik Einführung 
Technik Internet Backbone, TE142-19
Rüdiger Geib
Heinrich Hertz Str. 3-7
64297 Darmstadt
Tel.: 06151/6282747
Fax: 0251/7985109

Deutsche Telekom Netzproduktion GmbH 
Aufsichtsrat: Timotheus Höttges (Vorsitzender) 
Geschäftsführung: Friedrich Fuß (Vorsitzender), Albert Matheis, Klaus Peren 
Handelsregister: Amtsgericht Bonn HRB 14190 
Sitz der Gesellschaft: Bonn 
USt-IdNr.: DE 814645262

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 16:16:12 +0200

Hi Anna,

also thanks to you and your co-authors for starting the discussion on SM edge behaviours.

Some comments:

Section 3.2.1 Termination Decision

The brackets in the first sentence are puzzeling. Does it read better if formulated

'The ingress node makes a termination decision by comparing the
 locally computed "PCN-sustainable-rate" value with the locally 
 measured value "PCN-sent-traffic".' 

-------

The sentence

'where U is a configured domain-wide constant that defines the ratio
 between the PCN-supportable-rate and PCN-admissible-rate (see Section
 2).'

is hard to understand. Section 2 doesn't provide any information on the "PCN-supportable-rate". From the architecture I see that "PCN-supportable-rate" there it is defined as the "PCN-excess-rate" (in Figure 1) which is equivalent to the "PCN-admissible-rate" in your document (dangerous interpretation). 

Am I correct assuming that "PCN-supportable-rate" is equivalent to "PCN-sustainable-rate" ? If so, please adapt wording (supportable rate is preferrable, as this term is used by the architecture).

-------------

Section 3.1 and section 3.2.2

Please suggest values for D and w and the relation between both. Further a suggestion on the CLE threshold is useful. Am I right to assume this requires someone interested in SM setting up simulations?

-------------

While the excess rate marker may be a policer, I'm familiar with EWMA in routers from RED. Another mechanism applied with RED is the possibility to assign a marking profile, which could allow to start wth eg. 50% of all packets being marked once the CLE has been crossed. A slope could define, when to mark 100%. If applicable for an excess rate marker, this of course impacts the whole evaluation, as the edges don't detect 1% traffic being marked but 50% instead, once marking kicks in. The true question here is, whether an RED like behaviour can easily by supported by a policer or whether a virtual queue with RED behaviour could be used as excess rate marker.

My expectation would be that more marked packets improve functionality of the admission control decisions.

Regards,

Rudiger

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 16:25:46 +0200

Hi Tom,

If I understood that correctly, I'd appreciate an explicite statement on how to determine "D" in the text. Section 3.1 "Measurement requirements" suggests "D" to be 100 ms to 500 ms, which, if inserted as "D" in the 3.2.3 formula for picking "a" results in invalid values for "a" - if my tutorial on EWMA is correct.
----------------------------

Regards,

Rudiger

---

From: Tom Taylor <[email-masked]>
Date: Mon, 30 Mar 2009 18:50:14 -0400

Thanks for your comments. The drafts are due to change based on discussion at 
the meeting (recorded in my presentation) but I think your questions continue to 
be valid. Responses marked with [PTT].

[email-masked] wrote:
> Hi Tom,
> 
> thanks to you and the other authors for starting the discussion on edge
> behaviours. Two questions for clarification:
> 
> If I understand correctly, no smoothing is applied (eg. EWMA). This of course
> speeds up reaction, but may also introduce statistically triggered under/over
> termination. Is that correct?

[PTT] The problem with estimating supportable traffic rate or amount to be 
terminated for an aggregate is that we are reacting as soon as excess-marked 
traffic is observed. The implication is that previous to this point the system 
has been operating below supportable rate for the aggregate, so if we applied 
any sort of averaging we would underestimate the supportable rate for that 
aggregate. That means over-termination for sure.

[PTT] If we had the luxury of waiting for a few measurement periods before 
reacting we could do a bit of averaging and reduce the statistical error. But we 
don't have that luxury.
> After consulting a tutorial on EWMA and reading the edge behaviour drafts
> please confirm whether the following is correct:
> 
> - The constant "a" in section 3.2.3 Flow Admission Decisions (CL draft,
> formula also part of SM draft) must be chosen 0 < a < 1. - The draft proposes
> EWMA measurement intervals D > 1000 ms or 3000 ms respectively then.

[PTT] Big oops there. I got the fractions inverted relative to my intent. D is 
the measurement period. If it is 100 ms, my intent was to have a smoothing 
constant in the order of 0.1 (D/1000) down to 0.033 (D/3000).
> Please also add a statement, if the reported measurement period duration "D"
> is related to the measurement period defined in section 3.1 "Measurement
> requirements" (there, no formula letter is given for the measurement period,
> but a value for that period is suggested by 100 ms to 500 ms, which, if
> inserted as "D" in the 3.2.3 formula for picking "a" results in invalid
> values for "a" - if my tutorial on EWMA is correct). 
> Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einführung Technik
> Internet Backbone, TE142-19 Rüdiger Geib Heinrich Hertz Str. 3-7 64297
> Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109
> 
> 
> Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus Höttges
> (Vorsitzender) Geschäftsführung: Friedrich Fuß (Vorsitzender), Albert
> Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der
> Gesellschaft: Bonn USt-IdNr.: DE 814645262
> 
>