Subject: [PCN] Re: Questions on LC-PCN draft version 01

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 01 Nov 2007 06:34:40 +0000

Hi Anna

Thank you very much for your comments!
Before answering to your comments, see in line below, I would like to
explain in an abstract way the LC-PCN algorithm.

* Setting the thresholds at PCN_interior_nodes:
-----------------------------------------------
In order to calculate the PCN_upper_rate we use two parameters:
Maximum PHB capacity: that is the maximum capacity that can be
supported by a PCN_interior_node
Termination_offset_rate: that is an absolute rate value that should be
set equal into all PCN_interior_nodes. Note that this value is used by
PCN_interior_nodes to calculate their PCN_upper_rate and also during the
situation that a PCN_interior_node is in flow termination state and it
receives PCN_marked packets. Please see pseudo code on page 20.
This value must be set equal into all PCN_interior_nodes such that all
these nodes will know when to take into account the incoming PCN_marked
packets and when not.

The PCN_upper_rate is then found as:
PCN_upper_rate = "Maximum PHB capacity" - Termination_offset_rate

The PCN_lower_rate is configured in all PCN_interior-nodes and it can be
calculated in the following way:
PCN_lower_rate = PCN_upper_rate - Admission_offset_rate

The Admission_offset_rate is an absolute rate value and it is equal in
all PCN_interior_nodes and PCN_egress_nodes. Note that this value is
used by PCN_interior_nodes to calculate their PCN_lower_rate and the
PCN_egress_nodes to calculate their PCN_upper_rate_egress. Furthermore,
this value is used by the PCN_interior_nodes also during the situation
that a PCN_interior_node is in admission control state and it receives
PCN_marked packets. Please see pseudo code on page 13.
This value must be set equal into all PCN_interior_nodes such that all
these nodes will know when to take into account the incoming PCN_marked
packets and when not. Note that a PCN_interior_node can PCN_mark packets
up to an excess rate equal to the Admission_offset_rate. If the exess
rate in an PCN_interior_node is higher than the Admission_offset_rate,
then the PCN_interior_node changes state from admission control state to
flow termination state.

* Setting the thresholds at PCN_egress_nodes:
---------------------------------------------
The question is how to calculate the threshold that defines when a
PCN_egress_node goes into the admission control state.
One way to do that is to consider that when the PCN_egress_node receives
a PCN_marked packet it will mean that at least one PCN_interior_node
started to be admission control congested and therefore it will go from
Normal state to admission control state. Of course this will somehow
might provide some errors, because there might be situations that this
consideration might be to conservative. Therefore, we use a percentage
of received PCN_marking encoded packets in proportion to total rate of
received packets. In this version of the draft we call this value as:
PCN_lower_rate_egress. This is wrong.
What we should say is:
PCN_lower_rate_egress: is equal to incoming_PCN_marking_rate, when:
(incoming_PCN_marking_rate/measured PHB rate) = to a preconfigured
percentage, say 1%. From now on I denote this percentage as:
PCN_lower_percentage_egress.
Thus we can say that a PCN_egress_node changes from Normal state to
admission control state when
incoming_PCN_marking_rate/measured PHB rate > PCN_lower_percentage_egress.
Where,
incoming_PCN_marking_rate = N * input_PCN_marking_bytes/T
Where,
input_PCN_marking_bytes = received number of "PCN_marking" encoded
packets during measurement period T.

Now we defined the condition that the PCN_egress_node changes state from
Normal state to admission control state. But how will the PCN_egress_node
change state from admission control state to flow termination state.
In order to explain this, it is imporatnt to note that each
PCN_interior_node that is in admission control state it can PCN_mark
packets up to a value equal to Admission_offset_rate. Furthermore, if a
PCN_interior_node receives incoming PCN_marked packets and is in the
addmission control state, it will not remark any packets if the excess
rate is equal or lower than the incoming_PCN_marking_rate, see page 13.
Furthermore, if we will consider as normal situations the situations
that no ECMP occurs and that all flows belonging to the same
ingress-egress aggregate will use the same path from PCN_ingress to
PCN_egress, this will mean that when the PCN_egress_node receives, for
the given ingress-egress aggregate an excess rate equal to
Admission_offset_rate it will have to change from admission control
state to flow termination state.
Thus in this case the second threshold, that in this case is a rate and
not a percentage, can be calculated as follows:
PCN_upper_egress_rate = PCN_lower_egress_rate + Admission_offset_rate.
However, there are some corner cases, that mainly occur when the
different congestion points (admission control congested
PCN_interior_nodes) on the same path are not simulataneously starting to
be congested. Therefore we use the multicongestion_error parameter to
identify the error bound that ocurs due to these corner cases. Note that
this error bound can be e.g., predefined ones off line by the operator,
by studying the network topology and/or studying how often such corner
cases could occur and/or doing off line measurements. Therefore we use:
PCN_upper_rate_egress = PCN_lower_rate_egress + Admission_offset_rate +/-
multicongestion_error

* How the states of operation in PCN_interior_nodes are being changed?
---------------------------------------------------------------------
This is explained on page 17, 18, by using Figure 4.

Change from Normal state to Admission control state: event A
Occurs when:
Measured PHB rate > PCN_lower_rate

Change from Admission control state to Flow Termination  state: event B
Occurs when:
Measured PHB rate > PCN_upper_rate

* How the states of operation in PCN_egress_nodes are being changed?
---------------------------------------------------------------------
This is explained on page 21, 22. Note that the description of event A on
page 21 has to be modified to avoid the confusions that were caused up
to now, see explanation given above.

Change from Normal state to Admission control state: event A
Occurs when:
incoming_PCN_marking_rate/measured PHB rate) > PCN_lower_percentage_egress
As explained above:
IF ((incoming_PCN_marking_rate/measured PHB rate) =
PCN_lower_percentage_egress)
THEN PCN_lower_egress_rate = incoming_PCN_marking_rate

Change from Admission control state to flow termination state: event B
Occurs when:
incoming_PCN_marking_rate > PCN_upper_rate_egress

It is important to note that also the explanation of event C on page 21,
has to be modified to avoid the confusions that were caused up to now,
see explanation given above:
Change from Admission control state to Normal state:
Occurs when:
incoming_PCN_marking_rate/measured PHB rate) =<
PCN_lower_percentage_egress

