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

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

3rd (& last - phew) of several emails to try & close Open Issues on
http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt 

the baseline encoding draft envisages that there may be non-PCN-traffic
that shares the same DSCP as PCN traffic. Question is whether we assume
that PCN-interior-nodes will treat these two sorts of traffic the same
as regards scheduling priority, or whether it's possible they might not
be?
                                              
http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-02.txt
says:
   o  The scheduling behaviour is coupled with the DSCP only.
      Therefore, the same scheduling and buffer management rules are
      applied for non-PCN-capable and PCN-capable traffic using the same
      PCN-enabled DSCP.
 
This seems very reasonable to me. 
However, since a PCN-interior-node has to classify (distinguish)
PCN-pkts from non-PCN ones with the same DSCP (done by examining the ECN
field) - therefore it would in theory be possible to schedule them
differently.
 
Also, I guess that "the same buffer management rules" means that when it
comes to traffic conditioning (policing) on PCN-interior-nodes, then the
PCN-pkts and non-PCN pkts (sharing the same DSCP) will also be treated
the same. Again, this seems very reasonable to me.

Comments?
Thanks,
Phil/

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

---

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

See comments below.

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:47 PM
To: [email-masked]
Subject: [PCN] Issue 3 on draft-eardley-pcn-marking-behaviour-01

the baseline encoding draft envisages that there may be non-PCN-traffic
that shares the same DSCP as PCN traffic. Question is whether we assume
that PCN-interior-nodes will treat these two sorts of traffic the same
as regards scheduling priority, or whether it's possible they might not
be?
[Joe] Interior-nodes will forward non-PCN and PCN traffic using the same
scheduling priority. ECN field is not used for mapping packets to
different queue (scheduling priority).
                                              
[Joe] The above statement is correct.
 
This seems very reasonable to me. 
However, since a PCN-interior-node has to classify (distinguish)
PCN-pkts from non-PCN ones with the same DSCP (done by examining the ECN
field) - therefore it would in theory be possible to schedule them
differently.
[Joe] Yes it would be possible. However core routers normally have only
small number queues or scheduling classes (between 1 and 8) adding more
requires additional hardware in the fast path. 

Comments?
Thanks,
Phil/

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 23 Jul 2008 10:43:47 -0400

Hi Joe,  
 
you say below 
 
Are you proposing to impose this constraint in the standard?  Is it not
overly constraining?
 
Anna 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jozef Babiarz
	Sent: Tuesday, July 22, 2008 9:50 PM
	To: [email-masked]; [email-masked]
	Subject: Re: [PCN] Issue 3 on
draft-eardley-pcn-marking-behaviour-01

	See comments below.

	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:47 PM
	To: [email-masked]
	Subject: [PCN] Issue 3 on draft-eardley-pcn-marking-behaviour-01

	3rd (& last - phew) of several emails to try & close Open Issues
on http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt 

	the baseline encoding draft envisages that there may be
non-PCN-traffic that shares the same DSCP as PCN traffic. Question is
whether we assume that PCN-interior-nodes will treat these two sorts of
traffic the same as regards scheduling priority, or whether it's
possible they might not be?
	[Joe] Interior-nodes will forward non-PCN and PCN traffic using
the same scheduling priority. ECN field is not used for mapping packets
to different queue (scheduling priority).

http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-02.txt
says:
	   o  The scheduling behaviour is coupled with the DSCP only.
	      Therefore, the same scheduling and buffer management rules
are
	      applied for non-PCN-capable and PCN-capable traffic using
the same
	      PCN-enabled DSCP.
	[Joe] The above statement is correct.
	 
	This seems very reasonable to me. 
	However, since a PCN-interior-node has to classify (distinguish)
PCN-pkts from non-PCN ones with the same DSCP (done by examining the ECN
field) - therefore it would in theory be possible to schedule them
differently.
	[Joe] Yes it would be possible. However core routers normally
have only small number queues or scheduling classes (between 1 and 8)
adding more requires additional hardware in the fast path. 
	 
	Also, I guess that "the same buffer management rules" means that
when it comes to traffic conditioning (policing) on PCN-interior-nodes,
then the PCN-pkts and non-PCN pkts (sharing the same DSCP) will also be
treated the same. Again, this seems very reasonable to me.

	Comments?
	Thanks,
	Phil/

---

From: Steven Blake <[email-masked]>
Date: Wed, 23 Jul 2008 13:06:49 -0400

On Wed, 2008-07-23 at 10:43 -0400, Anna Charny (acharny) wrote:

> Hi Joe,  
>  
> you say below 
> [Joe] Interior-nodes will forward non-PCN and PCN traffic using the same scheduling priority. 
> ECN field is not used for mapping packets to different queue (scheduling priority).
>  
> Are you proposing to impose this constraint in the standard?  Is it
> not overly constraining?

It should not necessarily be a mandatory constraint.  But it might be a
good assumption.

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Thu, 24 Jul 2008 00:07:23 -0400

> It should not necessarily be a mandatory constraint.  But it might be a

I should clarify: it's a safe assumption that many routers will forward
packets having the same DSCP value with the same PHB (irrespective of
the value of the ECN bits).  I anticipate resistance from the IETF
community if we propose otherwise.

Regards,

// Steve