Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 13 Sep 2007 23:45:22 -0400

Bob,
Sorry for the delay in resending to your questions.

First, I agree with your comments in email to Ruediger, dated Wed
29/08/2007 and would like to emphasize that defining marking that is
dimensionless, will allow PCN system to scale. (ie marking meaning
pre-congestion state or condition rather than certain rate). 

On your point that marking should rise gradually then get steeper as the
reference rate is approached and rapidly saturate at some point (the
reference rate). We need to discuss further. It's not that I'm against
this idea, I just do not see how practically we can take advantage of it
to control over admission under flash crowd conditions. (more on this
topic later in the email)

>Joe,

>At 15:17 27/08/2007, Jozef Babiarz wrote:
>>I think there is a bit more to this issue than just different levels
of
>>pre-congestion.
>>
>>For admission control the challenge for PCN is to find out how much
new
>>traffic can be added on to a specific link or path and not to
determine
>>the level of congestion.

>I agree that the AC challenge for PCN is to find how much new traffic
can 
>be added, but surely not just for a specific link. The full challenge
is 
>for any single ingress edge node to know how much it can add. But it
has to 
>accept the fact that it doesn't know how many other ingress nodes are 
>competing to add traffic to the same link. (See previous response to 
>Ruediger - although I don't think you're asking for the same thing, but
it 
>sounds like you are).

>more...

>>The purpose of admission control is to prevent
>>congestion of the service class on link that forwards PCN traffic. PCN
>>is deployed in Diffserv networks, with the understanding that PCN
>>traffic is forwarded using priority scheduling.
>>
>>Voice with silence suppression plus calls naturally ending as well new
>>calls being added generates highly variable traffic. The marking by
>>interior node to indicate that PCN admission threshold is exceeded or
>>not, needs to be quick to reflect true traffic levels.

>Agreed

>>Analysis of the
>>marking density and control of response to the marking can be handled
at
>>the edges. The proposed marking scheme in draft-babiarz-pcn-3sm-00.txt
>>for admission control, produces the following behavior, when PCN
traffic
>>is fare below the admission stop threshold, no packets are marked. As
>>the variable traffic increases and some packets exceed the token
bucket
>>rate (admission stop threshold) they are marked. If additional new
>>traffic is allowed to be admitted on to the link, more packets will
>>exceed the token bucket rate therefore marking density increases
>>possibly until all packets are marked. However, for pure and stable
CBR
>>traffic you will get a step marking (on-off) where the transition from
>>no marking to all packets marked being quick.

>I'm not sure which you you are saying is more desirable:

[Joe] My thinking is that the ingress node, the one that is controlling
admission of new flows needs to know if it can or can not admit new
flow, simply yes or no. My assumption is that the ingress node only has
limited view of traffic rate and characteristics of the new flow to be
admitted, like what would be specified for a VoIP or video conferencing
service. 

I think your suggesting that we provide the ingress node an early
warning that traffic is approaching the configured admissible threshold
when an egress node sees some marking. The ingress node uses some policy
or algorithm to control the admission of new flows when the path is
close to admissible threshold. Providing three levels (stop-light
methodology) green admit, orange admit with caution, and red stop?

>- the outcome with variable traffic (a gradual transition from 0-100%
>marking)
>- or the outcome for CBR traffic (a step change)?

>I think you're saying that a gradual transition is desirable, but that
even 
>with on-off marking you get a gradual transition as long as there's 
>variation in the traffic, which there usually is.

>(See later for my view)

[Joe] Yes, with the threshold marking define in 3sm draft you get a
transition form no marking to 100% marking. The transition depends on
variation of the traffic and settings of the token bucket, size and
marking threshold.

>
>>My view is that PCN should work equally well regardless of the number
of
>>flows in an ingress-egress aggregate from one to many flows,

>Agreed.

>>as well
>>should work without the need for ingress-egress aggregation concept.

>If you mean by this, that a new flow shouldn't need to use information
from 
>existing flows in an aggregate, I agree. That's a performance
enhancement, 
>not an essential function.

[Joe] Yes, plus for first flow of aggregate or if the deployment does
not use ingress-egress aggregation concepts through tunneling or other
methods.

>>The
>>so called on-off marking approach is not that dependent on the rate of
>>ingress-egress traffic meaning that edge node will be able to
determine
>>if new flow should be admitted based on low bit rate (probe or single
>>voice flow) or high bit rate flow(s) passing through the pre-congested
>>link.

>I think I am agreeing with you in everything you say, except on one
point 
>(if I understand you right). So I'll restate everything I believe,
tagged 
>with whether we're agreeing or disagreeing, to try to reach closure, as

>we've been going round these issues for some time (pre-PCN w-g).

>Agreement?: A gradual transition in interior admission marking is
desirable 
>as the boundary nodes can always turn this into a threshold or use it
in 
>innovative ways, to be determined.

[Joe] Generally in agreement. Not sure if gradual transition is that
important. Concern that I have is that links with different rates and
different traffic types will affect the behavior of gradual transition
from 0-100%. A link that has its admissible threshold configured at 5
Mbps and another at 400 Mbps will produce different range of gradual
transition. How is the egress node to determine how close the traffic is
to admissible threshold? 

>Agreement?: Whether the transition is gradual is a serious issue,
because a 
>distributed measurement-based admission control (DMBAC) system like PCN

>admits traffic one round trip before it knows whether it should have
done. 
>So in a flash crowd (mass calling event) admissions can overshoot if
the 
>interior admission marking only flips from 0-100% at the last instant. 
>Whereas if the interior nodes give a gradual increase, the boundary
nodes 
>can use the early warning contingency to be more conservative when
>necessary.

[Joe] Yes agree. However we will need to quantify this with simulations.
Need to point out that for some traffic there is the issue of the start
of media packets is delayed (until person answers the phone) after the
admission decisions was made. 

>Agreement: We hope and expect that traffic levels will be variable
because 
>of silence suppression etc. Then step (on-off) marking on interior
nodes 
>will be sufficient. It will still lead to a gradual increase in
admission 
>marking as the token bucket level goes back and forth across the step, 
>because it will stay increasingly on the marking side the closer the 
>average rate gets to the 'PCN lower rate' ("admission stop threshold"
in 
>your terms).

[Joe] Even for voice traffic without silence suppression the token
bucket can be made small and with the arrivals and natural termination
will generate traffic variability. 

>Agreement: It would be sufficient to standardise step marking (on-off
e.g. 
>3sm) as a minimum requirement for admission control.

[Joe] Yes. We should only standardize the marking behavior and not a
specific algorithm.

>Agreement: This would leave one case of pure and stable CBR traffic
that 
>would not give a smooth rise in marking, but would toggle from 0 to
100% on 
>the addition of the last flow.

[Joe] In theory yes, in practices there is transition point where some
packets are marked before 100% marking. However the transition point may
be fast. In a multi service network were other (non PCN) traffic will
introduce variability to the true CBR traffic. This is why we always
have de-jitter buffers even for CBR codecs

>Disagreement?: Stable CBR-like traffic won't necessarily be unusual in 
>certain networks. It is certainly possible (tho unlikely) that a
particular 
>link may be fed by a large proportion of CBR codecs without silence 
>suppression (e.g. where a network itself deploys a load of cheap codecs
for 
>PSTN-emulation). But much more likely are links where the total traffic
is 
>CBR-like even tho each flow is variable, due to statistical aggregation
of 
>very many variable flows.

[Joe] CBR sourced flows will be common and so will large PSTN gateways
in networks for a long time. I think the issue that your are raising is
that these PSTN gateways mostly generate CBR voice traffic and there
will be very little other traffic on the link to introduce traffic
variability, accept for flows starting and ending? I agree, it's a valid
scenario.

>Disagreement?: The algo shouldn't have to rely on the traffic being 
>variable to behave in the way we want. Ramp marking (as in the body of 
>draft-briscoe-twvwg-cl-phb-03.txt) creates a gradual increase in
marking 
>even for CBR-like traffic. Then the marking algo gives a more gradual 
>transition WHATEVER the traffic (unless it's locally shaped to be
absolutly 
>pure CBR).

[Joe] My view is that the defined marking behavior (algorithm) should
not rely on traffic being CBR or VBR-like. It needs to work equally well
for both types. 

I think the area where we may disagree on is does gradual transition or
any transition of marking versus on-off address the flash crowd (mass
calling event) as can be expected in telephony.

Currently, I do not believe that the gradual transition (RAMP) marking
approach or on/off as in 3sm address this because the flow is admitted
by the network at the control plain, telephone rings and not until it is
answered before any media packets are sent through the network. The time
between when the ingress node (or the network) makes the decision to
admit and time when the newly admitted flows will send packets can be
several seconds. 

My view is that early warning through transition marking will not
provide sufficient protection against over-admission. Admission control
is distributed and the ingress nodes do not know how many flows have
been admitted but are not sending any packets just yet. So I'm not
convinced that it adds real value for controlling over-admission.

>The following ASCII art illustrates this. Even for step marking, the
curve 
>of marking probability against mean arrival rate is smoother for
traffic 
>with more variance, but if the traffic doesn't have enough variance,
you 
>can push the curve smoother by using a ramp algo. The flatter the ramp,
the 
>smoother the curve.

^_
|p, mean marking probability                           |
|                                                      |
|                                                     !|
|                                                     !|
|                                                     !|
|                                                     ;|
|                                                    ,;|
|                                                    ,;|
|                                                    |;|
|                                                    |;|
|                                    variance        ;;|
|                                of total PCN       / ||
|                             traffic on link,      | ||
|                                           v       , ||
|                             OR             +---  .  ||
|                             slope of ramp  |\    ,  ||
|                                            | \  /   ||
|                                               _/    ||
|                                            __/ \    ||
|                                       ,--^^     \   ||           mean
|                         __,,,,----^^^^           \_/ |        arrival
|    /|    ______._,_=_=_=_____,,,,,,,,,,......----^\  |           rate,
+---/ | /----------------------------------------------+------------->_
      |/                                               X              x
                                              PCN lower rate

>Agreement: A gradual increase in marking will sometimes lead to a flow 
>being denied that could have been admitted. But that's unavoidable
anyway 
>if some flows are variable - we even had that trade-off to an extent
even 
>in Intserv-style admission control. However, ramp marking makes the
range 
>of rates over which you get under-admission wider than it was with just

>natural traffic variability.

[Joe] Agree. For admission control, I believe that we need to develop
methods that minimize this effect. From simulation results that I have
done to date leads me to believe that it's better to allow faster
response, as it improves utilization meaning more flows can be supported
especially when we have high aggregation as flows are terminating and
new flows being added at rate of several flows per second.

>Agreement?:
>* For a link with a large number of flows with high statistical 
>multiplexing, the benefit of artifically creating a gradual increase
using 
>ramp marking outweighs the cost. You get early warning of a flash crowd
but 
>miss the odd flow unnecessarily (when the system hits its admission
limit, 
>which should be rare anyway).

[Joe] On large links with many small flows flash crowd is of less
concern. However, we should not assume that large links will always have
many small flows. Large link could have few large flows. The other issue
that I would like to raise is that we have not discussed a potential
denial of service attack on the network. New flows are setup and
admitted but no media packets are sent for an extended period of time
and then all at once media packets are sent. I believe we need to
protect against this. 

Not sure if you need gradual transition (RAMP) marking or will just
simple transitional marking as in 3sm do? See later in email link to
simulation results. Yes RAMP marking provides early warning that you're
approaching admissible threshold, however I do not think that early
warning is sufficient of a mechanism to provide protection against
over-admission or admission control DoS attacks. 

>* For a link only carrying a small number of flows within its PCN lower

>rate, the cost of ramp marking in under-admissions outweighs its
benefit. 
>Note, this needen't be a low capacity link - it might be a high
capacity 
>link with a few large flows.
>* For a link in between - with high number of flows but not high enough

>stat mux to smooth to CBR-like, the traffic variance may give enough of
a 
>gradual increase to handle flash crowds without needing to add more 
>smoothness using ramp marking (ie cost of ramp under-admissions
outweights 
>benefit of more smoothness when you've got enough anyway).

>Agreement?: Note: links with a few flows fall outside the PCN charter,
but 
>that shouldn't stop us prefering solutions that handle such links, all 
>other issues being equal.

[Joe] Agree.

>Agreement?: If I'm right in all this, I believe we should allow and 
>encourage (but not mandate) vendors to implement ramp marking on
machines 
>targeted for PCN interior nodes (ie SHOULD implement ramp). Then ramp
is 
>available if it's needed, but can be turned off if it isn't.

[Joe] I'm not against RAMP marking. We need to verify that it really
adds value ie, it does provide sufficient protection against
over-admission due to flash crowd, DoS attacks, etc. The selection of
algorithm should be left up to the equipment vendor. 

Bob, have you done any simulations to quantify the performance? If not,
I will see if we can run some simulations with RAMP and compare it to
on/off in 3sm. 

>Agreement?: But we should advise that step marking is the best solution
(ie 
>SHOULD deploy step) if there's enough variability in the traffic anyway
(or 
>only a few flows are expected on the link).

[Joe] I think that we should state the "step marking" (need to write the
behavior for step marking) is a minimum requirement with gradual
transitional (ramp) marking optional.  We need simulation results to
quantify benefits of "ramp marking" for admission control. 

>Agreement?: But ramp marking is hard to do on much current hardware. So

>it's useful that it's not a MUST. However, if an operator needs ramp 
>marking (a risk of flash crowds and links with smoothly aggregated
traffic) 
>we should caution that inability to deploy ramp is NOT a good reason
for 
>not deploying it.

[Joe] See above. Agree.

>Disagreement: You imply that, with low packet probing rates, step
(on-off) 
>marking can determine whether to admit a new flow faster than ramp.
Given 
>both have a range over which they mark packets probabilistically, I
don't 
>believe this is the way to state the distinction between them.
Certainly 
>ramp marks packets probabilistically over a wider range of loads. But,
for 
>either algo, the ingress boundary node doesn't know whether an interior

>node is within this range or not when it probes. So it has to send as
many 
>probes in both cases in case an interior node might be in its
probabilistic 
>range of marking.

[Joe] I see your point and agree. I was thinking that there are only two
conditions, admit or stop admit that is sent to ingress node. During the
transition or early warning if a probe has one or more packets marked
the decision is to not admit the new flow. Also the density of marking
to trigger stop admission can be made service class dependent. 

My view of probing is that the ingress nodes sends small packets every
20 or 100ms until the admitted flow starts sending media packets. For
ingress-egress paths that have no packets flowing. There are two phases
to admission control. First probing is used to verify during the
application signalling phase that a new flow can be admitted. If during
the application signalling phase probe packets are marketed, admission
of new flow can be blocked by information passed to the control plain.
However if no marking is detected application signalling is informed to
proceed. Probing continues until the admitted flow starts sending
packets. If during the second phase probe packets become 100% marked,
the flow is blocked at the network layer and a message is sent to the
application control layer indicating flow admission was blocked. This
condition should happen very infrequently but it provides protection
against flash crowds and attacks on admission control system. 

>Disagreement?: In fact, ramp actually gives a much quicker probing time

>than step:
>* Step: If the queue is above the step 5% of the time due to traffic 
>variation, over a *long* time period it will indeed mark 5% of probes.
BUT 
>over a *short* period it will mark all the probes the same (queue
length 
>correlation over time).
>* Ramp: If the queue is varying around the point on the ramp that is
doing 
>5% marking, it will mark each probe with ~5% probability, independently
of 
>how it marked previous ones.
>So, with either algo you have to send the same number of probes, but
with 
>ramp you can send them back-to-back, while with step you get hardly any

>more information unless you send them spaced over a long time period
(ie a 
>few seconds). Hence ramp should be much quicker to probe.

[Joe] OK I agree that probing can be made to work with ramp. To quantify
performance differences, we would have to do simulations. 

Bob, my view on the differences between the admission stop marking
(on/off or step) in 3sm draft and RAMP.

The 3sm marking approach for admission control uses a very simple token
bucket algorithm and marking transition form 0 to 100% is based on rate
variation over the measured admissible threshold. The marking density is
directly depended on rate changes.

The RAMP marking approach has an added function where at the admission
threshold there is an algorithm that marks packet based on probability. 

Do you agree as these are the major differences?

Do you have an RAMP algorithm that you can send us so that we can
simulate to see the difference in performance?

>Pls say whether you agree or disagree with each point, so we can home
in on 
>exactly why we keep both going round this loop.

[Joe] Below is a link to simulation results of admission control using
3sm marking. http://standards.nortel.com/pcn/Admit_Cont_CBR.pdf 

This simulation is of CBR only traffic with the admissible threshold set
to 16 Mbps or 200 CBR flows. This simulation shows rate variation that
CBR voice traffic generates and behavior of 3sm marking for admission
control.

- AS-clear timer = 0.1 sec. means blocking of new flows last for 100ms
after "block admission signal" was received.
- Orange trace is the admitted traffic rate on the link.
- Pink trace shows number of flows admitted and active. 
- Red trace shows cumulative number of flows blocked.

To understand the results here is additional information.
Simulation setup:
- The flow arrival is 7.5 flows/sec.
- Mean holding time of flow is 60 seconds.
- Offered load on average is 36 Mbps or 450 flows.
- Flow arrival uses Poisson distribution.
- No probing is used in these simulations.
- Media delay limit = 0 sec. means start of sending packets is not
delayed.
- Media delay limit = 10 sec. means start of sending packets is delayed
randomly between 0 and 10 seconds.
-All flows belong to one aggregate.

Admission Control:
In simulations, when egress detects a packet marked, it sends "block
admission signal" to ingress. The block admission signal blocks
admission of new flows for a period of time, programmable 100ms or 1
sec. after which time if no block admission signal were received new
flows are admitted. The delay from marking of packet and sending of
block admission signal is programmable and we simulate with 2 and 200ms
as the RTT.

Also here is a link to more simulation results with different scenarios.
Admission control results starting on page 13. 
http://standards.nortel.com/pcn/3sM-Simulation-1.pdf

Regards, Joe.

>Cheers

>Bob

email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]] 
Sent: August 30, 2007 3:41 PM
To: Babiarz, Jozef (CAR:0S03)
Cc: Geib, Ruediger; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking

Joe,

At 15:17 27/08/2007, Jozef Babiarz wrote:
>I think there is a bit more to this issue than just different levels of
>pre-congestion.
>
>For admission control the challenge for PCN is to find out how much new
>traffic can be added on to a specific link or path and not to determine
>the level of congestion.

I agree that the AC challenge for PCN is to find how much new traffic
can 
be added, but surely not just for a specific link. The full challenge is

for any single ingress edge node to know how much it can add. But it has
to 
accept the fact that it doesn't know how many other ingress nodes are 
competing to add traffic to the same link. (See previous response to 
Ruediger - although I don't think you're asking for the same thing, but
it 
sounds like you are).

more...

>The purpose of admission control is to prevent
>congestion of the service class on link that forwards PCN traffic. PCN
>is deployed in Diffserv networks, with the understanding that PCN
>traffic is forwarded using priority scheduling.
>
>Voice with silence suppression plus calls naturally ending as well new
>calls being added generates highly variable traffic. The marking by
>interior node to indicate that PCN admission threshold is exceeded or
>not, needs to be quick to reflect true traffic levels.

Agreed

>Analysis of the
>marking density and control of response to the marking can be handled
at
>the edges. The proposed marking scheme in draft-babiarz-pcn-3sm-00.txt
>for admission control, produces the following behavior, when PCN
traffic
>is fare below the admission stop threshold, no packets are marked. As
>the variable traffic increases and some packets exceed the token bucket
>rate (admission stop threshold) they are marked. If additional new
>traffic is allowed to be admitted on to the link, more packets will
>exceed the token bucket rate therefore marking density increases
>possibly until all packets are marked. However, for pure and stable CBR
>traffic you will get a step marking (on-off) where the transition from
>no marking to all packets marked being quick.

I'm not sure which you you are saying is more desirable:
- the outcome with variable traffic (a gradual transition from 0-100%
marking)
- or the outcome for CBR traffic (a step change)?

I think you're saying that a gradual transition is desirable, but that
even 
with on-off marking you get a gradual transition as long as there's 
variation in the traffic, which there usually is.

(See later for my view)

>
>My view is that PCN should work equally well regardless of the number
of
>flows in an ingress-egress aggregate from one to many flows,

Agreed.

>as well
>should work without the need for ingress-egress aggregation concept.

If you mean by this, that a new flow shouldn't need to use information
from 
existing flows in an aggregate, I agree. That's a performance
enhancement, 
not an essential function.

>The
>so called on-off marking approach is not that dependent on the rate of
>ingress-egress traffic meaning that edge node will be able to determine
>if new flow should be admitted based on low bit rate (probe or single
>voice flow) or high bit rate flow(s) passing through the pre-congested
>link.

I think I am agreeing with you in everything you say, except on one
point 
(if I understand you right). So I'll restate everything I believe,
tagged 
with whether we're agreeing or disagreeing, to try to reach closure, as 
we've been going round these issues for some time (pre-PCN w-g).

Agreement?: A gradual transition in interior admission marking is
desirable 
as the boundary nodes can always turn this into a threshold or use it in

innovative ways, to be determined.

Agreement?: Whether the transition is gradual is a serious issue,
because a 
distributed measurement-based admission control (DMBAC) system like PCN 
admits traffic one round trip before it knows whether it should have
done. 
So in a flash crowd (mass calling event) admissions can overshoot if the

interior admission marking only flips from 0-100% at the last instant. 
Whereas if the interior nodes give a gradual increase, the boundary
nodes 
can use the early warning contingency to be more conservative when
necessary.

Agreement: We hope and expect that traffic levels will be variable
because 
of silence suppression etc. Then step (on-off) marking on interior nodes

will be sufficient. It will still lead to a gradual increase in
admission 
marking as the token bucket level goes back and forth across the step, 
because it will stay increasingly on the marking side the closer the 
average rate gets to the 'PCN lower rate' ("admission stop threshold" in

your terms).

Agreement: It would be sufficient to standardise step marking (on-off
e.g. 
3sm) as a minimum requirement for admission control.

Agreement: This would leave one case of pure and stable CBR traffic that

would not give a smooth rise in marking, but would toggle from 0 to 100%
on 
the addition of the last flow.

Disagreement?: Stable CBR-like traffic won't necessarily be unusual in 
certain networks. It is certainly possible (tho unlikely) that a
particular 
link may be fed by a large proportion of CBR codecs without silence 
suppression (e.g. where a network itself deploys a load of cheap codecs
for 
PSTN-emulation). But much more likely are links where the total traffic
is 
CBR-like even tho each flow is variable, due to statistical aggregation
of 
very many variable flows.

Disagreement?: The algo shouldn't have to rely on the traffic being 
variable to behave in the way we want. Ramp marking (as in the body of 
draft-briscoe-twvwg-cl-phb-03.txt) creates a gradual increase in marking

even for CBR-like traffic. Then the marking algo gives a more gradual 
transition WHATEVER the traffic (unless it's locally shaped to be
absolutly 
pure CBR).

The following ASCII art illustrates this. Even for step marking, the
curve 
of marking probability against mean arrival rate is smoother for traffic

with more variance, but if the traffic doesn't have enough variance, you

can push the curve smoother by using a ramp algo. The flatter the ramp,
the 
smoother the curve.

^_
|p, mean marking probability                           |
|                                                      |
|                                                     !|
|                                                     !|
|                                                     !|
|                                                     ;|
|                                                    ,;|
|                                                    ,;|
|                                                    |;|
|                                                    |;|
|                                    variance        ;;|
|                                of total PCN       / ||
|                             traffic on link,      | ||
|                                           v       , ||
|                             OR             +---  .  ||
|                             slope of ramp  |\    ,  ||
|                                            | \  /   ||
|                                               _/    ||
|                                            __/ \    ||
|                                       ,--^^     \   ||           mean
|                         __,,,,----^^^^           \_/ |        arrival
|    /|    ______._,_=_=_=_____,,,,,,,,,,......----^\  |           rate,
+---/ | /----------------------------------------------+------------->_
      |/                                               X              x
                                              PCN lower rate

Agreement: A gradual increase in marking will sometimes lead to a flow 
being denied that could have been admitted. But that's unavoidable
anyway 
if some flows are variable - we even had that trade-off to an extent
even 
in Intserv-style admission control. However, ramp marking makes the
range 
of rates over which you get under-admission wider than it was with just 
natural traffic variability.

Agreement?:
* For a link with a large number of flows with high statistical 
multiplexing, the benefit of artifically creating a gradual increase
using 
ramp marking outweighs the cost. You get early warning of a flash crowd
but 
miss the odd flow unnecessarily (when the system hits its admission
limit, 
which should be rare anyway).
* For a link only carrying a small number of flows within its PCN lower 
rate, the cost of ramp marking in under-admissions outweighs its
benefit. 
Note, this needen't be a low capacity link - it might be a high capacity

