Subject: RE: [PCN] comments on single marking draft

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 13 Dec 2006 11:36:37 -0500

Hi Phil,
 
Thanks for the thoughtful comments.  A few responses below:

________________________________

 > From: [email-masked] [mailto:[email-masked]] 
 > Sent: Wednesday, December 13, 2006 9:59 AM
 > To: [email-masked]
 > Subject: [PCN] comments on single marking draft

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

Yes, indeed the reaction time is slower.  It seems to me that from the
practical standpoint slower reaction time may in principle be bad
because it may result in overshoot when the load grows rapidly and
undershoot when it drops.  However, we did not really see much of either
in the simulations (see below on comments regarding undershoot).

In fact I believe that is the moderate overshoot we see in the
simulation is exactly because of the slower reaction time. However, it
should be pointed that the simulations assumed benign poisson arrivals.
One of the things to do for the future is to investigate how bad it can
become if arrivals are much burstier.  We saw in earlier simulations
that virtual queue is relatively tolerant to a moderate increase in
burstiness of arrivals - so you are right we need to look at burtier
arrivals here as well.

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

I think you are saying you would prefer a smaller measurement interval
than 100ms? (once the interval is chosen ewma sensitivity is presented
in th edraft). The 100ms was chosen to make the load on the egress
device manageable if there are lots of ingresses.  I guess the question
boils down to how bad over/under admission is with these parameters.  So
far we think it is OK. But indeed burstier arrivals and in general more
beating up on the simulation would help. We do plan to do more of that.

>* 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).

We actually did consider the false rejects (undersoot) by looking what
happens when the offered load is below the admission thresold
(specifically we looked at 0.95 and 1 load (although we showed only 0.95
load in the draft, I think). We were looking specifically to see if we
will see any significant false rejects (which would result in
under-admission). 
It did appear that for the simulation we did underadmission was quite
small (see negative "over-admission" numbers reflecting the
under-udmission in the draft). But again we would like to do more to see
if we see more underadmission for more abrupt traffic changes.

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

See above. Specific suggestions on setups that you feel might show the
problem you are concerned about are very welcome.

One thing to remember here is that "video" we used in our simulations is
not really video - it is on-ff CBR with long on and off periods (330 ms
and 660 ms respectively).  With a releatively small number of these
"video" flows considered, one would expect the aggregate traffic to
still be rather abruptly changing. Further, as we had only one or very
few of these "video" flows per ngress-egrees pair, the ingress
measurements are really challenging as 100 ms measurements really
oscillate between 0 and peak rate most of the time.  We had always felt
that this kind of "video" represents a "lower bound" on the actual video
behavior (that is, we felt that if performance is OK with this, it
should be better with real video. One of the things we are trying to do
right now is to implement more realistic video models. Will see if our
intuition is confirmed then.

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

I believe you are saying that when two PCN domains merge, then a virtual
queue approach allows the operator to considerthe two omains as a single
domain, while for the single marking approach the choice is either to
mandate the same u in nboth or keep the boundary. I think that is true,
and is certainly a tradeoff to consider.  One question here is whether
an operator who wants to merge two domains would really feel that
mandating the same u is a limiting factor?
 
>* 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."

I believe we actually did that - the "single bottleneck topology" with
video corresponds to the same bottleneck capacity but all video flows
sharing the same ingress-egreess pair.  Will doublecheck...

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

I will double-check, but I believe the answer we arrived at was "no" (in
the experiments we tried) - in that the RTT had no effect in the
distribution of admitted flows among the ingresses.  We should reflect
this more clearly in the next revision of the draft.

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

We will check that - we finally got to the multiple bottleneck case, but
started with preemption first, as it is relevant to both approaches.

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

Still to be thought through further, but for the moment seemed like a
reasonable initial assumption.
 
Best,
Anna 

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

---

From: <[email-masked]>
Date: Tue, 19 Dec 2006 16:32:54 -0000

Anna
a few follow-ups in-line
Thanks - happy Christmas!
phil

> -----Original Message-----
> From: Anna Charny (acharny) [mailto:[email-masked]]
> Sent: 13 December 2006 16:37
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> Cc: Xinyang (Joy) Zhang
> Subject: RE: [PCN] comments on single marking draft
> 
> Hi Phil,
> 

Great - another way of assessing this might be the 'vulnerability
period'? - time for  which you could admit calls although you shouldn't.
the measurement overshoot depends on the number of call attempts during
the vulnerability periods during the simulation - which depends on the
call arrival stats. 

> beating up on the simulation would help. We do plan to do more of
that.
if your mean interval is 100ms, clearly your 'vulnerability period' is
at least (roughly) 100ms. 

> problem you are concerned about are very welcome.

Will think about
> mandating the same u is a limiting factor?

I think this is probably fair (except where you say "an operator who
wants to merge two domains", they could be in separate operators)