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

[<[e-mail]>]

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