Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft char ter

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 5 Sep 2006 11:25:09 -0400

Hi, all:

I have some basic questions as follows:

1.	It appears that PCN will be used when one or more links/nodes are
congested within the network. However, based on PCN as I understand from the
description provided below, the call/flow will be prevented from entering
the network by the edge router. However, the calls/flows can be re-routed
by-passing those congested nodes/links if there are alternate paths that
have sufficient bandwidth still are available. If so, the basic question is
this: How will the decision for preventing the calls/flows be taken by the
edge node/router based on PCN if there is no centralized intelligent entity
to know that there is no additional bandwidth considering all possible
alternate routing paths within the network?
2.	Will there be any mechanisms to use PCN in the distributed
environment to take the right decision by the edge router not to admit the
calls/flows knowing the entire health/bandwidth of the network?
3.	Are there any possible drafts written by anyone to look into those
so that we can provide comments?

Well I am interested about the PCN standards because it will be a step
improvement on the top of the DiffServ mechanisms because it is awful to
starting dropping real-time payload traffics like audio/video once the calls
are accepted.

Best regards,

Radhika R. Roy

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, September 04, 2006 6:09 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter

Copy for info, as think this PCN (pre-congestion notification) work is
relevant to your WG.

Please send replies to the PCN mailing list, [email-masked]
<mailto:[email-masked]>   - you can subscribe at

http://www1.ietf.org/mailman/listinfo/pcn
<http://www1.ietf.org/mailman/listinfo/pcn> 

thanks. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 04 September 2006 10:07
To: [email-masked]
Subject: [PCN] PCN (Pre-Congestion Notification) draft charter

We are hoping to organize a BOF on PCN (pre-congestion notification) at the
next IETF. Some of us have now put together a first draft of a Charter -
below. We'd very much appreciate your comments and suggestions - for
instance: is the scope right? Is the range of deployment models ok? Is it a
reasonable set of milestones and are the timescales ok?

We're now working on a Problem Statement draft. 

Thanks.

PCN Draft Charter (Pre-Congestion Notification)

The PCN BOF (WG) will tackle the problem of how to provide scalable,
resilient admission control and strong QoS assurance while using packet
marking techniques. Current attempts to deliver QoS using only packet
marking (e.g. DiffServ) are limited in the level of QoS assurance that can
be provided without substantial over-provisioning. To improve the QoS
assurance, PCN will add flow admission control and flow pre-emption. In
normal circumstances admission control should protect the QoS of previously
admitted flows. In times of heavy congestion (for example caused by route
changes due to link or router failure) pre-emption of some flows should
preserve the QoS of remaining flows.

