Subject: [PCN] New version of the marking behaviour draft

From: <[email-masked]>
Date: Thu, 26 Jun 2008 10:01:11 +0100

I've just updated the marking behaviour draft,
http://www.ietf.org/internet-drafts/draft-eardley-pcn-marking-behaviour-
01.txt 

Main change was to re-write Traffic conditioning section - also tried to
take account of the two encoding drafts (baseline & extension).

Comments welcome!

Thanks

Phil

Abstract
 
   This document standardises the two marking behaviours of PCN-nodes:
   threshold marking and excess traffic marking.  Threshold marking
   marks all PCN-packets if the PCN traffic rate is greater than a first
   configured rate.  Excess traffic marking marks a proportion of PCN-
   packets, such that the amount marked equals the traffic rate in
   excess of a second configured rate.

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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 29 Jun 2008 18:51:20 -0400

Phil, 

My comments on draft-eardley-pcn-marking-behaviour-01 version. 

**********************

Section 2 specifies the functions involved, which in outline (see Figure
1) are:

   o  Packet classify and condition - decide whether an incoming packet

      belongs to a PCN-flow or not;

[Joe] This is a PCN ingress node function and not part of the metering
and marking behavior that this draft is defining. This should be moved
to Arch draft or draft that defines edge behaviors.

o  Condition: drop or downgrade packets if the link is overloaded;

[Joe] This could be a PCN ingress node function but not part of the
metering and marking behavior that this draft is defining. This should
be moved to Arch draft or draft that defines edge behaviors.

   Figure 1: Schematic of functions for PCN-marking

[Joe] The Classify and Condition blocks should be deleted. As stated
above, combination of the DSCP field and ECN field in the IP header is
used to indicate that a packet is a PCN-packet, so packet classification
is not needed. 