* Generated excess rate by an PCN_interior_node operating in admission
control state.
-------------------------------------------------------------

The excess rate = signaled_overload_rate.
The maximum excess rate that a PCN_interior_node can calculate in
admission control state is equal to Admission_offset_rate, see
explanation above.
The number of bytes that are remarked, signaled_remarked_bytes depend on
the value of calculated excess rate (signaled_overload_rate), the value
of the Admission_offset_rate and the value of the
incoming_PCN_marking_rate, see pseudo code on page 13.

Note that all packets that are passing through a congested
PCN_interior_node an are not being PCN_marked by the PCN_interior_node
have to be remarked using the PCN_Affected_marking.

Regarding probes, the probe packets that are passing through a congested
node are either PCN_marked or PCN_Affected_marked.

* Generating excess rate by an PCN_interior_node operating in flow
termination state:
----------------------------------------------------------------
The excess rate = signaled_overload_rate.
Note that the calculation of the signaled_overload_rate is different than
in the situation that the PCN_Interior_node operates in admission
control state, see page 19 and 20. This is due to the fact that a
sliding window is used to solve an undershooting problem, see discussion
on page 19.
The number of bytes that are remarked, signaled_remarked_bytes depend on
the value of calculated excess rate (signaled_overload_rate), the value
of the Termination_offset_rate and the value of the
incoming_PCN_marking_rate, and the see pseudo code on page 20.

Note that all packets that are passing through a congested
PCN_interior_node an are not being PCN_marked by the PCN_interior_node
have to be remarked using the PCN_Affected_marking.

* Providing admission control at PCN_egress_nodes:
--------------------------------------------------
 When the PCN_egress_node is operating in admission control state than a
flow that is requesting admission into the PCN domain can b etreated in
the following way:

If no probing is used, the request for admission can be accomplished by
using an external to PCN signaling protocol. In this case when the
request arrives at a PCN_egress_node that operates in admission control
state then the request is rejected. If it operates in Normal state is
accepted.

If probing is used, the request for admission is accomplished by using
probe packets. In this case when the probe arrives at a PCN_egress_node
and it is either PCN_marking or PCN_Affected_marking encoded is
rejected. Otherwise is accepted.
Note that probes can only be used when PCN_Affected_marking is appled in
whole PCN domain. Otherwise, the admission control procedure will work
by using e.g., an external signaling protocol used between
PCN_ingress_nodes and PCN_egress_nodes.

* Providing flow termination at PCN_egress_nodes:
--------------------------------------------------

When a PCN_egress_node operates on flow termination it calculates the
incoming excess rate (incoming_PCN_marking_rate).
By using the excess rate the PCN_egress_node calclates the numer of flows
that have to be terminated using the pseudo code given on page 23. Note
that the PCN_egress_node has to maintain per flow reservation states.
The information contained in the per flow states is used for the
calculation of the flow that have to be terminated, see pseudocode on
page 23. Note also that this pseudo code uses priority clases, but it
operates when also no priority clases are used by setting
Maximum_priority = 0
Where, 0 =< priority_class =< Maximum_priority

Below, I am providing some answers to your comments!

> -----Original Message-----
> From: Anna Charny (acharny) [mailto:[email-masked]]
> Sent: zondag 7 oktober 2007 21:40
> To: [email-masked]; Georgios Karagiannis; Lars Westberg
> (KI/EAB)
> Cc: [email-masked]
> Subject: Questions on LC-PCN draft version 01
>
> Dear authors of the LC-PCN draft,
>
> Am I right that there has been no response yet to Phil's questions
> (attached at the end) on the new version of your draft below (I
> checked the pcn list and it does not seem it went there)? If the
> response was sent, can you resend it please?
>
> I have many of the same questions, and also a few additional ones.
> Here are some of them.
>
> 1) I do not understand whether pcn-lower_rate_egress and
> pcn_upper_rate ingress are expressed as a fraction of the total rate
> (a unitless entity, analogous to CLE) or an absolute value (in bits or
> bytes per second). The text seems to be contradictory on this point:
>
> on page 8 it is a fraction:
>
> "PCN_lower_rate_egress = predefined percentage of received
> PCN_marking",
>
> while on page 13 it is an absolute rate:
>
> "If the incoming_PCN_marking_rate is higher than a preconfigured
> PCN_lower_rate_egress, ..." where the
>
> (Incoming_PCN_marking_rate is clearly defined as abslolue rate on page
> 12: "Where the "incoming_PCN_marking_rate" is calculated as follows:
> incoming_PCN_marking_rate = (received number of "PCN_marking"
> DSCP during T)* N)/T;)

Georgios: You are right, please see discussion above on paragaph denoted
as:
"Setting the thresholds at PCN_egress_nodes".

We use a percentage of received PCN_marking encoded packets in proportion
to total rate of received packets to define when a PCN_egres_node goes
from Normal state to admission control state. In this version of the
draft we call this value as: PCN_lower_rate_egress. This is wrong.
What we should say is:
PCN_lower_rate_egress: is equal to incoming_PCN_marking_rate, when:
(incoming_PCN_marking_rate/measured PHB rate) = to a preconfigured
percentage, say 1%. From now on I denote this percentage as:
PCN_lower_percentage_egress.
Thus we can say that a PCN_egress_node changes from Normal state to
admission control state when
incoming_PCN_marking_rate/measured PHB rate > PCN_lower_percentage_egress.
Where,
incoming_PCN_marking_rate = N * input_PCN_marking_bytes/T
Where,
input_PCN_marking_bytes = received number of "PCN_marking" encoded
packets during measurement period T.

>
> 2) Regarding the question above,
>
> * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are
> absolute rates, then how do you choose that abslolute rate value,
> given that the rates of ingress-egress aggregates at the same ingress
> may be vastly different in magnitude?

Georgios: See explanation above! Hopefully this misundersatnding is also
solved!

>
> *if, however, pcn_lower_rate_eggress (and
> pcn_uppre-rate_egress) are ratios, then what is the guidance of
> setting these ratios so that the egress can always tell admission
> state from the termination state, given that the same marking is used
> for admission and termination marking?
> Specifically, suppose at the bottleneck pcn_lower_threshold is set to
> X, and pcn_upper_threshold to aX with some a>1 (assume for example
> a=1.5).
> How does the egress node tell between the conditions when the total
> pcn traffic on the bottleneck is 1.1X (which is the state wnen
> admission is needed but termination is not, - in this case
> (1.1X-X)/X=0.1 traffic is pcn-marked), and the case when the total
> traffic on the bottleneck is 1.1aX, which is the case when termination
> is needed, and (1.1ax-ax)/ax=0.1), if in both cases the ratio between
> marked and total traffic is the same value 0.1?

Georgios: In order to solve the above described problems,
the thresholds used in the PCN_interior_nodes and PCN_egress_nodes are
using:
the Admission_offset_rate that is an absolute rate value which is set
equal into whole PCN domain.

Note that the maximum excess rate that a PCN_interior_node can calculate
in admission control state is equal to Admission_offset_rate. If the
excess rate is higher than the Admission_offset_rate then the node
changes from admission control state to flow termination state.

Please see all details that I have provided at the top of this email. In
particular, check the paragraphs denoted above as:
"Setting the thresholds at PCN_interior_nodes"
"Setting the thresholds at PCN_egress_nodes"
"Generated excess rate by an PCN_interior_node operating in admission
control state"

>
> 3) On page 9, multicongestion error error is introduced, but the text
> is silent on how this error is defined and what is it set to (if it is
> a configuration parameter), or how it is measured (if it is something
> that is being measured). Can you explain, please?

Georgios:
Please see the paragraph denoted above as "Setting the thresholds at
PCN_egress_nodes"

Best regards,
Georgios

>
> I have some more questions, including sharing those asked by Phil in
> the attached message), but I will stop now, as I hope clarifications
> on the above (and Phil's) questions will help understand the draft
> better...
>
> Thank you in advance for clarifying all this.
>
> Anna

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

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 1 Nov 2007 12:00:28 -0400

Hi Georgios,

A few more clarification questions:

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 2:35 AM
> To: Anna Charny (acharny); [email-masked]; Lars 
> Westberg (KI/EAB)
> Cc: [email-masked]
> Subject: Re: Questions on LC-PCN draft version 01
> 
> Hi Anna
> 
> Before answering to your comments, see in line below, I would 
> like to explain in an abstract way the LC-PCN algorithm.
> 
> Maximum PHB capacity: that is the maximum capacity that can 
> be supported by a PCN_interior_node
> Termination_offset_rate: that is an absolute rate value that 
> should be set equal into all PCN_interior_nodes. Note that 
> this value is used by PCN_interior_nodes to calculate their 
> PCN_upper_rate and also during the situation that a 
> PCN_interior_node is in flow termination state and it 
> This value must be set equal into all PCN_interior_nodes such 
> that all these nodes will know when to take into account the 
> incoming PCN_marked packets and when not.
> 

So if you have a link of 10 Mbps and a link of 40 Mbps (say each is
allowed to use all bandwidth for PCN, for simplicity), then they both
use the same *absolote* value of the termination-offset-rate?.  So If I
wanted to have  PCN-upper-rate 20% below my link capacity on all links,
I would not be able to do so with this approach?  A larger link would
have a smaller relative safety margin, then...  Same comment for the
difference between admission and termination - the relative difference
between admission and termination threshods (Pcn-lower-rate and
pcn-upper-rate) is global, so the larger links have a smaller relative
difference between admission and termination thresholds. Right?

> The PCN_lower_rate is configured in all PCN_interior-nodes 
> and it can be calculated in the following way:
> The Admission_offset_rate is an absolute rate value and it is 
> equal in all PCN_interior_nodes and PCN_egress_nodes. Note 
> that this value is used by PCN_interior_nodes to calculate 
> their PCN_lower_rate and the PCN_egress_nodes to calculate 
> their PCN_upper_rate_egress. Furthermore, this value is used 
> by the PCN_interior_nodes also during the situation that a 
> PCN_interior_node is in admission control state and it 
> receives PCN_marked packets. Please see pseudo code on page 13.
> This value must be set equal into all PCN_interior_nodes such 
> that all these nodes will know when to take into account the 
> incoming PCN_marked packets and when not. Note that a 
> PCN_interior_node can PCN_mark packets up to an excess rate 
> equal to the Admission_offset_rate. If the exess rate in an 
> PCN_interior_node is higher than the Admission_offset_rate, 
> then the PCN_interior_node changes state from admission 
> control state to flow termination state.

OK.

> The question is how to calculate the threshold that defines 
> when a PCN_egress_node goes into the admission control state.
> One way to do that is to consider that when the 
> PCN_egress_node receives a PCN_marked packet it will mean 
> that at least one PCN_interior_node started to be admission 
> control congested and therefore it will go from Normal state 
> to admission control state. Of course this will somehow might 
> provide some errors, because there might be situations that 
> this consideration might be to conservative. Therefore, we 
> use a percentage of received PCN_marking encoded packets in 
> proportion to total rate of received packets. In this version 
> of the draft we call this value as:
> (incoming_PCN_marking_rate/measured PHB rate) = to a 
> preconfigured percentage, say 1%. From now on I denote this 
> percentage as:

In the draft, pcn_lower- and -upper_rate_egress seem to be defined on a
per *ingress-egress-pair basis*.
Is that correct? 

> Thus we can say that a PCN_egress_node changes from Normal 
> state to admission control state when 
> Where, input_PCN_marking_bytes = received number of 
> "PCN_marking" encoded packets during measurement period T.

Again, is it per ingress-egress pair, or not?

> 
> Now we defined the condition that the PCN_egress_node changes 
> state from Normal state to admission control state. But how 
> will the PCN_egress_node change state from admission control 
> PCN_interior_node that is in admission control state it can 
> PCN_mark packets up to a value equal to 
> Admission_offset_rate. Furthermore, if a PCN_interior_node 
> receives incoming PCN_marked packets and is in the addmission 
> control state, it will not remark any packets if the excess 
> Furthermore, if we will consider as normal situations the 
> situations that no ECMP occurs and that all flows belonging 
> to the same ingress-egress aggregate will use the same path 
> from PCN_ingress to PCN_egress, this will mean that when the 
> PCN_egress_node receives, for the given ingress-egress 
> aggregate an excess rate equal to Admission_offset_rate it 
> will have to change from admission control state to flow 
> termination state.
> Thus in this case the second threshold, that in this case is 
> a rate and not a percentage, can be calculated as follows:

Here is where I am afraid I am fundamentally confused.
Pcn_lower-egress_rate seems to have beed redefined above as a percentage
threshold, but it is 
an absolute rate again here. Perhaps you just mean that
Pcn-lower-egress-rate = 
pcn_lower_egress_percentage *
total-measured-rate-of-this-ingress-egrees-aggregate/100?
So pcn-lower-egress-rate then is just the fraction of the total rate of
the ingress-egress aggregate corresponding to the configured percentage
threshold. Right?

Assuming the above is correct, I cannot see how the system will work
correctly.  Consider the following example.  A bottleneck link of
capacity 100 mbps , pcn-termination-offset of 40mbps and
pcn-admission-offset of 30 mbps is shared by 100 ingress-egress
aggregates, each with the total pcn rate of 1 mbps. On this link
pcn-upper-threshold is 60mbps, and pcn-lower-threshold is 30mbps.
Suppose further that all 100 ingress-egress aggregates go to different
egress nodes (and suppose for simplicity there is no other traffic going
to these egresses). The bottleneck link is clearly in the termination
state, as the total rate of pcn traffic on this link is 100 mbps which
is above the pcn-upper-threshold. This means we want the egress nodes to
somehow recognise this state and get into the termination mode.   But it
seems in this example the egresses can't ever recognize that the system
is in the termination mode. See below.

Suppose pcn-lower-egress-percentage is set to w% (0<w<=100).  Then, each
of these egresses will compute the (absolute) pcn-lower-egress-rate as
total pcn traffic of the ingress-egress aggregate it sees (which is 1
mbps) times the pcn_lower_egress_percentage/100, so it will get
pcn-lower-egress-rate= w* 0.01 Mbps.
According to your explanation above, it will then compute
Pcn-upper-egress-rate=pcn-lower-egress-rate+Admission-offset-rate=
w*0.01 mbps+30mbps >= 30 mbps (for all possible settings of w).

So our pcn-upper-egress rate is always greater than 30 Mbps, while the
entire rate of pcn traffic the egress will ever see is *at most* 1 Mbps
(because it is plainly the total rate of the single ingress-egress
aggreate that goes to this egress).  So, regardless of the actual amount
of marked traffic in this egress-egress aggregate, the absolute excess
rate of this ingress-egress aggregate will never be above 1mbps either.
In turn that means that the pcn-upper-egress-rate will NEVER be exceeded
(because pcn-upper-egress-rate is so much larger than the total rate of
the pcn traffic at the egress). In turn, that appears to mean that in
this scenario none of the egresses will ever end up in termination
state, and so termination will never occur.  That does not seem right. 

I would appreciate any help in clarifying this. 

Anna

> However, there are some corner cases, that mainly occur when 
> the different congestion points (admission control congested
> PCN_interior_nodes) on the same path are not simulataneously 
> starting to be congested. Therefore we use the 
> multicongestion_error parameter to identify the error bound 
> that ocurs due to these corner cases. Note that this error 
> bound can be e.g., predefined ones off line by the operator, 
> by studying the network topology and/or studying how often 
> such corner cases could occur and/or doing off line 
> measurements. Therefore we use:
> PCN_upper_rate_egress = PCN_lower_rate_egress + 
> Admission_offset_rate +/- multicongestion_error
> 
> Change from Admission control state to Flow Termination  
> state: event B Occurs when:
> This is explained on page 21, 22. Note that the description 
> of event A on page 21 has to be modified to avoid the 
> confusions that were caused up to now, see explanation given above.
> 
> incoming_PCN_marking_rate/measured PHB rate) > 
> PCN_lower_percentage_egress As explained above:
> Change from Admission control state to flow termination 
> state: event B Occurs when:
> It is important to note that also the explanation of event C 
> on page 21, has to be modified to avoid the confusions that 
> were caused up to now, see explanation given above:
> * Generated excess rate by an PCN_interior_node operating in 
> admission control state.
> The maximum excess rate that a PCN_interior_node can 
> calculate in admission control state is equal to 
> Admission_offset_rate, see explanation above.
> The number of bytes that are remarked, 
> signaled_remarked_bytes depend on the value of calculated 
> excess rate (signaled_overload_rate), the value of the 
> Admission_offset_rate and the value of the 
> PCN_interior_node an are not being PCN_marked by the 
> PCN_interior_node have to be remarked using the PCN_Affected_marking.
> 
> 
> Regarding probes, the probe packets that are passing through 
> a congested node are either PCN_marked or PCN_Affected_marked.
> 
> * Generating excess rate by an PCN_interior_node operating in 
> flow termination state:
> Note that the calculation of the signaled_overload_rate is 
> different than in the situation that the PCN_Interior_node 
> operates in admission control state, see page 19 and 20. This 
> is due to the fact that a sliding window is used to solve an 
> undershooting problem, see discussion on page 19.
> The number of bytes that are remarked, 
> signaled_remarked_bytes depend on the value of calculated 
> excess rate (signaled_overload_rate), the value of the 
> Termination_offset_rate and the value of the 
> PCN_interior_node an are not being PCN_marked by the 
> PCN_interior_node have to be remarked using the PCN_Affected_marking.
> 
>  When the PCN_egress_node is operating in admission control 
> state than a flow that is requesting admission into the PCN 
> domain can b etreated in the following way:
> 
> If no probing is used, the request for admission can be 
> accomplished by using an external to PCN signaling protocol. 
> In this case when the request arrives at a PCN_egress_node 
> that operates in admission control state then the request is 
> rejected. If it operates in Normal state is accepted.
> 
> If probing is used, the request for admission is accomplished 
> by using probe packets. In this case when the probe arrives 
> at a PCN_egress_node and it is either PCN_marking or 
> PCN_Affected_marking encoded is rejected. Otherwise is accepted.
> Note that probes can only be used when PCN_Affected_marking 
> is appled in whole PCN domain. Otherwise, the admission 
> control procedure will work by using e.g., an external 
> signaling protocol used between PCN_ingress_nodes and 
> PCN_egress_nodes.
> 
> When a PCN_egress_node operates on flow termination it 
> calculates the incoming excess rate (incoming_PCN_marking_rate).
> By using the excess rate the PCN_egress_node calclates the 
> numer of flows that have to be terminated using the pseudo 
> code given on page 23. Note that the PCN_egress_node has to 
> maintain per flow reservation states.
> The information contained in the per flow states is used for 
> the calculation of the flow that have to be terminated, see 
> pseudocode on page 23. Note also that this pseudo code uses 
> priority clases, but it operates when also no priority clases 
> are used by setting Maximum_priority = 0 Where, 0 =< 
> priority_class =< Maximum_priority
> 
> 
> 
> We use a percentage of received PCN_marking encoded packets 
> in proportion to total rate of received packets to define 
> when a PCN_egres_node goes from Normal state to admission 
> control state. In this version of the draft we call this 
> value as: PCN_lower_rate_egress. This is wrong.
> What we should say is:
> (incoming_PCN_marking_rate/measured PHB rate) = to a 
> preconfigured percentage, say 1%. From now on I denote this 
> percentage as:
> Thus we can say that a PCN_egress_node changes from Normal 
> state to admission control state when 
> Where, input_PCN_marking_bytes = received number of 
> "PCN_marking" encoded packets during measurement period T.
> 
> 
> >
> absolute 
> > rates, then how do you choose that abslolute rate value, given that 
> > the rates of ingress-egress aggregates at the same ingress may be 
> > vastly different in magnitude?
> 
> Georgios: See explanation above! Hopefully this 
> misundersatnding is also solved!
> 
> >
> Georgios: In order to solve the above described problems, the 
> thresholds used in the PCN_interior_nodes and PCN_egress_nodes are
> using:
> the Admission_offset_rate that is an absolute rate value 
> which is set equal into whole PCN domain.
> 
> Note that the maximum excess rate that a PCN_interior_node 
> can calculate in admission control state is equal to 
> Admission_offset_rate. If the excess rate is higher than the 
> Admission_offset_rate then the node changes from admission 
> control state to flow termination state.
> 
> Please see all details that I have provided at the top of 
> this email. In particular, check the paragraphs denoted above as:
> "Generated excess rate by an PCN_interior_node operating in 
> admission control state"
> 
> 
> 
> >
> Please see the paragraph denoted above as "Setting the 
> thresholds at PCN_egress_nodes"
> 
> 
> Best regards,
> Georgios
> 
> 
> >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 02 Nov 2007 16:20:23 +0000

Hi Anna

Please see in line!

On 11/1/2007, "Anna Charny (acharny)" <[email-masked]> wrote:

>use the same *absolote* value of the termination-offset-rate?.

Georgios: Yes, you are right! This has to do with the importance of using
the Termination_offset_rate. We will motivate this in the following
version of the draft.

> So If I
>have a smaller relative safety margin, then...

Georgios: Yes, this can be considered as a disadvantage. However, there
might be other ways of preconfiguring each PCN_interior_node to know the
termination_offset rate used by each neighbour PCN_interior_node. Then
the pseudocode on page 20 will have to use the Termination_offset_rate
associated with the incoming link from where the incoming PCN_marked
packets are arriving. Then this constraint can be avoided.

>Same comment for the

Georgios: No, because the Admission_offset_rate is an absolute value!
So this difference is globally equal.

>per *ingress-egress-pair basis*.

georgios: Yes, it is correct!
>Again, is it per ingress-egress pair, or not?

georgios: Yes, it is correct!

>the ingress-egress aggregate corresponding to the configured percentage

Georgios: I think I could not explain and translate what I wanted to do
in the right way!
A better way of expressing the need of using a rate of percentage of the
received PCN_marking encoded packets, would be the following:

Pcn-lower-egress-rate = pcn_lower_egress_percentage *
Admission_offset_rate

