Re: [PCN] PCN termination marking algorithm

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.  
On this one:

>>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 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: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
Behalf Of philip.eardley@bt.com
	Sent: Thursday, February 28, 2008 8:27 AM
	To: karagian@cs.utwente.nl; pcn@ietf.org
	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!). 

	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:karagian@cs.utwente.nl] 
	Sent: 28 February 2008 13:08
	To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org
	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 

	the LC-PCN algorithm should also be included in this comparison!

	Best regards,

	Georgios

		________________________________

				From: pcn-bounces@ietf.org
[mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
		Sent: woensdag 27 februari 2008 14:13
		To: pcn@ietf.org
		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).

		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
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn

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