Subject: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

From: <[email-masked]>
Date: Wed, 16 Jul 2008 18:26:50 +0100

2nd of several emails to try & close Open Issues on
http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt 

it's clear the PCN-ingress-nodes MUST do traffic conditioning
(policing). However, how about PCN-interior-nodes? 

So the question is: should PCN-interior-node traffic conditioning be a
MUST, SHOULD or MAY?

Why is traffic conditioning needed on PCN-interior-nodes?

Because the traffic pattern might be sufficient to overload a link (not
just pre-congest it).

However, you might argue that 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. But in the meantime lower priority flows would be
starved (can avoid starvation by setting the rate above which pkts are
dropped to be less than the line rate, ie ensuring there's always some
capacity for lower priority traffic).  Also, if only two encoding states
(PCN-marked and not PCN-marked) are available, then the operator might
choose to just do admission control. Flow termination would then rely on
some other mechanism (eg just waiting for end users to terminate their
flows because the perceived qos is bad).

So MAY seems too weak to me. 

SHOULD means "that there may exist valid reasons in particular
circumstances to ignore a particular item"
So that seems ok to me. 
 
Comments?
Phil/

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

---

From: <[email-masked]>
Date: Wed, 16 Jul 2008 18:33:34 +0100

Sorry, pushed send too quick, one more point added in-line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 16 July 2008 18:27
To: [email-masked]
Subject: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

[phil] also: Another reason that each PCN-node needs to police
non-PCN-traffic that shares the same DSCP (see baseline encoding draft).
Otherwise the non-PCN-traffic could break the PCN admission control. Of
course an operator might know that it never has any such traffic. 

 
Comments?
Phil/

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 22 Jul 2008 00:26:26 -0400

Phil my views on PCN-interior-nodes and policing requirements.

There is a dependency on how the new DSCP for PCN is defined. My
assumption is that in the definition of the new DSCP there will be a
statement that ECN semantics as defined in RFC 3168 do not apply and
that this DSCP will use new ECN semantics as defined in the
pcn-marking-behaviour and pcn-encoding-drafts. 

Option 1: If the Voice Admit DSCP is used than traffic that is marked
with this DSCP is admission controlled. The newly defined Voice Admit
DSCP can support two types of traffic, pcn-traffic that is admission
controlled by PCN mechanisms and non-pcn-traffic that uses some other
means for admission control.

Option 1 does not require interior nodes do perform policing function as
both traffic types are controlled by admission control and rates are
enforced through policing at the ingress to PCN-domain.

Option 2: If the new DSCP is defined in way so that PCN-admission
controlled and non-admission controlled traffic can be marked with it,
than non-admission controlled traffic that uses this new DSCP needs
(MUST) to be policed on all interior-nodes.  The policing function is
required to limit the amount of non-admission controlled traffic that is
allowed to be aggregated with PCN-traffic into queue on each link. If
the group chooses to go with option 2, than we will need to also explain
how metering and dropping will be done. E.g., meter only non-admission
controlled traffic (non-pcn-traffic), meter both pcn-traffic and
non-pcn-traffic and drop only non-pcn-traffic. 

Option 2 requires interior nodes to support egress policing function
which most core routers do not have.  

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

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: July 16, 2008 1:27 PM
To: [email-masked]
Subject: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

 
Comments?
Phil/

---

From: Michael Menth <[email-masked]>
Date: Tue, 22 Jul 2008 07:14:02 +0200

Hi,

I thought that also PCN flows might have parameters that are policed at 
ingress nodes to avoid that admitted voice flows can upgrade to video 
without new permission?

Regards,

Michael

Jozef Babiarz wrote:
> Option 1 does not require interior nodes do perform policing function 
> as both traffic types are controlled by admission control and rates 
> are enforced through policing at the ingress to PCN-domain.
>
> required to limit the amount of non-admission controlled traffic that 
> is allowed to be aggregated with PCN-traffic into queue on each link. 
> If the group chooses to go with option 2, than we will need to also 
> explain how metering and dropping will be done. E.g., meter only 
> non-admission controlled traffic (non-pcn-traffic), meter both 
> pcn-traffic and non-pcn-traffic and drop only non-pcn-traffic.
>
> /Regards, Joe/
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of [email-masked]
> *Sent:* July 16, 2008 1:27 PM
> *To:* [email-masked]
> *Subject:* [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01
>
> it’s clear the PCN-ingress-nodes MUST do traffic conditioning 
> Because the traffic pattern might be sufficient to overload a link 
> (not just pre-congest it).
>
> 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. But in the meantime lower priority 
> flows would be starved (can avoid starvation by setting the rate above 
> which pkts are dropped to be less than the line rate, ie ensuring 
> there’s always some capacity for lower priority traffic). Also, if 
> only two encoding states (PCN-marked and not PCN-marked) are 
> available, then the operator might choose to just do admission 
> control. Flow termination would then rely on some other mechanism (eg 
> just waiting for end users to terminate their flows because the 
> perceived qos is bad).
>
> SHOULD means “that there may exist valid reasons in particular circumstances to ignore a particular item”
> So that seems ok to me. 
>  
> Comments?
> Phil/
>
> ------------------------------------------------------------------------
>

-- 
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: <[email-masked]>
Date: Tue, 22 Jul 2008 19:04:19 +0100

hi michael
 
yes, this is already covered:
 
<<
   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).
 