This means that event_A in Section 4.2.3 will be activated when
incoming_PCN_marking_rate > pcn_lower_egress_percentage *
Admission_offset_rate
or when:
incoming_PCN_marking_rate > Pcn-lower-egress-rate

This means that the PCN_egress_ node does not change to admission control
state when at least one PCN_marked packet arrives, but it changes when
the incoming_PHB_marking rate equals a percentage of the
Admission_offset_rate. This is due to the fact that
Admission_offset_rate is used by the interioe nodes to change from
admission control state to flow termination state.

>state, and so termination will never occur. That does not seem right.

Georgios: Thank you for the given example, which stimulated me to better
translate what I wanted to specify and what I have written down.
Please see above that I defned:
Pcn-lower-egress-rate = pcn_lower_egress_percentage *
Admission_offset_rate

The situation that you described cannot (often) occur
because the difference between the admission control threshold and flow
termination threshold at the egress is equal to Admission_offset_rate +/-
multicongestion_error. Note that the Admission_offset_rate is an
absolute rate value. The multicongestion_error is used to identify the
bounds that certain situations occur where the PCN_egreess_ node should
have been in flow termination state but it is not. Please see previous
discussions on this.

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 2 Nov 2007 14:27:55 -0400

Hi Georgios,

Still something does not seem right.  So let me restate my current
understanding:

At the internal node:

Pcn-upper-rate = max pcn capacity  - termination-offset-rate
Pcn-lower-rate = pcn-upper rate - admission-offset rate

(both offsetas are global values)

At the egress:

Pcn-lower-egress-percentage - a configured percentage
Pcn-lower-egress-rate = 

