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

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:Christian.Hublet at alcatel-lucent.be]
Sent: 28 August 2008 15:27
To: Eardley,PL,Philip,CXR9 R; pcn at ietf.org
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: philip.eardley at bt.com [mailto:philip.eardley at bt.com]
Sent: donderdag 28 augustus 2008 11:25
To: HUBLET Christian; pcn at ietf.org
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:Christian.Hublet at alcatel-lucent.be]
Sent: 27 August 2008 17:00
To: Eardley,PL,Philip,CXR9 R; pcn at ietf.org
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 4^th 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: philip.eardley at bt.com [mailto:philip.eardley at bt.com]
Sent: woensdag 27 augustus 2008 10:01
To: HUBLET Christian; pcn at ietf.org
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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of HUBLET Christian
Sent: 26 August 2008 09:30
To: pcn at ietf.org
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 : Christian.Hublet at alcatel-lucent.be

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

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.