The initial scope of the BOF (WG) is the use of PCN within a single DiffServ
region. The overall approach will be based on a separation of functionality
between the interior routers and edge nodes of the DiffServ region. Interior
routers mark packet headers when their traffic is above a certain level, as
an early warning of incipient congestion ("pre-congestion"); this builds on
concepts from RFC 3168 "The Addition of Explicit Congestion Notification to
IP". Edge nodes of the DiffServ Region monitor the markings and that
information is used to make flow admission control and pre-emption
decisions. The decisions could be made by the edge nodes or by a centralised
system (which is informed of the edge nodes' measurements). 

The WG will address the following specific problems and develop standards
track solutions to them:

*                     When should an interior router mark a packet (i.e. at
what traffic level) in order to give early warning of its own congestion?

*                     How should such a mark be encoded in a packet (in the
ECN and/or DSCP fields)?

*                     How should these markings (at packet granularity) be
converted into admission control and flow pre-emption decisions (at flow
granularity)?

To support this, the WG will work on the following Informational documents:

*                     a Problem Statement, to describe the problems the
group is tackling and the assumptions made

*                     at least two deployment models, initially to help
focus the problem statement and later to check that the solutions being
developed satisfy the deployment scenario. Possible deployment models may
be: 

o        IntServ over DiffServ (RFC2998): the DiffServ region is PCN-enabled
and its edge nodes decide about admission and flow pre-emption

o        SIP-controlled PCN: routers within the DiffServ region are
PCN-capable and trusted SIP endpoints (gateway or host) perform admission
and flow pre-emption  

o        Pseudowire: PCN may be used as a congestion avoidance mechanism for
end-user deployed pseudowires (collaborate with the PWE3 WG)

*                      a generic analysis of the signalling extensions
required to support PCN. Note that extensions/enhancements to specific
signalling protocols (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG.

*                     at least one example solution implementing the
framework and its performance evaluation (e.g. simulation results), to
provide evidence of the viability of the proposed standard in the proposed
deployment models

*                     an analysis of the tradeoffs of different encoding
possibilities (e.g. ECN and DCSP marking)

The initial scope of the WG will restrict the problem space in the following
ways:

*                     By assuming the PCN-enabled Internet Region is a
controlled environment, i.e. all the interior routers and edge nodes of the
region run PCN and trust each other

*                     By assuming there are many flows on any bottleneck
link in the PCN-enabled region 

*                     By focusing on the QoS assurance required by real time
applications generating inelastic traffic like voice and video requiring low
delay, jitter and packet loss, i.e. as defined by the Controlled Load
Service [RFC2211]. 

Subsequent re-chartering may investigate solutions for when some of these
restrictions are not in place. 

Topics out of scope for the WG include a general investigation of admission
control mechanisms.

The WG will draw on the substantial prior academic and IETF work on
measurement-based admission control. 

Milestones

Nov 2006          initial Problem statement

Nov 2006          initial deployment models

March 2007        initial router marking behaviour (including encoding)

March 2007        initial flow admission control and pre-emption mechanism
(including edge node measurements)

March/July 2007   submit Problem statement

March/July 2007   submit deployment models

Nov 2007          submit router marking behaviour

Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism

Nov 2007          initial signalling analysis

Mar 2008          re-charter or close

Philip Eardley

Networks Researcher

BT Group 

Phone:              +44 (0)1473 645938

Fax :                 +44 (0)1473 640929

Email:                <mailto:[email-masked]> [email-masked]

BT MeetMe:      +44 (0)870 241 2994 

Passcode:         16851189#

BT Group plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England and Wales no. 4190816   This electronic message
contains information from BT Group plc which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended recipient
be aware that any disclosure, copying, distribution or use of the contents
of this information is prohibited. If you have received this electronic
message in error, please notify us by telephone or email (to the numbers or
address above) immediately. Activity and use of the BT Group plc E-mail
system is monitored to secure its effective operation and for other lawful
business purposes. Communications using this system will also be monitored
and may be recorded to secure effective operation and for other lawful
business purposes. 

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

---

From: <[email-masked]>
Date: Tue, 5 Sep 2006 16:55:42 +0100

Hi,

Thanks - just a quick reply on 3 before I go home!

Probably the best place to start is 

http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-
03.txt

best wishes,

phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 September 2006 16:25
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft
charter

Hi, all:

1.	It appears that PCN will be used when one or more links/nodes
are congested within the network. However, based on PCN as I understand
from the description provided below, the call/flow will be prevented
from entering the network by the edge router. However, the calls/flows
can be re-routed by-passing those congested nodes/links if there are
alternate paths that have sufficient bandwidth still are available. If
so, the basic question is this: How will the decision for preventing the
calls/flows be taken by the edge node/router based on PCN if there is no
centralized intelligent entity to know that there is no additional
bandwidth considering all possible alternate routing paths within the
network?
2.	Will there be any mechanisms to use PCN in the distributed
environment to take the right decision by the edge router not to admit
the calls/flows knowing the entire health/bandwidth of the network?
3.	Are there any possible drafts written by anyone to look into
those so that we can provide comments?

Well I am interested about the PCN standards because it will be a step
improvement on the top of the DiffServ mechanisms because it is awful to
starting dropping real-time payload traffics like audio/video once the
calls are accepted.

Best regards,

Radhika R. Roy

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, September 04, 2006 6:09 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft
charter

Please send replies to the PCN mailing list, [email-masked]  - you can
subscribe at

thanks. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 04 September 2006 10:07
To: [email-masked]
Subject: [PCN] PCN (Pre-Congestion Notification) draft charter

We are hoping to organize a BOF on PCN (pre-congestion notification) at
the next IETF. Some of us have now put together a first draft of a
Charter - below. We'd very much appreciate your comments and suggestions
- for instance: is the scope right? Is the range of deployment models
ok? Is it a reasonable set of milestones and are the timescales ok?

Thanks.

The PCN BOF (WG) will tackle the problem of how to provide scalable,
resilient admission control and strong QoS assurance while using packet
marking techniques. Current attempts to deliver QoS using only packet
marking (e.g. DiffServ) are limited in the level of QoS assurance that
can be provided without substantial over-provisioning. To improve the
QoS assurance, PCN will add flow admission control and flow pre-emption.
In normal circumstances admission control should protect the QoS of
previously admitted flows. In times of heavy congestion (for example
caused by route changes due to link or router failure) pre-emption of
some flows should preserve the QoS of remaining flows.

The initial scope of the BOF (WG) is the use of PCN within a single
DiffServ region. The overall approach will be based on a separation of
functionality between the interior routers and edge nodes of the
DiffServ region. Interior routers mark packet headers when their traffic
is above a certain level, as an early warning of incipient congestion
("pre-congestion"); this builds on concepts from RFC 3168 "The Addition
of Explicit Congestion Notification to IP". Edge nodes of the DiffServ
Region monitor the markings and that information is used to make flow
admission control and pre-emption decisions. The decisions could be made
by the edge nodes or by a centralised system (which is informed of the
edge nodes' measurements). 

The WG will address the following specific problems and develop
standards track solutions to them:

*                     When should an interior router mark a packet (i.e.
at what traffic level) in order to give early warning of its own
congestion?

*                     How should such a mark be encoded in a packet (in
the ECN and/or DSCP fields)?

*                     How should these markings (at packet granularity)
be converted into admission control and flow pre-emption decisions (at
flow granularity)?

To support this, the WG will work on the following Informational
documents:

*                     at least two deployment models, initially to help
focus the problem statement and later to check that the solutions being
developed satisfy the deployment scenario. Possible deployment models
may be: 

o        IntServ over DiffServ (RFC2998): the DiffServ region is
PCN-enabled and its edge nodes decide about admission and flow
pre-emption

o        SIP-controlled PCN: routers within the DiffServ region are
PCN-capable and trusted SIP endpoints (gateway or host) perform
admission and flow pre-emption  

o        Pseudowire: PCN may be used as a congestion avoidance mechanism
for end-user deployed pseudowires (collaborate with the PWE3 WG)

*                      a generic analysis of the signalling extensions
required to support PCN. Note that extensions/enhancements to specific
signalling protocols (e.g. RSVP, NSIS, SIP) will not be done in the PCN
WG.

*                     at least one example solution implementing the
framework and its performance evaluation (e.g. simulation results), to
provide evidence of the viability of the proposed standard in the
proposed deployment models

The initial scope of the WG will restrict the problem space in the
following ways:

*                     By assuming the PCN-enabled Internet Region is a
controlled environment, i.e. all the interior routers and edge nodes of
the region run PCN and trust each other

*                     By focusing on the QoS assurance required by real
time applications generating inelastic traffic like voice and video
requiring low delay, jitter and packet loss, i.e. as defined by the
Controlled Load  Service [RFC2211]. 

Subsequent re-chartering may investigate solutions for when some of
these restrictions are not in place. 

Topics out of scope for the WG include a general investigation of
admission control mechanisms.

Milestones

March 2007        initial flow admission control and pre-emption
mechanism (including edge node measurements)

Nov 2007/Mar 2008 submit flow admission control and pre-emption
mechanism

 

Philip Eardley

Networks Researcher

BT Group 

Fax :                 +44 (0)1473 640929

Email:               [email-masked]
<mailto:[email-masked]> 

Passcode:         16851189#

BT Group plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England and Wales no. 4190816   This electronic message
contains information from BT Group plc which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended
recipient be aware that any disclosure, copying, distribution or use of
the contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone or email
(to the numbers or address above) immediately. Activity and use of the
BT Group plc E-mail system is monitored to secure its effective
operation and for other lawful business purposes. Communications using
this system will also be monitored and may be recorded to secure
effective operation and for other lawful business purposes.

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 6 Sep 2006 13:45:35 -0400

Hi Roy,

If I understand your first questions correctly, the PCN mechanism is
capable of detecting current status of on-path congestion level. If the
path is not congested the flow is allowed to be setup on that path,
however if the path is congested normally the setup on that specific
path would be blocked. When setup of the session fails the application
controlling session setup (sip proxy) is informed. Some admission
control systems could have the ability to re-attempt a session setup but
using different edge router therefore a different path. 

With PCN, the decision making of should a flow be admitted can be
distrusted or centralized. Some deployment models may choose distributed
where others centralized.  I would like the admission control and
pre-emption mechanism that we agree on to support both models.

To your second question, yes I think the PCN mechanism could be used
where current congestion state information is sent to some centralized
place for monitoring health/bandwidth utilization in the network.
Currently this is outside the scope of current work.

We are planning to write at least two different deployment models before
the BoF.

Regards, Joe 
QoS & Network Architecture 
Telephone: 613-763-6098 (ESN 393-6098) 
Email: [email-masked] 

From: Roy, Radhika R. [mailto:[email-masked]] 
Sent: Tuesday, September 05, 2006 11:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft
char ter

Hi, all:

Best regards,

Radhika R. Roy

thanks. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 04 September 2006 10:07
To: [email-masked]
Subject: [PCN] PCN (Pre-Congestion Notification) draft charter

Thanks.

Milestones

 

Philip Eardley

Networks Researcher

BT Group 

Fax :                 +44 (0)1473 640929

Passcode:         16851189#

BT Group plc