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

["Geib, Ruediger" <[e-mail]>]

Phil,
 
I agree to you to requiring "MUST" for the following two fundamental PCN functions:
 
A packet classified as a PCN-packet MUST be metered as follows. 

[Joe] change MUST to MAY in above as this is only an example.

 

[phil] disagree. If we make this a MAY it means the PCN standard doesn't require any particular marking behaviour!!

 

The interface MUST have:

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

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

 
But I agree with Joe that the example should be separated from the requirements.
 
Regards,
 
Rudiger

 

________________________________

	From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
	Sent: Tuesday, March 04, 2008 12:13 PM
	To: [e-mail]
	Subject: Re: [PCN] PCN admission marking algorithm - consensus?
	
	

	Here are some replies to some comments that Joe sent me (Joe replied to a draft version I sent directly, but all the comments below still apply to the version I sent to list) (hope that's ok joe).

	 

	Thanks

	phil

	 

	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
	Sent: 27 February 2008 11:02
	To: [e-mail]
	Subject: [PCN] PCN admission marking algorithm - consensus?

	 

	I think we have consensus on the admission marking behaviour. This is a first attempt to capture that in Stds language, is it any use?

	 

	 

	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. 

	[Joe] Suggest rewording "The same choice MUST be made for every PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD be configured so that all links within the PCN-domain support the PCN function. 

	The work MUST is to strong. I believe it is OK to have a node that does not support the PCN function as long as other nodes provide the PCN functions, i.e., a node may provide PCN-function on both ingoing and outgoing interfaces to compensate for a node that does not provide PCN function. 

	My other issue is really a chart issue, if inside the PCN-domain an operator configures his network in such a way that there are links that can not be congested why would he need PCN-function on those links?

	 

	[phil] the architecture draft says "However if it's known
	   that an interface cannot become pre-congested then it's not strictly
	   necessary for it to be capable of PCN-marking.  But this must be
	   known even in unusual circumstances, eg after the failure of some
	   links.

	I suppose this makes it a SHOULD

	 

	 

	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.

	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.

	[Joe] I would suggest that the second line be reword to say that "all other packets are not PCN-packets".

	 

	[PHIL] Actually this needs to be updated, since we may need to take account of [quoting arch draft]:

	There may be traffic that is more important than PCN, perhaps a
	      particular application or an operator's control messages.  A PCN-
	      node may dedicate capacity to such traffic or priority schedule it
	      over PCN.  In the latter case its traffic needs to contribute to
	      the PCN meters.

	 

	 

	Meter function:

	Note: The meter is described as a 'token bucket with threshold', however the implementation is not standardised. For example, it could equally well be implemented as a virtual queue (which operates with negative tokens).

	 

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

	[Joe] change MUST to MAY in above as this is only an example.

	 

	[phil] disagree. If we make this a MAY it means the PCN standard doesn't require any particular marking behaviour!!

	 

	The interface MUST have:

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

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

	[Joe] The above MUST can be changed to SHOULD. 

	 

	[phil] MUST seems right to me. 

	 

	 

	a token bucket, which 

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

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

	2 if TB.fill < TB.threshold, then the meter indicates "admission mark" to the Mark function

	[Joe] Need to add that TB.threshold MUST be configured to be less than maximum TB.size and grater than TB.size=0

	 

	[phil] ok, although I suppose 'equal to' is ok in both cases

	 

	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

	[Joe] The two notes are not needed.

	 

	[phil] they were meant to make it clear that numbering doesn't imply must be done in this order (which the reader might otherwise assume)?

	 

	If TB.fill < size of the PCN-packet, then the meter MAY:

	a. leave TB.fill unaltered and indicate "admission mark" to the Mark function

	b. set TB.fill = 0 and indicate "admission mark" to the Mark function     

	c. set TB.fill = 0 and check if TB.fill < TB.threshold and if it is, then indicate "admission mark" to the Mark function        

	Note: Option a is expected to be the simplest to implement. 

	[Joe] The above points are not needed as "1B" states that minimum TB size=0, it should not go negative.

	 

	[phil] note, if the meter does choice a, then TB.fill is unaltered. This needs to stated I think.

	 

	 

	Mark function:

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

	[1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously "admission marked" and "termination marked":

	If the PCN-packet's codepoint is already "termination mark" then it MUST NOT be altered, ie the following step is not performed.

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

	[Joe]Reword the Marking function to as:

	The "admission marking" is only applied to unmarked PCN packets.

	As note could state that "termination marked" packets MUST NOT be remarked, but I believe it is not needed as there may be networks that only do admission  control and not flow termination. 

	 

	[phil] however, if the encoding chosen allows a pkt to be both 'adm marked' & 'termin marked' then your check is unnecessary. This is what the text tries to say. However, I don't think this section should be discussed too much at the moment, as hopefully we reach rapid convergence on the encoding option & then we know better what to write here. 

	 

	 

	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
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn