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

From: <[email-masked]>
Date: Tue, 15 Jul 2008 13:51:20 +0100

Joe 

Thanks very much for all the comments!

In-line replies

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 29 June 2008 23:51
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] New version of the marking behaviour draft

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.

[phil] yes, pkt classification is a PCN ingress node function but it's
also a function that all PCN-nodes need to do. They have to decide
whether a particular pkt is a PCN-pkt or not, by looking at the DSCP &
ECN fields. However, the mention of PCN-flow is somewhat misleading and
it think it would be better to re-phrase this bullet:

o  Packet classify - decide whether a packet is a PCN-packet or not;

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.

[phil] yes, conditioning is a PCN ingress node function but it's also a
function for all PCN-nodes. 

[phil] I'm not sure about your comment about deleting from this draft
discussion about specific PCN-ingress-node policing (traffic
conditioning) actions. The PCN-ingress-node's traffic conditioning is
very similar to other PCN-nodes, just some slight specialisation, so it
seems easy to talk about it here. Also the PCN-ingress-node policing
stuff is MUSTs which is ok in this draft but not possible in the
Informational archit draft & edge behaviour drafts.

   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. 

[phil] I would call this action [looking at the combination of dscp &
ecn to determine if it's a pcn-pkt] pkt classification. Alternative
name?

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.

[phil] the different term seems better to me, and a re-wording on these
lines is good/

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

[phil] I think admission control metering also needs to meter
non-PCN-traffic, since it has the same DSCP as PCN-traffic it shares the
link's capacity (equal scheduling priority). Otherwise there's a risk of
over-admission of pcn, if there's lots of the non-PCN-traffic.

The issue of queues is a separate one. The pcn-traffic and
non-pcn-traffic might use the same queue or different queues. But even
in the latter case, same scheduling priority (this seems implicit in
them having the same DSCP - in principle I suppose they could be
scheduled with different priorities).

Yes each pcn-node polices non-pcn-traffic, this is covered later. 

   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.

[phil] yes it has a different dscp. However it uses pcn capacity but
scheduled at a higher priority (ie am assuming this traffic doesn't have
its own dedicated capacity but rather just uses the same capacity as pcn
but scheduled at a higher priority).

   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.

[phil] all this traffic should contribute to the PCN meters, since it
shares the same capacity as PCN. If there's lots of this traffic then
there's less room for PCN-traffic. 

[phil] I think it would be worth adding to the Appendix. Especially if
metered-traffic only consists of PCN-traffic, then traffic conditioning
on PCN-interior-nodes may not be critical, since if a Pcn-node is
overloaded then flow termination will rapidly bring the amount of
pcn-traffic back below the PCN-excess-rate. So traffic conditioning on
PCN-interior-nodes would only be needed for a short period of time, so
perhaps an operator might choose not to do it. So perhaps traffic
conditioning on PCN-interior-nodes is a SHOULD or even MAY rather than a
MUST. 

   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.

[phil] the danger of re-ordering is mentioned in section B.3. however,
it would be good to have a discussion about whether downgrading is a
sensible traffic conditioning action, or whether (like shaping) it
should be listed as an unsuitable action. 

...

2.3.  Traffic conditioning function

...

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

[phil] for me, the issue is whether the PCN-traffic and non-pcn-traffic
are scheduled with the same priority. Separate queues opens up the
possibility of different priorities, but of course they could still be
prioritised the same. I've been assuming that because they've got the
same dscp they'll have the same scheduling priority - however I guess
this wouldn't necessarily have to be the case. Worth discussing this,
and what the most likely /sensible implementation is. 

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?

[phil] re "know if the packet is going to be dropped or not at some
later stage in the node". In fact, the dropping (etc) action will
presumably be implemented in a node before the metering function, at
least that seems the easiest way to implement it. Perhaps I should
re-write with this assumption, but point out this issue if you do it the
other way round. The problem was explained by Michael in one of his
papers, if I remember it right it's that you end up terminating too much
traffic if a node meters pkts that it also drops. 

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?

[phil] shares same capacity, not 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.

[phil] I tried to follow the terminology of rfc 2474 & 2475. as is the
way, the match isn't 100% right for pcn. Eg 2474 defines traffic
conditioning as including "metering, policing, shaping, and packet
marking." 
I chose to use the term Policing only in the context of
PCN-ingress-nodes. Of course I could have just called that traffic
conditioning as well, and strictly that would be more correct. I just
thought it would be easier to save the word policing for ingress node
action. However, I'm not sure this was the right choice. 

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

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: Mon, 21 Jul 2008 23:04:44 -0400

Phil,

Some additional comments below yours. 

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

From: [email-masked] [mailto:[email-masked]] 
Sent: July 15, 2008 8:51 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] New version of the marking behaviour draft

Joe 

In-line replies

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 29 June 2008 23:51
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] New version of the marking behaviour draft

Phil, 

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

*      Packet classify - decide whether a packet is a PCN-packet or not;

[Joe] State that packet classification is based on DSCP and ECN fields
only for interior nodes. 

[Joe] I always thought that the purpose of this work was that within PCN
domain, PCN traffic is controlled at edges so that conditioning
(dropping of PCN packets) could be avoided? If interior nodes are going
to drop PCN packets how can QoS be assured and what is the value of PCN?

[Joe] At PCN ingress-node traffic classification and condition needs to
be expended to address all scenarios.  e.g., untrusted DSCP, ECN and
traffic rate, trusted DSCP, ECN but untrusted traffic rate, trusted
DSCP, ECN and traffic rate, etc. I just do not think that this is draft
where this needs to be addressed in. 

[Joe] RFC 2475 provides some terminology. I believe BA Classifier would
be an appropriate term with a note that it also includes the ECN field.

1.1.  Terminology

 

[Joe]  There is not risk of over-admission if the non-PCN-traffic is
admission controlled by some other means.

[Joe] This will depend on how the new DSCP is defined. For example if
PCN uses the Voice Admit DSCP than traffic that is marked with that DSCP
is admission controlled and does not need to be policed on interior
nodes as it is controlled at ingress to the network. If the PCN domain
chooses to support both, flows that are admission controlled by some
other means and by PCN mechanism, than one option is, each admission
control mechanism controls the amount of traffic that can be admitted on
to the link independently and the rates are configured so that the sum
does not exceed the service class capacity for that link. The other
option is that PCN and Voice Admit traffic is aggregate and metered
against the capacity of the service class of that link. Both are
acceptable and operator can choose. 

 

[Joe] I'm confused. Why have traffic that is scheduled by a different
queue be included into PCN scheduling capacity? If you are going to mix
traffic that is admission control and not admission controlled into the
same scheduling class (queue) than this requires a section explaining
how it's going to work and how all the additional meters and drops in
all the interior nodes are configured. My assumption is that this type
of configuration would not be popular as it would be very complex to
configure, but could be documented in an appendix. 

[Joe] I think we should document a scenario where there is only PCN
traffic, PCN and traffic that is admission controlled by some other
means, and finally PCN traffic and other real-time traffic that is not
admission controlled. The last one will require additional meters and
droppers on all interior nodes. 

      priority packets.

[Joe] My understanding is that DiffServ architecture does not recommend
mechanisms that introduce mis-ordering of packets.   

...

...

[Joe] DiffSer architecture states that all packets marked with the same
DSCP are forwarded from the same queue or scheduling class. ECN field is
not used in determining what queue or scheduling class the packet should
be forwarded from. That means that at ingress to PCN domain, there are
the following configuration options. One is that only pcn-traffic are
marked with the DSCP that supports PCN. Option 2, both pcn-traffic and
non-pcn-traffic is marked with the same DSCP but non-PCN-traffic is
admission controlled by other means. Option 3 both PCN-traffic and
non-pcn-traffic is marked with same DSCP and the non-pcn-traffic is not
admission controlled.

My other point is that "scheduled with the same priority" or "from the
same queue" is equivalent. 

      overloaded.

[Joe] Yes one of the flow termination approaches was sensitive but
others where not. I would expect that dropping of pcn-traffic that
exceeds the pcn-service-rate (scheduler) will cause the queue to
overflow and this is how packets will be dropped. This is how we
simulated flow termination with packet loss. Most routers do not have
meter function on egress interfaces so adding a requirement that PCN
traffic be metered and dropped before it is send to queue will require
new silicon.

B.2.  Classify

[Joe] Forwarding capacity or rate on router is configured per queue. 

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

Comments welcome!

Thanks

Phil

Abstract