> Sent: Friday, November 02, 2007 12:20 PM
> Subject: RE: Questions on LC-PCN draft version 01
> 
> Hi Anna
> 
> >> Termination_offset_rate: that is an absolute rate value 
> that should 
> >> be set equal into all PCN_interior_nodes. Note that this value is 
> >> used by PCN_interior_nodes to calculate their 
> PCN_upper_rate and also 
> >> during the situation that a PCN_interior_node is in flow 
> termination 
> >> state and it receives PCN_marked packets. Please see 
> pseudo code on 
> >> page 20.
> >> This value must be set equal into all PCN_interior_nodes such that 
> >> all these nodes will know when to take into account the incoming 
> >> PCN_marked packets and when not.
> >>
> Georgios: Yes, you are right! This has to do with the 
> importance of using the Termination_offset_rate. We will 
> motivate this in the following version of the draft.
> 
> > So If I
> Georgios: Yes, this can be considered as a disadvantage. 
> However, there might be other ways of preconfiguring each 
> PCN_interior_node to know the termination_offset rate used by 
> each neighbour PCN_interior_node. Then the pseudocode on page 
> 20 will have to use the Termination_offset_rate associated 
> with the incoming link from where the incoming PCN_marked 
> >> The Admission_offset_rate is an absolute rate value and it 
> is equal 
> >> in all PCN_interior_nodes and PCN_egress_nodes. Note that 
> this value 
> >> is used by PCN_interior_nodes to calculate their 
> PCN_lower_rate and 
> >> the PCN_egress_nodes to calculate their PCN_upper_rate_egress. 
> >> Furthermore, this value is used by the PCN_interior_nodes 
> also during 
> >> the situation that a PCN_interior_node is in admission 
> control state 
> >> and it receives PCN_marked packets. Please see pseudo code on page 
> >> 13.
> >> This value must be set equal into all PCN_interior_nodes such that 
> >> all these nodes will know when to take into account the incoming 
> >> PCN_marked packets and when not. Note that a PCN_interior_node can 
> >> PCN_mark packets up to an excess rate equal to the 
> >> Admission_offset_rate. If the exess rate in an 
> PCN_interior_node is 
> >> higher than the Admission_offset_rate, then the PCN_interior_node 
> >> changes state from admission control state to flow 
> termination state.
> >
> >OK.
> >
> >>
> >> One way to do that is to consider that when the PCN_egress_node 
> >> receives a PCN_marked packet it will mean that at least one 
> >> PCN_interior_node started to be admission control congested and 
> >> therefore it will go from Normal state to admission 
> control state. Of 
> >> course this will somehow might provide some errors, because there 
> >> might be situations that this consideration might be to 
> conservative. 
> >> Therefore, we use a percentage of received PCN_marking encoded 
> >> packets in proportion to total rate of received packets. In this 
> >> version of the draft we call this value as:
> >> incoming_PCN_marking_rate = N * input_PCN_marking_bytes/T Where, 
> >> Now we defined the condition that the PCN_egress_node 
> changes state 
> >> from Normal state to admission control state. But how will the 
> >> PCN_egress_node change state from admission control state to flow 
> >> termination state.
> >> packets up to a value equal to Admission_offset_rate. 
> Furthermore, if 
> >> a PCN_interior_node receives incoming PCN_marked packets and is in 
> >> the addmission control state, it will not remark any 
> packets if the 
> >> excess rate is equal or lower than the 
> incoming_PCN_marking_rate, see 
> >> page 13.
> situations 
> >> PCN_egress, this will mean that when the PCN_egress_node receives, 
> >> for the given ingress-egress aggregate an excess rate equal to 
> >> Thus in this case the second threshold, that in this case 
> is a rate 
> >> and not a percentage, can be calculated as follows:
> >Pcn_lower-egress_rate seems to have beed redefined above as a 
> >percentage threshold, but it is an absolute rate again here. Perhaps 
> >you just mean that Pcn-lower-egress-rate = 
> pcn_lower_egress_percentage 
> >* total-measured-rate-of-this-ingress-egrees-aggregate/100?
> Georgios: I think I could not explain and translate what I 
> wanted to do in the right way!
> A better way of expressing the need of using a rate of 
> percentage of the received PCN_marking encoded packets, would 
> be the following:
> 
> This means that event_A in Section 4.2.3 will be activated 
> when incoming_PCN_marking_rate > pcn_lower_egress_percentage 
> * Admission_offset_rate or when:
> This means that the PCN_egress_ node does not change to 
> admission control state when at least one PCN_marked packet 
> arrives, but it changes when the incoming_PHB_marking rate 
> equals a percentage of the Admission_offset_rate. This is due 
> to the fact that Admission_offset_rate is used by the 
> interioe nodes to change from admission control state to flow 
> termination state.
> 
> >
> >egress nodes (and suppose for simplicity there is no other traffic 
> >going to these egresses). The bottleneck link is clearly in the 
> >termination state, as the total rate of pcn traffic on this 
> link is 100 
> >mbps which is above the pcn-upper-threshold. This means we want the 
> >egress nodes to somehow recognise this state and get into the 
> >termination mode. But it seems in this example the egresses 
> can't ever 
> >recognize that the system is in the termination mode. See below.
> 
> 
> >
> >In turn that means that the pcn-upper-egress-rate will NEVER be 
> >exceeded (because pcn-upper-egress-rate is so much larger than the 
> >total rate of the pcn traffic at the egress). In turn, that 
> appears to 
> >mean that in this scenario none of the egresses will ever end up in 
> >termination state, and so termination will never occur. That 
> does not seem right.
> 
> 
> Georgios: Thank you for the given example, which stimulated 
> me to better translate what I wanted to specify and what I 
> have written down.
> The situation that you described cannot (often) occur because 
> the difference between the admission control threshold and 
> flow termination threshold at the egress is equal to 
> Admission_offset_rate +/- multicongestion_error. Note that 
> the Admission_offset_rate is an absolute rate value. The 
> multicongestion_error is used to identify the bounds that 
> certain situations occur where the PCN_egreess_ node should 
> have been in flow termination state but it is not. Please see 
> previous discussions on this.
> 
> >
> >> PCN_interior_nodes) on the same path are not 
> simulataneously starting 
> >> to be congested. Therefore we use the 
> multicongestion_error parameter 
> >> to identify the error bound that ocurs due to these corner cases. 
> >> Note that this error bound can be e.g., predefined ones 
> off line by 
> >> the operator, by studying the network topology and/or studying how 
> >> often such corner cases could occur and/or doing off line 
> >> +/- multicongestion_error
> >>
> >> Change from Normal state to Admission control state: event 
> A Occurs 
> >> when:
> >> This is explained on page 21, 22. Note that the 
> description of event 
> >> A on page 21 has to be modified to avoid the confusions that were 
> >> caused up to now, see explanation given above.
> >>
> >> Change from Normal state to Admission control state: event 
> A Occurs 
> >> when:
> >> It is important to note that also the explanation of event 
> C on page 
> >> 21, has to be modified to avoid the confusions that were 
> caused up to 
> >> now, see explanation given above:
> signaled_remarked_bytes depend 
> >> on the value of calculated excess rate 
> (signaled_overload_rate), the 
> >> value of the Admission_offset_rate and the value of the 
> >> Regarding probes, the probe packets that are passing through a 
> >> congested node are either PCN_marked or PCN_Affected_marked.
> >>
> different 
> >> than in the situation that the PCN_Interior_node operates in 
> >> admission control state, see page 19 and 20. This is due 
> to the fact 
> >> that a sliding window is used to solve an undershooting 
> problem, see 
> >> discussion on page 19.
> signaled_remarked_bytes depend 
> >> on the value of calculated excess rate 
> (signaled_overload_rate), the 
> >> value of the Termination_offset_rate and the value of the 
> state than 
> >> a flow that is requesting admission into the PCN domain can b 
> >> etreated in the following way:
> >>
> accomplished 
> >> by using an external to PCN signaling protocol.
> >> In this case when the request arrives at a PCN_egress_node that 
> >> operates in admission control state then the request is 
> rejected. If 
> >> If probing is used, the request for admission is accomplished by 
> >> using probe packets. In this case when the probe arrives at a 
> >> PCN_egress_node and it is either PCN_marking or 
> PCN_Affected_marking 
> >> encoded is rejected. Otherwise is accepted.
> >> Note that probes can only be used when 
> PCN_Affected_marking is appled 
> >> in whole PCN domain. Otherwise, the admission control 
> procedure will 
> >> work by using e.g., an external signaling protocol used between 
> calculates the 
> numer of 
> >> flows that have to be terminated using the pseudo code 
> given on page 
> >> 23. Note that the PCN_egress_node has to maintain per flow 
> >> reservation states.
> >> Maximum_priority = 0 Where, 0 =< priority_class =< Maximum_priority
> >>
> >>
> >>
> >> We use a percentage of received PCN_marking encoded packets in 
> >> proportion to total rate of received packets to define when a 
> >> PCN_egres_node goes from Normal state to admission control 
> state. In 
> >> this version of the draft we call this value as: 
> >> incoming_PCN_marking_rate = N * input_PCN_marking_bytes/T Where, 
> >> Note that the maximum excess rate that a PCN_interior_node can 
> >> Admission_offset_rate then the node changes from admission control 
> this email. 
> >> In particular, check the paragraphs denoted above as:

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 2 Nov 2007 14:31:47 -0400

