Subject: Re: [PCN] Please modify the marking behaviour draft

From: <[email-masked]>
Date: Thu, 5 Mar 2009 18:22:20 -0000

Hi Daisuke

I've thought a bit more about your proposal, and read your
draft-satoh-pcn-ST-marking (thanks for sending me a version that will
soon be the 01 doc. I think most of my comments are relevant to the
earlier version, but there are one or two that need the update to make
sense, sorry to rest of WG where this is the case but I wanted to send
my comments before I forgot them!)

First, I'd like to understand a bit more your reasoning behind the
proposal. OK, you want a marking behaviour that can give reasonable
admission control and flow termination even when only 2 PCN encoding
states are available (PCN-marked & not marked). There is already a
proposal that achieves this - ie "single marking"
http://www.watersprings.org/pub/id/draft-charny-pcn-single-marking-03.tx
t (just expired, but i believe will be renewed very soon). Your
simulations (roughly speaking) show that the behaviour of your marking
behaviour is similar to that of SM. Please could you explain in what
situations /scenarios it has a significant advantage. The SM proposal
works with the existing marking behaviour in the WG doc
http://tools.ietf.org/wg/pcn/draft-ietf-pcn-marking-behaviour/ which has
been extensively simulated etc, so we need to understand where it has
clear benefit (ie beyond being a plausible alternative). I think this is
the most important comment.

I wonder about the relative complexity of your marking behaviour
(compared with draft-ietf-pcn-marking-behaviour). It seems somewhat more
complex (because of the linking of two token buckets; and the second
threshold at just below the 'full' level of the token bucket). 

A similar complexity concern I have is about migration. The
draft-ietf-pcn-marking-behaviour has both threshold and excess-rate
meters as musts to implement. One reason is that it makes it easy to
migrate, when an extra PCN encoding state becomes available, from SM to
the more accurate admission & termination of (eg) CL. With your approach
this requires a 3rd meter (& possibly a 4th, depending whether the MkTB
token bucket is good enough).

[I think this issue is relevant to the -01 version, not the -00]. I
didn't follow the termination method if the link is very heavily
overloaded, ie above the link capacity. You seem to imply that something
beyond the normal mechanism is done, but I didn't get it.

The termination mechanism is to terminate y% of flows every 'measuring
interval', if the sending rate is > receiving rate (I assume these are
measured for a particular ingress-egress-aggregate). First, this method
seems to need careful balancing of the parameters (y & measuring
interval) in order to ensure that termination is fast enough but not too
much is over-terminated. Maybe the over-termination is limited to y%, ie
known amount, so this aspect not too bad (still need to set measurement
interval).
Second, the approach to date has to been to try to allow a range of
possible termination approaches - not sure whether this is possible with
your draft (don't know).

Distinguishing admission and termination: it is (I think) inevitable
that any scheme with just one PCN-marked encoding will have scenarios
where it mistakenly terminates when it should just be doing admission
control, at least in theory. For example, in your draft if the pattern
of traffic means that L pkts in a row are marked (ie pkts arriving at an
egress from a particular ingress), even though PCN-nodes are doing
admission marked (ie marking 1/N pkts). Immediate reaction is that this
"mistaken termination" seems more likely to happen than with SM.
However, this needs more thought (would you argue it is less likely?)
Also, the choice of the 1/N parameter seems to depend on the odds of L
pkts in a row being marked - which seems to depend on the traffic
pattern, type of traffic (CBR, VBR etc), factors which may be uncertain
when management configuration is done?

Also i worry that this problem could be critical with synchronised
traffic, eg CBR flows or smoothed by nw. then every pkt for a particular
flow (or ingress-egress-aggregate) might be marked by a router doing
admission marking. Your simulations seem to show no problem with
synchronisation with CBR traffic, but I didn't understand conceptually
if this is because the problem I describe is impossible to happen, or
didn't because of some simulation assumption, or something else. 

I don't understand why the MkTB has the "shallow.threshold" just below
the "full" level of the token bucket (it's below by the size of the
metered-packet). [There's a reference "see Appendix" but wasn't sure
which bit of appendix to read.] why is this needed at all? (sorry, am
sure you explained this to me at the last ietf but I've forgotten.)

Thanks
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ SATOH Daisuke
{ Sent: 21 January 2009 07:46
{ To: [email-masked]
{ Subject: [PCN] Please modify the marking behaviour draft
{ 
{ 
{ 
{ Hi Phil,
{ 
{ 
{ If you received this e-mail again, I'm sorry.
{ 
{ 
{ I would like you to modify draft-ietf-pcn-marking-behaviour-01. I made
{ an example of modification as follows.
{ I understand I have to show you the performance of our algorithm. So I
{ have to update draft-satoh-pcn-st-marking-00. We have simulated our
{ algorithm
{ in extreme cases for both admission and termination. Now we are
{ simulating it. Please wait for performance evaluation awhile.
{ 
{ 
{ 
{ ---
{ 2.3. Threshold meter function
{ 
{ 2.3.1 Threshold meter function with One threshold
{ A PCN-node MUST implement a Threshold Meter that has behaviour
{ functionally
{ equivalent to the following. The meter acts like a token bucket, which
{ is sized in bits and has a configured bit rate, termed
{ PCN-threshold-rate. The amount of tokens in the token bucket is termed
{ TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a
{ maximum value TBthreshold.max. Tokens are removed equal to the size in
{ bits of the metered-packet, to a minimum TBthreshold.fill=0. The token
{ bucket has a configured intermediate depth, termed
TBthreshold.threshold.
{ If TBthreshold.fill < TBthreshold.threshold, then the meter indicates
to
{ the Marking function that the packet is to be threshold-marked;
{ otherwise it does not.
{ 
{ 
{ 2.3.2 Threshold meter function with two threshold
{ A PCN-node MUST implement a Threshold Meter that has behaviour
{ functionally
{ equivalent to the following.
{ 
{ The meter acts like a token bucket, which is sized in bits and has a
{ configured
{ bit rate, termed PCN-threshold-rate. The amount of tokens in the token
{ bucket is termed TBthreshold.fill. Tokens are added at the
{ PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are
{ removed equal to the size in bits of the metered-packet, to a minimum
{ TBthreshold.fill=0. The token bucket has two configured intermediate
{ depths, termed TBthreshold.shallow.threshold and
TBthreshold.threshold,
{ where TBthreshold.shallow.threshold is greater than
{ TBthreshold.threshold. If (TBthreshold.fill <
{ TBthreshold.shallow.threshold) and (TBthreshold.fill >=
{ TBthreshold.threshold), then the meter indicates to the Marking
function
{ that one-N-th packets are threshold-marked. If TBthreshold.fill <
{ TBthreshold.threshold, then the meter indicates to the Marking
function
{ that the packet is to be threshold-marked; otherwise it does not.
{ 
{ 
{ 
{ 2.5 Combination of the meter functions
{ A PCN-node MAY implement combination of Threshold and Excess traffic
{ meters. The
{ meter is composed of two tandem meters of Threshold and Excess traffic
{ meters or two Threshold meters or two Excess traffic meters. The
former
{ meter is used for marking switch and the latter meter is used for
{ marking.
{ 
{ The combined meter has behaviour functionally equivalent to the
following.
{ 
{ 
{ If TBthreshold.fill >= TBthreshold.threshold (when the former meter is
the
{ Threshold
{ meter) or if the token bucket is not empty (the former meter is the
{ Excess traffic meter), the combined meter indicates to the Marking
{ function that the packet is not to be marked even if the latter meter
{ indicates to the Marking function that the packet is to be marked.
{ Otherwise, the combined meter indicates the same result as the latter
{ meter's indication to the Marking function.
{ 
{ 
{ 
{ A.3 Combined metering and marking
{ The combined meter by using two Threshold meters is introduced. The
two
{ combined
{ token buckets with the following parameters:
{ 
{ o TBthreshold.PCN-threshold-rate.former: token rate of the former
token
{ bucket (bits/second)
{ 
{ o TBthreshold.PCN-threshold-rate.latter: token rate of the latter
token
{ bucket (bits/second)
{ 
{ o TBthreshold.max.former: depth of the former token bucket (bits)
{ 
{ o TBthreshold.max.latter: depth of the latter token bucket (bits)
{ 
{ o TBthreshold.threshold.former: marking threshold of the former token
{ bucket (bits)
{ 
{ o TBthreshold.shallow.threshold.latter: One-Nth marking threshold of
the
{ latter token bucket (bits)
{ 
{ o TBthreshold.threshold.latter: marking threshold of the latter token
{ bucket (bits)
{ 
{ o TBthreshold.lastUpdate: time both token buckets were last updated
{ (seconds)
{ 
{ o TBthreshold.fill.former: amount of tokens in the former token bucket
{ (bits)
{ 
{ o TBthreshold.fill.latter: amount of tokens in the latter token bucket
{ (bits)
{ 
{ 
{ A PCN-packet has the following parameters:
{ 
{ o packet.size: the size of the PCN-packet (bits)
{ 
{ o packet.mark: the PCN encoding state of the packet
{ 
{ In addition there is the parameter:
{ 
{ o now: the current time (seconds)
{ 
{ 
{ The following steps are performed when a PCN-packet arrives on a link:
{ 
{ o TBthreshold.fill.former = min(TBthreshold.max.former,
{ TBthreshold.fill.former +
{ TBthreshold.PCN-threshold-rate.former*(now - TBthreshold.lastUpdate));
{ // add tokens to the former token bucket
{ 
{ o TBthreshold.fill.latter = min(TBthreshold.max.latter,
{ TBthreshold.fill.latter +
{ TBthreshold.PCN-threshold-rate.latter*(now -
TBthreshold.lastUpdate));//
{ add tokens to the latter token bucket
{ 
{ 
{ o TBthreshold.fill.former = max(0, TBthreshold.fill.former -
packet.size);
{ //remove
{ tokens from the former token bucket
{ 
{ 
{ o TBthreshold.fill.latter = max(0, TBthreshold.fill.latter -
packet.size);
{ //remove
{ tokens from the latter token bucket
{ 
{ 
{ o if (TBthreshold.fill.former < TBthreshold.threshold.former) then
{      if  (TBthreshold.fill.latter <
TBthreshold.shallow.threshold.latter)
{ then
{         if (TBthreshold.fill.latter >= TBthreshold.threshold.latter)
then
{ 	       one-Nth packets are threshold-marked
{         else
{ 		packet.mark = threshold-marked;
{ //do threshold marking with two thresholds only when
{ TBthreshold.fill.former <= TBthreshold.threshold.former
{ 
{ o TBthreshold.lastUpdate = now
{ ---
{ Best regards,
{ 
{ Daisuke
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn