Subject: [PCN] PCN termination marking algorithm - consensus?

From: <[email-masked]>
Date: Wed, 27 Feb 2008 13:12:59 -0000

Here also is an attempt for consensus on the termination marking
behaviour.

 If an interface of the PCN-domain performs PCN Admission Marking then
it performs three functions, which are outlined in
draft-ietf-pcn-architecture as follows:

   o  Packet classify - decide whether an incoming packet is a PCN-
      packet or not.  Another PCN WG document will specify encoding,
      using the DSCP and/or ECN fields.
 
   o  PCN-meter - measure the 'amount of PCN-traffic'.  The measurement
      is made as an aggregate of all PCN-packets, and not per flow.
 
   o  PCN-mark - algorithms determine whether to PCN-mark PCN-packets
      and what packet encoding is used (as specified in another PCN WG
      document).

These functions are now described in more detail.

Note: The PCN-node MAY implement these three functions on either its
ingoing or outgoing interfaces. The same choice MUST be made for every
PCN-node in one PCN-domain. 

[Lars has commented: do we need to allow this choice?]

Classify function:

If a packet's ECN/DSCP fields have the value PCN, as defined in
[RFC-encoding], then it MUST be classified as a PCN-packet. However, if
the PCN-packet is already "termination marked", as defined in
[RFC-encoding], then the Meter function SHOULD NOT be performed. (*)

If a packet's ECN/DSCP fields do not have the value PCN, as defined in
[RFC-encoding], then it MUST NOT be classified as a PCN-packet.

Meter function:

Note: The meter is described as a 'token bucket', however the
implementation is not standardised.

A packet classified as a PCN-packet MUST be metered as follows. 

The interface MUST have:

[1] a configured bit rate, termed PCN-upper-rate

[2] a meter for PCN-packets, which MUST have the following behaviour:

a token bucket, operating in bits: 

1A tokens are added at the PCN-upper-rate, to a maximum TB.size

1B tokens are removed equal to the size in bits of the PCN-packet, to a
minimum TB.size=0

2 if TB.fill = 0, then the meter indicates "termination mark" to the
Mark function

Note: Step 1A can be triggered by a packet and so can be done at the
same time as Step 1B.

Note: Step 2 can be performed before or after step 1

The following SHOULD be done (**) instead of Step 2 above (Step 2 is
then superfluous).

if TB.fill < maximum size of PCN-packet, then the meter indicates
"termination mark" to the Mark function

The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets
in the PCN-domain. 

Note: Step 1B above is still performed. 

Mark function:

If the meter indicates to "termination mark" a PCN-packet, then:

the PCN-packet's ECN/DSCP fields MUST be set to the codepoint
"termination marked", as defined in [RFC-encoding]

(*) Explanation: for CL termination (ie the termination based on rates,
rather than the 3SM termination based on marked pkts), if the meter
counts pkts that are already termination marked then there'll be
over-termination in the event of multiple bottlenecks. However, since
this option is probably more complicated to implement than a normal
classifier (?), I suggest it is a SHOULD.

(**) Explanation: this captures the point that Michael makes in
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08
-PCN-MFT.pdf
<http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth0
8-PCN-MFT.pdf>  & Bob makes in
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02
.txt
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-0
2.txt>  Otherwise flows with big pkts get marked more than flows with
small pkts. However, since this option is more complicated to implement
than a normal token bucket, I suggest it is a SHOULD.

we could also add an example algorithm, such as that in
http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt
Fig 10.1
<http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt%
20Fig%2010.1>  on page 21.

Comments?

phil

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

---

From: Michael Menth <[email-masked]>
Date: Wed, 27 Feb 2008 14:44:07 +0100

Hi Phil,

[email-masked] wrote:
> If a packet’s ECN/DSCP fields have the value PCN, as defined in 
> [RFC-encoding], then it MUST be classified as a PCN-packet. However, 
> if the PCN-packet is already “termination marked”, as defined in 
> If a packet’s ECN/DSCP fields do not have the value PCN, as defined in 
> Note: The meter is described as a ‘token bucket’, however the 
> 1B tokens are removed equal to the size in bits of the PCN-packet, to 
> a minimum TB.size=0
>
> 2 if TB.fill = 0, then the meter indicates “termination mark” to the 
> Mark function
>
I think this is buggy because when packets are marked, they may have 
already reduced the number of tokens in the bucket. The invariant of 
excess marking is that the size of all non-marked packets is removed 
from the token bucket but not the size of marked packets. Therefore, 
this algorithm marks more packets than necessary.

Correct:
1B if TB.fill<packet.size, then the meter indicates “termination mark” 
to the Mark function
1C if TB.fill<packet.size, tokens are removed equal to the size in bits 
of the PCN-packet

Do not interchange the order of 1A, 1B, and 1C! Packet size independent 
marking performs the tests of 1B and 1C for a maximum packet size (aka 
MTU or threshold).

Regards,

Michael

> “termination mark” to the Mark function
>
> The “maximum size of PCN-packet” is the MTU in bits of any PCN-packets 
> in the PCN-domain.
>
> If the meter indicates to “termination mark” a PCN-packet, then:
>
> the PCN-packet’s ECN/DSCP fields MUST be set to the codepoint 
> “termination marked”, as defined in [RFC-encoding]
>
> (*) Explanation: for CL termination (ie the termination based on 
> rates, rather than the 3SM termination based on marked pkts), if the 
> meter counts pkts that are already termination marked then there’ll be 
> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf 
> & Bob makes in 
> http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt 
> Otherwise flows with big pkts get marked more than flows with small 
> pkts. However, since this option is more complicated to implement than 
> a normal token bucket, I suggest it is a SHOULD.
>
> <http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt%20Fig%2010.1> 
> on page 21.
>
> Comments?
>
> phil
>
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:07:32 +0100

Hi Phil
 
I am not in favour of using the token bucket as the only metering function
that can be used in PCN!
Regarding the comparison, I think that if you want to base any decission on
it, then 
the LC-PCN algorithm should also be included in this comparison!
 
Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: woensdag 27 februari 2008 14:13
To: [email-masked]
Subject: [PCN] PCN termination marking algorithm - consensus?

Here also is an attempt for consensus on the termination marking behaviour.

 If an interface of the PCN-domain performs PCN Admission Marking then it
performs three functions, which are outlined in draft-ietf-pcn-architecture
as follows:

 

Note: The PCN-node MAY implement these three functions on either its ingoing
or outgoing interfaces. The same choice MUST be made for every PCN-node in
one PCN-domain. 

Classify function:

If a packet's ECN/DSCP fields have the value PCN, as defined in
[RFC-encoding], then it MUST be classified as a PCN-packet. However, if the
PCN-packet is already "termination marked", as defined in [RFC-encoding],
then the Meter function SHOULD NOT be performed. (*)

Meter function:

Note: The meter is described as a 'token bucket', however the implementation
is not standardised.

The interface MUST have:

2 if TB.fill = 0, then the meter indicates "termination mark" to the Mark
function

Note: Step 1A can be triggered by a packet and so can be done at the same
time as Step 1B.

The following SHOULD be done (**) instead of Step 2 above (Step 2 is then
superfluous).

The "maximum size of PCN-packet" is the MTU in bits of any PCN-packets in
the PCN-domain. 

 

Mark function:

the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "termination
marked", as defined in [RFC-encoding]

(*) Explanation: for CL termination (ie the termination based on rates,
rather than the 3SM termination based on marked pkts), if the meter counts
pkts that are already termination marked then there'll be over-termination
in the event of multiple bottlenecks. However, since this option is probably
more complicated to implement than a normal classifier (?), I suggest it is
a SHOULD.

(**) Explanation: this captures the point that Michael makes in
<http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PC
N-MFT.pdf>
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN
-MFT.pdf & Bob makes in
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.tx
t>
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt
Otherwise flows with big pkts get marked more than flows with small pkts.
However, since this option is more complicated to implement than a normal
token bucket, I suggest it is a SHOULD.

we could also add an example algorithm, such as that in
<http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt%20Fi
g%2010.1>
http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig
10.1 on page 21.

Comments?

phil

---

From: <[email-masked]>
Date: Thu, 28 Feb 2008 13:26:36 -0000

We've got to have *one* metering function for termination (& one for
adm). 

I thought the idea was that lc-pcn would get into anna's comparison
draft, ie in the same format & the same general level of understanding
of how it works (the latter being a pre-requisite to getting it in
there!). 

Even so, I looked at the latest lc-pcn & S4.3.1 (interior node &
termination) and it says:

The PCN-interior-nodes can measure the PHB aggregated PCN traffic
   that exceeds a configured-admissible-rate and mark this excess PCN

   traffic

which is exactly what the email below does.

Please explain what youre concerned about!

thanks.

Phil/

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

I am not in favour of using the token bucket as the only metering
function that can be used in PCN!

Regarding the comparison, I think that if you want to base any decission
on it, then 

Best regards,

Georgios

 

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: woensdag 27 februari 2008 14:13
	To: [email-masked]
	Subject: [PCN] PCN termination marking algorithm - consensus?

	 

	 If an interface of the PCN-domain performs PCN Admission
Marking then it performs three functions, which are outlined in
draft-ietf-pcn-architecture as follows:

	   o  Packet classify - decide whether an incoming packet is a
PCN-
	      packet or not.  Another PCN WG document will specify
encoding,
	      using the DSCP and/or ECN fields.
	 
	   o  PCN-meter - measure the 'amount of PCN-traffic'.  The
measurement
	      is made as an aggregate of all PCN-packets, and not per
flow.
	 
	   o  PCN-mark - algorithms determine whether to PCN-mark
PCN-packets
	      and what packet encoding is used (as specified in another
PCN WG
	      document).

	Note: The PCN-node MAY implement these three functions on either
its ingoing or outgoing interfaces. The same choice MUST be made for
every PCN-node in one PCN-domain. 

	Classify function:

	If a packet's ECN/DSCP fields do not have the value PCN, as
defined in [RFC-encoding], then it MUST NOT be classified as a
PCN-packet.

	Meter function:

	The interface MUST have:

	[2] a meter for PCN-packets, which MUST have the following
behaviour:

	1B tokens are removed equal to the size in bits of the
PCN-packet, to a minimum TB.size=0

	2 if TB.fill = 0, then the meter indicates "termination mark" to
the Mark function

	Note: Step 1A can be triggered by a packet and so can be done at
the same time as Step 1B.

	The following SHOULD be done (**) instead of Step 2 above (Step
2 is then superfluous).

	if TB.fill < maximum size of PCN-packet, then the meter
indicates "termination mark" to the Mark function

	The "maximum size of PCN-packet" is the MTU in bits of any
PCN-packets in the PCN-domain. 

	 

	Mark function:

	 

meter counts pkts that are already termination marked then there'll be

	Comments?

	phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:28:59 +0100

Hi Phil
 
My concerns are similar to the previous email that I have sent regarding
admission control.
I would like to have a more clear understanding on what you are proposing
before we can get any consensus!

In my option all options that are currently decribed in the current version
of the archietcture draft will be reduced at the moment that the encoding
method is selected and probably also when the PCN algorithms used at
interior and edges are selected.

I thought that the idea of the architecture draft is to provide a
description of the architectural options that can be used, such that later
on a selection on the algorithms is done.

If that is not the case then the publication of the architecture draft
should be delayed until the above selections are done!

Best regards,

Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 28 februari 2008 14:27
To: [email-masked]; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

We've got to have *one* metering function for termination (& one for adm). 

I thought the idea was that lc-pcn would get into anna's comparison draft,
ie in the same format & the same general level of understanding of how it
works (the latter being a pre-requisite to getting it in there!). 

   traffic

thanks.

Phil/

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

Best regards,

Georgios

 

  _____  

 

 

Classify function:

Meter function:

The interface MUST have:

 

Mark function:

 

Comments?

phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:30:13 +0100

Hi Phil

Best regards,

Georgios

  _____  

   traffic

thanks.

Phil/

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

Best regards,

Georgios

 

  _____  

 

 

Classify function:

Meter function:

The interface MUST have:

 

Mark function:

 

Comments?

phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:31:33 +0100

Hi Phil

Best regards,

Georgios

  _____  

   traffic

thanks.

Phil/

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

Best regards,

Georgios

 

  _____  

 

 

Classify function:

Meter function:

The interface MUST have:

 

Mark function:

 

Comments?

phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:32:48 +0100

Hi Phil

Best regards,

Georgios

  _____  

   traffic

thanks.

Phil/

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

Best regards,

Georgios

 

  _____  

 

 

Classify function:

Meter function:

The interface MUST have:

 

Mark function:

 

Comments?

phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:32:43 +0100

Hi Phil

Best regards,

Georgios

  _____  

   traffic

thanks.

Phil/

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

Best regards,

Georgios

 

  _____  

 

 

Classify function:

Meter function:

The interface MUST have:

 

Mark function:

 

Comments?

phil

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 28 Feb 2008 09:34:53 -0500

Hi all,

Sorry for coming late into the discussions. I was dealing with a
personal emergency and am now trying to sort through a really large
amount of email. 

Will comment on things as I go through and understand them.  

there!). 

The new version of lc-pcn draft came too late to get into the comparison
draft this time.  Georgious did in fact send various short versions of
the behaviors to me before the new version of the lc-pcn draft came out,
but it was not clear still exactly how it works. Once the new lc-pcn
draft is discussed and understood by the WG, we will deal with plugging
it into the comparison draft.  

Anna 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: Thursday, February 28, 2008 8:27 AM
	To: [email-masked]; [email-masked]
	Subject: Re: [PCN] PCN termination marking algorithm -
consensus?

	We've got to have *one* metering function for termination (& one
for adm). 

	I thought the idea was that lc-pcn would get into anna's
comparison draft, ie in the same format & the same general level of
understanding of how it works (the latter being a pre-requisite to
getting it in there!). 

	The PCN-interior-nodes can measure the PHB aggregated PCN
traffic
	   that exceeds a configured-admissible-rate and mark this
excess PCN

	   traffic

	thanks.

	Phil/

	-----Original Message-----
	From: Georgios Karagiannis [mailto:[email-masked]] 
	Sent: 28 February 2008 13:08
	To: Eardley,PL,Philip,CXR9 R; [email-masked]
	Subject: RE: [PCN] PCN termination marking algorithm -
consensus?

	Hi Phil

	I am not in favour of using the token bucket as the only
metering function that can be used in PCN!

	Regarding the comparison, I think that if you want to base any
decission on it, then 

	Best regards,

	Georgios

	 

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: woensdag 27 februari 2008 14:13
		To: [email-masked]
		Subject: [PCN] PCN termination marking algorithm -
consensus?

		Here also is an attempt for consensus on the termination
marking behaviour.

		 If an interface of the PCN-domain performs PCN
Admission Marking then it performs three functions, which are outlined
in draft-ietf-pcn-architecture as follows:

		   o  Packet classify - decide whether an incoming
packet is a PCN-
		      packet or not.  Another PCN WG document will
specify encoding,
		      using the DSCP and/or ECN fields.
		 
		   o  PCN-meter - measure the 'amount of PCN-traffic'.
The measurement
		      is made as an aggregate of all PCN-packets, and
not per flow.
		 
		   o  PCN-mark - algorithms determine whether to
PCN-mark PCN-packets
		      and what packet encoding is used (as specified in
another PCN WG
		      document).

		Note: The PCN-node MAY implement these three functions
on either its ingoing or outgoing interfaces. The same choice MUST be
made for every PCN-node in one PCN-domain. 

		Classify function:

		If a packet's ECN/DSCP fields have the value PCN, as
defined in [RFC-encoding], then it MUST be classified as a PCN-packet.
However, if the PCN-packet is already "termination marked", as defined
in [RFC-encoding], then the Meter function SHOULD NOT be performed. (*)

		If a packet's ECN/DSCP fields do not have the value PCN,
as defined in [RFC-encoding], then it MUST NOT be classified as a
PCN-packet.

		Meter function:

		Note: The meter is described as a 'token bucket',
however the implementation is not standardised.

		A packet classified as a PCN-packet MUST be metered as
follows. 

		The interface MUST have:

		[2] a meter for PCN-packets, which MUST have the
following behaviour:

		1A tokens are added at the PCN-upper-rate, to a maximum
TB.size

		2 if TB.fill = 0, then the meter indicates "termination
mark" to the Mark function

		Note: Step 1A can be triggered by a packet and so can be
done at the same time as Step 1B.

		The following SHOULD be done (**) instead of Step 2
above (Step 2 is then superfluous).

		The "maximum size of PCN-packet" is the MTU in bits of
any PCN-packets in the PCN-domain. 

		 

		Mark function:

		If the meter indicates to "termination mark" a
PCN-packet, then:

		the PCN-packet's ECN/DSCP fields MUST be set to the
codepoint "termination marked", as defined in [RFC-encoding]

		(*) Explanation: for CL termination (ie the termination
based on rates, rather than the 3SM termination based on marked pkts),
if the meter counts pkts that are already termination marked then
there'll be over-termination in the event of multiple bottlenecks.
However, since this option is probably more complicated to implement
than a normal classifier (?), I suggest it is a SHOULD.

		(**) Explanation: this captures the point that Michael
makes in

		Comments?

		phil

---

From: <[email-masked]>
Date: Thu, 28 Feb 2008 19:01:21 -0000

>> such that later on a selection on the algorithms is done.

Actually I think we're now at the stage where we have good consensus on
what the marking algorithms (behaviours) are. So now is the time to
agree it!

- For admission, it reflects what's in anna's comparison draft

- For termination, it also reflects what's in anna's comparison draft,
with the added info we now have from michael's emft draft that 3SM
termination system behaviour can be got with the CL marking behaviour (&
a new edge behaviour).

> I thought that the idea of the architecture draft is to provide a
description of the architectural options

lars is discouraging this & trying to get us to make the choices now. I
think we can do this for the marking really quite easily. The edge
behaviour may be harder to reach consensus on. 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 28 February 2008 13:33
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN termination marking algorithm - consensus?

Hi Phil

I would like to have a more clear understanding on what you are
proposing before we can get any consensus!

In my option all options that are currently decribed in the current
version of the archietcture draft will be reduced at the moment that the
encoding method is selected and probably also when the PCN algorithms
used at interior and edges are selected.

I thought that the idea of the architecture draft is to provide a
description of the architectural options that can be used, such that
later on a selection on the algorithms is done.

Best regards,

Georgios

	   traffic

	thanks.

	Phil/

	-----Original Message-----
	From: Georgios Karagiannis [mailto:[email-masked]] 
	Sent: 28 February 2008 13:08
	To: Eardley,PL,Philip,CXR9 R; [email-masked]
	Subject: RE: [PCN] PCN termination marking algorithm -
consensus?

	Hi Phil

	Best regards,

	Georgios

	 

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
		Sent: woensdag 27 februari 2008 14:13
		To: [email-masked]
		Subject: [PCN] PCN termination marking algorithm -
consensus?

		 

		 

		Classify function:

		Meter function:

		The interface MUST have:

		 

		Mark function:

		 

		Comments?

		phil