Subject: [PCN] Deployment Status?

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 May 2011 02:45:20 +0300

Hi guys, 

I was wondering what the deployment status of the PCN mechanism is. 
Is it ending up like so many other QoS proposals? If so, did we learn something about what went wrong?

Ciao
Hannes

---

From: <[email-masked]>
Date: Fri, 27 May 2011 08:46:13 +0200

Hi Hannes,

PCN is specified in a modular way. That's an advantage and parts of PCN may see deployment. Bob mentioned, that DCTCP applies ECN or PCN marking (I didn't read the publication yet).

For the time being, Deutsche Telekom will not deploy RSVP or the like to signal for QoS, but PCN is based on the presence of such a protocol. We could imagine something lightweight, but nothing requiring state maintenance in routers. So full PCN will not be deployed. But measurement based admissiion control to signal network busy is within scope.

PCN deployment requires (beyond others) the following mechanisms which aren't available:
- threshold marking.
- Ingress to egress aggregate measurement (difficult in the presence of ECMP, may work if tunnels are used).

There's a draft supported by me removing the need for the latter. The former is still required but not available.

I like the way the WG worked and the results it produced (and yet hoping that the above mentioned draft sees enough support to get WG status).

QoS comes with a lot of complexity. As usual, only simple solutions allow for interoperable end to end deployment. As all standards bodies failed to standardise a simple basic set of interoperable end to end QoS mechanisms (in general, not just regarding PCN), there's hardly any widely accepted standard applied by all carriers.

While Expedited Forwarding using a single DSCP is widely deployed, Assured Forwarding (using four classes and 12 DSCPs without telling the reader which application should use which class) is the first QoS standard creating as many problems as it solves. That's true for most of the varuious other QoS related standards which followed (not limited to IETF). There's too much flexibility and too little standardisation of simple solutions.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, May 27, 2011 1:45 AM
To: [email-masked]
Subject: [PCN] Deployment Status?

Hi guys,

Ciao
Hannes

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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 27 May 2011 13:54:43 +0100

Hannes,

Just a few additional points to add to Ruediger's email.

At 07:46 27/05/2011, [email-masked] wrote:
>Hi Hannes,
>
>PCN is specified in a modular way. That's an advantage and parts of 
>PCN may see deployment. Bob mentioned, that DCTCP applies ECN or PCN 
>marking (I didn't read the publication yet).

To clarify, DCTCP currently uses ECN, but there's work to test it 
with PCN threshold marking instead (it's not being called PCN, but 
it's exactly the same marking algo).

>For the time being, Deutsche Telekom will not deploy RSVP or the 
>like to signal for QoS, but PCN is based on the presence of such a 
>protocol. We could imagine something lightweight, but nothing 
>requiring state maintenance in routers. So full PCN will not be 
>deployed. But measurement based admissiion control to signal network 
>busy is within scope.

Just to be clear, the idea of PCN was to avoid per-flow state mtce in 
routers, except once, where you (probably) do flow policing at ingress.

There has been work on using alternative signalling systems to RSVP, 
such as RACF with SIP at app layer and COPS down to the PCN edge router.

Also, PCN has been considered for internal use, giving early warning 
that overbooking an MPLS-TE aggregate has started to reach its limits 
and needs increasing.

>PCN deployment requires (beyond others) the following mechanisms 

* Broadcom implemented threshold marking in their chipsets in early 
2010 so it has been widely available for all vendors who buy-in their 
chipsets from Broadcom (which is a large part of the market).
* I believe Huawei also implemented threshold marking, altho I don't 
know whether they are selling it as a feature.

>of ECMP, may work if tunnels are used).

* I believe Huawei implemented this too.

Is anyone aware of any others?

>There's a draft supported by me removing the need for the latter. 
>The former is still required but not available.
>
>I like the way the WG worked and the results it produced (and yet 
>hoping that the above mentioned draft sees enough support to get WG status).

Yup

>QoS comes with a lot of complexity. As usual, only simple solutions 
>allow for interoperable end to end deployment. As all standards 
>bodies failed to standardise a simple basic set of interoperable end 
>to end QoS mechanisms (in general, not just regarding PCN), there's 
>hardly any widely accepted standard applied by all carriers.
>
>While Expedited Forwarding using a single DSCP is widely deployed, 
>Assured Forwarding (using four classes and 12 DSCPs without telling 
>the reader which application should use which class) is the first 
>QoS standard creating as many problems as it solves. That's true for 
>most of the varuious other QoS related standards which followed (not 
>limited to IETF). There's too much flexibility and too little 
>standardisation of simple solutions.

I agree with Ruediger on all this.

Also, other criticial failings IMO:
- Complex and/or non-existent APIs
- Unrealistic applicability message. There's been a lack of 
recognition that QoS is a transient requirement for leading edge 
applications. For any particular app, the need goes away as as line 
rates increase (and queuing delay reduces), but the requirement moves 
to new leading edge apps. Instead, QoS has always been sold as 
something that is a characteristic of a particular app, which becomes 
patently false; just as the standards become ready everyone is 
already using the app without QoS.
- Unrealistic economics. Lack of recognition that you don't need QoS 
if your policy is to continually maintain high quality BE by overprovisioning.

This last point may be changing - recent predicitions seem to show 
that over the next 3-4 years revenues will fall significantly short 
of what is required to pay for predicted growth in demand for 
capacity - in both fixed and mobile.

So you never know - we might yet be dragging out and dusting off the 
standards for some of the (simpler) QoS mechanisms some time soon.

Bob

>learn something about what went wrong?

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design