Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate"

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Sep 2007 08:31:15 +0200

Phil,
 
with a small delay of 5 weeks (but no one else reacted yet?): both,
description and definition proposed by you below are allright with me.
 
Regards,
 
Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 08, 2007 7:37 PM
To: [email-masked]
Subject: [PCN] PCN architecture, use of phrases like "exceeds rate"

I wrote a new / replacement para in the intro - to try to overcome bob's
rant - which complained about using phrases like "do marking when the
current rate exceeds a reference rate" [copied at end] - whilst still
giving the innocent reader (if such a person exists) a sporting chance
of understanding what it's all about:

<<Two rates, a PCN-lower-rate and a PCN-upper-rate, can be associated
with each link of the PCN-domain. Each rate is used by an algorithm
(specified in another document) that determines how and when a number of
PCN-packets are marked, and how the markings are encoded in packet
headers. PCN-egress-nodes make measurements of the packet markings and
send information as necessary to the nodes that make the decision about
which PCN-flows to accept/reject or terminate, based on this
information. Another document will describe decision-making algorithms.
Overall the aim is to enable PCN-nodes to give an "early warning" of
potential congestion before there is any significant build-up of
PCN-packets in the queue; the admission control mechanism limits the
PCN-traffic on each link to *roughly* its PCN-lower-rate and the flow
termination mechanism limits the PCN-traffic on each link to *roughly*
its PCN-upper-rate.>>

I know the last bit mentions rate - hopefully it's ok by relating it to
the overall system performance, rather than how each link does marking.
I'm not sure whether "*roughly*" is really necessary or whether you
think i cheated. 

I also added to the definitions for example:

<<Threshold-marking: a PCN-marking algorithm such that all PCN-traffic
is marked if the PCN-traffic exceeds a particular rate (either the
PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the
overall intent of the algorithm rather than its instantaneous behaviour,
since the rate measured at a particular moment depends on the algorithm,
its implementation and the traffic's variance as well as its rate.>>

** bob's rant

> * Marking is when "current" rate is "above" a reference rate?

> "   o  Admission-marking: the marking of PCN-packets by a PCN-node to

>        indicate that the PCN-traffic on a link is above the
configured-

>        admissible-rate.

>     o  Termination-marking: the marking of PCN-packets by a PCN-node
to

>        indicate that the PCN-traffic on a link is above the
configured-

>        termination-rate.

> "

> These marking definitions and other examples hilighted in magenta in
the

> above PDF prejudge marking mechanisms as rate measurements.

> We don't just have marking when the _current_rate is _above_ the
reference

> rate. We can have marking when the _current_ rate is _below_, or when
the

> _past_ rate was _above_.

> The configured rates are parameters of a (to be defined) mechanism.
These

> mechanisms will not have to mark packets when the rate is above these

> configured rates. That depends on the mechanism.

> This sounds picky, but it's actually a big rant I have about all this

> loose

> discussion of rate (yes, the issue of what rate means is mentioned in
the

> draft, but we need to be careful about such sloppy usage). IMHO, it's

> important to scale our conception of time down to inter-arrival times,
to

> be precise. Then the rate is packet size/interarrival time. Therefore
seen

> at a small enough timescale, rate might be varying rapidly above and
below

> the configured rate.

> A marking mechanism could be implemented by a virtual queue rather
than a

> rate measurement. When the offered instantaneous rate has been below
the

> configured-admission-rate for many packets (perhaps hundreds), marking

> will

> and should still occur,... if the virtual queue is still above a
marking

> threshold even if it is emptying rather than filling. This can be a

> deliberate design choice that says we still want admission marking
when

> there has been recent overload to allow time for the control loop to
work.

> It ensures a greater safety margin is automatically created by the
marking

> mechanism when recent traffic had higher variance. This was the
marking

> algorithm that was most studied and simulated in CL-PHB draft.

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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 19 Sep 2007 21:54:36 -0400

Phil and others, since Ruediger email brought this to my attention. I
have the following comments.

I think we should change the word "algorithm" to "marking behaviour" and
"rate" to "threshold". At least I believe that we should avoid
specifying a specific algorithm but just define the behaviour of the
algorithm. This would allow vendors to choose an algorithm that they
believe gives best results. So would propose the following.

<<Two traffic thresholds, a PCN-lower-threshold and a
PCN-upper-threshold, can be associated with each link of the PCN-domain.
Each traffic threshold has a marking behaviour(specified in another
document) that determines how and when PCN-packets are marked, and how
the markings are encoded in packet headers. PCN-egress-nodes make
measurements of the packet markings and send information as necessary to
the nodes that make the decision about which PCN-flow(s) to
accept/reject or terminate, based on this information. Another document
will describe decision-making behaviour. Overall the aim is to enable
PCN-nodes to give an "early warning" of potential congestion before
there is any significant build-up of PCN-packets in the queue; the
admission control mechanism limits the PCN-traffic on each link to
*roughly* its PCN-lower- threshold and the flow termination mechanism
limits the PCN-traffic on each link to *roughly* its
PCN-upper-threshold.>>

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

________________________________

From: Geib, Ruediger [mailto:[email-masked]] 
Sent: September 19, 2007 2:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate"

Phil,

Regards,

Ruediger

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Wednesday, August 08, 2007 7:37 PM
	To: [email-masked]
	Subject: [PCN] PCN architecture, use of phrases like "exceeds
rate"

	I wrote a new / replacement para in the intro - to try to
overcome bob's rant - which complained about using phrases like "do
marking when the current rate exceeds a reference rate" [copied at end]
- whilst still giving the innocent reader (if such a person exists) a
sporting chance of understanding what it's all about:

	<<Two rates, a PCN-lower-rate and a PCN-upper-rate, can be
associated with each link of the PCN-domain. Each rate is used by an
algorithm (specified in another document) that determines how and when a
number of PCN-packets are marked, and how the markings are encoded in
packet headers. PCN-egress-nodes make measurements of the packet
markings and send information as necessary to the nodes that make the
decision about which PCN-flows to accept/reject or terminate, based on
this information. Another document will describe decision-making
algorithms. Overall the aim is to enable PCN-nodes to give an "early
warning" of potential congestion before there is any significant
build-up of PCN-packets in the queue; the admission control mechanism
limits the PCN-traffic on each link to *roughly* its PCN-lower-rate and
the flow termination mechanism limits the PCN-traffic on each link to
*roughly* its PCN-upper-rate.>>

	I know the last bit mentions rate - hopefully it's ok by
relating it to the overall system performance, rather than how each link
does marking. I'm not sure whether "*roughly*" is really necessary or
whether you think i cheated. 

	<<Threshold-marking: a PCN-marking algorithm such that all
PCN-traffic is marked if the PCN-traffic exceeds a particular rate
(either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition
reflects the overall intent of the algorithm rather than its
instantaneous behaviour, since the rate measured at a particular moment
depends on the algorithm, its implementation and the traffic's variance
as well as its rate.>>

	** bob's rant

configured-

	>     o  Termination-marking: the marking of PCN-packets by a
PCN-node to

configured-

	> These marking definitions and other examples hilighted in
magenta in the

	> We don't just have marking when the _current_rate is _above_
the reference

	> rate. We can have marking when the _current_ rate is _below_,
or when the

	> The configured rates are parameters of a (to be defined)
mechanism. These

	> discussion of rate (yes, the issue of what rate means is
mentioned in the

	> important to scale our conception of time down to
inter-arrival times, to

	> be precise. Then the rate is packet size/interarrival time.
Therefore seen

	> at a small enough timescale, rate might be varying rapidly
above and below

	> A marking mechanism could be implemented by a virtual queue
rather than a

	> rate measurement. When the offered instantaneous rate has been
below the

	> and should still occur,... if the virtual queue is still above
a marking

	> deliberate design choice that says we still want admission
marking when

	> there has been recent overload to allow time for the control
loop to work.

	> It ensures a greater safety margin is automatically created by
the marking

	> mechanism when recent traffic had higher variance. This was
the marking

---

From: <[email-masked]>
Date: Mon, 24 Sep 2007 15:44:34 +0100

Joe

The change of the word 'algorithm' to 'marking behaviour' is ok with me.
Yes, we will have to decide what level of detail to standardise the
marking behaviour, but we don't have to decide that in this document. 

I'd prefer not to change 'rate' to 'threshold' at the moment. Since in a
token bucket or virtual queue implementation it does correspond to a
rate. Also, would prefer not to re-open the terminology rat-hole. 

Thanks

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 20 September 2007 02:55
To: Geib, Ruediger; Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate"

 

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

Phil,

Regards,

Ruediger

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Wednesday, August 08, 2007 7:37 PM
	To: [email-masked]
	Subject: [PCN] PCN architecture, use of phrases like "exceeds
rate"

	** bob's rant

configured-

PCN-node to

configured-

magenta in the

the reference

or when the

mechanism. These

mentioned in the

inter-arrival times, to

Therefore seen

above and below

rather than a

below the

a marking

marking when

loop to work.

the marking

the marking

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 24 Sep 2007 13:50:26 -0400

Phil, I'm OK with rate. 

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: [email-masked] [mailto:[email-masked]] 
Sent: September 24, 2007 10:45 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate"

Joe

Thanks

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 20 September 2007 02:55
To: Geib, Ruediger; Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate"

 

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

Phil,

Regards,

Ruediger

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
	Sent: Wednesday, August 08, 2007 7:37 PM
	To: [email-masked]
	Subject: [PCN] PCN architecture, use of phrases like "exceeds
rate"

	** bob's rant

configured-

PCN-node to

configured-

magenta in the

the reference

or when the

mechanism. These

mentioned in the

inter-arrival times, to

Therefore seen

above and below

rather than a

below the

a marking

marking when

loop to work.

the marking

the marking