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

From: <[email-masked]>
Date: Tue, 4 Mar 2008 11:13:02 -0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 27 February 2008 11:02
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 4 Mar 2008 12:24:21 +0100

Phil,
 
I agree to you to requiring "MUST" for the following two fundamental PCN functions:

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

The interface MUST have:

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

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Tuesday, March 04, 2008 12:13 PM
	To: [email-masked]
	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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 27 February 2008 11:02
	To: [email-masked]
	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:

	 

	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?

	 

	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]:

	 

	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).

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

	The interface MUST have:

	 

	a token bucket, which 

	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

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

	[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)?

	a. leave TB.fill unaltered 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        

	[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:

	[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]

	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

---

From: Michael Menth <[email-masked]>
Date: Wed, 05 Mar 2008 14:16:52 +0100

Hi,

I would like to briefly comment some issues raised along this thread. 
Possibly there were also some misunderstandings.

There was the debate concerning whether the metering and marking 
function has to be done at the head end or tail end of a link. This has 
actually no impact on the obtained markings. Therefore, I do not 
understand why this must be standardized and the configuration must be 
consistent. If we say the location must be the same for all links of a 
domain, this is not enough for inter-operability when vendor A 
implements all function for the head end and vendor B for the tail end 
of a link. Therefore, we should provide either more flexibility or 
specify exactly where to implement the functions.

The question whether packet metering and marking is done before or after 
packet loss occurs has more impact on the correctness of PCN than the 
above aspect. For the case of termination marking see 3.2 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-Eval.pdf
Therefore, standardizing this issue could avoid different behavior of 
different equipment in challenging situations. However, this possibly 
reduces implementation options for vendors.

Regards,

Michael

[email-masked] wrote:
>
> 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
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of [email-masked]
> *Sent:* 27 February 2008 11:02
> *To:* [email-masked]
> *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?
>
> [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.
>
> 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
> If a packet’s ECN/DSCP fields have the value PCN, as defined in 
> If a packet’s ECN/DSCP fields do not have the value PCN, as defined in 
> [Joe] I would suggest that the second line be reword to say that “all 
> other packets are not PCN-packets”.
>
> 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).
>
> [phil] disagree. If we make this a MAY it means the PCN standard 
> doesn’t require any particular marking behaviour!!
>
> The interface MUST have:
>
> 2 if TB.fill < TB.threshold, then the meter indicates “admission mark” 
> to the Mark function
>
> [phil] ok, although I suppose ‘equal to’ is ok in both cases
>
> [phil] they were meant to make it clear that numbering doesn’t imply 
> 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
>
> then indicate “admission mark” to the Mark function
>
> [Joe] The above points are not needed as “1B” states that minimum TB 
> If the meter indicates to “admission mark” a PCN-packet, then:
>
> 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]
>
> The “admission marking” is only applied to unmarked PCN packets.
>
> As note could state that “termination marked” packets MUST NOT be 
> [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 
> <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: <[email-masked]>
Date: Wed, 5 Mar 2008 13:37:58 -0000

> From: Michael Menth [mailto:[email-masked]]
> Sent: 05 March 2008 13:17
> To: Eardley,PL,Philip,CXR9 R; pcn

Yes, I think this is sensible. Does anyone have preferences (Joe has
said he prefers the former)

> above aspect. For the case of termination marking see 3.2 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-
> Eval.pdf

I think I remember from 'corridor' discussions at last ietf that the
router needs to ensure that it first drops pkts (if necessary) and then
marks them. Then everything works as expected. If I got this right, then
this seems a good thing to add. 
Thanks
phil

> > apply to the version I sent to list) (hope that's ok joe).
> >
> > Thanks
> >
> > phil
> >
> performs three functions, which are outlined in draft-ietf-pcn-
> architecture as follows:
> >
> > [Joe] Suggest rewording "The same choice MUST be made for every
> > PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD
> > Note: The meter is described as a 'token bucket with threshold',
> > doesn't require any particular marking behaviour!!
> >
> > The interface MUST have:
> >
> > If the PCN-packet's codepoint is already "termination mark" then it

---

From: Michael Menth <[email-masked]>
Date: Wed, 05 Mar 2008 14:50:04 +0100

Hi,

[email-masked] wrote:
>> function has to be done at the head end or tail end of a link. This
>>     
> has
>   
As far as I can remember the discussion was the following. If a 
processor cannot have several meters and markers per outgoing links, 
which may be implementation-specific, the marking functionality for 
admission may be implemented on the outgoing link and for termination on 
incoming links. It can also be done vice-versa. It was discussed as an 
implementation issue allowing more flexibility depending on existing code.

Regards,

    Michael

>   
>> The question whether packet metering and marking is done before or
>>     
> after
>   
>>> *From:* [email-masked] [mailto:[email-masked]] *On
>>>       
> Behalf
>   
>>> I think we have consensus on the admission marking behaviour. This
>>>       
> is
>   
>>> If an interface of the PCN-domain performs PCN Admission Marking
>>>       
> then it
>   
>>>    o  PCN-meter - measure the 'amount of PCN-traffic'.  The
>>>       
> measurement
>   
>>>    o  PCN-mark - algorithms determine whether to PCN-mark
>>>       
> PCN-packets
>   
>>>       and what packet encoding is used (as specified in another PCN
>>>       
> WG
>   
>>>       document).
>>>
>>> ingoing or outgoing interfaces. The same choice MUST be made for
>>>       
> every
>   
>>> be configured so that all links within the PCN-domain support the
>>>       
> PCN
>   
>>> function.
>>>
>>> and outgoing interfaces to compensate for a node that does not
>>>       
> provide
>   
>>> PCN function.
>>>
>>> that can not be congested why would he need PCN-function on those
>>>       
> links?
>   
>>>    that an interface cannot become pre-congested then it's not
>>>       
> strictly
>   
>>> If a packet's ECN/DSCP fields do not have the value PCN, as defined
>>>       
> in
>   
>>> [Joe] I would suggest that the second line be reword to say that
>>>       
> "all
>   
>>>       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:
>>>
>>> however the implementation is not standardised. For example, it
>>>       
> could
>   
>>> [2] a meter for PCN-packets, which MUST have the following
>>>       
> behaviour:
>   
>>> 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
>   
>>> must be done in this order (which the reader might otherwise
>>>       
> assume)?
>   
>>> b. set TB.fill = 0 and indicate "admission mark" to the Mark
>>>       
> function
>   
>>> remarked, but I believe it is not needed as there may be networks
>>>       
> that
>   
>>> marked' & 'termin marked' then your check is unnecessary. This is
>>>       
> what
>   
>>> convergence on the encoding option & then we know better what to
>>>       
> write
>   
>>> here.
>>>
>>> <http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-
>>>       
>> 00.txt%20Fig%2010.1>
>>     
>>> on page 21.
>>>
>>> Comments?
>>>
>>> phil
>>>
>>>
>>>