link with a few large flows.
* For a link in between - with high number of flows but not high enough 
stat mux to smooth to CBR-like, the traffic variance may give enough of
a 
gradual increase to handle flash crowds without needing to add more 
smoothness using ramp marking (ie cost of ramp under-admissions
outweights 
benefit of more smoothness when you've got enough anyway).

Agreement?: Note: links with a few flows fall outside the PCN charter,
but 
that shouldn't stop us prefering solutions that handle such links, all 
other issues being equal.

Agreement?: If I'm right in all this, I believe we should allow and 
encourage (but not mandate) vendors to implement ramp marking on
machines 
targeted for PCN interior nodes (ie SHOULD implement ramp). Then ramp is

available if it's needed, but can be turned off if it isn't.

Agreement?: But we should advise that step marking is the best solution
(ie 
SHOULD deploy step) if there's enough variability in the traffic anyway
(or 
only a few flows are expected on the link).

Agreement?: But ramp marking is hard to do on much current hardware. So 
it's useful that it's not a MUST. However, if an operator needs ramp 
marking (a risk of flash crowds and links with smoothly aggregated
traffic) 
we should caution that inability to deploy ramp is NOT a good reason for

not deploying it.

Disagreement: You imply that, with low packet probing rates, step
(on-off) 
marking can determine whether to admit a new flow faster than ramp.
Given 
both have a range over which they mark packets probabilistically, I
don't 
believe this is the way to state the distinction between them. Certainly

ramp marks packets probabilistically over a wider range of loads. But,
for 
either algo, the ingress boundary node doesn't know whether an interior 
node is within this range or not when it probes. So it has to send as
many 
probes in both cases in case an interior node might be in its
probabilistic 
range of marking.

Disagreement?: In fact, ramp actually gives a much quicker probing time 
than step:
* Step: If the queue is above the step 5% of the time due to traffic 
variation, over a *long* time period it will indeed mark 5% of probes.
BUT 
over a *short* period it will mark all the probes the same (queue length

correlation over time).
* Ramp: If the queue is varying around the point on the ramp that is
doing 
5% marking, it will mark each probe with ~5% probability, independently
of 
how it marked previous ones.
So, with either algo you have to send the same number of probes, but
with 
ramp you can send them back-to-back, while with step you get hardly any 
more information unless you send them spaced over a long time period (ie
a 
few seconds). Hence ramp should be much quicker to probe.

Pls say whether you agree or disagree with each point, so we can home in
on 
exactly why we keep both going round this loop.

Cheers

Bob

>Regards, Joe
>email:[email-masked]
>Telephone:613-763-6098
>-----Original Message-----
>From: Geib, Ruediger [mailto:[email-masked]]
>Sent: August 24, 2007 3:09 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking
>
>Lachlan, Bob,
>
>you both seem to agree that ramp marking is the best solution.
>Picking up Lachlan's pretty sound arguments on different thresholds
>for different types of incoming calls - what you describe is
>estimating the available (not consumed) PCN bandwidth rather than
>just a "pre congestion notification", I think.
>If there's a simple solution to realize this idea, PCN should
>investigate it. This could be helpful if there's a new call to be
>admitted and no PCN flow exists between two gateways. The question
>then would be, whether a certain bandwidth is available, rather
>than "any congestion visible".

ToDo:

* an edge ingress node needs to use its own knowledge of its own rate 
contribution to the problem (x).
0 <= p <= 1

Bob

>Regards,
>
>Ruediger
>
>
>|Lachlan wrote:
>|I believe that the marking scheme should carry as much information as
>|possible about the network state, and that thresholding should be done
>|as late as possible (at the decision-making end-points).  The more
>|information the decision-making entity has, better the decisions it
>|can make.
>|
>|If things like thresholding are done where the admission decisions are
>|made, there is also a smoother upgrade path for changes in the
>|admission rules.  For example, an operator may want to apply different
>|thresholds applied to different types of incoming calls.  If routers
>|provide a single threshold, this can't be implemented at a later
>|stage.  Similarly, an operator may want to admit a certain percentage
>|of traffic dependent on the congestion level, rather than admitting
>|all or none.
>
>|Bob wrote:
>|[BB] The problem we were trying to solve with ramp marking was the
>|reverse:
>|we were looking for a marking algo that produced a smooth increase in
>|marking over a wider range of loads. The edge nodes can always turn a
>|smooth rise into a toggle at a specific threshold marking level.
>
>
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pcn

________________________________________________________________________
____
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
645196 

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