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

[Michael Menth <[e-mail]>]

Hi Phil,

[e-mail] wrote:
>
> 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
>
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

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

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn

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