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

From: <[email-masked]>
Date: Wed, 27 Feb 2008 11:02:07 -0000

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. 

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.

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. 

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:

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

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

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. 

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]

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: Lars Eggert <[email-masked]>
Date: Wed, 27 Feb 2008 13:32:30 +0200

Hi,

I think this is a very useful attempt at formalizing things!

A few comments on specific things below.

> PCN-node in one PCN-domain.

Is there any difference in functionality or any other reason why we  
wouldn't just decide on one? Leaving this open means that potential  
users of PCN need to buy matching equipment or at least configure one  
more thing correctly.

> Meter function:

Can we agree to always add the units of the various rates and  
counters, i.e., whether they are in bits or packets? Some of them are  
already clearly identified, but not all. Doing this would improve the  
description.

> marked" and "termination marked":

Do you think it would make sense to wait with the architecture until a  
few key decisions have been reached on the encoding? That would allow  
us to simplify the description by avoiding constructs like "REQUIRED,  
unless".

Lars

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 12:33:30 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars
> Eggert
> Sent: 27 February 2008 11:33
> To: ext [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] PCN admission marking algorithm - consensus?
> 
> Hi,
> 

No difference in functionality & I agree it would be nice to have fewer
configurables. 
Egress seems more natural to me (if it's a real queue then naturally
it's done at the egress). However, I know of existing kit where it looks
like you can easily configure it to do PCN marking on the ingress
interface but not on egress interface (still trying to clarify this).
Not sure if this is a relevant consideration. 

> already clearly identified, but not all. Doing this would improve the

Yes, and should check this in terms of
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02
.txt 

Which I think means that it should meter in terms of bits (virtual queue
is concerned about congestion of the line (ie bit/sec)) and mark
irrespective of the pkt size.
I had a quick chat with bob & believe this is what his byte-pkt-mark
draft says (with the exception that if the machine architecture pads to
the MTU size, then you have to interpret 'size of pkt' to mean 'size
after padding').

> us to simplify the description by avoiding constructs like "REQUIRED,

Don't think it impacts the architecture, but yes it makes sense to me
that key encoding decisions are made first in order to avoid this
construct.

---

From: Michael Menth <[email-masked]>
Date: Wed, 27 Feb 2008 14:50:03 +0100

Hi,

[email-masked] wrote:
>>> ingoing or outgoing interfaces. The same choice MUST be made for
>>>       
> every
>   

The rational behind this was to give more freedom to possibly existing 
hardware when only one meter and marker per in/outgoing interface is 
feasible.

> irrespective of the pkt size.

That's also my view: packet size dependent metering (bits/bytes) and 
packet size independent marking (packets of different size have the same 
marking probability).

Regards,

    Michael

-- 
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: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Feb 2008 14:24:27 +0100

Hi Phil,

I would like to have a more clear understanding on what 
you are proposing before we can get any consensus!

In my option all options that are currently decribed in the current version
of the archietcture draft 
will be reduced at the moment that the encoding method is selected and
probably also 
when the PCN algorithms used at interior and edges are selected.

I thought that the idea of the architecture draft is to provide a
description of the 
architectural options that can be used, such that later on a selection 
on the algorithms is done.

If that is not the case then the publication of the architecture draft
should be delayed
until the above selections are done!

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Menth
> Sent: woensdag 27 februari 2008 14:50
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > No difference in functionality & I agree it would be nice to have 
> > fewer configurables.
> > it's done at the egress). However, I know of existing kit where it 
> > looks like you can easily configure it to do PCN marking on the 
> > ingress interface but not on egress interface (still trying 
> to clarify this).
> The rational behind this was to give more freedom to possibly 
> existing hardware when only one meter and marker per 
> in/outgoing interface is feasible.
> 
> 
> >   
> >>> Meter function:
> >>>       
> > Which I think means that it should meter in terms of bits (virtual 
> > queue is concerned about congestion of the line (ie 
> bit/sec)) and mark 
> That's also my view: packet size dependent metering 
> (bits/bytes) and packet size independent marking (packets of 
> different size have the same marking probability).
> 
> Regards,
> 
>     Michael
> 
> > draft says (with the exception that if the machine 
> architecture pads 
> > to the MTU size, then you have to interpret 'size of pkt' to mean 
> > 'size after padding').
> >
> >   
> >>> Mark function:
> >>>
> >> Do you think it would make sense to wait with the 
> architecture until 
> >> a few key decisions have been reached on the encoding? That would 
> >> allow us to simplify the description by avoiding constructs like 
> >> "REQUIRED, unless".
> >>     
> >
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: <[email-masked]>
Date: Thu, 28 Feb 2008 13:29:13 -0000

The email below is about the marking behaviour. Not about the encoding
or edge behaviours.

The purpose of my email: I believe we have good consensus on the marking
behaviour for both admission & termination. So we can formalise them &
reach agreement hopefully with some speed. 

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 28 February 2008 13:24
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Subject: RE: [PCN] PCN admission marking algorithm - consensus?
> 
> 
> Hi Phil,
> 
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-
> > > 02

---

From: <[email-masked]>
Date: Fri, 29 Feb 2008 08:20:29 -0000

Anna has pointed out to me that this email should talk about "PCN
threshold marking" rather than "PCN Admission marking". Similarly the
other email should be about "PCN excess marking" rather than "PCN
termination marking". This reflects what we agreed a couple of ietfs ago
& also the phrasing in the architecture draft. Sorry & thanks anna for
spotting the mistake

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?

 

 

Classify function:

Meter function:

The interface MUST have:

a token bucket, which 

 

Mark function:

 

Comments?

phil