Sorry, this went out unfinished (cat walked on keyboard :-))
PLEASE IGNORE

Ann a

> From: Anna Charny (acharny) 
> Sent: Friday, November 02, 2007 2:28 PM
> To: Georgios Karagiannis; [email-masked]; Lars 
> Westberg (KI/EAB)
> Cc: [email-masked]
> Subject: [PCN] RE: Questions on LC-PCN draft version 01
> 
> Hi Georgios,
> 
> > To: Anna Charny (acharny); [email-masked]; 
> Lars Westberg 
> > (KI/EAB)
> > Cc: [email-masked]
> > Georgios: Yes, you are right! This has to do with the importance of 
> > using the Termination_offset_rate. We will motivate this in the 
> > following version of the draft.
> > 
> > > So If I
> > PCN_interior_node to know the termination_offset rate used by each 
> > neighbour PCN_interior_node. Then the pseudocode on page 20 
> will have 
> > to use the Termination_offset_rate associated with the 
> incoming link 
> > from where the incoming PCN_marked packets are arriving. Then this 
> > constraint can be avoided.
> > 
> > 
> > >Same comment for the
> preconfigured 
> percentage of 
> > the received PCN_marking encoded packets, would be the following:
> > 
> > incoming_PCN_marking_rate > pcn_lower_egress_percentage
> > This means that the PCN_egress_ node does not change to admission 
> > control state when at least one PCN_marked packet arrives, but it 
> > changes when the incoming_PHB_marking rate equals a 
> percentage of the 
> > Georgios: Thank you for the given example, which stimulated me to 
> > better translate what I wanted to specify and what I have written 
> > down.
> > The situation that you described cannot (often) occur because the 
> > difference between the admission control threshold and flow 
> > termination threshold at the egress is equal to 
> Admission_offset_rate 
> > +/- multicongestion_error. Note that the 
> Admission_offset_rate is an 
> > bounds that certain situations occur where the PCN_egreess_ node 
> > should have been in flow termination state but it is not. 
> Please see 
> calculate in 
> preconfigured

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 02 Nov 2007 18:36:15 +0000

Hi Anna

Please see in line

>(both offsetas are global values)

Georgios: Yes, but the termination_offset_rate could be released from
this constraint if each PCN_interior_node would be configured to know
the Termination_offset_rate of each neighbour interior node.
>Pcn-lower-egress-rate = Pcn-lower-egress-percentage  * Admission_offset_rate

PCN_upper_egress_rate= Pcn-lower-egress-rate + admission_offset_rate +/-
multicongestion_error

Best regards,
Georgios

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 2 Nov 2007 15:24:32 -0400

Hi Georgios,

OK, trying again...

Something still seems wrong. 

First wanted to confirm that I now got the setting of the thresholds
right (the following collected from your various responses):

NOTE:  I am ignoring multi-congestion error because I am still trying to
figure out how it works in a single bottleneck case. 

Pcn-lower-egress-percentage is some configured value (%)

Pcn-lower-egress-rate = pcn-lower-egress-percentage *
admission-termination-rate/100 (I assume the division by 100 is
necessary?)

Pcn-upper-egress-rate=pcn-lower-egress-rate+Admission-offset-rate

Admisison-offset-rate is a global parameter that has the meaning of the
difference between the pcn-upper-rate and pcn-lower-rate at all interior
nodes (which is assumed the same in all cases).

Egress goes into termination mode when it sees the rate of marked
packets of a given ingress exceeding the pcn-upper-egress-rate.

So far so good?

Assuming it is all correct,  my example where none of the egresses can
ever go into the termination mode remains valid, I believe.  Let me
restate the example.

Consider the following example. A bottleneck link of capacity 100 mbps ,
pcn-termination-offset of 40mbps and pcn-admission-offset of 30 mbps is
shared by 100 ingress-egress aggregates, each with the total pcn rate of
1 mbps. On this link pcn-upper-threshold is 60mbps, and
pcn-lower-threshold is 30mbps. Suppose further that all 100
ingress-egress aggregates go to different egress nodes (and suppose for
simplicity there is no other traffic going to these egresses; this last
assumption is irrelevant because the egress measurement is per
ingress-egress pair anyway, but makes it convenient to imagine). The
bottleneck link is clearly in the termination state, as the total rate
of pcn traffic on this link is 100 mbps which is above the
pcn-upper-threshold. 

