Subject: [PCN] EncodingCompDraftIssue#1: Reliance on DiffServ for traffic separation

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 10 Jul 2007 12:37:10 -0400

This is the start of Issue #1 for draft-chan-pcn-encoding-comparison-xx.txt.

In -00 of the Encoding Comparison draft,
we have organized the encoding choices and made some assumptions
on the possible use of DiffServ for the purpose of separating the PCN traffic
from all other traffic.

Would want to test this assumption by making it the Issue #1 for the
Encoding Comparison draft:

"Should the PCN WG requires the use of DiffServ (or some other mechanism)
to separate the PCN (packet) traffic from all other (packet) traffic?"

The result of discussion on this Issue #1 will affect how we compare 
the different
Encoding choices (including the use of ECN bits and other DSCPs).

This assumption on requirement may also affect the Requirements on 
Metering Algorithms
and Marking Semantics as we go forward.

A secondary (for the future) idea that may play into this discussion is that
should we use PCN on other real-time traffic service classes?  Should these
different real-time service classes be separated by the use of DiffServ?

Thanks!
-- Kwok --

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 11 Jul 2007 08:31:11 +0200

Hi Kwok,

|"Should the PCN WG requires the use of DiffServ (or some other 
|mechanism) to separate the PCN (packet) traffic from all other 
|(packet) traffic?"

Is your question, whether PCN traffic should have dedicated 
resources? 

Regards,

Ruediger

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 11 Jul 2007 11:56:06 -0400

Hi Ruediger:

There are actually multiple impacts that can result from discussion 
of this issue:

- PCN Encoding choices, with PCN traffic separated, there are 
encoding states that
   can be off-loaded from the 2 bit ECN field.  Providing some flexibility to
   encoding choices.  Then there is the question of how much separation should
   be provided by DiffServ?  Should DiffServ be used to encode all PCN states?

- PCN Metering mechanism, with PCN traffic separated, there may be different
   factors to consider when considering PCN Metering mechanism requirements.

With this, there are actually 2 kinds of resources:
- the bits in the IP header for encoding is a resource
- the traffic forwarding path resources

And there is also management/operational resource that need to be considered.

So the answer to your question YES, whether PCN traffic should have dedicated
resources in both Encoding sense and Traffic Forwarding sense.

And we may have additional questions when we want to consider more than one
kind of PCN traffic.

I am starting this off as an EncodingCompDraft Issue just because this is the
first major discussion we need to have to generate -01 of the 
EncodingCompDraft.

Hope this helps.
Thanks!
-- Kwok --

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 22 Jul 2007 22:54:20 +0100

Kwok,

I think no-one answered your question below that is a pre-requisite for the 
whole encoding comparison. See embedded for my response.

>to separate the PCN (packet) traffic from all other (packet) traffic?"

May I re-write this question with a specific example, to ensure everyone 
understands (and to confirm I've understood your question)?

How do we distinguish three states like these:
                                         Option X        Option Y
0... other non-EF, non-PCN states       DSCP0...        DSCP0...
1 EF scheduling without PCN marking     DSCP1           DSCP1 + ECN0
2 EF scheduling with    PCN marking     DSCP2           DSCP1 + ECN1

In both cases, the DSCP distinguishes PCN marking from not, but in Option Y 
PCN is turned on by the DS field *combined* with the ECN field.

A packet's DSCP says what scheduling behaviour the interface should use to 
handle that packet. It can also say that the packet should experience a 
congestion marking behaviour (3168 says all PHBs get the default 3168 ECN 
marking behaviour unless the PHB spec defines otherwise).

But there are the above two ways to get the same scheduling behaviour with 
and without marking during (pre-)congestion. I don't mind which, but these 
are options that have to be added to the mix to be decided. Actually, given 
a free choice I'd prefer Option Y, as it's got the same logic as RFC3168 ECN.

Bob

>The result of discussion on this Issue #1 will affect how we compare the 
>different

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196