1.1.  Terminology

   o  Other-traffic: traffic that uses the same DS codepoint as PCN-

      traffic, but a different value in the ECN field; has the same

      priority as PCN-traffic (in terms of scheduling at PCN-nodes); but

      is not subject to PCN-marking, nor PCN's admissin control and flow

      termination mechanisms.  Thus PCN-traffic and other-traffic have

      different per-domain behaviours RFC 3086 [RFC3086].  Note: there

      may be no other-traffic in a PCN-domain.  Note: the term PCN-BA

      does not include other-traffic (this is a clarification, as the

      definition of behaviour aggregate in RFC 2474 [RFC2474], RFC 2475

      [RFC2475] is somewhat ambiguous in the context of PCN.

[Joe] Suggest rewording above to:

Non-PCN-traffic: traffic that is admission controlled using some other
means and uses the same DS codepoint as PCN-traffic but a different
value in the ECN field; has the same priority as PCN-traffic (in terms
of scheduling at PCN-nodes); but is not subject to PCN-marking, nor
PCN's admission control and flow termination mechanisms. 

[Joe comment] The mixture of non-PCN and PCN traffic into the same queue
introduces two options for metering. Only PCN traffic is metered or
Non-PCN and PCN traffic is metered against PCN-threshold and PCN-excess
rates. For flow termination, metering PCN and non-PCN traffic is
required otherwise not enough traffic will be removed. For admission
control metering could be performed just for PCN-traffic or PCN and
non-PCN traffic. Should also note that each PCN node needs police
non-PCN traffic otherwise non-PCN traffic could break the PCN admission
control. Think it would be good idea that is issues is documented later
in this draft.   

   o  Priority-traffic: traffic that is more important than PCN that

      shares the same capacity as PCN and is priority scheduled over PCN

      (perhaps an operator's control messages).  Note: there may be no

      priority-traffic in a PCN-domain.

[Joe] Delete the above. If traffic is going to be scheduled differently
than it needs a different DS codepoint.

   o  Metered-traffic: the collective term for PCN-traffic and (if any)

      priority-traffic and other-traffic.

[Joe] Delete the above. Do not understand why this is needed.

   o  Downgrade: Re-marking a packet, ie changing its DS codepoint, into

      a lower priority behaviour aggregate, such as best effort or

      assured forwarding; as a consequence perhaps dropping lower

      priority packets.

[Joe] Downgrading of packets, changing DS codepoints so that they are
forward by a different queue is very bad as it cause miss ordering of
packets. The downgrading concept can be used in admission control,
instead of block a new flow from being admitted is allowed into the
network into a service class that is not admission control and therefore
it my encounter lower queues. Delete the above.

2.1.  Scope

All metered-traffic MUST be metered by the metering functions

   specified in Sections 2.3, 2.4 and 2.5 (with the minor exception

   noted below in Section 2.5).  Priority-traffic and other-traffic MUST

   NOT be PCN-marked (ie only PCN-packets can be PCN-marked).

[Joe] Suggest rewording after changes are made to sections below.

2.2.  Classify function

   A packet MUST be classified as a PCN-packet if the value of its DSCP

   and ECN fields are as standardised in

   [I-D.moncaster-pcn-baseline-encoding] or

   [I-D.draft-moncaster-pcn-3-state-encoding], as applicable to the PCN-

   domain.  Otherwise the packet MUST NOT be classified as a PCN-packet.

   A packet MUST be classified as an other-traffic packet if it uses the

   same DSCP as PCN-traffic, but a different value in the ECN field.

   A packet MUST be classified as a priority-traffic packet if it shares

   the same capacity as PCN-traffic and other-traffic and is priority

   scheduled over them.

[Joe] The Classify function is PCN ingress function and it does not
belong in this document. Please delete it.

2.3.  Traffic conditioning function

   On all links in the PCN-domain, traffic conditioning MUST be done by:

   o  metering all metered-traffic to determine if the level of metered-

      traffic is sufficiently high to overload the PCN behaviour

      aggregate(s).  (According to RFC 2475 [RFC2475] metering is "the

      process of measuring the temporal properties (eg rate) of a

      traffic stream".

   o  if the level of metered-traffic is sufficiently high, then do one

      or more of the following:

      *  drop PCN-packets;

      *  downgrade PCN-packets;

      *  drop other-packets;

      *  downgrade other-packets.

      *  <you might argue that other-packets should get harsher

         treatment since they're not subject to PCN's adm & termination

         control, only subject to the weaker DiffServ style static TCAs

         at the PCN-ingress-node>

   If PCN-packets are dropped (or downgraded) then:

   o  excess-traffic-marked PCN-packets SHOULD be preferentially dropped

      (downgraded);

   o  PCN-packets that are dropped (downgraded) SHOULD NOT be metered by

      the Excess traffic Meter.

   In addition, PCN-ingress-nodes MUST police PCN-traffic by:

   o  metering PCN-packets that are part of a previously admitted PCN-

      flow, to check that it keeps to the agreed rate or flowspec (eg

      RFC 1633 [RFC1633] for a microflow, and its NSIS equivalent).

   o  checking that any packets received that demand PCN treatment do

      indeed belong to a previously admitted flow.

   o  dropping or downgrading packets that fail the above checks.

   In addition, PCN-ingress-nodes MUST police other-traffic by:

   o  metering other-traffic to check that it meeds its traffic

      conditioning agreement, which is the parameters of the traffic

      that will be accepted from a customer.  Typically it is statically

      defined as part of the subscription-time service level agreement,

      as in the DiffServ architecture RFC 2475 [RFC2475]

   o  dropping or downgrading packets that fail the above check.

   In addition, an operator MAY measure the amount of traffic entering

   (or leaving) its network for accounting reasons.  Consideration is

   out of scope of this document.

[Joe] The complete section 2.3.  Traffic conditioning function needs to
be deleted and replaced with discussion of the issues when PCN and
non-PCN traffic is aggregated into a single forwarding service class or
queue. If an operator chooses to use the same forwarding service class
for both PCN and non-PCN traffic than the non-PCN traffic SHOULD be
policed on each PCN node. (Also SHOULD or MUST is up for debate).

[Joe comment] My personal view is that to keep it simple PCN and non-PCN
traffic should not be mixed into the same forwarding service class
(queue). But for completeness it should be covered in a section in the
back of the draft.  

2.5.  Excess traffic meter function

   A packet SHOULD NOT be metered (by this excess traffic meter

   function) in the following two cases:

   o  If the packet is already excess-traffic-marked;

   o  If this PCN-node drops (downgrades) the packet because the link is

      overloaded.

[Joe] Suggest deleting the word downgrades. I also have an issue with
the meter needing to know if the packet is going to be dropped or not at
some later stage in the node. This requirement may introduce high
complexity in some router implementations. Why is this important?

B.2.  Classify

   Traffic that has a higher DiffServ priority than PCN, but shares the

   same capacity, is metered as though it were PCN-traffic but cannot be

   PCN-marked.  This means that a meter may indicate a packet is to be

   PCN-marked, but the Marking function knows it cannot be marked.  It

   is left open to the implementation exactly what to do in this case;

   one simple possibility is to mark the next PCN-packet.  Note that

   unless the PCN-packets are a large fraction of all the metered-

   packets then the PCN mechanisms may not work well.

   Similar remarks can be made with respect to other-traffic.

[Joe] Do not understand B.2. How can if have higher DiffServ priority
and share the same queue?

B.3.  Traffic conditioning

[Joe] How do you downgrade a packet without causing re-ordering of
packets in flow under congestion?

[Joe] Section B.3 Traffic conditioning need significant amount of
rewriting. Would suggest that it be called Traffic Policing and as it
pertains to PCN and real-time flows only packet dropping could be
applied. The other traffic conditioning methods should be deleted as
they not appropriated for real-time applications.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: June 26, 2008 5:01 AM
To: [email-masked]
Subject: [PCN] New version of the marking behaviour draft

Comments welcome!

Thanks

Phil

Abstract