This means we want the egress nodes to somehow recognise this state and
get into the termination mode. But it seems in this example the egresses

can't ever recognize that the system is in the termination mode. See
below.

Suppose pcn-lower-egress-percentage is set to w% (0<w<=100), and let
u=w/100. Then, each of these egresses will compute the 
pcn-lower-egress-rate=u*admission-offset-rate

and 

pcn-upper-egress-rate=pcn-lower-rate+admission-offset-rate = 
(u+1)*admission-offset-rate > admission-offset-rate = 30Mbps

So our pcn-upper-egress rate is always greater than 30 Mbps, 
while the entire rate of pcn traffic the egress will ever see is *at 
most* 1 Mbps (because it is plainly the total rate of the single
ingress-egress aggreate that goes to this egress). So, regardless of the

actual amount of marked traffic in this egress-egress aggregate, the 
absolute excess rate of this ingress-egress aggregate will never be
above 1mbps either.In turn that means that the pcn-upper-egress-rate
will NEVER be exceeded (because pcn-upper-egress-rate is so much larger
than the  total rate of the pcn traffic at the egress). In turn, that 
appears to mean that in this scenario none of the egresses will ever end
up in termination state, and so termination will never occur. That 
(still) does not seem right.

So again, even with the corrected definition of pcn-lower-thershold,
this example seems to imply a rather fundamental flaw in the algorithm.

You say, in your response to the previous example, that 

>the situation that you described cannot (often) occur because 
> Admission_offset_rate +/- multicongestion_error. 

I believe that multi-congestion error is irrelevant here, because 
in the considered example there is only a single congestion point.

>Note that 

I do not understand the relevance of the multiocongestion error in this
case, or rules for its setting  at all, I am afraid.  Do we need
multi-congestion error (which I do not know how to set anyway) to deal
with a single congestion point also?  What should it be set to?  Do you
need to examine a configuration AND all ingress-egress aggregare rates
AND all possible failures to set it correctly? 

Best,
Anna

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 02 Nov 2007 20:04:44 +0000

Hi Anna

Please see in line!

Best regards,
Georgios

>can't ever recognize that the system is in the termination mode. See

Georgios: I think that the example that you provide is an wors case
scenario.
First of all the Admission_offset_rate is too high.
This Admission_offset_rate should be set such that siuations as you
describe will not occur.

>AND all possible failures to set it correctly? 

Georgios: You are right that the muli-congestion-error does not play a
role, but the selection of the Admission_offset_rate plays in this
situation a signifficat role and it should be selected such that wores
case scenarios, such as the one described by you do not occur+

>> while the

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 2 Nov 2007 17:40:14 -0400

Hi Georgios,

You are saying that the example I provided was a worst case scenario
that cannot happen in practice.  

Why is that? All that is required to construct a similar example is to
have a bottleneck which multiplexes traffic from many  ingresses to one
(or a small number of) egresses, and these aggregates can together load
the bottleneck link.  This scenario will easily  result in the situation
when the admission-offset on the bottleneck (i.e. the difference between
the admission and termination thresholds) is large compared to the
individual ingress-egress aggregate. Why do you think that is a corner
case? 

Anna 

> Sent: Friday, November 02, 2007 4:05 PM
> To: Anna Charny (acharny); Lars Westberg (KI/EAB); 
> [email-masked]
> Cc: [email-masked]
> >NOTE:  I am ignoring multi-congestion error because I am 
> still trying 
> >to figure out how it works in a single bottleneck case.
> >
> >difference between the pcn-upper-rate and pcn-lower-rate at all 
> >interior nodes (which is assumed the same in all cases).
> >
> >Consider the following example. A bottleneck link of 
> capacity 100 mbps 
> >, pcn-termination-offset of 40mbps and pcn-admission-offset 
> of 30 mbps 
> >is shared by 100 ingress-egress aggregates, each with the total pcn 
> >rate of
> Georgios: I think that the example that you provide is an 
> wors case scenario.
> This Admission_offset_rate should be set such that siuations 
> as you describe will not occur.
> 
> 
> >
> >entire rate of pcn traffic the egress will ever see is *at
> >appears to mean that in this scenario none of the egresses will ever 
> >end up in termination state, and so termination will never 
> occur. That
> >>the situation that you described cannot (often) occur because  the 
> >>+/- multicongestion_error.
> >
> >I believe that multi-congestion error is irrelevant here, because in 
> >the considered example there is only a single congestion point.
> >
> >>Note that
> >>multicongestion_error is used to identify the bounds that  certain 
> >>situations occur where the PCN_egreess_ node should  have 
> been in flow 
> >>termination state but it is not. Please see  previous 
> discussions on 
> >>this.
> >
> Georgios: You are right that the muli-congestion-error does 
> not play a role, but the selection of the 
> Admission_offset_rate plays in this situation a signifficat 
> role and it should be selected such that wores case 
> scenarios, such as the one described by you do not occur+
> 
> 
> >Best,
> >Anna
> importance of 
> >> neighbour PCN_interior_node. Then the pseudocode on page 
> 20 will have 
> >> >total pcn traffic of the ingress-egress aggregate it sees 
> (which is 
> >> >1
> >> absolute rate value. The multicongestion_error is used to identify 
> >> the bounds that certain situations occur where the 
> PCN_egreess_ node 
> >> >> Georgios: You are right, please see discussion above on 
> paragaph 
> >> >> denoted
> >> >> as:

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 09 Nov 2007 12:38:29 +0000

Hi Anna

Sorry for the quick response! I think that you are right!

What we had to emphasize is that the Admission_offset_rate at
PCN_egress_nodes is different than the Admission_offset_rate used at the
PCN_interior_nodes.

If we will consider as normal situations the situations that
no ECMP occurs and that all flows belonging to the same ingress-egress
aggregate will use the same path from PCN_ingress to PCN_egress,
this will mean that when the PCN_egress_node receives, for the given
ingress-egress aggregate an excess rate equal to a fraction of the
Admission_offset_rate, say fraction F * Admission_offset_rate, where
"fraction used for admission control" > F >= 1,
it will have to change from admission control state to flow termination
state. Note that F can be preconfigured and depends on
the network topology.

Best regards,
Georgios

On 11/2/2007, "Anna Charny (acharny)" <[email-masked]> wrote:

>> >> most* 1 Mbps