Subject: Re: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01

From: <[email-masked]>
Date: Mon, 1 Sep 2008 11:36:44 +0100

Hi chris,

>> If this interpretation is correct, this bullet point brings the same
message to the table as the message in bullet point 3 covering priority
traffic and PCN traffic.

[phil] Yes. This makes me think that the bullets need to be re-written,
which I've tried to do below. Is this clearer? (no technical changes,
but hopefully clearer!)

6.5.  PCN-traffic
   The following are some high-level points about how PCN works:
 
   o  There needs to be a way for a PCN-node to distinguish PCN-traffic
from other traffic.  This is through a combination of the DSCP field
and/or ECN field.
   o  It is not advised to have non PCN-traffic that competes for the
same capacity as PCN-traffic, but if there is such traffic, there needs
to be a mechanism to limit it. "Capacity" means the forwarding bandwidth
on a link; "competes" means that non PCN-packets will delay PCN-packets
in the queue for the link. Hence more non PCN-traffic results in poorer
QoS for PCN. Further, the unpredictable amount of non PCN-traffic makes
the PCN mechanisms less accurate and so reduces PCN's ability to protect
the QoS of admitted PCN-flows.  

      o  Two examples of such non PCN-traffic (ie that competes for the
same capacity as PCN-traffic) are:

1.    traffic that is priority scheduled over PCN (perhaps a particular
application or an operator's control messages).
2.    traffic that is scheduled at the same priority as PCN (for example
if the Voice-Admit codepoint is used for PCN-traffic and there is
voice-admit traffic in the PCN-domain
[I-D.moncaster-pcn-baseline-encoding]).
   o  If there is such non PCN-traffic (ie that competes for the same
capacity as PCN-traffic), then PCN's mechanisms should take account of
it, in order to improve the accuracy of the decision about whether to
admit (or terminate) a PCN-flow. The suggested mechanism is that such
non PCN-traffic contributes to the PCN meters (ie is metered by the
threshold-marking and excess-traffic-marking algorithms).
   o  There will be non PCN-traffic that doesn't compete for the same
capacity as PCN-traffic, because it is forwarded at lower priority.
Hence it shouldn't contribute to the PCN meters. Examples are best
effort and assured forwarding traffic. However, a PCN-node should
dedicate some capacity to lower priority traffic so that it isn't
starved.  
   o  The document assumes that the PCN mechanisms are applied to a
single behaviour aggregate in the PCN-domain. However, it would also be
possible to apply them independently to more than one behaviour
aggregate, which are distinguished by DSCP.                       

Phil

Ps Just to follow up a couple of points from your email, hopefully now
redundant!

>> So I do not see why sharing the same queue or scheduling at the same
priority is the key element to suddenly take into account the non PCN
traffic for metering.

[phil] because then the non-PCN traffic may impact the qos that the
pcn-traffic gets (ie pcn pkts may get 'held up' by non pcn pkts)

>> Bullet point 6 is covering lower priority traffic. If in bullet point
3, higher priority traffic is taken into account when capacity is
shared, why should the document  exclude the situation that lower
priority traffic and PCN traffic are sharing the same capacity. 

[phil] the point is that lower priority traffic doesn't adversely affect
the QoS received by the PCN-traffic.

>> Fourth bullet point: As indicated before, I do not understand the
relation between sharing the same queue and metering both types of
traffic with a single token bucket for PCN control. I can imagine that
in some cases this is required but in some cases it is not.

[phil] if pcn-traffic & non pcn share the same queue means that more
traffic of one sort may affect the qos that the other sort of traffic
gets. The question is how to judge whether there is 'room' for the
prospective new PCN flow to be admitted - since this is done via the
state of the token bucket, it implies that both sorts of traffic need to
contribute to the token bucket. 

 

-----Original Message-----
From: HUBLET Christian [mailto:[email-masked]] 
Sent: 28 August 2008 15:27
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Request for clarification of Other and priority
traffic - seedraft-eardley-pcn-marking-behaviour-01

Hi Phil, 

We are making progress. Bullet point 3 is clear, bullet point 4 is still
an issue for me.

I have the impression that capacity means bandwidth or allowed share of
the available resources configured by the operator:

   - If an amount of bandwidth is assigned for the aggregate of PCN and
some identified non PCN service, PCN and the identified non PCN traffic
must be metered together. 

    - In other cases, the traffic must not be metered together.

This is in line with the message in bullet point 3 covering PCN traffic
and priority traffic. 

Bullet point 4 is covering PCN traffic and other traffic being traffic
scheduled at the same priority (with implementation options 2 queues
scheduled at the same priority or single queue handling both types of
traffic). Since PCN is based on virtual queue (token bucket), PCN
traffic can be metered separately. One could even say that there is no
relation between the virtual queue and the real queue behavior if both
are correctly configured. So I do not see why sharing the same queue or
scheduling at the same priority is the key element to suddenly take into
account the non PCN traffic for metering. If of course the operator
configures a bandwidth capacity for the aggregate of PCN and non PCN
traffic, both types of traffic must be metered together. If this
interpretation is correct, this bullet point brings the same message to
the table as the message in bullet point 3 covering priority traffic and
PCN traffic.

Bullet point 6 is covering lower priority traffic. If in bullet point 3,
higher priority traffic is taken into account when capacity is shared,
why should the document  exclude the situation that lower priority
traffic and PCN traffic are sharing the same capacity. It also suggest a
link between scheduling and PCN which is as indicated above is not clear
to me. 

If this is true, my view on a message that you are bringing in the
paragraph 6.5 could be:

The PCN architecture is capable of covering situations where PCN and Non
PCN traffic share the same network. It might be needed that non PCN
traffic is taken into account in the metering. This is illustrated in
the examples in the different bullet points that illustrate when non PCN
traffic should be metered together with PCN traffic. But it is not
advised that PCN traffic and non PCN traffic share the same capacity
(assigned bandwidth) because it reduces the capability of PCN to protect
admitted flows. Correct?

Some proposals/remarks related to the document  

Second bullet point: I believe this is an important bullet. the bullet
could be rephrased as follows.

The PCN architecture targets to handle admittance and termination for
multiple services co-existing in the same PCN domain. Those services
will be distinguished via a DSCP value. The PCN mechanisms could protect
each service individually. Services could also be grouped. The
aggregated traffic level of the group of services could be protected via
a PCN mechanism.

Third bullet point: The message is clear know. But not yet reflected in
the text.

First proposal.

... or priority schedule it over PCN. In the latter case PCN and
priority scheduled traffic are sharing the same bandwidth. In this
case....

Other proposal: restructure as you propose and use your text below to
clarify the message.

Fourth bullet point: As indicated before, I do not understand the
relation between sharing the same queue and metering both types of
traffic with a single token bucket for PCN control. I can imagine that
in some cases this is required but in some cases it is not.

I hope this brings us a step forward in understanding other and priority
traffic.

Sixth bullet point: 

kr,

Chris

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 28 augustus 2008 11:25
To: HUBLET Christian; [email-masked]
Subject: RE: [PCN] Request for clarification of Other and priority
traffic - seedraft-eardley-pcn-marking-behaviour-01

Thanks chris, in-line

phil

-----Original Message-----
From: HUBLET Christian [mailto:[email-masked]] 
Sent: 27 August 2008 17:00
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Request for clarification of Other and priority
traffic - seedraft-eardley-pcn-marking-behaviour-01

Phil,

Thanks for the reply.

Unfortunately the message in section 6.5 is not clear to me:

First bullet point : no remarks.

Second bullet point : single metering for all the identified DSCP
values, or metering per DSCP value, or a mix of the two mechanisms

[phil] this bullet reflects old discussions where we talked about PCn
running separately for several classes - so your 2nd sense ie "metering
per DSCP value". 

However, the first sense would also be possible.

I'm not actually sure in retrospect that this bullet adds much, so I
propose deleting it. 

please shout if you object & would prefer to keep it (if so, please
suggest a re-phrasing)

Third bullet point : I understand that BW of priority scheduled traffic
on the same link should be taking into account by the PCN token bucket.

        --> so capacity in the marking draft means link 

    The strange point is that a PCN node dedicates capacity to NON PCN
traffic. what does this mean?

[phil] i think this is just that I could make the sentence construction
clearer. It means that there are 2 possibilities

[1] the router has some capacity set aside dedicated for the "important"
traffic (eg operator's control msgs). This means that pcn isnt allowed
to use this capacity, even if "important traffic" isnt currently using
it. In this case there's nothing for PCn to worry about

[2] the router shares capacity between the "important" traffic & pcn
traffic. But it's assumed that the "important" traffic is always
priority scheduled ahead of pcn-traffic. It would be possible in a worst
case for pcn to get no capacity. Clearly the "important" traffic needs
to contribute to pcn's meters. 

Fourth bullet point : "uses same capacity on a link as PCN traffic"

        --> capacity is probably bandwidth that is shared. PCN traffic
and non PCN but same codepoint. 

    share the same capacity since scheduling ...

        --> capacity is a queue with a certain servicing rate which is
common for PCN and non PCN ?

Fifth bullet point : "it is not advised to have non PCN traffic that
shares the same capacity on a link as PCN traffic"

        --> Capacity is bandwidth that is shared between PCN and non PCN
traffic 

So my view is that capacity is used in different meaning in section 6.5.

"Capacity" - I meant the capacity as in the forwarding bandwidth on the
link. But I think in practice this is equivalent to same queue.

if there are different types of traffic "sharing capacity", then
possibilities are:

1. all the types of traffic go in the same queue. Clearly then the
router's capacity is shared.

2. each type of traffic goes in a separate queue and the queues are
scheduled with equal priority.

However, assuming that both types of traffic have same dscp (this is the
example mentioned in the 4th bullet), then in practice both types of
traffic go in the same queue. (In theory it would be possible to go in
different queues (by the router classification looking at ECN field),
but in practice it seems that nodes only look at dscp when determining
what queue to put traffic in. But in any case, even if separate queues
were used, this is really just an implementation detail that we
shouldn't worry about.)

Chris, do you think it makes it clear if I re-phrase it from:

There may be other traffic that uses the same capacity (on a link)
      as PCN-traffic.  

To:

There may be other traffic that uses the same capacity as PCN-traffic.
"Capacity" means forwarding bandwidth on a link.
 
And in:
they will share the
      same capacity since scheduling behaviour is coupled with the DSCP
      only.
- add the phrase "in practice" (next to "scheduling behaviour")

Please suggest some alternative words if you think they'd help. I guess
I've read this stuff too many times  - find it hard to view it from
perspective of someone coming to it fresh!

Thanks

phil

I suppose a discussion is held in the past that discusses the value of
taking into account other and priority traffic.

Could some one point me to a doc or email discussion that provides a
view on the problem. Thanks.

kr,

Chris Hublet

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 27 augustus 2008 10:01
To: HUBLET Christian; [email-masked]
Subject: RE: [PCN] Request for clarification of Other and priority
traffic - seedraft-eardley-pcn-marking-behaviour-01

Thanks Chris,

Indeed this section is unclear and will be improved in the next version.

However, it should be better in the most recent verson of the
architecture draft, section 6.5 "PCN-traffic"
http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05.txt 

I think this answers your questions, but would appreciate it if you
could have a look and see if it makes sense or leaves something unclear.

The sense of this S6.5 text will appear in the next version of the
marking draft

Thanks

phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
HUBLET Christian
Sent: 26 August 2008 09:30
To: [email-masked]
Subject: [PCN] Request for clarification of Other and priority traffic -
seedraft-eardley-pcn-marking-behaviour-01

Hello, 

>From draft-eardley-pcn-marking-behaviour-01, I understand that the to be
metered traffic is : 
        - PCN traffic + Other traffic + Priority traffic. 

>From the draft it is not clear to me what priority traffic basically
means: 
        - In the definitions of section 1.1, priority traffic shares the
same capacity. 
        - I wonder what the meaning is of capacity: 
                1. sharing the same physical interface (read capacity)
or 
                2. the bandwidth (read capacity) is configured for the 2
(or 3) types of traffic. (no separate capacity (bandwidth) is specified
per traffic type)

I suppose that for the "other traffic" also both definitions can be
applicable. 

In the first definition, I see an issue for admittance control. If not
all other and priority traffic is actually present in the network, 

there could be an overadmittance of the PCN traffic. A practical example
could be coexistance of business traffic and residential traffic in the
same diffserv network. 

The residential traffic is controlled via PCN, the business traffic is
controlled via a policer at the edge of the network. If not all sessions
for the business traffic are active, the PCN traffic could take capacity
which was meant to be used for business traffic.

In the second definition, I do not understand why lower priority traffic
should not be taken into account if the same capacity (read bandwidth)
is shared with PCN traffic.

I have the impression that there is a strict requirement to take into
account other traffic and priority traffic if present (metered packet
(see section 2.4) is part of meter traffic (see section 1.1)). If the
first definition is applied, this strict requirement can have a huge
impact on the number of applications that can be  supported  in the
diffserv domain and the accuracy with which the PCN bandwidth is
controlled. In the second definition, it is the wish of the operator to
share the bandwidth for a number of applications which is basically a
normal policy. But in this last case, it is not clear why lower priority
traffic can't share the same bandwidth.

Thanks for clarifying. 

Kr, 

Chris 

_________________________________ 
Christian hublet 
Bell Labs - Fixed Access 
Copernicuslaan 50 
B2018 Antwerp 
Belgium 
Tel. +32 3 2408789; 
Email : [email-masked] 

============================================ 

Alcatel-Lucent Bell NV 
Fortis 220-0002334-42 
VAT BE 0404 621 642 Register of Legal Entities Antwerp 

DISCLAIMER: This message (including any attachments) contains
confidential information intended for a specific individual and purpose,
and is protected by law. If you are not the intended recipient, you
should delete this message. Any disclosure, copying, or distribution of
this message, or the taking of any action based on it, is strictly
prohibited without the prior consent of its author.

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

---

From: "HUBLET Christian" <[email-masked]>
Date: Tue, 2 Sep 2008 12:37:58 +0200

From: HUBLET Christian 
Sent: dinsdag 2 september 2008 10:15
To: [email-masked]'
Subject: RE: [PCN] Request for clarification of Other and priority
traffic - seedraft-eardley-pcn-marking-behaviour-01

Hi Phil,
 
I understand the message that you are bringing. And this is well
reflected by the proposed text. I am just missing the use case where the
total bandwidth of a traffic class is shared between PCN and non PCN
traffic, both types of traffic need to be metered. Note that in the
original text, this case was covered.
 
>From a technical point of view, I disagree that traffic sharing the same
queue or priority scheduled over PCN traffic MUST ALWAYS be taken into
account in the metering. Note that I agree that priority traffic and
other traffic has impact on the overall behavior of the PCN traffic. But
if the network is properly dimensioned, meaning the amount of other and
priority traffic is controlled via a non PCN mechanism, it is in my view
not a MUST that PCN and non PCN traffic is metered together. 
Metering PCN only or including also non PCN traffic should be looked at
on a case by case basis.
 
As a practical example:
Suppose we extend the PCN architecture to also control VOD traffic.
E.g. suppose we have 3 types of traffic in the network priority
scheduled over each other:
    voice + video phony
    BC TV (lower priority)
    VOD (lowest priority)
    Best Effort
I doubt whether we have take into account the voice and BCTV portion of
the traffic for the control of VOD traffic although these traffic types
have an impact on scheduling delay, queue buildup,... But if the total
BW of the priority traffic classes are controlled by a separate
mechanism (which could be PCN based), there is in my view no need to
include this traffic in the metering for the VOD BW control.
 
kr,
 
Chris

Sent: maandag 1 september 2008 12:37

Hi chris,

6.5.  PCN-traffic
 
   o  There needs to be a way for a PCN-node to distinguish PCN-traffic
from other traffic.  
          This is through a combination of the DSCP field and/or ECN
field.
   o  It is not advised to have non PCN-traffic that competes for the
same capacity as PCN-traffic, 
          but if there is such traffic, there needs to be a mechanism to
limit it.
       "Capacity" means the forwarding bandwidth on a link; 
       "competes" means that non PCN-packets will delay PCN-packets in
the queue for the link. 
        Hence more non PCN-traffic results in poorer QoS for PCN. 
        Further, the unpredictable amount of non PCN-traffic makes the
PCN mechanisms less accurate 
        and so reduces PCN's ability to protect the QoS of admitted
PCN-flows.  

1.    traffic that is priority scheduled over PCN  (perhaps a particular
application or an operator's control messages).
2.    traffic that is scheduled at the same priority as PCN (
 for example if the Voice-Admit codepoint is used for PCN-traffic 
  and there is voice-admit traffic in the PCN-domain
[I-D.moncaster-pcn-baseline-encoding]).
   o  If there is such non PCN-traffic (ie that competes for the same
capacity as PCN-traffic), 
           then PCN's mechanisms should take account of it, 
          in order to improve the accuracy of the decision about whether
to admit (or terminate) a PCN-flow. 
          The suggested mechanism is that such non PCN-traffic
contributes to the PCN meters 
         (ie is metered by the threshold-marking and
excess-traffic-marking algorithms).
   o  There will be non PCN-traffic that doesn't compete for the same
capacity as PCN-traffic, 
            because it is forwarded at lower priority. Hence it
shouldn't contribute to the PCN meters. 
           Examples are best effort and assured forwarding traffic. 
           However, a PCN-node should dedicate some capacity to lower
priority traffic so that it isn't starved.  
   o  The document assumes that the PCN mechanisms are applied to a
single behaviour aggregate in the PCN-domain. 
           However, it would also be possible to apply them
independently to more than one behaviour aggregate, 
           which are distinguished by DSCP.                       

Phil

 

-----Original Message-----
From: HUBLET Christian [mailto:[email-masked]] 
Sent: 28 August 2008 15:27
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Request for clarification of Other and priority

Hi Phil, 

First proposal.

Sixth bullet point: 

kr,

Chris

Thanks chris, in-line

phil

-----Original Message-----
From: HUBLET Christian [mailto:[email-masked]] 
Sent: 27 August 2008 17:00
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Request for clarification of Other and priority

Phil,

Thanks for the reply.

To:

And in:
they will share the

Thanks

phil

kr,

Chris Hublet

Thanks Chris,

 

Thanks

phil

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

Hello, 

metered traffic is : 

means: 

Thanks for clarifying. 

Kr, 

Chris 

Alcatel-Lucent Bell NV 
Fortis 220-0002334-42