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

["Georgios Karagiannis" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: woensdag 27 februari 2008 14:13
To: [e-mail]
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-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

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