Subject: [PCN] comments on single marking draft

From: <[email-masked]>
Date: Wed, 13 Dec 2006 14:58:30 -0000

Anna, all,

Here at last are some comments on your single marking idea as described
in
http://ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.txt

The flow pre-emption mechanism is essentially the same as in the Briscoe
drafts, so they should behave the same. The comments below are all for
admission control. 

The draft is very interesting, due to its two big advantages, as you
point out:

- only need a single pkt encoding, easier to stdise

- only need a single measurement operation at routers [so simpler,
faster] & this a measurement they do anyway [easier router upgrade]

in your simulations, you analyse the probability of "false accepts" ie
accept calls when the network state really means should be rejected.
>From your simulations, it seems this is probably OK, although it's
harder to choose the parameters that make it work (harder than for the
Briscoe i-d). 

* Reaction time:

An important potential drawback is how quickly it reacts to changes in
load, especially if the load suddenly increases above the
configured-admission-rate how quickly does the mechanism ensure that new
calls are rejected. This is worse for the token bucket algorithm
compared with the virtual queue - because the latter moves rapidly from
marking 0% to 100% of packets as the load increases, whilst the former
only marks the excess rate. 

Also, a smaller ewma 'weight' means that the egress effectively averages
over a longer time. Unfortunately, for the video scenario Table A4
suggests you need to use a small ewma weight. 

It would be nice to get a handle on how significant this problem is. 

ewma 'weight':-

ewma_new = weight * new_measurement + (1-weight)*ewma_old

calculated/measured every 100ms interval according to
http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati
on-00.txt 

so a weight of 0.1 is very roughly smoothing over about 1sec & weight of
0.9 smoothing over roughly 0.1sec.

I'd imagined the smoothing was over a shorter time period.

* False rejects:

One danger (which I don't think you considered) is that new call
request(s) may be rejected when they actually should be accepted,
because the measured-ewma (=CLE) is greater than the CLE_threshold
whereas the actual-ewma is smaller. In general, an operator won't like
false rejects (= money).

It's quite hard to know how to assess this problem. Say you set
CLE-threshold to 5% - there'll be times when you measure CLE as 5.01% (&
reject) when really it's 4.99% - however, the actual traffic level is
pretty much at your design level, so this error doesn't feel too
important to me. However, if your CLE-threshold is 0.01% my instinct is
that there's a much higher chance of falsely rejecting a call when the
actual traffic level is still quite a way below your design level.

Unfortunately, for the video scenario Table A4 suggests you need to use
a small CLE-threshold.

* Inter-domain case

you use a system-wide constant u, the assumed ratio between pre-emption
and admission thresholds for all links in the PCN-region. 

The thought is that the PCN-region can gradually be extended to cover
multiple domains. But each might be using different values for u - so
inter-domain operations might be hampered. This needs more thought. 

* Other comments:

- it would be nice if the simulations could be re-run for multiple
videos per ingress-egress-aggregate - to check that the deduction is
correct that "we believe that the severe degradation of performance in
this topology is directly attributable to the lack of traffic
aggregation on the ingress-egress pair basis."

- in the simulations, could you check whether the probability of
accepting a call request on a *particular* ingresss-egress-aggregate is
biased by the RTT 

- your assumptions in the simulations seemed ok to me:

  - single bottleneck - if there are multiple bottlenecks, would expect
the method still to be ok - the marking %s combine as required. 

  - No packet loss - if there was packet loss, would expect method still
to be ok, as would expect all packets getting through the overloaded
router to be marked. NB must not preferentially drop marked packets,
otherwise might get no pkts through.

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