thanks
phil

From: Michael Menth [mailto:[email-masked]]
Sent: Tue 22/07/2008 06:14
To: Eardley,PL,Philip,CXR9 R
Cc: Jozef Babiarz; [email-masked]
Subject: Re: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

Hi,

Regards,

Michael

Jozef Babiarz wrote:
> there's always some capacity for lower priority traffic). Also, if
> SHOULD means "that there may exist valid reasons in particular circumstances to ignore a particular item"
> So that seems ok to me.
> 
> Comments?
> Phil/
>

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 19:12:03 +0100

joe
follow up on on Option 1. if there's  a failure and traffic is re-routed, then a link could get overloaded. question is what to do about this. flow termination of course possible. if PCN-domain not runnign flow termination, then question is whether it's worth having policing on PCN-interior-nodes as a possibility to protect against this. i guess your view is that this should only be a MAY, since policing funciton isn't something most core routers can do?
 
thanks
phil

From: Jozef Babiarz [mailto:[email-masked]]
Sent: Tue 22/07/2008 05:26
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

There is a dependency on how the new DSCP for PCN is defined. My assumption is that in the definition of the new DSCP there will be a statement that ECN semantics as defined in RFC 3168 do not apply and that this DSCP will use new ECN semantics as defined in the pcn-marking-behaviour and pcn-encoding-drafts. 

Option 1: If the Voice Admit DSCP is used than traffic that is marked with this DSCP is admission controlled. The newly defined Voice Admit DSCP can support two types of traffic, pcn-traffic that is admission controlled by PCN mechanisms and non-pcn-traffic that uses some other means for admission control.

Option 1 does not require interior nodes do perform policing function as both traffic types are controlled by admission control and rates are enforced through policing at the ingress to PCN-domain.

Option 2: If the new DSCP is defined in way so that PCN-admission controlled and non-admission controlled traffic can be marked with it, than non-admission controlled traffic that uses this new DSCP needs (MUST) to be policed on all interior-nodes.  The policing function is required to limit the amount of non-admission controlled traffic that is allowed to be aggregated with PCN-traffic into queue on each link. If the group chooses to go with option 2, than we will need to also explain how metering and dropping will be done. E.g., meter only non-admission controlled traffic (non-pcn-traffic), meter both pcn-traffic and non-pcn-traffic and drop only non-pcn-traffic. 

Option 2 requires interior nodes to support egress policing function which most core routers do not have.  

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: July 16, 2008 1:27 PM
To: [email-masked]
Subject: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

2nd of several emails to try & close Open Issues on http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt 

it's clear the PCN-ingress-nodes MUST do traffic conditioning (policing). However, how about PCN-interior-nodes? 

So the question is: should PCN-interior-node traffic conditioning be a MUST, SHOULD or MAY?

Because the traffic pattern might be sufficient to overload a link (not just pre-congest it).

However, you might argue that 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. But in the meantime lower priority flows would be starved (can avoid starvation by setting the rate above which pkts are dropped to be less than the line rate, ie ensuring there's always some capacity for lower priority traffic).  Also, if only two encoding states (PCN-marked and not PCN-marked) are available, then the operator might choose to just do admission control. Flow termination would then rely on some other mechanism (eg just waiting for end users to terminate their flows because the perceived qos is bad).

 
Comments?
Phil/

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 22 Jul 2008 19:44:11 -0400

I think we need to be careful here. Under failure if we perform flow
termination and downgrading independently than there is the possibility
that too much traffic will removed from PCN service class. Also under
failure conditions most likely the best effort service class is also
heavily congested and the downgraded flow will experience high packet
loss.
I'm a bit uncomfortable with MAY. Would prefer to say that downgrading
of flows once admitted is future work, like rate-adoption.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: July 22, 2008 2:12 PM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

joe
follow up on on Option 1. if there's  a failure and traffic is
re-routed, then a link could get overloaded. question is what to do
about this. flow termination of course possible. if PCN-domain not
runnign flow termination, then question is whether it's worth having
policing on PCN-interior-nodes as a possibility to protect against this.
i guess your view is that this should only be a MAY, since policing
funciton isn't something most core routers can do?
 
thanks
phil

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

 
Comments?
Phil/

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 22 Jul 2008 21:33:46 -0400

Phil wrote:

So that seems ok to me.

[Joe] See my previous email. If PCN and non-PCN-traffic that is NOT
admission control share the same forwarding class, than interior nodes
MUST police non-PCN-traffic that is not admission control using some
other mechanism.

If PCN and non-PCN-traffic which is admission control by some other
means share the same forwarding class, than interior nodes DO NOT need
to police non-PCN-traffic that is admission controlled at ingress to PCN
domain. Suggestion is to allow both options and it's up to the network
administrator to configure their network correctly.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: July 16, 2008 1:34 PM
To: [email-masked]
Subject: Re: [PCN] Issue 2 on draft-eardley-pcn-marking-behaviour-01

-----Original Message-----

 
Comments?
Phil/