From pcn-bounces@ietf.org Mon Sep 04 05:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKAQd-0002QP-1s; Mon, 04 Sep 2006 05:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKAQc-0002QH-50 for pcn@ietf.org; Mon, 04 Sep 2006 05:07:38 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKAQX-0001J0-3B for pcn@ietf.org; Mon, 04 Sep 2006 05:07:38 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Sep 2006 10:07:25 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Sep 2006 10:07:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Sep 2006 10:07:23 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CC6B@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN (Pre-Congestion Notification) draft charter Thread-Index: AcbQAYi9xsMdnywQQdS0KTufbV8hRg== From: To: X-OriginalArrivalTime: 04 Sep 2006 09:07:23.0917 (UTC) FILETIME=[8907C3D0:01C6D001] X-Spam-Score: 0.6 (/) X-Scan-Signature: f27aa5169a850f4f07ecb12d54c20028 Subject: [PCN] PCN (Pre-Congestion Notification) draft charter X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1547420259==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1547420259== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D001.88C5CD2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D001.88C5CD2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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? =20 We're now working on a Problem Statement draft.=20 =20 Thanks. =20 =20 PCN Draft Charter (Pre-Congestion Notification) =20 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. =20 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).=20 =20 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)? =20 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:=20 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 =20 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) =20 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=20 * 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].=20 =20 Subsequent re-chartering may investigate solutions for when some of these restrictions are not in place.=20 =20 Topics out of scope for the WG include a general investigation of admission control mechanisms. =20 The WG will draw on the substantial prior academic and IETF work on measurement-based admission control.=20 =20 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 =20 =20 Philip Eardley Networks Researcher BT Group=20 =20 Phone: +44 (0)1473 645938 Fax : +44 (0)1473 640929 Email: philip.eardley@bt.com =20 BT MeetMe: +44 (0)870 241 2994=20 Passcode: 16851189# =20 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.=20 =20 ------_=_NextPart_001_01C6D001.88C5CD2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:        =        philip.eardley@bt.com

BT MeetMe:      +44 (0)870 241 = 2994

Passcode:       &nb= sp; 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.

 

=00 ------_=_NextPart_001_01C6D001.88C5CD2E-- --===============1547420259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1547420259==-- From pcn-bounces@ietf.org Tue Sep 05 11:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKd4K-00076j-DV; Tue, 05 Sep 2006 11:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKco4-0000Ru-P9 for pcn@ietf.org; Tue, 05 Sep 2006 11:25:44 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKco3-00015D-Nj for pcn@ietf.org; Tue, 05 Sep 2006 11:25:44 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 5 Sep 2006 11:25:33 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006090511253304347 ; Tue, 05 Sep 2006 11:25:33 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Sep 2006 11:25:32 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E94@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: philip.eardley@bt.com Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft char ter Date: Tue, 5 Sep 2006 11:25:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5 x-originalarrivaltime: 05 Sep 2006 15:25:16.0442 (UTC) FILETIME=[7D5247A0:01C6D0FF] X-Spam-Score: 0.1 (/) X-Scan-Signature: cdc29c58dbe62a8af768e96593e872ad X-Mailman-Approved-At: Tue, 05 Sep 2006 11:42:30 -0400 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0535242114==" Errors-To: pcn-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0535242114== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D0FF.7DB673F4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6D0FF.7DB673F4 Content-Type: text/plain; charset="iso-8859-1" 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: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Monday, September 04, 2006 6:09 AM To: tsvwg@ietf.org; nsis@ietf.org; pwe3@ietf.org; ieprep@ietf.org 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, pcn@ietf.org - you can subscribe at http://www1.ietf.org/mailman/listinfo/pcn thanks. -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: 04 September 2006 10:07 To: pcn@ietf.org 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: philip.eardley@bt.com 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. ------_=_NextPart_001_01C6D0FF.7DB673F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, September = 04, 2006 6:09 AM
To: tsvwg@ietf.org; = nsis@ietf.org; pwe3@ietf.org; ieprep@ietf.org
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, pcn@ietf.org =  - you can subscribe at

http://www1.ietf.org/= mailman/listinfo/pcn

 

thanks. =

-----Original Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: 04 September 2006 = 10:07
To: pcn@ietf.org
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:

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

·       &nbs= p;           &nbs= p; How should such a = mark be encoded in a packet (in the ECN and/or DSCP fields)?

·       &nbs= p;           &nbs= p; 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:

·       &nbs= p;           &nbs= p; a Problem = Statement, to describe the problems the group is tackling and the assumptions = made

·       &nbs= p;           &nbs= p; 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)

·       &nbs= p;           &nbs= p;  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.

·       &nbs= p;           &nbs= p; 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

·       &nbs= p;           &nbs= p; 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:

·       &nbs= p;           &nbs= p; 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

·       &nbs= p;           &nbs= p; By assuming there = are many flows on any bottleneck link in the PCN-enabled region =

·       &nbs= p;           &nbs= p; 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:      &nbs= p;        philip.eardley@bt.com

BT MeetMe:      +44 (0)870 241 = 2994

Passcode:       &n= bsp; 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.

 

------_=_NextPart_001_01C6D0FF.7DB673F4-- --===============0535242114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0535242114==-- From pcn-bounces@ietf.org Tue Sep 05 12:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdoG-0001zW-EM; Tue, 05 Sep 2006 12:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdoE-0001zM-Kx for pcn@ietf.org; Tue, 05 Sep 2006 12:29:58 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKdoB-0001y7-9x for pcn@ietf.org; Tue, 05 Sep 2006 12:29:58 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 16:55:43 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Sep 2006 16:55:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter Date: Tue, 5 Sep 2006 16:55:42 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CC84@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230E94@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter Thread-Index: AcbQ/5JIXAFC2qcpSP6FtlQL556HwgAAP1eQ From: To: X-OriginalArrivalTime: 05 Sep 2006 15:55:42.0820 (UTC) FILETIME=[BDED7240:01C6D103] X-Spam-Score: 0.6 (/) X-Scan-Signature: 53bbbffb1f9e780660701ef83a59efe0 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2125284325==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2125284325== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D103.BDB96E1B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D103.BDB96E1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks - just a quick reply on 3 before I go home! =20 Probably the best place to start is=20 http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 03.txt =20 best wishes, phil =20 -----Original Message----- From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: 05 September 2006 16:25 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter =20 Hi, all: =20 I have some basic questions as follows: =20 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? =20 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. =20 Best regards, Radhika R. Roy =20 ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Monday, September 04, 2006 6:09 AM To: tsvwg@ietf.org; nsis@ietf.org; pwe3@ietf.org; ieprep@ietf.org Subject: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter =20 Copy for info, as think this PCN (pre-congestion notification) work is relevant to your WG. =20 Please send replies to the PCN mailing list, pcn@ietf.org - you can subscribe at http://www1.ietf.org/mailman/listinfo/pcn =20 thanks.=20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: 04 September 2006 10:07 To: pcn@ietf.org Subject: [PCN] PCN (Pre-Congestion Notification) draft charter =20 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? =20 We're now working on a Problem Statement draft.=20 =20 Thanks. =20 =20 PCN Draft Charter (Pre-Congestion Notification) =20 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. =20 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).=20 =20 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)? =20 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:=20 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 =20 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) =20 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=20 * 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].=20 =20 Subsequent re-chartering may investigate solutions for when some of these restrictions are not in place.=20 =20 Topics out of scope for the WG include a general investigation of admission control mechanisms. =20 The WG will draw on the substantial prior academic and IETF work on measurement-based admission control.=20 =20 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 =20 =20 Philip Eardley Networks Researcher BT Group=20 =20 Phone: +44 (0)1473 645938 Fax : +44 (0)1473 640929 Email: philip.eardley@bt.com =20 BT MeetMe: +44 (0)870 241 2994=20 Passcode: 16851189# =20 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.=20 =20 ------_=_NextPart_001_01C6D103.BDB96E1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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: = RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]
Sent: 05 September 2006 = 16:25
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [NSIS] FW: = [PCN] PCN (Pre-Congestion Notification) draft charter

 

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: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, September = 04, 2006 6:09 AM
To: tsvwg@ietf.org; = nsis@ietf.org; pwe3@ietf.org; ieprep@ietf.org
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, pcn@ietf.org  - you can = subscribe at

http://www1.ietf.org/m= ailman/listinfo/pcn

 

thanks.

-----Original Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: 04 September 2006 = 10:07
To: pcn@ietf.org
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:        =        philip.eardley@bt.com

BT MeetMe:      +44 (0)870 241 = 2994

Passcode:       &nb= sp; 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. =

 

=00 ------_=_NextPart_001_01C6D103.BDB96E1B-- --===============2125284325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============2125284325==-- From pcn-bounces@ietf.org Wed Sep 06 08:30:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKwXZ-0004TM-Et; Wed, 06 Sep 2006 08:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKwXY-0004T5-8e for pcn@ietf.org; Wed, 06 Sep 2006 08:30:00 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKwXV-0003qk-Ot for pcn@ietf.org; Wed, 06 Sep 2006 08:30:00 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A394E2DC9 for ; Wed, 6 Sep 2006 14:29:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 980F52DC3 for ; Wed, 6 Sep 2006 14:29:52 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 806C82AFB for ; Wed, 6 Sep 2006 14:29:52 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k86CTqs22575 for ; Wed, 6 Sep 2006 14:29:52 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 75D306F58E for ; Wed, 6 Sep 2006 14:28:56 +0200 (CEST) Message-ID: <44FEBF54.5000102@informatik.uni-wuerzburg.de> Date: Wed, 06 Sep 2006 14:30:12 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [PCN] Related work regarding "Resilient Admission Control" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, as this BOF focuses on "Resilient Admission Control" I would like to draw your attention to the following papers. 1. We have collected different approaches for "Network Admission Control" and made them resilient to failures. A performance comparison shows that the difference among their resource requirements is significant: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth07-Sub-3.pdf 2. Furthermore, we have done a comparison regarding the resource requirements in networks with (resilient) admission control and (resilient) capacity overprovisioning: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth06n.pdf 3. Finally, I would like to point out a hybrid approach between parameter- and measurement-based AC which we call experience-based AC (EBAC). It does not need instant measurements and it essentially works like overbooking airplanes to get rid of the inefficiency of pure parameter-based AC: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth06g.pdf Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 06 10:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyUT-0005vj-Ry; Wed, 06 Sep 2006 10:34:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyUS-0005ve-P3 for pcn@ietf.org; Wed, 06 Sep 2006 10:34:56 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKyUR-0005Pq-DZ for pcn@ietf.org; Wed, 06 Sep 2006 10:34:56 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 6 Sep 2006 10:34:45 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006090610344413349 ; Wed, 06 Sep 2006 10:34:44 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Sep 2006 10:34:43 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E9D@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: menth@informatik.uni-wuerzburg.de Subject: RE: [PCN] Related work regarding "Resilient Admission Control" Date: Wed, 6 Sep 2006 10:34:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5 x-originalarrivaltime: 06 Sep 2006 14:34:40.0688 (UTC) FILETIME=[9648BB00:01C6D1C1] Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, Michael: Thanks for sending good papers, and I will go over those. By the way, we will be pleased if you could send any papers related to the "Measurement-based Admission Control" because the traffic characteristics over the public Internet have become so complex due the addition of real-time audio/video and Web-based applications, no traffic models from circuit/packet-switched to the self-similar-traffic models ever devised to the best of my knowledge are applicable. For now, I hope that the distributed (and/or a kind of centralized) measurement-based traffic models and call admission control will be more realistic. However, your help will be appreciated if you could point out some papers that help the PCN folks like us. Best regards, Radhika -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: Wednesday, September 06, 2006 8:30 AM To: pcn@ietf.org Subject: [PCN] Related work regarding "Resilient Admission Control" Hi all, as this BOF focuses on "Resilient Admission Control" I would like to draw your attention to the following papers. 1. We have collected different approaches for "Network Admission Control" and made them resilient to failures. A performance comparison shows that the difference among their resource requirements is significant: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth07-Sub-3.pdf 2. Furthermore, we have done a comparison regarding the resource requirements in networks with (resilient) admission control and (resilient) capacity overprovisioning: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth06n.pdf 3. Finally, I would like to point out a hybrid approach between parameter- and measurement-based AC which we call experience-based AC (EBAC). It does not need instant measurements and it essentially works like overbooking airplanes to get rid of the inefficiency of pure parameter-based AC: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth06g.pdf Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 06 10:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyaH-0007pc-IH; Wed, 06 Sep 2006 10:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyaF-0007pX-LU for pcn@ietf.org; Wed, 06 Sep 2006 10:40:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKyaE-0006Oi-5g for pcn@ietf.org; Wed, 06 Sep 2006 10:40:55 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 06 Sep 2006 07:40:53 -0700 X-IronPort-AV: i="4.08,221,1154934000"; d="scan'208"; a="1852131521:sNHT51459956" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k86EerXL007099; Wed, 6 Sep 2006 07:40:53 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k86EepwB012530; Wed, 6 Sep 2006 07:40:52 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 10:40:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Related work regarding "Resilient Admission Control" Date: Wed, 6 Sep 2006 10:40:05 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Related work regarding "Resilient Admission Control" Thread-Index: AcbRwbjx6tKxydWZTvemE/nQoNPCaAAAFVGw From: "Anna Charny \(acharny\)" To: "Roy, Radhika R." , X-OriginalArrivalTime: 06 Sep 2006 14:40:06.0883 (UTC) FILETIME=[58B62330:01C6D1C2] DKIM-Signature: a=rsa-sha1; q=dns; l=3143; t=1157553653; x=1158417653; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Related=20work=20regarding=20=22Resilient=20Admission=20 Control=22; X=v=3Dcisco.com=3B=20h=3Dx0f0CzQ6j7LbOpSaIuO4zezCqUw=3D; b=XqkA7kwUYV8M6pYFGS6CasLp2pQ0m/6wYKufuc6TFGzrRrB0SM4zMjmj1Uxg3Z5c8XD9pPGD yAvTWpE6X4pI9rtvf7KsF7dixOVcLL1PyTG8xvH4yYvWFiexqxnLJC2M; Authentication-Results: sj-dkim-8.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, I seem to be getting access Forbidden errors wen I try to access the links =20 You point to. Is this something that can be fixed?=20 Thanks, Anna=20 -----Original Message----- From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Wednesday, September 06, 2006 10:35 AM To: menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org Subject: RE: [PCN] Related work regarding "Resilient Admission Control" Hi, Michael: Thanks for sending good papers, and I will go over those. By the way, we will be pleased if you could send any papers related to the "Measurement-based Admission Control" because the traffic characteristics over the public Internet have become so complex due the addition of real-time audio/video and Web-based applications, no traffic models from circuit/packet-switched to the self-similar-traffic models ever devised to the best of my knowledge are applicable. For now, I hope that the distributed (and/or a kind of centralized) measurement-based traffic models and call admission control will be more realistic. However, your help will be appreciated if you could point out some papers that help the PCN folks like us. Best regards, Radhika -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: Wednesday, September 06, 2006 8:30 AM To: pcn@ietf.org Subject: [PCN] Related work regarding "Resilient Admission Control" Hi all, as this BOF focuses on "Resilient Admission Control" I would like to draw your attention to the following papers. 1. We have collected different approaches for "Network Admission Control" and made them resilient to failures. A performance comparison shows that the difference among their resource requirements is significant: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth07-Sub-3.pdf 2. Furthermore, we have done a comparison regarding the resource requirements in networks with (resilient) admission control and (resilient) capacity overprovisioning: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth06n.pdf 3. Finally, I would like to point out a hybrid approach between parameter- and measurement-based AC which we call experience-based AC (EBAC). It does not need instant measurements and it essentially works like overbooking airplanes to get rid of the inefficiency of pure parameter-based AC: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ Menth06g.pdf Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 06 13:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1T5-0000eU-1F; Wed, 06 Sep 2006 13:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1T3-0000b8-GA for pcn@ietf.org; Wed, 06 Sep 2006 13:45:41 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1T2-0004Tk-0D for pcn@ietf.org; Wed, 06 Sep 2006 13:45:41 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k86Hjam28840; Wed, 6 Sep 2006 13:45:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft char ter Date: Wed, 6 Sep 2006 13:45:35 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650BE3B699@zcarhxm1.corp.nortel.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230E94@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft char ter Thread-Index: AcbRAmpN7vswbzA7Rs6IMDcRf8OFRQA0/EeQ From: "Jozef Babiarz" To: "Roy, Radhika R." , X-Spam-Score: 0.3 (/) X-Scan-Signature: 4120a90b86e256a7465e9d130cb2a242 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111363381==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1111363381== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D1DC.41DA7FFC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D1DC.41DA7FFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.=20 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. =20 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. =20 We are planning to write at least two different deployment models before the BoF. =20 Regards, Joe=20 QoS & Network Architecture=20 Telephone: 613-763-6098 (ESN 393-6098)=20 Email: babiarz@nortel.com=20 ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Tuesday, September 05, 2006 11:25 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: RE: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft char ter =20 Hi, all: =20 I have some basic questions as follows: =20 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? =20 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. =20 Best regards, Radhika R. Roy =20 ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Monday, September 04, 2006 6:09 AM To: tsvwg@ietf.org; nsis@ietf.org; pwe3@ietf.org; ieprep@ietf.org Subject: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter =20 Copy for info, as think this PCN (pre-congestion notification) work is relevant to your WG. =20 Please send replies to the PCN mailing list, pcn@ietf.org - you can subscribe at http://www1.ietf.org/mailman/listinfo/pcn =20 thanks.=20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: 04 September 2006 10:07 To: pcn@ietf.org Subject: [PCN] PCN (Pre-Congestion Notification) draft charter =20 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? =20 We're now working on a Problem Statement draft.=20 =20 Thanks. =20 =20 PCN Draft Charter (Pre-Congestion Notification) =20 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. =20 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).=20 =20 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)? =20 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:=20 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 =20 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) =20 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=20 * 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].=20 =20 Subsequent re-chartering may investigate solutions for when some of these restrictions are not in place.=20 =20 Topics out of scope for the WG include a general investigation of admission control mechanisms. =20 The WG will draw on the substantial prior academic and IETF work on measurement-based admission control.=20 =20 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 =20 =20 Philip Eardley Networks Researcher BT Group=20 =20 Phone: +44 (0)1473 645938 Fax : +44 (0)1473 640929 Email: philip.eardley@bt.com =20 BT MeetMe: +44 (0)870 241 2994=20 Passcode: 16851189# =20 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.=20 =20 ------_=_NextPart_001_01C6D1DC.41DA7FFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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: = babiarz@nortel.com

From: Roy, = Radhika R. [mailto:RADHIKA.R.ROY@saic.com]
Sent: Tuesday, September = 05, 2006 11:25 AM
To: = philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: RE: [NSIS] FW: = [PCN] PCN (Pre-Congestion Notification) draft char = ter

 

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: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, September = 04, 2006 6:09 AM
To: tsvwg@ietf.org; = nsis@ietf.org; pwe3@ietf.org; ieprep@ietf.org
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, pcn@ietf.org =  - you can subscribe at

http://www1.ietf.org/m= ailman/listinfo/pcn

 

thanks. =

-----Original Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: 04 September 2006 = 10:07
To: pcn@ietf.org
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:       = ;        philip.eardley@bt.com

BT MeetMe:      +44 (0)870 241 = 2994

Passcode:       &nb= sp; 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.

 

------_=_NextPart_001_01C6D1DC.41DA7FFC-- --===============1111363381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1111363381==-- From pcn-bounces@ietf.org Fri Sep 08 08:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfLY-0007VG-70; Fri, 08 Sep 2006 08:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfLW-0007US-L5 for pcn@ietf.org; Fri, 08 Sep 2006 08:20:34 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLfLS-0008OE-35 for pcn@ietf.org; Fri, 08 Sep 2006 08:20:34 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0BE3B2E46; Fri, 8 Sep 2006 14:20:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id F343A2E1F; Fri, 8 Sep 2006 14:20:26 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id AA2592DE6; Fri, 8 Sep 2006 14:20:24 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k88CKOs10598; Fri, 8 Sep 2006 14:20:24 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D0DAD6F58E; Fri, 8 Sep 2006 14:19:26 +0200 (CEST) Message-ID: <4501601C.4040202@informatik.uni-wuerzburg.de> Date: Fri, 08 Sep 2006 14:20:44 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Roy, Radhika R." , acharny@cisco.com Subject: Re: [PCN] Related work regarding "Resilient Admission Control" References: <62D92A9A02BCC845B202323D49A48426230E9D@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230E9D@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Roy, dear Anna, 1. An overview with plenty of pointers into existing literature and a categorization of different admission control methods can be found on page 41 - 49 of my PhD thesis: http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Menth04.pdf As far as I have learned from Section 3.1.2 in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt, the AC approach is a kind of feedback-based admission control (p. 48). Other protocols have implemented that concept in a similar (but not in the same) way. 2. The links of my previous email regarding resilient admission control are valid, but the mailer broke the URLs into two lines. You can also use the following shortcuts to access the papers: http://menth.net/Publications/papers/Menth07-Sub-3.pdf http://menth.net/Publications/papers/Menth06n.pdf 3. Just to make our collection of papers on Experience-Based Admission Control (EBAC) complete: http://menth.net/Publications/papers/Menth04k.pdf http://menth.net/Publications/papers/Menth04f.pdf http://menth.net/Publications/papers/Menth06g.pdf http://menth.net/Publications/papers/Menth06q.pdf Kind regards, Michael Roy, Radhika R. wrote: > Hi, Michael: > > Thanks for sending good papers, and I will go over those. > > By the way, we will be pleased if you could send any papers related to > the "Measurement-based Admission Control" because the traffic > characteristics over the public Internet have become so complex due the > addition of real-time audio/video and Web-based applications, no traffic > models from circuit/packet-switched to the self-similar-traffic models > ever devised to the best of my knowledge are applicable. > > For now, I hope that the distributed (and/or a kind of centralized) > measurement-based traffic models and call admission control will be more > realistic. > > However, your help will be appreciated if you could point out some > papers that help the PCN folks like us. > > Best regards, > Radhika > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: Wednesday, September 06, 2006 8:30 AM > To: pcn@ietf.org > Subject: [PCN] Related work regarding "Resilient Admission Control" > > > Hi all, > > as this BOF focuses on "Resilient Admission Control" I would like to > draw your attention to the following papers. > > 1. We have collected different approaches for "Network Admission > Control" and made them resilient to failures. A performance comparison > shows that the difference among their resource requirements is > significant: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ > Menth07-Sub-3.pdf > > 2. Furthermore, we have done a comparison regarding the resource > requirements in networks with (resilient) admission control and > (resilient) capacity overprovisioning: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ > Menth06n.pdf > > 3. Finally, I would like to point out a hybrid approach between > parameter- and measurement-based AC which we call experience-based AC > (EBAC). It does not need instant measurements and it essentially works > like overbooking airplanes to get rid of the inefficiency of pure > parameter-based AC: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/ > Menth06g.pdf > > Kind regards, > > Michael > > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 08 08:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfYB-0005ga-Vq; Fri, 08 Sep 2006 08:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfYA-0005bP-Nr for pcn@ietf.org; Fri, 08 Sep 2006 08:33:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLfY9-0003KA-B4 for pcn@ietf.org; Fri, 08 Sep 2006 08:33:38 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Sep 2006 05:33:37 -0700 X-IronPort-AV: i="4.08,230,1154934000"; d="scan'208"; a="40591085:sNHT43232112" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88CXaWA008926; Fri, 8 Sep 2006 08:33:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k88CXZuM006573; Fri, 8 Sep 2006 08:33:36 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 08:33:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Related work regarding "Resilient Admission Control" Date: Fri, 8 Sep 2006 08:33:34 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Related work regarding "Resilient Admission Control" Thread-Index: AcbTQTWChrN4czNlTwaRIye70hAAHQAAb+cg From: "Anna Charny \(acharny\)" To: , "Roy, Radhika R." X-OriginalArrivalTime: 08 Sep 2006 12:33:36.0097 (UTC) FILETIME=[01139D10:01C6D343] DKIM-Signature: a=rsa-sha1; q=dns; l=4168; t=1157718816; x=1158582816; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Related=20work=20regarding=20=22Resilient=20Admission=20 Control=22 |To:, =0A=20=20=20=20=20=20=20=20=22Roy, =2 0Radhika=20R.=22=20; X=v=3Dcisco.com=3B=20h=3Dx0f0CzQ6j7LbOpSaIuO4zezCqUw=3D; b=gZOk71qWIKY8/0xfeJ/I6rod8AP7g4soe4yK9UsHkyizipCgT2IhIAytkzeS+JRnKatH6gpF LY6YLLrC5B2rZjcYRli4c3t0HRNgr0FsOdr2LMF1b8KFxpOU8/ItfuXu; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Thank you, Michael!=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Friday, September 08, 2006 8:21 AM To: Roy, Radhika R.; Anna Charny (acharny) Cc: pcn@ietf.org Subject: Re: [PCN] Related work regarding "Resilient Admission Control" Dear Roy, dear Anna, 1. An overview with plenty of pointers into existing literature and a categorization of different admission control methods can be found on page 41 - 49 of my PhD thesis: http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Ment h04.pdf As far as I have learned from Section 3.1.2 in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 03.txt, the AC approach is a kind of feedback-based admission control (p. 48).=20 Other protocols have implemented that concept in a similar (but not in the same) way. 2. The links of my previous email regarding resilient admission control are valid, but the mailer broke the URLs into two lines. You can also use the following shortcuts to access the papers: http://menth.net/Publications/papers/Menth07-Sub-3.pdf http://menth.net/Publications/papers/Menth06n.pdf 3. Just to make our collection of papers on Experience-Based Admission Control (EBAC) complete: http://menth.net/Publications/papers/Menth04k.pdf http://menth.net/Publications/papers/Menth04f.pdf http://menth.net/Publications/papers/Menth06g.pdf http://menth.net/Publications/papers/Menth06q.pdf Kind regards, Michael Roy, Radhika R. wrote: > Hi, Michael: > > Thanks for sending good papers, and I will go over those. > > By the way, we will be pleased if you could send any papers related to > the "Measurement-based Admission Control" because the traffic=20 > characteristics over the public Internet have become so complex due=20 > the addition of real-time audio/video and Web-based applications, no=20 > traffic models from circuit/packet-switched to the=20 > self-similar-traffic models ever devised to the best of my knowledge are applicable. > > For now, I hope that the distributed (and/or a kind of centralized)=20 > measurement-based traffic models and call admission control will be=20 > more realistic. > > However, your help will be appreciated if you could point out some=20 > papers that help the PCN folks like us. > > Best regards, > Radhika > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of=20 > Michael Menth > Sent: Wednesday, September 06, 2006 8:30 AM > To: pcn@ietf.org > Subject: [PCN] Related work regarding "Resilient Admission Control" > > > Hi all, > > as this BOF focuses on "Resilient Admission Control" I would like to=20 > draw your attention to the following papers. > > 1. We have collected different approaches for "Network Admission=20 > Control" and made them resilient to failures. A performance comparison > shows that the difference among their resource requirements is > significant: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/paper > s/ > Menth07-Sub-3.pdf > > 2. Furthermore, we have done a comparison regarding the resource=20 > requirements in networks with (resilient) admission control and > (resilient) capacity overprovisioning: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/paper > s/ > Menth06n.pdf > > 3. Finally, I would like to point out a hybrid approach between > parameter- and measurement-based AC which we call experience-based AC=20 > (EBAC). It does not need instant measurements and it essentially works > like overbooking airplanes to get rid of the inefficiency of pure=20 > parameter-based AC: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/paper > s/ > Menth06g.pdf > > Kind regards, > > Michael > > =20 -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 12 23:11:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNLAF-0003m1-Co; Tue, 12 Sep 2006 23:11:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNLAF-0003lw-02 for pcn@ietf.org; Tue, 12 Sep 2006 23:11:51 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNLAC-0007Rc-NC for pcn@ietf.org; Tue, 12 Sep 2006 23:11:50 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5I00IQKGQHHH@usaga01-in.huawei.com> for pcn@ietf.org; Tue, 12 Sep 2006 20:08:42 -0700 (PDT) Received: from huawei.com (usams01-in [172.18.4.10]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5I00L8IGQHAC@usaga01-in.huawei.com> for pcn@ietf.org; Tue, 12 Sep 2006 20:08:41 -0700 (PDT) Received: from [172.18.4.6] (Forwarded-For: [68.0.102.87]) by usams01-in.huawei.com (mshttpd); Tue, 12 Sep 2006 22:15:45 -0500 Date: Tue, 12 Sep 2006 22:15:45 -0500 From: YongLucy 73674 To: pcn@ietf.org Message-id: <50ef93509e3a.509e3a50ef93@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [PCN] PCN (Pre-Congestion Notification) draft charter X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Every One, It is great to organize a BOF on PCN. This is a very important function for QoS. The draft charter covers many features from IP perspectives (I think). Should we also cover features from MPLS perspective? Something like PCN per LSP. How could PCN contain the sufficient informaton for edge router or CL to take an action on it? For multiple segements having congestion potential, could a consolidated PCN be propagated to the ingress or egress edge router? Should RSVP be used in PCN for a LSP or a bit is inserted in packets? Anyway this is a good starting point. Best Regards, Lucy Yong ******************************************************************************************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ******************************************************************************************* _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 13 02:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNON6-0001D6-S6; Wed, 13 Sep 2006 02:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNON6-0001D1-9g for pcn@ietf.org; Wed, 13 Sep 2006 02:37:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNON5-0000rF-02 for pcn@ietf.org; Wed, 13 Sep 2006 02:37:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2006 02:37:19 -0400 X-IronPort-AV: i="4.09,158,1157342400"; d="scan'208"; a="102119576:sNHT41348518" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8D6bIb1009233; Wed, 13 Sep 2006 02:37:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8D6bIuI029482; Wed, 13 Sep 2006 02:37:18 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 02:37:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter Date: Wed, 13 Sep 2006 02:37:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN (Pre-Congestion Notification) draft charter Thread-Index: AcbW4peIdxzqek/DRauVxmxtlwwrSQAG5EKA From: "Anna Charny \(acharny\)" To: "YongLucy 73674" , X-OriginalArrivalTime: 13 Sep 2006 06:37:18.0192 (UTC) FILETIME=[0EEAEF00:01C6D6FF] DKIM-Signature: a=rsa-sha1; q=dns; l=2124; t=1158129438; x=1158993438; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20PCN=20(Pre-Congestion=20Notification)=20draft=20charter |To:=22YongLucy=2073674=22=20,=20; X=v=3Dcisco.com=3B=20h=3Dwm/CG6Md91AeUQYt5q2bHg7Tcyg=3D; b=LkAQEPP9A0/Zq6Hx2ZI85+TqQsAbX6lBbhSdEPavMOQ9gkTpX/eIAYKLQqps2aYeMZ87kv6D TjiJ++PF4w5Qeqgf1sIeZEYCJ2e6n2gjmfyrIlh/luGy+mfqVJPeCTXI; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lucy, Thank you for your post. Our initial assumption was that mpls-ecn work will continue within tsvwg (see draft-davie-ecn-mpls). I guess it is a question to the list and the working group chairs on whether this should be undertaken within the PCN WG (assuming it be formed). One argument for keeping it within tsvwg is that it has broader application than the proposed scope for the PCN BoF/new WG. But we are open to comments/suggestions on this. Anna=20 -----Original Message----- From: YongLucy 73674 [mailto:lucyyong@huawei.com]=20 Sent: Tuesday, September 12, 2006 11:16 PM To: pcn@ietf.org Subject: [PCN] PCN (Pre-Congestion Notification) draft charter Hello Every One, It is great to organize a BOF on PCN. This is a very important function for QoS. The draft charter covers many features from IP perspectives (I think). Should we also cover features from MPLS perspective? Something like PCN per LSP. How could PCN contain the sufficient informaton for edge router or CL to take an action on it? For multiple segements having congestion potential, could a consolidated PCN be propagated to the ingress or egress edge router? Should RSVP be used in PCN for a LSP or a bit is inserted in packets? Anyway this is a good starting point. Best Regards, Lucy Yong ************************************************************************ ******************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! =20 ************************************************************************ ******************* _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 13 10:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVch-0007gK-7T; Wed, 13 Sep 2006 10:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVcf-0007gF-Q2 for pcn@ietf.org; Wed, 13 Sep 2006 10:21:53 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNVcd-0003yr-E3 for pcn@ietf.org; Wed, 13 Sep 2006 10:21:53 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5J00GYWBR89M@usaga01-in.huawei.com> for pcn@ietf.org; Wed, 13 Sep 2006 07:18:44 -0700 (PDT) Received: from huawei.com (usams01-in [172.18.4.10]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5J00HIYBR77D@usaga01-in.huawei.com> for pcn@ietf.org; Wed, 13 Sep 2006 07:18:43 -0700 (PDT) Received: from [172.18.4.6] (Forwarded-For: [68.0.102.87]) by usams01-in.huawei.com (mshttpd); Wed, 13 Sep 2006 09:25:47 -0500 Date: Wed, 13 Sep 2006 09:25:47 -0500 From: YongLucy 73674 Subject: Re: RE: [PCN] PCN (Pre-Congestion Notification) draft charter To: "Anna Charny (acharny)" Message-id: <5100d5510cd0.510cd05100d5@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=windows-1252 Content-language: en Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna=2C Thank you for the response=2E If IETF open a new WG to tackle packet netw= ork admission control for QoS=2C it would be good to eye on a packet netw= ork=2C which includes IP=2C MPLS=2C maybe Ethernet=2E Since MPLS is expec= ted to support connection oriented P2P services=2C using network admissio= n control to guarantee the QoS is important for service provider=2E I hav= e read Davie=92s ECN draft=2C it is a good start and could be extended fo= r more intelligent admission control=2E For example=2C pre-congestion det= ecting point can provide more information or a decision for the ER=2E Sim= ple notification can=92t solve the congestion issue well and avoid oscill= ation symptom=2E = Personally=2C I think the new group SHOULD broader the application includ= ing MPLS at least=2E = Best Regards=2C Lucy = *************************************************************************= ****************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained herein in any way (in= cluding=2C but not limited to=2C total or partial disclosure=2C reproduct= ion=2C or dissemination) by persons other than the intended recipient(s) = is prohibited=2E If you receive this e-mail in error=2C please notify the= sender by phone or email immediately and delete it! ************************************************************************= ******************* ----- Original Message ----- From=3A =22Anna Charny (acharny)=22 =3Cacharny=40cisco=2Ecom=3E Date=3A Wednesday=2C September 13=2C 2006 1=3A37 am Subject=3A RE=3A =5BPCN=5D PCN (Pre-Congestion Notification) draft charte= r =3E Hi Lucy=2C =3E = =3E Thank you for your post=2E Our initial assumption was that mpls-ecn = =3E workwill continue within tsvwg (see draft-davie-ecn-mpls)=2E I = =3E guess it is a =3E question to the list and the working group chairs on whether this = =3E shouldbe undertaken within the PCN WG (assuming it be formed)=2E One = =3E argumentfor keeping it within tsvwg is that it has broader = =3E application than the =3E proposed scope for the PCN BoF/new WG=2E But we are open to =3E comments/suggestions on this=2E =3E = =3E Anna = =3E = =3E -----Original Message----- =3E From=3A YongLucy 73674 =5Blucyyong=40huawei=2Ecom=5D = =3E Sent=3A Tuesday=2C September 12=2C 2006 11=3A16 PM =3E To=3A pcn=40ietf=2Eorg =3E Subject=3A =5BPCN=5D PCN (Pre-Congestion Notification) draft charter =3E = =3E Hello Every One=2C =3E = =3E It is great to organize a BOF on PCN=2E This is a very important = =3E functionfor QoS=2E The draft charter covers many features from IP = =3E perspectives (I =3E think)=2E Should we also cover features from MPLS perspective=3F Some= thing =3E like PCN per LSP=2E How could PCN contain the sufficient informaton f= or =3E edge router or CL to take an action on it=3F For multiple segements = =3E havingcongestion potential=2C could a consolidated PCN be propagated = =3E to the =3E ingress or egress edge router=3F =3E Should RSVP be used in PCN for a LSP or a bit is inserted in packets=3F= =3E = =3E Anyway this is a good starting point=2E =3E = =3E Best Regards=2C =3E Lucy Yong =3E = =3E = =3E *********************************************************************= *** =3E ******************* =3E This email and its attachments contain confidential information from =3E HUAWEI=2C which is intended only for the person or entity whose = =3E address is =3E listed above=2E Any use of the information contained herein in any wa= y =3E (including=2C but not limited to=2C total or partial disclosure=2C =3E reproduction=2C or dissemination) by persons other than the intended =3E recipient(s) is prohibited=2E If you receive this e-mail in error=2C = =3E pleasenotify the sender by phone or email immediately and delete it! =3E = =3E *********************************************************************= *** =3E ******************* =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E PCN mailing list =3E PCN=40ietf=2Eorg =3E https=3A//www1=2Eietf=2Eorg/mailman/listinfo/pcn =3E _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 13 18:52:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNdaV-0003Zs-Is; Wed, 13 Sep 2006 18:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNdaU-0003Zi-Vj for pcn@ietf.org; Wed, 13 Sep 2006 18:52:10 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNdaS-0004PL-LH for pcn@ietf.org; Wed, 13 Sep 2006 18:52:10 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8DMq6u20848 for ; Wed, 13 Sep 2006 18:52:06 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Sep 2006 18:52:05 -0400 Message-Id: <6.2.5.6.0.20060913181104.03c888d8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Sep 2006 18:52:05 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Sep 2006 22:52:05.0356 (UTC) FILETIME=[3BFBEAC0:01C6D787] X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [PCN] PCN Problem Statement Draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: Please see the initial PCN (Pre-Congestion Notification) Problem Statement draft: http://standards.nortelnetworks.com/tsvwg/draft-chan-pcn-problem-statement-00.txt This draft have been submitted to IETF, but you can retrieve it at the above link prior to its availability on the IETF server. We wish to use this Problem Statement draft to facilitate discussion on the topic of Pre-Congestion Notification. As this is the -00 version, this is still work-in-progress. We invite discussions concerning this draft on pcn@ietf.org and plan to submit a -01 version prior to the 67th IETF @ San Diego draft submission cut-off date. We still have numerous open questions concerning this draft, they can be categorized as: 1. Terminology. As most new WG/BOF have. Currently 2 open questions: The usage of terms: - PCN-End (or Edge) Node (PEN) - PCN-Interior (or Intermediate) Node (PIN) For the Functional Architecture description section of the draft. 2. Problem Scope. One of the open questions: - What does "many flows" mean? How many is "many"? 10, 20, 100, 1000 flows? This relates to how "many" will provide accurate enough measurements (at the PIN, at the PEN). 3. What should the proposed WG (hopeful result of the BOF) standardize? Current 2 open questions: - Should measurement algorithm(s) at the PIN be standardized? - Should measurement algorithm(s) at the PEN be standardized? And what criteria to use for judging these algorithm(s)? 4. What about signaling? How should this work's signalling need be fullfilled? These are just some initial thinkings on the discussion topics. Please read this SHORT draft (16 pages including all the boiler plate text) and start the discussion on pcn@ietf.org. I plan to organize a file itemizing these and additional discussions/issues topics. And using the itemization in the E-Mail Subject field for more user friendly, organized discussion threads. But please start the discussions ASAP. Please also see our proposed draft charter (this same version had been sent to pcn@ietf.org on Sept 4, 2006, just making it available here for your convenience): http://standards.nortelnetworks.com/tsvwg/PCN_draft_charter_v00.txt Thank you very much! -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 14 13:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNuhJ-0000QU-3Y; Thu, 14 Sep 2006 13:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNuhI-0000Q2-2v for pcn@ietf.org; Thu, 14 Sep 2006 13:08:20 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNuhF-0000lm-Oj for pcn@ietf.org; Thu, 14 Sep 2006 13:08:20 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8EH8Fn17183 for ; Thu, 14 Sep 2006 13:08:15 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 13:08:13 -0400 Message-Id: <6.2.5.6.0.20060914125822.03c06a20@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Sep 2006 13:08:13 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2006 17:08:13.0867 (UTC) FILETIME=[5D1247B0:01C6D820] X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [PCN] Document Repository for the PCN BOF/WG X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: I have created a document repository for this PCN BOF/WG. Please see: http://standards.nortel.com/pcn/ It contains the currently published documents we sent on this list (pcn@ietf.org). We will continue to populate this repository as more documents are published. Please send me documents you want me to post on this repository. Since all documents posted are from the pcn@ietf.org list, this repository will follow the IETF copyright, etc (IETF NOTE WELL) rules of the pcn@ietf.org mailing list. Thank you! -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 14 16:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyBC-0004Fv-Lb; Thu, 14 Sep 2006 16:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyBB-0004Fl-9I; Thu, 14 Sep 2006 16:51:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNyB5-00055P-Gk; Thu, 14 Sep 2006 16:51:25 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Sep 2006 16:51:19 -0400 X-IronPort-AV: i="4.09,166,1157342400"; d="scan'208,217"; a="102481910:sNHT56568136" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8EKpJNP026286; Thu, 14 Sep 2006 16:51:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8EKpIuI010572; Thu, 14 Sep 2006 16:51:18 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 16:51:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Sep 2006 16:51:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Pre-Congestion Notification BOF Thread-Index: AcbYP4YfvtirvYIhSFGdD6HjZk4Lpg== From: "Anna Charny \(acharny\)" To: "Magnus Westerlund" , "Lars Eggert" X-OriginalArrivalTime: 14 Sep 2006 20:51:18.0588 (UTC) FILETIME=[86FC9FC0:01C6D83F] DKIM-Signature: a=rsa-sha1; q=dns; l=12403; t=1158267079; x=1159131079; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:Request=20for=20Pre-Congestion=20Notification=20BOF |To:=22Magnus=20Westerlund=22=20, =0A=20=20=2 0=20=20=20=20=20=22Lars=20Eggert=22=20; X=v=3Dcisco.com=3B=20h=3DJYVkF9vD087dbOzYxtV8/QXyz2Y=3D; b=g5B909wmuidlQwDHvsEW8mDzNY5Z90wnDbD3fFa92IJtpLv2M79VyJM8TEGwlw+i9yjGIGnZ ozwl0fExKVyPzy1n5oQwwXQPWBeDaXpVRND9oX//vWyqL+xHUfX0ZLRp; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( 45 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: pcn@ietf.org, agenda@ietf.org Subject: [PCN] Request for Pre-Congestion Notification BOF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0933843717==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0933843717== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D83F.86BCF870" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D83F.86BCF870 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Lars and Magnus, =20 This message constitutes a formal request for Pre-Congestion Notification BOF at the November IETF meeting in San Diego. =20 =20 The BOF description and its proposed agenda are attached at the end of this message. =20 If this BOF is approved, we would like to request a two-hour slot that avoids scheduling conflicts with the following working groups: tsv, nsis, sip, ieprep, ecrit, pwe3, dccp. =20 We also ask that you CC agenda@ietf.org with your decision. =20 Of course we welcome any feedback you might have. =20 Best Regards, Anna Charny =20 PCN BOF Description =20 The Pre-Congestion Notification (PCN) BOF will address the problem of how to provide scalable and 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. =20 The overall approach will be based on a the concept of a PCN-Region, within which the functionality is separated between the PCN-Interior Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF will be the case of a single DiffServ region, which maps to a PCN-Region. PINs 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". PENs monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the PENs or by a centralized system (which is informed of the PCN information).=20 The BOF will address the need and the motivation for PCN work in the context of IETF, provide a brief overview of prior PCN efforts and related work, and review open issues. The BOF will also discuss the scope of work and solicit feedback on the proposed charter. Ultimately, the goal of the BOF is to solicit community feedback on whether the problem is clear and needs to be addressed, and consequently whether the creation of a new PCN WG within the scope of the proposed charter is warranted. =20 The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt . The problem statement and motivation for the PCN work is discussed in more detail in draft-chan-pcn-problem-statement-00, which has been submitted to IETF and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt . =20 Proposed BOF agenda =20 =20 1. Agenda bashing (5 min) 2. Motivation and Problem Statement presentation (15 min) 3. Discussion of motivation and problem statement (30 min) 4. Overview of prior PCN efforts, related work and open issues (15 min) 5. Overview of the proposed charter (10 min) 6. Discussion/bashing of the proposed charter (20 min)=20 7. General discussion and poll on the WG creation (25 min) ------_=_NextPart_001_01C6D83F.86BCF870 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello = Lars and=20 Magnus,
 
This = message=20 constitutes a formal request for Pre-Congestion Notification BOF at the = November=20 IETF meeting in San Diego. 
 
The = BOF description=20 and its proposed agenda are attached at the end of this=20 message.
 
If this BOF is=20 approved,  we would like to request a two-hour slot that avoids = scheduling=20 conflicts with the following working groups:  tsv, nsis, sip, ieprep, ecrit, pwe3,=20 dccp.
 
We also=20 ask that you CC agenda@ietf.org with=20 your decision.
 
Of course we=20 welcome any feedback you might have.
 
Best=20 Regards,
Anna=20 Charny
 
PCN BOF Description
 
The=20 Pre-Congestion Notification=20 (PCN)  BOF will = address the=20 problem of how to provide scalable and=20 resilient admission control and strong QoS assurance while using = packet=20 marking techniques. Current attempts to deliver QoS using only packet = marking=20 (e.g. DiffServ) are limited in the level of QoS assurance that can be = provided=20 without substantial over-provisioning. To improve the QoS assurance, PCN = will=20 add flow admission control and flow pre-emption. In normal circumstances = admission control should protect the QoS of previously admitted flows. = In times=20 of heavy congestion (for example caused by route changes due to link or = router=20 failure) pre-emption of some flows should preserve the QoS of remaining=20 flows.
 
The overall = approach=20 will be based on a the concept of a PCN-Region, within which the = functionality=20 is separated between the PCN-Interior Node (PIN)=20 and the PCN-End Node (PEN). The = initial=20 scope of the BOF will be the case of a single DiffServ region, = which maps=20 to a = PCN-Region.  =20 PINs mark packet headers = when their=20 traffic is above a certain level, as an early warning of incipient = congestion=20 (“pre-congestion”); this builds on concepts from RFC 3168 = "The Addition of=20 Explicit Congestion Notification to IP". =20 PENs monitor the = markings and=20 that information is used to make flow admission control and pre-emption=20 decisions. The decisions could be made by the PENs or by a centralized system (which is = informed=20 of the PCN information).=20

The BOF will address the need and the = motivation for=20 PCN work in the context of IETF, = provide a=20 brief overview of prior PCN efforts and related work,  and review open issues.  The BOF will also discuss the scope of work = and=20 solicit feedback on the proposed charter.  Ultimately, the goal of = the=20 BOF is to solicit community = feedback on=20 whether the problem is clear and needs to be addressed, and consequently = whether=20 the creation of a new PCN = WG within=20 the scope of the proposed charter is warranted.
 
The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt= . =20 The problem statement and motivation for the PCN work is discussed in = more=20 detail in draft-chan-pcn-problem-statement-00, which has been submitted = to IETF=20 and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement= -00.txt.
 
Proposed=20 BOF agenda  =
 
1.=20  Agenda bashing  = (5=20 min)
2.  Motivation and = Problem Statement presentation  (15=20 min)
3.  Discussion of motivation and = problem=20 statement (30 min)
4. =20 Overview of prior PCN efforts,=20 related work and open=20 issues (15 min)
5. =20 Overview of the proposed charter (10 min)
6. =20 Discussion/bashing of the proposed charter (20 min) 
7.  General discussion and poll = on the WG=20 creation (25 min)
= ------_=_NextPart_001_01C6D83F.86BCF870-- --===============0933843717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0933843717==-- From pcn-bounces@ietf.org Thu Sep 14 17:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyRc-0002U8-Gp; Thu, 14 Sep 2006 17:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNyRZ-0002TA-3S; Thu, 14 Sep 2006 17:08:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNyRX-0006UR-FV; Thu, 14 Sep 2006 17:08:21 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Sep 2006 17:08:19 -0400 X-IronPort-AV: i="4.09,166,1157342400"; d="scan'208,217"; a="102484767:sNHT58667804" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8EL8IIQ001900; Thu, 14 Sep 2006 17:08:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8EL8IdM002469; Thu, 14 Sep 2006 17:08:18 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 17:08:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Sep 2006 17:08:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: request for comments : Pre-Congestion Notification BOF Thread-Index: AcbYP4YfvtirvYIhSFGdD6HjZk4LpgAAArNA From: "Anna Charny \(acharny\)" To: , , , , , , , X-OriginalArrivalTime: 14 Sep 2006 21:08:18.0670 (UTC) FILETIME=[E700C8E0:01C6D841] DKIM-Signature: a=rsa-sha1; q=dns; l=15065; t=1158268098; x=1159132098; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:request=20for=20comments=20=3A=20Pre-Congestion=20Notification=20BOF |To:, =20, =20, =20, =0A=20=20=20=20=20=20=20=20, =20, =20,=20; X=v=3Dcisco.com=3B=20h=3DKLVS47oTgOlui5Yc+sNvxQCORMA=3D; b=qHx7qIfS4bxqiefMJyFjACDfZGAx4xMzftZYpW53xMM2qDpbS413iuGxFj0Q1d01yL7R8qEO KJC5lyYf5+RB6IjsAV8BcZ8qkkAth8VKo8yP0LuBXLe3lhEdJvu/bLJa; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( 45 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: pcn@ietf.org Subject: [PCN] request for comments : Pre-Congestion Notification BOF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024832769==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1024832769== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D841.E6B39F70" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D841.E6B39F70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear all, =20 We have submitted a request for Pre-Congestion Notification BOF at the San Diego meeting. The proposed BOF description, agenda, draft charter and the problem statement draft are in the attached message below. =20 We welcome your feedback on any of these documents. Please send your comments to pcn@ietf.org. =20 Best Regards, Anna Charny ________________________________ From: Anna Charny (acharny)=20 Sent: Thursday, September 14, 2006 4:51 PM To: 'Magnus Westerlund'; 'Lars Eggert' Cc: 'agenda@ietf.org'; pcn@ietf.org Subject: Request for Pre-Congestion Notification BOF Hello Lars and Magnus, =20 This message constitutes a formal request for Pre-Congestion Notification BOF at the November IETF meeting in San Diego. =20 =20 The BOF description and its proposed agenda are attached at the end of this message. =20 If this BOF is approved, we would like to request a two-hour slot that avoids scheduling conflicts with the following working groups: tsv, nsis, sip, ieprep, ecrit, pwe3, dccp. =20 We also ask that you CC agenda@ietf.org with your decision. =20 Of course we welcome any feedback you might have. =20 Best Regards, Anna Charny =20 PCN BOF Description =20 The Pre-Congestion Notification (PCN) BOF will address the problem of how to provide scalable and 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. =20 The overall approach will be based on a the concept of a PCN-Region, within which the functionality is separated between the PCN-Interior Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF will be the case of a single DiffServ region, which maps to a PCN-Region. PINs 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". PENs monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the PENs or by a centralized system (which is informed of the PCN information).=20 The BOF will address the need and the motivation for PCN work in the context of IETF, provide a brief overview of prior PCN efforts and related work, and review open issues. The BOF will also discuss the scope of work and solicit feedback on the proposed charter. Ultimately, the goal of the BOF is to solicit community feedback on whether the problem is clear and needs to be addressed, and consequently whether the creation of a new PCN WG within the scope of the proposed charter is warranted. =20 The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt . The problem statement and motivation for the PCN work is discussed in more detail in draft-chan-pcn-problem-statement-00, which has been submitted to IETF and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt . =20 Proposed BOF agenda =20 =20 1. Agenda bashing (5 min) 2. Motivation and Problem Statement presentation (15 min) 3. Discussion of motivation and problem statement (30 min) 4. Overview of prior PCN efforts, related work and open issues (15 min) 5. Overview of the proposed charter (10 min) 6. Discussion/bashing of the proposed charter (20 min)=20 7. General discussion and poll on the WG creation (25 min) ------_=_NextPart_001_01C6D841.E6B39F70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Dear all,
 
We have submitted a request = for Pre-Congestion=20 Notification BOF at the San Diego meeting.  The proposed BOF = description,=20 agenda, draft charter and the problem statement draft are in = the=20 attached message below.
 
We welcome your feedback on any of these = documents.  Please send your comments to pcn@ietf.org.
 
Best Regards,
Anna Charny

From: Anna Charny (acharny) =
Sent:=20 Thursday, September 14, 2006 4:51 PM
To: 'Magnus Westerlund'; = 'Lars=20 Eggert'
Cc: 'agenda@ietf.org'; pcn@ietf.org
Subject: = Request=20 for Pre-Congestion Notification BOF

Hello = Lars and=20 Magnus,
 
This = message=20 constitutes a formal request for Pre-Congestion Notification BOF at the = November=20 IETF meeting in San Diego. 
 
The = BOF description=20 and its proposed agenda are attached at the end of this=20 message.
 
If this BOF is=20 approved,  we would like to request a two-hour slot that avoids = scheduling=20 conflicts with the following working groups:  tsv, nsis, sip, ieprep, ecrit, pwe3,=20 dccp.
 
We also=20 ask that you CC agenda@ietf.org with=20 your decision.
 
Of course we=20 welcome any feedback you might have.
 
Best=20 Regards,
Anna=20 Charny
 
PCN BOF Description
 
The=20 Pre-Congestion Notification=20 (PCN)  BOF will = address the=20 problem of how to provide scalable and=20 resilient admission control and strong QoS assurance while using = packet=20 marking techniques. Current attempts to deliver QoS using only packet = marking=20 (e.g. DiffServ) are limited in the level of QoS assurance that can be = provided=20 without substantial over-provisioning. To improve the QoS assurance, PCN = will=20 add flow admission control and flow pre-emption. In normal circumstances = admission control should protect the QoS of previously admitted flows. = In times=20 of heavy congestion (for example caused by route changes due to link or = router=20 failure) pre-emption of some flows should preserve the QoS of remaining=20 flows.
 
The overall = approach=20 will be based on a the concept of a PCN-Region, within which the = functionality=20 is separated between the PCN-Interior Node (PIN)=20 and the PCN-End Node (PEN). The = initial=20 scope of the BOF will be the case of a single DiffServ region, = which maps=20 to a = PCN-Region.  =20 PINs mark packet headers = when their=20 traffic is above a certain level, as an early warning of incipient = congestion=20 (“pre-congestion”); this builds on concepts from RFC 3168 = "The Addition of=20 Explicit Congestion Notification to IP". =20 PENs monitor the = markings and=20 that information is used to make flow admission control and pre-emption=20 decisions. The decisions could be made by the PENs or by a centralized system (which is = informed=20 of the PCN information).=20

The BOF will address the need and the = motivation for=20 PCN work in the context of IETF, = provide a=20 brief overview of prior PCN efforts and related work,  and review open issues.  The BOF will also discuss the scope of work = and=20 solicit feedback on the proposed charter.  Ultimately, the goal of = the=20 BOF is to solicit community = feedback on=20 whether the problem is clear and needs to be addressed, and consequently = whether=20 the creation of a new PCN = WG within=20 the scope of the proposed charter is warranted.
 
The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt= . =20 The problem statement and motivation for the PCN work is discussed in = more=20 detail in draft-chan-pcn-problem-statement-00, which has been submitted = to IETF=20 and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement= -00.txt.
 
Proposed=20 BOF agenda  =
 
1.=20  Agenda bashing  = (5=20 min)
2.  Motivation and = Problem Statement presentation  (15=20 min)
3.  Discussion of motivation and = problem=20 statement (30 min)
4. =20 Overview of prior PCN efforts,=20 related work and open=20 issues (15 min)
5. =20 Overview of the proposed charter (10 min)
6. =20 Discussion/bashing of the proposed charter (20 min) 
7.  General discussion and poll = on the WG=20 creation (25 min)
= ------_=_NextPart_001_01C6D841.E6B39F70-- --===============1024832769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1024832769==-- From pcn-bounces@ietf.org Thu Sep 14 17:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNz7g-0004Cy-Qi; Thu, 14 Sep 2006 17:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNz7f-0004Cc-Lt for pcn@ietf.org; Thu, 14 Sep 2006 17:51:51 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNz7e-0006G8-5Q for pcn@ietf.org; Thu, 14 Sep 2006 17:51:51 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8ELpan04206 for ; Thu, 14 Sep 2006 17:51:37 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 17:51:17 -0400 Message-Id: <6.2.5.6.0.20060914173823.03313d50@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Sep 2006 17:51:16 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2006 21:51:17.0212 (UTC) FILETIME=[E7EF11C0:01C6D847] X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [PCN] draft-chan-pcn-problem-statement-00.txt discussion/issue list X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: As indicated in previous E-Mail concerning facilitating discussions of: http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt I have created a file listing the currently known discussion topics of this draft at: http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt Please let me know if there are additional concerns you would like to discuss, I will add them to the list. Please use the E-Mail Subject field guideline indicated in the file for discussion threads. I have also included the content of the file at the end of this E-Mail for completeness. But the content of this file will change over time, hence please always use http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt as the latest version and as the master. Thanks! -- Kwok -- Current content of the file: PCN Problem Statement Draft Issues List --------------------------------------- The purpose of this document and list is for: 1. Tracking the current open issues for draft-chan-pcn-problem-statement-xx.txt 2. Facilitate the discussion of these issues on pcn@ietf.org. For example, when discussing the "PCN-Region or PCN-Domain" issue, The subject field of the E-Mail sent to pcn@ietf.org should be: "Issue A.1: PCN-Region Term" This will help people interested in following the discussion threads. 3. Track the resolution of these issues. Hence this is a living document: - new issues will/may be added. - current issues may have their status/info updated. - including closing of issues with resolution indicated. Master copy of this document resides in: http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt The Issues List: A. Terminology Issues. As most new WG/BOF have. One goal of picking the appropriate terminology is for their applicability to the deployment scenarios we know of. To facilitate the applicability to multiple deployment scenarios, we have adopted a FUNCTIONAL DESCRIPTION approach for terminology. 1. PCN-Region or PCN-Domain Calling this the "PCN-Region Term" Issue. Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. 2. PCN-Interior Node or PCN-Intermediate Node (PIN) Calling this the "PIN Term" Issue. Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN-Interior Node 3. PCN-End Node or PCN-Edge Node or PCN-Boundary Node Calling this the "PEN Term" Issue. Reference: draft-chan-problem-statement-00.txt section 2.1. B. Environmental Issues. This relates to the environment PCN operates in. 1. How "many" flows are needed to provide accurate enough measurement at the PIN? Calling this the "Many flows at PIN" Issue. Reference: draft-chan-problem-statement-00.txt section 4.2. Reference: draft-chan-problem-statement-00.txt section 5 Aggregate Traffic Characteristics. Solution to this issue most likely requires simulation and research work. 2. How "many" flows are needed to provide accurate enough measurement at the PEN? If measurement is done at the PEN. Calling this the "Many flows at PEN" Issue. Reference: draft-chan-problem-statement-00.txt section 4.2. Reference: draft-chan-problem-statement-00.txt section 5 Aggregate Traffic Characteristics. Solution to this issue most likely requires simulation and research work. 3. How "many" flows for PIN/PEN relationship. As one can see, the above 2 issues on "Many flows at PIN/PEN" are related, and may impact each other. Hence using this Issue as the thread for their interaction discussions. Calling this the "PIN+PEN Many flows" Issue. Reference: draft-chan-problem-statement-00.txt section 4.2. Reference: draft-chan-problem-statement-00.txt section 5 Aggregate Traffic Characteristics. Solution to this issue most likely requires simulation and research work. 4. How should ECMP be handled? Does PCN need to operate in ECMP environment? Calling this the "ECMP" Issue. Reference: draft-chan-problem-statement-00.txt section 5 ECMP Routing. 5. How should Bi-Directional Sessions be handled? Calling this the "Bi-Directional Session" Issue. Reference: draft-chan-problem-statement-00.txt section 5 Bi-Directional Sessions. 6. Is Speed of Reaction a concern? This relates to the time scales used for judging the accuracy of the algorithms used for the measurements. We should use this discussion/issue thread for the time scale requirement of the algorithms. And may be related to the three "Many flows ..." issues above. Calling this the "Speed of Reaction" Issue. Reference: draft-chan-problem-statement-00.txt section 5 Speed of Reaction. 7. Should Global Coordination be considered? This is more of a characteristic of Deployment Scenarios. But may have consequences on the more basic approaches. Calling this the "Global Coordination" Issue. Reference: draft-chan-problem-statement-00.txt section 5 Global Coordination. 8. Should Aggregate Traffic Characteristics be specified as part of requirement? There is a possibility this can be combined with, or influence the "Many flows at PIN" Issue indicated earlier. Calling this the "Aggregate Traffic Characteristics" Issue. Reference: draft-chan-problem-statement-00.txt section 5 Aggregate Traffic Characteristics. C. Standardization Issues. What should the proposed WG (hopeful result of the BOF) standardize? 1. Should measurement algorithm(s) at the PIN be standardized? And what criteria to use for judging these algorithm(s)? Calling this the "PIN Algorithm Standardization" Issue. 2. Should measurement algorithm(s) at the PEN be standardized? And what criteria to use for judging these algorithm(s)? Calling this the "PIN Algorithm Standardization" Issue. D. Signaling Relationship Issues. What about signaling? Are there signaling requirements from the PCN work? How should they be fullfilled? 1. Just a general discussion thread for this for now. May have more detailed discussion threads later. Calling this the "General Signaling Requirement" Issue. E. Draft Content Issues. This is for if additional types of content should be added to the Problem Statement draft or should some current content be removed? 1. Should Deployment Scenarios details be in the Problem Statment draft (in the appendix like RFC 3726)? Or should they be in their own respective drafts? Calling this the "Deployment Scenario in Problem Statement" Issue. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 15 03:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7xb-0005Ll-C3; Fri, 15 Sep 2006 03:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7xZ-0005IY-Aq for pcn@ietf.org; Fri, 15 Sep 2006 03:18:01 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO7j1-0005iB-4c for pcn@ietf.org; Fri, 15 Sep 2006 03:03:00 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 15 Sep 2006 09:02:58 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Sep 2006 09:02:58 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF845@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: acharny@cisco.com Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter Date: Fri, 15 Sep 2006 09:02:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Anna, I'd think that issues related to ecn should continue to be discussed within the tsvwg, no matter whether they are related to mpls, ip or pcn. At the same time, drafts relevant for PCN need to be discussed and announced to the PCN BOF/WG. And mpls-ecn certainly is one of them. So my position is discussion in both WGs. If it was of help in transforming the pcn bof to the pcn WG, then I'd favour the PCN bof as the home of draft-davie-ecn-mpls. Regards, Rudiger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Wednesday, September 13, 2006 8:37 AM |To: YongLucy 73674; pcn@ietf.org |Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter | | |Hi Lucy, | |Thank you for your post. Our initial assumption was that mpls-ecn work |will continue within tsvwg (see draft-davie-ecn-mpls). I guess it is a |question to the list and the working group chairs on whether |this should be undertaken within the PCN WG (assuming it be formed). |One argument for keeping it within tsvwg is that it has broader |application than the proposed scope for the PCN BoF/new WG. But we |are open to comments/suggestions on this. | |Anna | |-----Original Message----- |From: YongLucy 73674 [mailto:lucyyong@huawei.com] |Sent: Tuesday, September 12, 2006 11:16 PM |To: pcn@ietf.org |Subject: [PCN] PCN (Pre-Congestion Notification) draft charter | |Hello Every One, | |It is great to organize a BOF on PCN. This is a very important function |for QoS. The draft charter covers many features from IP perspectives (I |think). Should we also cover features from MPLS perspective? Something |like PCN per LSP. How could PCN contain the sufficient informaton for |edge router or CL to take an action on it? For multiple |segements having congestion potential, could a consolidated PCN be |propagated to the ingress or egress edge router? |Should RSVP be used in PCN for a LSP or a bit is inserted in packets? | |Anyway this is a good starting point. | |Best Regards, |Lucy Yong | | |*************************************************************** |********* |******************* | This email and its attachments contain confidential information from |HUAWEI, which is intended only for the person or entity whose |address is |listed above. Any use of the information contained herein in any way |(including, but not limited to, total or partial disclosure, |reproduction, or dissemination) by persons other than the intended |recipient(s) is prohibited. If you receive this e-mail in error, please |notify the sender by phone or email immediately and delete it! | |*************************************************************** |********* |******************* | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 15 11:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFxU-0008DG-8C; Fri, 15 Sep 2006 11:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFxS-0008Co-Pr for pcn@ietf.org; Fri, 15 Sep 2006 11:50:26 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFxR-0003Og-Eu for pcn@ietf.org; Fri, 15 Sep 2006 11:50:26 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5N00K8U56NJO@usaga01-in.huawei.com> for pcn@ietf.org; Fri, 15 Sep 2006 08:47:11 -0700 (PDT) Received: from Yong73674 ([10.124.8.165]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5N00DEH56J42@usaga01-in.huawei.com> for pcn@ietf.org; Fri, 15 Sep 2006 08:47:11 -0700 (PDT) Date: Fri, 15 Sep 2006 10:50:17 -0500 From: Lucy Yong Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter In-reply-to: <6439282641581441A36F7F6F83ED2ED2CBF845@S4DE8PSAAFQ.mitte.t-com.de> To: "'Geib, Ruediger'" , acharny@cisco.com Message-id: <000801c6d8de$a4316e00$a5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbYl7hHvLZOPblGQFuFCSqyM18sRwARXakw X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Anna, I agree with Ruediger. I think PCN WG should tackle IP/MPLS together because more and more high available applications use MPLS transport mechanism. IP based marking may not effectively improve the application QoS. It would be better to study both together. Best Regards, Lucy -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: Friday, September 15, 2006 2:03 AM To: acharny@cisco.com Cc: pcn@ietf.org Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter Hello Anna, I'd think that issues related to ecn should continue to be discussed within the tsvwg, no matter whether they are related to mpls, ip or pcn. At the same time, drafts relevant for PCN need to be discussed and announced to the PCN BOF/WG. And mpls-ecn certainly is one of them. So my position is discussion in both WGs. If it was of help in transforming the pcn bof to the pcn WG, then I'd favour the PCN bof as the home of draft-davie-ecn-mpls. Regards, Rudiger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Wednesday, September 13, 2006 8:37 AM |To: YongLucy 73674; pcn@ietf.org |Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter | | |Hi Lucy, | |Thank you for your post. Our initial assumption was that mpls-ecn work |will continue within tsvwg (see draft-davie-ecn-mpls). I guess it is a |question to the list and the working group chairs on whether |this should be undertaken within the PCN WG (assuming it be formed). |One argument for keeping it within tsvwg is that it has broader |application than the proposed scope for the PCN BoF/new WG. But we |are open to comments/suggestions on this. | |Anna | |-----Original Message----- |From: YongLucy 73674 [mailto:lucyyong@huawei.com] |Sent: Tuesday, September 12, 2006 11:16 PM |To: pcn@ietf.org |Subject: [PCN] PCN (Pre-Congestion Notification) draft charter | |Hello Every One, | |It is great to organize a BOF on PCN. This is a very important function |for QoS. The draft charter covers many features from IP perspectives (I |think). Should we also cover features from MPLS perspective? Something |like PCN per LSP. How could PCN contain the sufficient informaton for |edge router or CL to take an action on it? For multiple |segements having congestion potential, could a consolidated PCN be |propagated to the ingress or egress edge router? |Should RSVP be used in PCN for a LSP or a bit is inserted in packets? | |Anyway this is a good starting point. | |Best Regards, |Lucy Yong | | |*************************************************************** |********* |******************* | This email and its attachments contain confidential information from |HUAWEI, which is intended only for the person or entity whose |address is |listed above. Any use of the information contained herein in any way |(including, but not limited to, total or partial disclosure, |reproduction, or dissemination) by persons other than the intended |recipient(s) is prohibited. If you receive this e-mail in error, please |notify the sender by phone or email immediately and delete it! | |*************************************************************** |********* |******************* | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 18 04:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPEq7-0002XB-Cc; Mon, 18 Sep 2006 04:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPEq5-0002X6-T8 for pcn@ietf.org; Mon, 18 Sep 2006 04:50:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPEq3-00074w-Bf for pcn@ietf.org; Mon, 18 Sep 2006 04:50:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Sep 2006 04:50:51 -0400 X-IronPort-AV: i="4.09,180,1157342400"; d="scan'208"; a="102916709:sNHT42445544" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8I8ooA3007512; Mon, 18 Sep 2006 04:50:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8I8oodM007073; Mon, 18 Sep 2006 04:50:50 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 04:50:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter Date: Mon, 18 Sep 2006 04:50:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN (Pre-Congestion Notification) draft charter Thread-Index: AcbYlPx1bHM58ZvzRjKK1d/s8PkfRACaks4A From: "Anna Charny \(acharny\)" To: "Geib, Ruediger" X-OriginalArrivalTime: 18 Sep 2006 08:50:50.0278 (UTC) FILETIME=[8A8EFC60:01C6DAFF] DKIM-Signature: a=rsa-sha1; q=dns; l=3421; t=1158569450; x=1159433450; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20PCN=20(Pre-Congestion=20Notification)=20draft=20charter |To:=22Geib,=20Ruediger=22=20; X=v=3Dcisco.com=3B=20h=3Dwm/CG6Md91AeUQYt5q2bHg7Tcyg=3D; b=n0ApiWG957RDlJnDbJFEeo/HMFivDWPF/4nrSe7U42SckTXD6FxRFGSJ5kGOHfTdni53VQ92 9b6pygLWQFoxOPAaQBI2qjSKxvgfZQkN2P7UswA5kcnUj50rerlDbRCl; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Thanks, Rudiger, Will definetely take your feedback into account. =20 Anna=20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: Friday, September 15, 2006 3:03 AM To: Anna Charny (acharny) Cc: pcn@ietf.org Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter Hello Anna, I'd think that issues related to ecn should continue to be discussed within the tsvwg, no matter whether they are related to mpls, ip or pcn. At the same time, drafts relevant for PCN need to be discussed and announced to the PCN BOF/WG. And mpls-ecn certainly is one of them. So my position is discussion in both WGs. If it was of help in transforming the pcn bof to the pcn WG, then I'd favour the PCN bof as the home of draft-davie-ecn-mpls. Regards, Rudiger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Wednesday, September 13, 2006 8:37 AM |To: YongLucy 73674; pcn@ietf.org |Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter | | |Hi Lucy, | |Thank you for your post. Our initial assumption was that mpls-ecn work |will continue within tsvwg (see draft-davie-ecn-mpls). I guess it is a |question to the list and the working group chairs on whether this=20 |should be undertaken within the PCN WG (assuming it be formed). |One argument for keeping it within tsvwg is that it has broader=20 |application than the proposed scope for the PCN BoF/new WG. But we are |open to comments/suggestions on this. | |Anna | |-----Original Message----- |From: YongLucy 73674 [mailto:lucyyong@huawei.com] |Sent: Tuesday, September 12, 2006 11:16 PM |To: pcn@ietf.org |Subject: [PCN] PCN (Pre-Congestion Notification) draft charter | |Hello Every One, | |It is great to organize a BOF on PCN. This is a very important function |for QoS. The draft charter covers many features from IP perspectives (I |think). Should we also cover features from MPLS perspective? Something=20 |like PCN per LSP. How could PCN contain the sufficient informaton for=20 |edge router or CL to take an action on it? For multiple segements=20 |having congestion potential, could a consolidated PCN be propagated to=20 |the ingress or egress edge router? |Should RSVP be used in PCN for a LSP or a bit is inserted in packets? | |Anyway this is a good starting point. | |Best Regards, |Lucy Yong | | |*************************************************************** |********* |******************* | This email and its attachments contain confidential information from=20 |HUAWEI, which is intended only for the person or entity whose address=20 |is listed above. Any use of the information contained herein in any way |(including, but not limited to, total or partial disclosure,=20 |reproduction, or dissemination) by persons other than the intended |recipient(s) is prohibited. If you receive this e-mail in error, please |notify the sender by phone or email immediately and delete it! |=20 |*************************************************************** |********* |******************* | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 18 10:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPK7c-0007sn-3B; Mon, 18 Sep 2006 10:29:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPK7b-0007sd-2E for pcn@ietf.org; Mon, 18 Sep 2006 10:29:19 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPK7Y-0001N2-Kz for pcn@ietf.org; Mon, 18 Sep 2006 10:29:19 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8IEMrc00559 for ; Mon, 18 Sep 2006 10:22:54 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 10:29:11 -0400 Message-Id: <6.2.5.6.0.20060918102736.06188688@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 18 Sep 2006 10:29:11 -0400 To: pcn@ietf.org From: Internet-Drafts@ietf.org (by way of Kwok Ho Chan ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Sep 2006 14:29:11.0975 (UTC) FILETIME=[CF501B70:01C6DB2E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org FYI. The Problem Statement draft is available at the IETF draft servers. -- Kwok -- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Pre-Congestion Notification Problem Statement Author(s) : K. Chan, et al. Filename : draft-chan-pcn-problem-statement-00.txt Pages : 16 Date : 2006-9-15 DiffServ mechanisms have been developed to support Quality of Service (QoS). However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre- Congestion Notification (PCN) investigates the use of per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow pre-emption mechanism is necessary in the times of heavy congestion (e.g. caused by route changes due to link or node failure). This document provides a problem statement on the addition of flow admission control and flow pre-emption functionality to a DiffServ network, in particular for the support of real time services such as voice and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chan-pcn-problem-statement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-chan-pcn-problem-statement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-9-15130236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chan-pcn-problem-statement-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 18 14:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPNy2-0004oW-Tm; Mon, 18 Sep 2006 14:35:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPNy1-0004oP-Fw for pcn@ietf.org; Mon, 18 Sep 2006 14:35:41 -0400 Received: from athena.hosts.co.uk ([85.233.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPNxz-0002UA-51 for pcn@ietf.org; Mon, 18 Sep 2006 14:35:41 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from ) id 1GPNxs-0000Qi-F2; Mon, 18 Sep 2006 19:35:35 +0100 In-Reply-To: <6.2.5.6.0.20060918102736.06188688@nortel.com> References: <6.2.5.6.0.20060918102736.06188688@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Date: Mon, 18 Sep 2006 14:35:23 -0400 To: by way of Kwok Ho Chan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Part of your problem statement advocates the use of preemption of flows as an option to maintain QoS of other existing flows when severe congestion (possibly through node failure occurs). Back in April, I posted a review of draft-briscoe-tsvwg-cl- architecture-02.txt and asked if an additional model or approach could be taken in place of preemption. The specific comments can be found at: (me) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06369.html. (bob) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06396.html In that thread I pointed the authors to another work in progress as one example that added the approach of engineered spare capacity instead of preemption. (fyi, the latest version of the suggested reading is: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft- lefaucheur-emergency-rsvp-02.txt). And in looking at the outline of draft-briscoe-tsvwg-cl-architecture-03.txt, it appears that the authors are still just focusing on preemption. (quite understandable, because what I suggested is significant and not easily added in a single rev). The reason I ask if your effort can consider another model other than preemption is that for certain deployments of VoIP in countries, like the U.S. and Germany, non-man-in-the-loop preemption is not allowed. This would seem to severely limit the actions you advocate during times of severe congestion, albeit for one type of flow. So while there isn't necessarily a technical concern in using preemption, unfortunately the realities of regulation and laws would seem to encourage your proposed group to consider additional alternatives. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 06:20:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcia-00011g-Dc; Tue, 19 Sep 2006 06:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPciZ-000114-3P for pcn@ietf.org; Tue, 19 Sep 2006 06:20:43 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPciW-0005wv-A1 for pcn@ietf.org; Tue, 19 Sep 2006 06:20:43 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3F7745339 for ; Tue, 19 Sep 2006 12:20:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 335A5453A for ; Tue, 19 Sep 2006 12:20:35 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 13ABC2F16 for ; Tue, 19 Sep 2006 12:20:34 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8JAKYs08115 for ; Tue, 19 Sep 2006 12:20:34 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 840136F58E for ; Tue, 19 Sep 2006 12:19:26 +0200 (CEST) Message-ID: <450FC491.5040509@informatik.uni-wuerzburg.de> Date: Tue, 19 Sep 2006 12:21:05 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, I've read the draft http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt I find the proposed concept pretty good as I consider it a simple and technically feasible solution. Here are my comments regarding the draft. 1) Abstract: Although I am working on this field for years, I haven't understood what the draft is about upon the first reading. Here is how I'd summarize the presented mechanism. This document describes a distributed, measurement-based, and resilient admission control for application in large DiffServ-based networks. All routers have a configured admission and pre-emption rate for their adjacent links. They measure the admitted traffic they forward on each outgoing link and use a so-called pre-congestion notification (PCN) mechanism to mark packets that exceed the configured rates. The egress router measures the rates of non-labelled, admission-marked, and preemption-marked packets from each ingress, and notifies the respective ingress if it must not admit any further packets or that it must even pre-empt a certain rate of admitted flows. Per-flow admission states are kept at the edge routers only, while the PCN markers that are required for all routers focus on the aggregate traffic. The admission control is resilient with regard to the following two aspects: (1) the configured admission and preemption rates can be chosen in such a way that the reservations for admitted flows are not pre-empted if a foreseeable failure occurs and (2) that reservations can be torn down explicitly if a large failure occurs to preserve the quality of service of the remaining flows. 2) The summary is very long. As the terminology is explained only in 1.2, it is sometime hard to follow Section 1.1. It is sometimes unnecessarily unprecise and, therefore, hard to follow. I think this could be rewritten without increasing the length of Sections 1.1 and 1.2 such that they it provide more clarity even at the first reading. 3) Terminology for "sustainable-aggregate-rate" is not clear. Suggestion: rate of non-preemption marked packets measured by an egress gateway for a specific ingress gateway; this is the supportable traffic rate between these gateways if the corresponding path is congested. 4) Section 2.2: o Routing: a study regarding the accuracy of load balancing schemes can be found in [LoadBalancing-a] Ruediger Martin, Michael Menth, and Michael Hemmkeppler: "Accuracy and Dynamics of Hash-Based Load Balancing Algorithms for Multipath Internet Routing", IEEE Broadnets, San Jose, CA, USA, October 2006 http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth06p.pdf [LoadBalancing-b] Ruediger Martin, Michael Menth, and Michael Hemmkeppler: "Accuracy and Dynamics of Multi-Stage Load Balancing for Multipath Internet Routing", currently under submission http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-6.pdf Section 3 and 4: no comments, they look good and are well understandable. 5) Section 5.1: o tunnel: what kind of tunnel? IP-in-IP tunneling from ingress gateway to egress gateway with the effect that all flows are forced by ECMP on the paths that is determined by the IPs of these tunnel endpoints? This is how understood tunneling later in 5.7.1. o probes: probe packets have the same address as the corresponding flow. Do they finally leave the CL-domain and reach the destination? This is unwanted extra traffic for this machine. 6) Section 5.2: Another potential solution: smart marking The meaning of preemption marked packets is: this is an excess packet and the rate of the corresponding CL-region-aggregate will be reduced in the future. Therefore, packets that are already preemption marked should not be counted at another router for the metering process which is done for preemption marking. This does not solve the problem in Figure 4, but it alleviates the problem in other constellations: IAR-b=1 @ +-----+ L1 +-----+ L2 |CPR=1| |CPR=2|@@@@ SAR-b=2/3 IAR-a=2 >####| R1 |####| R2 |#### SAR-a=1/2*2/3=1/3 +-----+ +-----+ These SARs lead in the end to a rate of 1 on link L2 although the configured-admission-rate (CAR) is 2. If already marked packets are not respected at R2 for the metering process for preemption marking, we get SAR-b=1 and SAR-a=1/2 which leads in the end to the fully used CAR on link L2. After I wrote this, I read the draft about the markers: http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt The suggested algorithm implements the preemption marker in fact in such a way that it respects only non-preemption-marked packets for the measurement process. This is a requirement which should also be mentioned in this draft. 7) Section 5.5 Another potential solution: add the declared rate to the SAR at the ingress gateway as long as new flows send hardly any traffic. This information must be obtained from the corresponding policers which are also under the control of the ingress gateway. Or add it for an initial period of e.g. 10 s? 8) Section 5.7.2 What does over-congested mean? 9) Section 5.7.4 Reminds me of RFC4127: Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering (and other models for that objective) 10) Section 5.7.5 I haven't understood the last sentence of this section. Can it be rephrased? 11) Section 6.8 *NEW* Other Network Admission Control Approaches Link admission control (LAC) describes how admission control (AC) can be done on a single link and comprises, e.g., the calculation of effective bandwidths which may be the base for a parameter-based AC. In contrast, network AC (NAC) describes how AC can be done for a network and focuses on the locations from which data is gathered for the admission decision. Most approaches implement a link budget based NAC (LB NAC) where each link has a certain AC-budget. RSVP works according to that principle, but also the new concept admits additional flows as long as each link on the new flow's path still has resources available. The border-to-border budget based NAC (BBB NAC) pre-configures an AC budget for all border-to-border relationships (=CL-region-aggregates) and if this capacity budget is exhausted, new flows are rejected. The TCA-based admission control which is associated with the DiffServ architecture implements an ingress budget based NAC (IB NAC). These basically different concepts have different flexibility and efficiency with regard to the use of link bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing the budgets in such a way that the network will not be congested after rerouting due to a failure. The efficiency of the approaches is different with and without such resilient requirements. [NAC-a] Michael Menth: "Efficient Admission Control and Routing in Resilient Communication Networks", PhD thesis, July 2004, http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Menth04.pdf [NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and Karl Schrodi: "Resilient Network Admission Control", currently under submission. http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-3.pdf 12) Section 11.1 Paragraph "The ECN-Capable ... codepoint set." is hard to understand. Two sentences more explanation could maybe help. 13) Section 11.3 By running the EWMA whenever a new packet for a specific CL-region-aggregate arrives makes the aging process depending on the arrival rate of the traffic. As a consequence, there is the problem with the stale information. This can be done in a better way, e.g. by using the time-exponentially weighted moving average (TEWMA) [TEWMA]. [TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness of Rate Measurements", in proceedings of GI/ITG Conference on Measuring, Modelling and Evaluation of Computer and Communication Systems (MMB), Dresden, Germany, September 2004 http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf If the TEWMA seems too complex (it requires the calculation of an exponential function), a rate of the admission- or preemption-marked packets can be calculated based on a, e.g., 20 ms interval and used as input for a conventional EWMA. 14) Some places in the document say that admission and preemption marking is done based on the rates of the packet AND some virtual queue size. This is misleading from my perspective. The objective is a) to admission-mark all packets of an CL-region-aggregate if the configured admission rate ist exceeded and b) to preemption-mark only those packets exceeding the configured preemption rate. The virtual queue is just a means to allow a tolerance against short-time rate fluctuations like the "cell delay variation tolerance" or the "burst tolerance" in ATM. More on this topic in an extra mail regarding draft-briscoe-tsvwg-cl-phb-02.txt Best wishes, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 09:21:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfXX-0004QO-5C; Tue, 19 Sep 2006 09:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPfXW-0004QE-UU for pcn@ietf.org; Tue, 19 Sep 2006 09:21:30 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfXU-0000sD-HJ for pcn@ietf.org; Tue, 19 Sep 2006 09:21:30 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8JDEjG23271; Tue, 19 Sep 2006 09:14:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 09:21:00 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650C208A4D@zcarhxm1.corp.nortel.com> In-Reply-To: <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: AcbbUU/EmYnfNEqvQ5KQMW4tf3Z+2wAmIFoA From: "Jozef Babiarz" To: "ken carlberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken thanks for your comments. Yes, there maybe other options or action that can be taken besides pre-emption. 1./ The routers can signal pre-congestion level(s) via ECN bits in IP header to egress hosts and egress hosts really this information to ingress hosts to reduce their sending rate if they can (use a lower rate codec). However, this does not totally solve the problem. 2./ The network is engineered so that there are sufficed spare resources available that should a router or link fail, that traffic is rerouted on to the spare resources. Again this does not totally solve the problem because there maybe multiple failures, etc.=20 Pre-emption is the last resort mechanism that removes real-time inelastic flows to bring that service class back into non-congested state. It will be interesting what guidelines/rules the FCC and other regulatory bodies will provide/use should an operator be forced to preempt m number of voice flows in the IP network? My take is that it would be similar to what is done in TDM networks today when a TDM switch or trunk fails and calls are lost. =20 =20 Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: Monday, September 18, 2006 2:35 PM To: by way of Kwok Ho Chan Cc: pcn@ietf.org Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Part of your problem statement advocates the use of preemption of =20 flows as an option to maintain QoS of other existing flows when =20 severe congestion (possibly through node failure occurs). Back in April, I posted a review of draft-briscoe-tsvwg-cl-=20 architecture-02.txt and asked if an additional model or approach =20 could be taken in place of preemption. The specific comments can be =20 found at: (me) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06369.html. (bob) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06396.html In that thread I pointed the authors to another work in progress as =20 one example that added the approach of engineered spare capacity =20 instead of preemption. (fyi, the latest version of the suggested =20 reading is: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-=20 lefaucheur-emergency-rsvp-02.txt). And in looking at the outline of =20 draft-briscoe-tsvwg-cl-architecture-03.txt, it appears that the =20 authors are still just focusing on preemption. (quite =20 understandable, because what I suggested is significant and not =20 easily added in a single rev). The reason I ask if your effort can consider another model other than =20 preemption is that for certain deployments of VoIP in countries, like =20 the U.S. and Germany, non-man-in-the-loop preemption is not allowed. =20 This would seem to severely limit the actions you advocate during =20 times of severe congestion, albeit for one type of flow. So while there isn't necessarily a technical concern in using =20 preemption, unfortunately the realities of regulation and laws would =20 seem to encourage your proposed group to consider additional =20 alternatives. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 09:36:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPflm-00012e-FN; Tue, 19 Sep 2006 09:36:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPflk-00012W-La for pcn@ietf.org; Tue, 19 Sep 2006 09:36:12 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPfle-00061c-5M for pcn@ietf.org; Tue, 19 Sep 2006 09:36:12 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 14:36:03 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Sep 2006 14:35:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 14:35:43 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCEB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Thread-Index: AcbbUU6dLwBQUXz5REio7b0actcIcgAhnsoQ From: To: , X-OriginalArrivalTime: 19 Sep 2006 13:35:43.0817 (UTC) FILETIME=[8183CB90:01C6DBF0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken Thanks for your comments. Trying to work out how to deal with them, as the set of docs will evolve following on from the PCN BoF.=20 Do we need to change the problem statement? Should we add near the end of Section 1.1, where flow pre-emption is mentioned, a comment something like?: Such a flow pre-emption mechanism is complementary to the techniques described in draft-lefaucheur-emergency-rsvp-02.txt [*]. Note that sometimes flow pre-emption is not appropriate, for policy or regulatory reasons. For example, for certain deployments of VoIP in the U.S. and Germany regulation does not allow non-man-in-the-loop pre-emption [**]. What do you reckon? [*] is this ok? Do you see them as complementary mechanisms? My reading is that both could be appropriate, depending on the circumstances. Also that draft-lefaucheur-emergency-rsvp applies to 'normal' circumstances, whereas flow pre-emption is targeted at 'abnormal' circumstances eg where several nodes have failed causing much less network capacity (so re-routing has overloaded some links). [**] just to clarify what this means - pre-emption is only allowed if a human explicitly authorises the pre-emption of a particular flow; automatic pre-emption by the network isn't allowed. This applies where the end user is getting a PSTN service. I don't think we need to change the Draft Charter http://standards.nortelnetworks.com/pcn/PCN_draft_charter_v00.txt and the standards-track docs won't need to mention this issue.=20 But at least one deployment model draft should mention it, saying it's a complementary technique etc.=20 is this ok? or do you think there are interactions between the two techniques that we need to explore, or something that needs to be added to the Charter? Thanks phil -----Original Message----- From: ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: 18 September 2006 19:35 To: by way of Kwok Ho Chan Cc: pcn@ietf.org Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Part of your problem statement advocates the use of preemption of =20 flows as an option to maintain QoS of other existing flows when =20 severe congestion (possibly through node failure occurs). Back in April, I posted a review of draft-briscoe-tsvwg-cl-=20 architecture-02.txt and asked if an additional model or approach =20 could be taken in place of preemption. The specific comments can be =20 found at: (me) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06369.html. (bob) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06396.html In that thread I pointed the authors to another work in progress as =20 one example that added the approach of engineered spare capacity =20 instead of preemption. (fyi, the latest version of the suggested =20 reading is: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-=20 lefaucheur-emergency-rsvp-02.txt). And in looking at the outline of =20 draft-briscoe-tsvwg-cl-architecture-03.txt, it appears that the =20 authors are still just focusing on preemption. (quite =20 understandable, because what I suggested is significant and not =20 easily added in a single rev). The reason I ask if your effort can consider another model other than =20 preemption is that for certain deployments of VoIP in countries, like =20 the U.S. and Germany, non-man-in-the-loop preemption is not allowed. =20 This would seem to severely limit the actions you advocate during =20 times of severe congestion, albeit for one type of flow. So while there isn't necessarily a technical concern in using =20 preemption, unfortunately the realities of regulation and laws would =20 seem to encourage your proposed group to consider additional =20 alternatives. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 09:58:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg7J-0006Ni-I5; Tue, 19 Sep 2006 09:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg7J-0006NZ-9T for pcn@ietf.org; Tue, 19 Sep 2006 09:58:29 -0400 Received: from hermes.hosts.co.uk ([85.233.160.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPg7I-0003iR-02 for pcn@ietf.org; Tue, 19 Sep 2006 09:58:29 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by hermes.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1GPg6p-0007u7-OP; Tue, 19 Sep 2006 14:58:00 +0100 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650C208A4D@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650C208A4D@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 09:58:05 -0400 To: "Jozef Babiarz" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, > 1./ The routers can signal pre-congestion level(s) via ECN bits in IP > header to egress hosts and egress hosts really this information to > ingress hosts to reduce their sending rate if they can (use a lower > rate > codec). However, this does not totally solve the problem. > 2./ The network is engineered so that there are sufficed spare > resources > available that should a router or link fail, that traffic is > rerouted on > to the spare resources. Again this does not totally solve the problem > because there maybe multiple failures, etc. understood. perhaps in the next iteration of the architecture document these can be more prominently placed/discussed so that it is seen as the same "level" as preemption. > Pre-emption is the last resort mechanism that removes real-time > inelastic flows to bring that service class back into non-congested > state. It will be interesting what guidelines/rules the FCC and other > regulatory bodies will provide/use should an operator be forced to > preempt m number of voice flows in the IP network? My take is that it > would be similar to what is done in TDM networks today when a TDM > switch > or trunk fails and calls are lost. well, within the context of the US PSTN, when such a condition exists and calls are lost, other existing calls on other switches are not preempted when the system tries to re-establish lost calls. When capacity has reached its limit, additional call attempts are blocked. maybe we have a different perspective of preemption. as I view it, preemption is removing *existing* state (circuit in the PSTN world) in favor of new state. In the US and some other countries, this is not allowed in the PSTN. I also don't claim to be an expert on the FCC, but recent rulings regarding 911 service for certain VoIP providers would seem that they intend to extend existing regulations from PSTN to certain VoIP providers. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 09:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg8U-0000Jw-NZ; Tue, 19 Sep 2006 09:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPg8T-0000GN-IF for pcn@ietf.org; Tue, 19 Sep 2006 09:59:41 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPg8R-0004SQ-4n for pcn@ietf.org; Tue, 19 Sep 2006 09:59:41 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8JDxSo03486; Tue, 19 Sep 2006 09:59:29 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 09:58:52 -0400 Message-Id: <6.2.5.6.0.20060919093100.03d9ebd8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Sep 2006 09:58:51 -0400 To: ken carlberg From: "Kwok-Ho Chan" Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt In-Reply-To: <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> References: <6.2.5.6.0.20060918102736.06188688@nortel.com> <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Sep 2006 13:58:52.0451 (UTC) FILETIME=[BD348730:01C6DBF3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: pcn@ietf.org, "by way of Kwok Ho Chan " X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken: Thank you very much for your suggestions. We are looking into different ways of reducing the offered traffic load to the network during different detected levels of congestions. The approach we are taking is to separate the DETECTION from the (RE)ACTION. The DETECTION mechanism does not dictate the use of PREEMPTION, just the need to reduce the offered traffic load to the congested portions of the network. We called this Preemption Marking. May be this terminology cause confusion? The (RE)ACTION mechanism may or may not require PREEMPTION. And how this is done depends on the Deployment Model. draft-briscoe-tsvwg-cl-architecture-xx.txt is one of the Deployment Models we are working on. We are working on another Deployment Model where a tighter integration with applications may allow differing (RE)ACTIONs to be deployed based on the scenario of deployment. But the draft-chan-pcn-problem-statement-00.txt does give the example of the use of Preemption in the MLPP scenario. We should indicate in the Problem Statement draft the issue of reducing the offered traffic load to the congested portions of the network without the use of active call (session) preemption. I will add this to the Issues List document I have at: http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt With one issue (Issue A.4) under the Terminology Issues section (A). And one issue (Issue B.9) under the Environmental Issues sedtion (B). We are trying to not indicate solutions in the Problem Statement draft. Hence the (RE)ACTION of Preemption should be discussed in each of the Deployment Model drafts. There may be more than one solution. I will try to address these issues in the next version of the Problem Statement draft. We should also discuss the different requirements of the Preemption concept to assist better Deployment Model drafts. Thanks! -- Kwok -- At 02:35 PM 9/18/2006, ken carlberg wrote: >Part of your problem statement advocates the use of preemption of >flows as an option to maintain QoS of other existing flows when >severe congestion (possibly through node failure occurs). > >Back in April, I posted a review of draft-briscoe-tsvwg-cl- >architecture-02.txt and asked if an additional model or approach >could be taken in place of preemption. The specific comments can be >found at: > >(me) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06369.html. >(bob) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06396.html > >In that thread I pointed the authors to another work in progress as >one example that added the approach of engineered spare capacity >instead of preemption. (fyi, the latest version of the suggested >reading is: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft- >lefaucheur-emergency-rsvp-02.txt). And in looking at the outline of >draft-briscoe-tsvwg-cl-architecture-03.txt, it appears that the >authors are still just focusing on preemption. (quite >understandable, because what I suggested is significant and not >easily added in a single rev). > >The reason I ask if your effort can consider another model other than >preemption is that for certain deployments of VoIP in countries, like >the U.S. and Germany, non-man-in-the-loop preemption is not allowed. >This would seem to severely limit the actions you advocate during >times of severe congestion, albeit for one type of flow. > >So while there isn't necessarily a technical concern in using >preemption, unfortunately the realities of regulation and laws would >seem to encourage your proposed group to consider additional >alternatives. > >-ken > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 10:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgR6-0007Ck-US; Tue, 19 Sep 2006 10:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgR6-00070o-6c for pcn@ietf.org; Tue, 19 Sep 2006 10:18:56 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgI8-0006pi-TN for pcn@ietf.org; Tue, 19 Sep 2006 10:09:42 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8JE9Co27762; Tue, 19 Sep 2006 10:09:12 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 10:08:45 -0400 Message-Id: <6.2.5.6.0.20060919100148.03d9e198@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Sep 2006 10:08:45 -0400 To: Lucy Yong From: "Kwok-Ho Chan" Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter In-Reply-To: <000801c6d8de$a4316e00$a5087c0a@china.huawei.com> References: <6439282641581441A36F7F6F83ED2ED2CBF845@S4DE8PSAAFQ.mitte.t-com.de> <000801c6d8de$a4316e00$a5087c0a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Sep 2006 14:08:46.0017 (UTC) FILETIME=[1EFF8310:01C6DBF5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: pcn@ietf.org, "'Geib, Ruediger'" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lucy: I will add the following issue as part of the Problem Statement Open Issues List: Issue B.10: Considerations for the operation of PCN with different lower layers (below the IP layer). One of these is MPLS, but IP also operate over other link layers. Should the PCN BOF/WG work on resolving how PCN may operate over different link layers? This will be (in about 30 minutes) reflected in: http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt This is just the documentation of this issue so we can address this. Please continue this discussion on the list using Issue B.10 in subject line. Thank you very much! -- Kwok -- At 11:50 AM 9/15/2006, Lucy Yong wrote: >Hello Anna, > >I agree with Ruediger. I think PCN WG should tackle IP/MPLS together because >more and more high available applications use MPLS transport mechanism. IP >based marking may not effectively improve the application QoS. It would be >better to study both together. > >Best Regards, >Lucy > >-----Original Message----- >From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >Sent: Friday, September 15, 2006 2:03 AM >To: acharny@cisco.com >Cc: pcn@ietf.org >Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter > >Hello Anna, > >I'd think that issues related to ecn should continue to be >discussed within the tsvwg, no matter whether they are >related to mpls, ip or pcn. At the same time, drafts relevant >for PCN need to be discussed and announced to the PCN BOF/WG. >And mpls-ecn certainly is one of them. So my position is >discussion in both WGs. If it was of help in transforming >the pcn bof to the pcn WG, then I'd favour the PCN bof as >the home of draft-davie-ecn-mpls. > >Regards, > >Rudiger > >|-----Original Message----- >|From: Anna Charny (acharny) [mailto:acharny@cisco.com] >|Sent: Wednesday, September 13, 2006 8:37 AM >|To: YongLucy 73674; pcn@ietf.org >|Subject: RE: [PCN] PCN (Pre-Congestion Notification) draft charter >| >| >|Hi Lucy, >| >|Thank you for your post. Our initial assumption was that mpls-ecn work >|will continue within tsvwg (see draft-davie-ecn-mpls). I guess it is a >|question to the list and the working group chairs on whether >|this should be undertaken within the PCN WG (assuming it be formed). >|One argument for keeping it within tsvwg is that it has broader >|application than the proposed scope for the PCN BoF/new WG. But we >|are open to comments/suggestions on this. >| >|Anna >| >|-----Original Message----- >|From: YongLucy 73674 [mailto:lucyyong@huawei.com] >|Sent: Tuesday, September 12, 2006 11:16 PM >|To: pcn@ietf.org >|Subject: [PCN] PCN (Pre-Congestion Notification) draft charter >| >|Hello Every One, >| >|It is great to organize a BOF on PCN. This is a very important function >|for QoS. The draft charter covers many features from IP perspectives (I >|think). Should we also cover features from MPLS perspective? Something >|like PCN per LSP. How could PCN contain the sufficient informaton for >|edge router or CL to take an action on it? For multiple >|segements having congestion potential, could a consolidated PCN be >|propagated to the ingress or egress edge router? >|Should RSVP be used in PCN for a LSP or a bit is inserted in packets? >| >|Anyway this is a good starting point. >| >|Best Regards, >|Lucy Yong >| >| >|*************************************************************** >|********* >|******************* >| This email and its attachments contain confidential information from >|HUAWEI, which is intended only for the person or entity whose >|address is >|listed above. Any use of the information contained herein in any way >|(including, but not limited to, total or partial disclosure, >|reproduction, or dissemination) by persons other than the intended >|recipient(s) is prohibited. If you receive this e-mail in error, please >|notify the sender by phone or email immediately and delete it! >| >|*************************************************************** >|********* >|******************* >| >| >|_______________________________________________ >|PCN mailing list >|PCN@ietf.org >|https://www1.ietf.org/mailman/listinfo/pcn >| >|_______________________________________________ >|PCN mailing list >|PCN@ietf.org >|https://www1.ietf.org/mailman/listinfo/pcn >| > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 10:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgSi-0000OB-I2; Tue, 19 Sep 2006 10:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgSh-0000O6-DO for pcn@ietf.org; Tue, 19 Sep 2006 10:20:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgSg-0001FF-1w for pcn@ietf.org; Tue, 19 Sep 2006 10:20:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2006 10:20:34 -0400 X-IronPort-AV: i="4.09,185,1157342400"; d="scan'208"; a="103219679:sNHT41885252" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8JEKXE6002529; Tue, 19 Sep 2006 10:20:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8JEKWuS023841; Tue, 19 Sep 2006 10:20:33 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 10:20:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 10:20:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbb88C1rB/hYEKtTIOeGcuAzrsY9AAAUcWw From: "Anna Charny \(acharny\)" To: "ken carlberg" , "Jozef Babiarz" X-OriginalArrivalTime: 19 Sep 2006 14:20:32.0795 (UTC) FILETIME=[C44546B0:01C6DBF6] DKIM-Signature: a=rsa-sha1; q=dns; l=4046; t=1158675633; x=1159539633; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20draft-chan-pcn-problem-statement-00.txt |To:=22ken=20carlberg=22=20, =20=22Jozef=20Babiarz=22=20 ; X=v=3Dcisco.com=3B=20h=3DKpZNl53nkXcZrdGvFZTjMQLTl8M=3D; b=em08YmrybSyVEOljDgMNUvTLXsfK0veEzFOsE6xVGMQzHqMg42QFU8dqZcvjg9dOYVlyUluF hmZogcb20kEajz0PqryQae4VWew7YCHeICvqksb7MndFbg2MvstAOQwr; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ken, You say that =20 >maybe we have a different perspective of preemption. as I view it,=20 >preemption is removing *existing* state (circuit in the PSTN world) in=20 >favor of new state. =20 I guess that may be one thing that needs clarification. The way I view it (and I think the way draft-chan-pcn-problem-statement-00.txt and related docs view the issue) is that pre-emption should kick in when for whatever reason provisioning mechanisms fail there simply is not enough capacity to carry all calls. Setting aside the issue of precedence for the moment, the expectation is that the level of traffic needed to trigger premption is typicaly higher (perhaps substanially higher) than the level triggering to stop admission of new flows. That means that when preemption does get triggered, there would actually not really be any new state admitted. The degree of how far apart preemption and admission thresholds are is of course a mater of configuration, but I would expect that they would be sufficiently apart to ensure that you do not just toggle preempted and new flows. Of course if there are higher precedence calls, then one might expect that a higher precedence call may be established while lower precedence calls may need to be preempted? Perhaps this expectation should be made more transparent in the drafts? >In the US and some other countries, this is not=20 >allowed in the PSTN.=20 Just wanted to make sure I understand exactly what is not allowed. Are you saying that PSTN is not allowed to preempt a lower precedence call in order to establish a high recedence call? Or are you referring to the same precedence levels? Thanks, Anna=20 -----Original Message----- From: ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: Tuesday, September 19, 2006 9:58 AM To: Jozef Babiarz Cc: pcn@ietf.org Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt Joe, > 1./ The routers can signal pre-congestion level(s) via ECN bits in IP=20 > header to egress hosts and egress hosts really this information to=20 > ingress hosts to reduce their sending rate if they can (use a lower=20 > rate codec). However, this does not totally solve the problem. > 2./ The network is engineered so that there are sufficed spare=20 > resources available that should a router or link fail, that traffic is > rerouted on to the spare resources. Again this does not totally solve=20 > the problem because there maybe multiple failures, etc. understood. perhaps in the next iteration of the architecture document these can be more prominently placed/discussed so that it is seen as the same "level" as preemption. > Pre-emption is the last resort mechanism that removes real-time=20 > inelastic flows to bring that service class back into non-congested=20 > state. It will be interesting what guidelines/rules the FCC and other > regulatory bodies will provide/use should an operator be forced to=20 > preempt m number of voice flows in the IP network? My take is that it=20 > would be similar to what is done in TDM networks today when a TDM=20 > switch or trunk fails and calls are lost. well, within the context of the US PSTN, when such a condition exists and calls are lost, other existing calls on other switches are not preempted when the system tries to re-establish lost calls. When capacity has reached its limit, additional call attempts are blocked. maybe we have a different perspective of preemption. as I view it, preemption is removing *existing* state (circuit in the PSTN world) in favor of new state. In the US and some other countries, this is not allowed in the PSTN. I also don't claim to be an expert on the FCC, but recent rulings regarding 911 service for certain VoIP providers would seem that they intend to extend existing regulations from PSTN to certain VoIP providers. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 10:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgYB-0003Jq-L6; Tue, 19 Sep 2006 10:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgYA-0003Jj-El for pcn@ietf.org; Tue, 19 Sep 2006 10:26:14 -0400 Received: from hermes.hosts.co.uk ([85.233.160.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgY9-0001tt-19 for pcn@ietf.org; Tue, 19 Sep 2006 10:26:14 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by hermes.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1GPgXm-00022L-Ja; Tue, 19 Sep 2006 15:25:53 +0100 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCEB@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCEB@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A00DF2C-4781-4F1F-BEB3-3B298C230B5C@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 10:25:56 -0400 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, > Do we need to change the problem statement? I wouldn't change the draft at this time. just consider my comment at the upcoming BoF > Should we add near the end of Section 1.1, where flow pre-emption is > mentioned, a comment something like?: > > Such a flow pre-emption mechanism is complementary to the techniques > described in draft-lefaucheur-emergency-rsvp-02.txt [*]. Note that > sometimes flow pre-emption is not appropriate, for policy or > regulatory > reasons. For example, for certain deployments of VoIP in the U.S. and > Germany regulation does not allow non-man-in-the-loop pre-emption > [**]. I don't know if its necessary to point to a specific approach. i think simply presenting the basics (eg, paraphrasing) some of the key points written in the lefaucheur-emergency draft on engineering spare capacity would be helpful. > [*] is this ok? Do you see them as complementary mechanisms? My > reading > is that both could be appropriate, depending on the circumstances. > Also > that draft-lefaucheur-emergency-rsvp applies to 'normal' > circumstances, > whereas flow pre-emption is targeted at 'abnormal' circumstances eg > where several nodes have failed causing much less network capacity (so > re-routing has overloaded some links). well, I see the discussions in the appendix and its potential modes of operation/deployment of draft-lefaucheur-emergency-rsvp as being something constructive to your draft. the body of the lefaucheur draft has potential to be complimentary to your work in the same context as your related work on MPLS. I'm not sure that I see a difference in circumstances: my feeling is that both have their interest in abnormal conditions. What may be different are motivations. > [**] just to clarify what this means - pre-emption is only allowed > if a > human explicitly authorises the pre-emption of a particular flow; > automatic pre-emption by the network isn't allowed. This applies where > the end user is getting a PSTN service. yes, for the US and Germany (and some other countries). There are cases where a person contacts the human operator to interrupt or break a call (the man-in-the-loop action). But automated preemption through signaling is not allowed in many jurisdictions/governments. The one exception, to my understanding, is Japan which does allow a measure of preemption for 911-type calls. > I don't think we need to change the Draft Charter > http://standards.nortelnetworks.com/pcn/PCN_draft_charter_v00.txt > and the standards-track docs won't need to mention this issue. > But at least one deployment model draft should mention it, saying > it's a > complementary technique etc. > is this ok? or do you think there are interactions between the two > techniques that we need to explore, or something that needs to be > added > to the Charter? i think I covered these questions above. cheers, -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 10:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPghI-0002d7-8b; Tue, 19 Sep 2006 10:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPghG-0002XX-EP; Tue, 19 Sep 2006 10:35:38 -0400 Received: from hermes.hosts.co.uk ([85.233.160.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPghF-0002jN-69; Tue, 19 Sep 2006 10:35:38 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by hermes.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1GPggt-0001wq-NO; Tue, 19 Sep 2006 15:35:16 +0100 In-Reply-To: <6.2.5.6.0.20060919093100.03d9ebd8@nortel.com> References: <6.2.5.6.0.20060918102736.06188688@nortel.com> <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> <6.2.5.6.0.20060919093100.03d9ebd8@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 10:35:22 -0400 To: Kwok-Ho Chan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: pcn@ietf.org, "by way of Kwok Ho Chan " X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > We are looking into different ways of reducing the offered traffic > load to the network > during different detected levels of congestions. > > The approach we are taking is to separate the DETECTION from the > (RE)ACTION. cool. > The DETECTION mechanism does not dictate the use of PREEMPTION, > just the > need to reduce the offered traffic load to the congested portions > of the network. > We called this Preemption Marking. > May be this terminology cause confusion? yes, it is if there are other (re)actions other than preemption. maybe something generic like "Action Marking". any other term is fine so long as it doesn't direct me the reader into a single form of a solution. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 10:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh0J-0001rD-EA; Tue, 19 Sep 2006 10:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPh0I-0001qF-C5 for pcn@ietf.org; Tue, 19 Sep 2006 10:55:18 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPh07-0004r4-QU for pcn@ietf.org; Tue, 19 Sep 2006 10:55:09 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8JEmMG11168; Tue, 19 Sep 2006 10:48:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 10:54:15 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650C267D22@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbb86s6zIjr8mtFTLKkVEbRGVqvewAAaUdg From: "Jozef Babiarz" To: "ken carlberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken, There at least two types of preemption as, I see it. One is when that configured bandwidth for that service on the path is fully utilized and there is a need to admit additional higher precedence voice flow, so the network preempts a lower precedence voice flow to make room. This is similar to MLPP capability in TDM voice networks.=20 The second usage of preemption is to protect the service class when there are network failures (router and or link). In this case, I believe that the IP network provides additional capability of rerouting traffic quickly when a path fails versus just dropping the voice channels as is done in TDM when switch fails. When rerouting of voice flows on detection of failures, there maybe situations that the remaining working network links do not have enough capacity to forward all the voice flows and provide good QoS, therefore some voice flows may need to be preempted.=20 Finally, operators do have the option of just using admission control not supporting preemption in their network. =20 Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: Tuesday, September 19, 2006 9:58 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt Joe, > 1./ The routers can signal pre-congestion level(s) via ECN bits in IP > header to egress hosts and egress hosts really this information to > ingress hosts to reduce their sending rate if they can (use a lower =20 > rate > codec). However, this does not totally solve the problem. > 2./ The network is engineered so that there are sufficed spare =20 > resources > available that should a router or link fail, that traffic is =20 > rerouted on > to the spare resources. Again this does not totally solve the problem > because there maybe multiple failures, etc. understood. perhaps in the next iteration of the architecture =20 document these can be more prominently placed/discussed so that it is =20 seen as the same "level" as preemption. > Pre-emption is the last resort mechanism that removes real-time > inelastic flows to bring that service class back into non-congested > state. It will be interesting what guidelines/rules the FCC and other > regulatory bodies will provide/use should an operator be forced to > preempt m number of voice flows in the IP network? My take is that it > would be similar to what is done in TDM networks today when a TDM =20 > switch > or trunk fails and calls are lost. well, within the context of the US PSTN, when such a condition exists =20 and calls are lost, other existing calls on other switches are not =20 preempted when the system tries to re-establish lost calls. When =20 capacity has reached its limit, additional call attempts are blocked. maybe we have a different perspective of preemption. as I view it, =20 preemption is removing *existing* state (circuit in the PSTN world) =20 in favor of new state. In the US and some other countries, this is =20 not allowed in the PSTN. I also don't claim to be an expert on the =20 FCC, but recent rulings regarding 911 service for certain VoIP =20 providers would seem that they intend to extend existing regulations =20 from PSTN to certain VoIP providers. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 11:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhS4-0001Ek-VA; Tue, 19 Sep 2006 11:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhS3-0001Ee-RK for pcn@ietf.org; Tue, 19 Sep 2006 11:23:59 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhRy-0000Uh-UI for pcn@ietf.org; Tue, 19 Sep 2006 11:23:59 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 16:23:41 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Sep 2006 16:23:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Date: Tue, 19 Sep 2006 16:23:39 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCED@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <450FC491.5040509@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: Acbb1VgsfL4t/nNXTwWCFG3WLztLKQAHVNOQ From: To: , X-OriginalArrivalTime: 19 Sep 2006 15:23:40.0248 (UTC) FILETIME=[95C4BD80:01C6DBFF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, Thanks very much for your very detailed comments. Some follow-ups in-line. I'm not quite sure how much the draft will change as a result of the new PCN bof/wg docs - eg the problem statement will take out the goals/assumptions section. Hopefully the overall effect will be to make this draft smaller and more focussed.=20 Best wishes,=20 phil -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 19 September 2006 11:21 To: pcn@ietf.org Subject: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Hi all, I've read the draft http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 03.txt I find the proposed concept pretty good as I consider it a simple and technically feasible solution.=20 [phil] thanks! Here are my comments regarding the draft. 1) Abstract: Although I am working on this field for years, I haven't understood what the draft is about upon the first reading. Here is how I'd summarize the presented mechanism. This document describes a distributed, measurement-based, and resilient admission control for application in large DiffServ-based networks. All routers have a configured admission and pre-emption rate for their=20 adjacent links. They measure the admitted traffic they forward on each outgoing link and use a so-called pre-congestion notification (PCN) mechanism to mark packets that exceed the configured rates. The egress router measures the rates of non-labelled, admission-marked, and preemption-marked packets from each ingress, and notifies the respective ingress if it must not admit any further packets or that it must even pre-empt a certain rate of admitted flows. Per-flow admission states are kept at the edge routers only, while the PCN markers that are required for all routers focus on the aggregate traffic. The admission control is resilient with regard to the following two aspects: (1) the configured admission and preemption rates can be chosen in such a way that the reservations for admitted flows are not pre-empted if a foreseeable failure occurs and (2) that reservations can be torn down explicitly if a large failure occurs to preserve the quality of service of the remaining flows. [phil] thanks, will try & make the next version more understandable.=20 2) The summary is very long. As the terminology is explained only in 1.2, it is sometime hard to follow Section 1.1. It is sometimes unnecessarily unprecise and, therefore, hard to follow. I think this could be rewritten without increasing the length of Sections 1.1 and 1.2 such that they it provide more clarity even at the first reading. [phil] ok, will try & make the next version shorter & clearer. Think this will change anyway, eg because of the set of docs for PCN BoF/WG. 3) Terminology for "sustainable-aggregate-rate" is not clear. Suggestion: rate of non-preemption marked packets measured by an egress gateway for a specific ingress gateway; this is the supportable traffic rate between these gateways if the corresponding path is congested. [phil] ok. I don't think the phrase " if the corresponding path is congested" is needed? 4) Section 2.2: o Routing: a study regarding the accuracy of load balancing schemes can be found in [LoadBalancing-a] Ruediger Martin, Michael Menth, and Michael Hemmkeppler: "Accuracy and Dynamics of Hash-Based Load Balancing Algorithms for Multipath Internet Routing", IEEE Broadnets, San Jose, CA, USA, October 2006 http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth06p.pdf [LoadBalancing-b] Ruediger Martin, Michael Menth, and Michael Hemmkeppler: "Accuracy and Dynamics of Multi-Stage Load Balancing for Multipath Internet Routing", currently under submission http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub- 6.pdf Section 3 and 4: no comments, they look good and are well understandable. [phil] will follow them up, thanks 5) Section 5.1: o tunnel: what kind of tunnel? IP-in-IP tunneling from ingress gateway to egress gateway with the effect that all flows are forced by ECMP on the paths that is determined by the IPs of these tunnel endpoints? This is how understood tunneling later in 5.7.1. [phil] yes, that was the idea o probes: probe packets have the same address as the corresponding flow. Do they finally leave the CL-domain and reach the destination? This is unwanted extra traffic for this machine. [phil] this is a good point. The context at this point of the doc is 'how to dael with ECMP?'. I think in the general case the answer to your question is 'yes'. Another option is that the probe has a flag in the header (eg specific DSCP), to indicate it's a probe & which alerts the egress it's a probe - which it then consumes. But you have to be careful that the ecmp algorithm doesn't include the 'probe flag' field in its caslculation - eg I think some ecmp algorithms do include the dscp. 6) Section 5.2: Another potential solution: smart marking The meaning of preemption marked packets is: this is an excess packet and the rate of the corresponding CL-region-aggregate will be reduced in the future. Therefore, packets that are already preemption marked should not be counted at another router for the metering process which is done for preemption marking. This does not solve the problem in Figure 4, but it alleviates the problem in other constellations: IAR-b=3D1 @ +-----+ L1 +-----+ L2 |CPR=3D1| |CPR=3D2|@@@@ SAR-b=3D2/3 IAR-a=3D2 >####| R1 |####| R2 |#### SAR-a=3D1/2*2/3=3D1/3 +-----+ +-----+ These SARs lead in the end to a rate of 1 on link L2 although the configured-admission-rate (CAR) is 2. If already marked packets are not respected at R2 for the metering process for preemption marking, we get SAR-b=3D1 and SAR-a=3D1/2 which leads in the end to the fully used CAR on link L2. After I wrote this, I read the draft about the markers: http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt The suggested algorithm implements the preemption marker in fact in such a way that it respects only non-preemption-marked packets for the measurement process. This is a requirement which should also be mentioned in this draft. [phil] ok. 7) Section 5.5 Another potential solution: add the declared rate to the SAR at the ingress gateway as long as new flows send hardly any traffic. This information must be obtained from the corresponding policers which are also under the control of the ingress gateway. Or add it for an initial period of e.g. 10 s? [phil] not sure about this. would the ingress do both this adm ctrl on declared rate & adm ctrl based on the adm marking of draft-briscoe-tsvwg-cl-architecture? How long would your "initial period" be chosen? When it ends, what does the ingress gateway have to do? [worried about it having to remember state, failure modes etc] 8) Section 5.7.2 What does over-congested mean? [phil] typo for congested, I think 9) Section 5.7.4 Reminds me of RFC4127: Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering (and other models for that objective) [phil] yes, reminiscent. Also, the idea in [Songhurst] would mean that the amount of CL traffic that could be admitted depends on the amount of non-CL traffic present; this isn't true for [I think] for the Russian dolls model, and not true for the mechanism discussed in draft-briscoe-tsvwg-cl-architecture 10) Section 5.7.5 I haven't understood the last sentence of this section. Can it be rephrased? [phil] sure. The sentence is meant to provide guidance on what the adm marking algorithm should be like; it's saying that in Fig 3 in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt the slope should be steep.=20 11) Section 6.8 *NEW* Other Network Admission Control Approaches [phil] (this is in Section 6, 'Relationship to other QoS mechanisms'). Yes, can add something like this - thanks.=20 Link admission control (LAC) describes how admission control (AC) can be done on a single link and comprises, e.g., the calculation of effective bandwidths which may be the base for a parameter-based AC. In contrast, network AC (NAC) describes how AC can be done for a network and focuses on the locations from which data is gathered for the admission decision. Most approaches implement a link budget based NAC (LB NAC) where each link has a certain AC-budget. RSVP works according to that principle, but also the new concept admits additional flows as long as=20 each link on the new flow's path still has resources available. The border-to-border budget based NAC (BBB NAC) pre-configures an AC budget for all border-to-border relationships (=3DCL-region-aggregates) and if this capacity budget is exhausted, new flows are rejected. The TCA-based admission control which is associated with the DiffServ architecture implements an ingress budget based NAC (IB NAC). These basically different concepts have different flexibility and efficiency with regard to the use of link bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing the budgets in such a way that the network will not be congested after rerouting due to a failure. The efficiency of the approaches is different with and without such resilient requirements. [NAC-a] Michael Menth: "Efficient Admission Control and Routing in Resilient Communication Networks", PhD thesis, July 2004, http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Ment h04.pdf [NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and Karl Schrodi: "Resilient Network Admission Control", currently under submission. http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub- 3.pdf 12) Section 11.1 Paragraph "The ECN-Capable ... codepoint set." is hard to understand. Two sentences more explanation could maybe help. [phil] ok 13) Section 11.3 By running the EWMA whenever a new packet for a specific CL-region-aggregate arrives makes the aging process depending on the arrival rate of the traffic. As a consequence, there is the problem with the stale information. This can be done in a better way, e.g. by using the time-exponentially weighted moving average (TEWMA) [TEWMA]. [TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness of Rate Measurements", in proceedings of GI/ITG Conference on Measuring, Modelling and Evaluation of Computer and Communication Systems (MMB), Dresden, Germany, September 2004 http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf If the TEWMA seems too complex (it requires the calculation of an exponential function), a rate of the admission- or preemption-marked packets can be calculated based on a, e.g., 20 ms interval and used as input for a conventional EWMA. [phil] will read. What's not clear to me at this stage is whether we'll end up standardising a specific averaging algorithm, or saying something like "must average, but choice of algorithm is left open", or something else.=20 14) Some places in the document say that admission and preemption marking is done based on the rates of the packet AND some virtual queue size. This is misleading from my perspective. The objective is a) to admission-mark all packets of an CL-region-aggregate if the=20 configured admission rate ist exceeded and b) to preemption-mark only those packets exceeding the configured=20 preemption rate. The virtual queue is just a means to allow a tolerance against=20 short-time rate fluctuations like the "cell delay variation tolerance" or the "burst tolerance" in=20 ATM. More on this topic in an extra mail regarding draft-briscoe-tsvwg-cl-phb-02.txt [phil] yes, this is a bit misleading, please could you point out where this is said. It shouldn't say ' marking is done based on rate of packet AND virtual queue size'. I know sometimes instead of talking about the virtual queue, the draft [especially early on] uses a phrase like 'marking depends on the amount of traffic' - this was an attempt not to get in to a specific implementation like a virtual queue.=20 yes, you're right about the reason for the virtual queue (it's also so the operator is free to choose any configured-admission-rate they like). Probably should point out more explicitly? Look forward to your other email, thanks for the feedback! Best wishes, Michael --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 11:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhSW-0001oa-5m; Tue, 19 Sep 2006 11:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhSV-0001nJ-Dg for pcn@ietf.org; Tue, 19 Sep 2006 11:24:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhSU-0000bs-QG for pcn@ietf.org; Tue, 19 Sep 2006 11:24:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Sep 2006 08:24:26 -0700 X-IronPort-AV: i="4.09,186,1157353200"; d="scan'208"; a="42477846:sNHT168281790" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8JFOQOM028101; Tue, 19 Sep 2006 11:24:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8JFOPuK022072; Tue, 19 Sep 2006 11:24:26 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 11:24:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Date: Tue, 19 Sep 2006 11:23:34 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: Acbb1VSVUBC+bzv4Q9Kf60B78u9WfgAId60A From: "Anna Charny \(acharny\)" To: , X-OriginalArrivalTime: 19 Sep 2006 15:24:25.0150 (UTC) FILETIME=[B0883DE0:01C6DBFF] DKIM-Signature: a=rsa-sha1; q=dns; l=13086; t=1158679466; x=1159543466; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Feedback=20to=20draft-briscoe-tsvwg-cl-architecture-03.t xt |To:,=20; X=v=3Dcisco.com=3B=20h=3Dne4P4PDOL13KHUCkWxgmEoqfbiw=3D; b=FOLAccESLkDQE3gqfJoQI/YXSK8uV2e4sAtoGeT8IvparHEoHs5Vq6NZqqNG+obgYawOxjcP yXTFobBfDOPUsbi8v2KqskZlkIBBuSZ4olZ6rqFNgZ0+wRPL/4uyUUaq; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, Thanks for the feedback. Please see a couple of comments below (marked [Anna]). -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Tuesday, September 19, 2006 6:21 AM To: pcn@ietf.org Subject: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Hi all, I've read the draft http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 03.txt I find the proposed concept pretty good as I consider it a simple and technically feasible solution. Here are my comments regarding the draft. 1) Abstract: Although I am working on this field for years, I haven't understood what the draft is about upon the first reading. Here is how I'd summarize the presented mechanism. This document describes a distributed, measurement-based, and resilient admission control for application in large DiffServ-based networks. All routers have a configured admission and pre-emption rate for their adjacent links. They measure the admitted traffic they forward on each outgoing link and use a so-called pre-congestion notification (PCN) mechanism to mark packets that exceed the configured rates. The egress router measures the rates of non-labelled, admission-marked, and preemption-marked packets from each ingress,=20 [Anna] just a clarification here: in fact the mechanisms for admission and preemption that were currently discussed in http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl- architecture-03.txt differ in what they look at at the egress - for cac it is the admission-marked packets that are being measured, while for preemption those that are not preempton marked.=20 and notifies the respective ingress if it must not admit any further packets or that it must even pre-empt a certain rate of admitted flows. Per-flow admission states are kept at the edge routers only, while the PCN markers that are required for all routers focus on the aggregate traffic. The admission control is resilient with regard to the following two aspects: (1) the configured admission and preemption rates can be chosen in such a way that the reservations for admitted flows are not pre-empted if a foreseeable failure occurs and (2) that reservations can be torn down explicitly if a large failure occurs to preserve the quality of service of the remaining flows. 2) The summary is very long. As the terminology is explained only in 1.2, it is sometime hard to follow Section 1.1. It is sometimes unnecessarily unprecise and, therefore, hard to follow. I think this could be rewritten without increasing the length of Sections 1.1 and 1.2 such that they it provide more clarity even at the first reading. [Anna] Will try to clean up/shorten the summary.=20 3) Terminology for "sustainable-aggregate-rate" is not clear. Suggestion: rate of non-preemption marked packets measured by an egress gateway for a specific ingress gateway; this is the supportable traffic rate between these gateways if the corresponding path is congested. [Anna] Thanks - will consider making it clearer 4) Section 2.2: o Routing: a study regarding the accuracy of load balancing schemes can be found in [LoadBalancing-a] Ruediger Martin, Michael Menth, and Michael Hemmkeppler: "Accuracy and Dynamics of Hash-Based Load Balancing Algorithms for Multipath Internet Routing", IEEE Broadnets, San Jose, CA, USA, October 2006 http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth06p.pdf [LoadBalancing-b] Ruediger Martin, Michael Menth, and Michael Hemmkeppler: "Accuracy and Dynamics of Multi-Stage Load Balancing for Multipath Internet Routing", currently under submission http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub- 6.pdf [Anna] In general load-balancing/ECMP issues are on our open issues list. Understanding accuracy of load-balancing is clearly of issues and approaches to deal with these issues tha have been discussed but on which consensus is yet to be reached. Seems like a good thing for the BoF/WG to address? Section 3 and 4: no comments, they look good and are well understandable. 5) Section 5.1: o tunnel: what kind of tunnel? IP-in-IP tunneling from ingress gateway to egress gateway with the effect that all flows are forced by ECMP on the paths that is determined by the IPs of these tunnel endpoints? This is how understood tunneling later in 5.7.1. o probes: probe packets have the same address as the corresponding flow. Do they finally leave the CL-domain and reach the destination? This is unwanted extra traffic for this machine. [Anna]these are but some possibilities. Again these are issue left open and are subject to further work/discussion 6) Section 5.2: Another potential solution: smart marking The meaning of preemption marked packets is: this is an excess packet and the rate of the corresponding CL-region-aggregate will be reduced in the future. Therefore, packets that are already preemption marked should not be counted at another router for the metering process which is done for preemption marking. This does not solve the problem in Figure 4, but it alleviates the problem in other constellations: IAR-b=3D1 @ +-----+ L1 +-----+ L2 |CPR=3D1| |CPR=3D2|@@@@ SAR-b=3D2/3 IAR-a=3D2 >####| R1 |####| R2 |#### SAR-a=3D1/2*2/3=3D1/3 +-----+ +-----+ These SARs lead in the end to a rate of 1 on link L2 although the configured-admission-rate (CAR) is 2. If already marked packets are not respected at R2 for the metering process for preemption marking, we get SAR-b=3D1 and SAR-a=3D1/2 which = leads in the end to the fully used CAR on link L2. After I wrote this, I read the draft about the markers: http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt The suggested algorithm implements the preemption marker in fact in such a way that it respects only non-preemption-marked packets for the measurement process. This is a requirement which should also be mentioned in this draft. [Anna] I believe that it is understood in the approaches that were considered for preemption that router meters the packet aggregates which have not already been preemption-marked. Need to go through various drafts to make sure this is clear. But again, one of the issues her is whether in fact there is consensus that this is a behaviour that is a MUST (and hence needs to be standardized) or whether this is just a good thing to have (my personal view here is that it does need to be standardized, but this is again an issue to reach consensus on). 7) Section 5.5 Another potential solution: add the declared rate to the SAR at the ingress gateway as long as new flows send hardly any traffic. This information must be obtained from the corresponding policers which are also under the control of the ingress gateway. Or add it for an initial period of e.g. 10 s? [Anna]Just to understand what you mean: this is a proposal to solve which aspect of the problem? 8) Section 5.7.2 What does over-congested mean? [Anna] Need to clarify. Means "very congested" :-) that is being above the chosen theshold, but need to look in detail and make the wording clear. 9) Section 5.7.4 Reminds me of RFC4127: Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering (and other models for that objective) [Anna] Not sure what point you are trying to make? 10) Section 5.7.5 I haven't understood the last sentence of this section. Can it be rephrased? [Anna] - thanks - will look into that and make sure it is clear 11) Section 6.8 *NEW* Other Network Admission Control Approaches Link admission control (LAC) describes how admission control (AC) can be done on a single link and comprises, e.g., the calculation of effective bandwidths which may be the base for a parameter-based AC. In contrast, network AC (NAC) describes how AC can be done for a network and focuses on the locations from which data is gathered for the admission decision. Most approaches implement a link budget based NAC (LB NAC) where each link has a certain AC-budget. RSVP works according to that principle, but also the new concept admits additional flows as long as each link on the new flow's path still has resources available. The border-to-border budget based NAC (BBB NAC) pre-configures an AC budget for all border-to- border relationships (=3DCL-region-aggregates) and if this capacity = budget is exhausted, new flows are rejected. The TCA-based admission control=20 which is associated with the DiffServ architecture implements an ingress budget based NAC (IB NAC). These basically different concepts have=20 different flexibility and efficiency with regard to the use of link=20 bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing the budgets in such a way that the network will not be congested after=20 rerouting due to a failure. The efficiency of the approaches is different with and without such resilient requirements. [NAC-a] Michael Menth: "Efficient Admission Control and Routing in Resilient Communication Networks", PhD thesis, July 2004, http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Ment h04.pdf [NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and Karl Schrodi: "Resilient Network Admission Control", currently under submission. http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub- 3.pdf [Anna] Thanks for pointing out this work. We have had some=20 experience in estimating bandwidth requirements of mechanisms=20 similar to the ones you propose in the above paper, and found that=20 the bandwidth requirements needed for resiliency depend quite=20 dramatically on the assumption on which failures one protects=20 against (just link or node, or shared risk link groups (SRLGs), and=20 are also rather topology dependent. We found that for some real networks capacity requirements nneeded to provide resiliency to=20 local failures in the manner you disuss in the above paper is quite=20 high. Some of the refereces in various pcn drafts also point to similar conclusions albeit the circumstances are slighly different=20 that those you consider. This sometimes extensive capacity needed =09 for resiliency seems in fact to motivate a lot of the pcn work, =09 which tries to address the "normal" operating conditions and =09 protect against unexpected (and/or expensive to protect otherwise) failures in a graceful manner.=20 12) Section 11.1 Paragraph "The ECN-Capable ... codepoint set." is hard to understand. Two sentences more explanation could maybe help. =20 [Anna] thanks, will do. 13) Section 11.3 By running the EWMA whenever a new packet for a specific CL-region-aggregate arrives makes the aging process depending on the arrival rate of the traffic. As a consequence, there is the problem with the stale information. This can be done in a better way, e.g. by using the time-exponentially weighted moving average (TEWMA) [TEWMA]. [TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness of Rate Measurements", in proceedings of GI/ITG Conference on Measuring, Modelling and Evaluation of Computer and Communication Systems (MMB), Dresden, Germany, September 2004 http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf If the TEWMA seems too complex (it requires the calculation of an exponential function), a rate of the admission- or preemption-marked packets can be calculated based on a, e.g., 20 ms interval and used as input for a conventional EWMA. [Anna] Thanks - will look into the reference. Again, from the standartisation point one needs to decide how much detail does one=20 have to standardize and in fact at the moment the question of=20 whether anything that the edges do must be standardized at all is an open question. This would be something the BoF/WG would adress I=20 presume (assuming of course the WG is created) 14) Some places in the document say that admission and preemption marking is done based on the rates of the packet AND some virtual queue size. This is misleading from my perspective. The objective is a) to admission-mark all packets of an CL-region-aggregate if the configured admission rate ist exceeded and b) to preemption-mark only those packets exceeding the configured preemption rate. The virtual queue is just a means to allow a tolerance against short-time rate fluctuations like the "cell delay variation tolerance" or the "burst tolerance" in ATM. More on this topic in an extra mail regarding draft-briscoe-tsvwg-cl-phb-02.txt [Anna] Thanks - will clean up to make sure it is clearer.=20 Best regards, Anna _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 11:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhUQ-0002xX-1d; Tue, 19 Sep 2006 11:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPhUO-0002xS-Vw for pcn@ietf.org; Tue, 19 Sep 2006 11:26:24 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPhUM-0000q3-KH for pcn@ietf.org; Tue, 19 Sep 2006 11:26:24 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8JFQJo15268; Tue, 19 Sep 2006 11:26:19 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 11:26:08 -0400 Message-Id: <6.2.5.6.0.20060919112217.03de4e50@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Sep 2006 11:26:08 -0400 To: ken carlberg From: "Kwok-Ho Chan" Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt In-Reply-To: References: <6.2.5.6.0.20060918102736.06188688@nortel.com> <52A41712-0CCB-4064-B6E8-56EAD386751B@g11.org.uk> <6.2.5.6.0.20060919093100.03d9ebd8@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Sep 2006 15:26:08.0788 (UTC) FILETIME=[EE4E2540:01C6DBFF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Thanks! Please see the updated issues list (with Issues A.4 and B.9) at: http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt It seems you are agreeing with the approach we are taking. But we still need to work out some of the details. -- Kwok -- At 10:35 AM 9/19/2006, ken carlberg wrote: >>We are looking into different ways of reducing the offered traffic >>load to the network >>during different detected levels of congestions. >> >>The approach we are taking is to separate the DETECTION from the >>(RE)ACTION. > >cool. > >>The DETECTION mechanism does not dictate the use of PREEMPTION, >>just the >>need to reduce the offered traffic load to the congested portions >>of the network. >>We called this Preemption Marking. >>May be this terminology cause confusion? > >yes, it is if there are other (re)actions other than preemption. >maybe something generic like "Action Marking". any other term is >fine so long as it doesn't direct me the reader into a single form of >a solution. > >-ken > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 12:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiSJ-0007Oe-R8; Tue, 19 Sep 2006 12:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiEz-0001JC-Jh for pcn@ietf.org; Tue, 19 Sep 2006 12:14:33 -0400 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPiEy-00070K-4H for pcn@ietf.org; Tue, 19 Sep 2006 12:14:33 -0400 Received: from c-69-250-216-138.hsd1.md.comcast.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 19 Sep 2006 17:14:07 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 12:13:59 -0400 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Tue, 19 Sep 2006 12:28:18 -0400 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Anna, >> maybe we have a different perspective of preemption. as I view it, >> preemption is removing *existing* state (circuit in the PSTN >> world) in >> favor of new state. > > I guess that may be one thing that needs clarification. The way I > view > it (and I think the way draft-chan-pcn-problem-statement-00.txt and > related docs view the issue) is that pre-emption should kick in > when for > whatever reason provisioning mechanisms fail there simply is not > enough > capacity to carry all calls. Setting aside the issue of precedence > for > the moment, the expectation is that the level of traffic needed to > trigger premption is typicaly higher (perhaps substanially higher) > than > the level triggering to stop admission of new flows. That means that > when preemption does get triggered, there would actually not really be > any new state admitted. I'm sorry, but with that last sentence you lost me :-)...I kind of understood some of the things you were saying, but there were too many things you left out (why does one have an admission control at level X and a preemption level at X+N?, are you implying that the edge is keeping track of the flows it rejects?....that would seem quite granular in keeping measurements). I'm not sure its necessary to clarify the above. Its probably just best that we agree that future work should include a more detailed discussion of what is preemption in the context of your architecture. > The degree of how far apart preemption and > admission thresholds are is of course a mater of configuration, but I > would expect that they would be sufficiently apart to ensure that > you do > not just toggle preempted and new flows. Of course if there are higher > precedence calls, then one might expect that a higher precedence call > may be established while lower precedence calls may need to be > preempted? > > Perhaps this expectation should be made more transparent in the > drafts? > >> In the US and some other countries, this is not >> allowed in the PSTN. > > Just wanted to make sure I understand exactly what is not allowed. > Are > you saying that PSTN is not allowed to preempt a lower precedence call > in order to establish a high recedence call? Or are you referring to > the same precedence levels? as an example, in the US PSTN, all calls from the general public are treated with the same level of precedence. the exception are systems like GETS, but they simply increase the probability of call completion -- they do not use preemption. private systems based on MLPP, like Autovon in the DoD and NATO, do allow different levels of priority and subsequent preemption if so needed. rfc-4190 and rfc-4542 provide background on these systems/services along with discussion in the context of IP (since this is the IETF :-) just to recap. I just wanted to point out that there are jurisdictions that do not allow preemption for voice communications used by the general public -- this definitely applies for a number of PSTNs, and I'm sure it will trickle down to certain deployments of VoIP. Hence, I would recommend that the group consider other (re) actions other than preemption....which from the feedback of my original note, seems will be done. regards, -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 13:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjGI-0005jF-Uw; Tue, 19 Sep 2006 13:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPjGH-0005j3-CF for pcn@ietf.org; Tue, 19 Sep 2006 13:19:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPjGF-0001GO-O5 for pcn@ietf.org; Tue, 19 Sep 2006 13:19:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 19 Sep 2006 10:19:55 -0700 X-IronPort-AV: i="4.09,186,1157353200"; d="scan'208"; a="322890285:sNHT50471224" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8JHJtxx012847; Tue, 19 Sep 2006 10:19:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8JHJs1G028253; Tue, 19 Sep 2006 10:19:55 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 13:19:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 19 Sep 2006 13:19:16 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: AcbcCNA0OXNVr6lNTfO72C1jsndUvgAAD/4g From: "Anna Charny \(acharny\)" To: "ken carlberg" , X-OriginalArrivalTime: 19 Sep 2006 17:19:54.0164 (UTC) FILETIME=[D28BDF40:01C6DC0F] DKIM-Signature: a=rsa-sha1; q=dns; l=5751; t=1158686395; x=1159550395; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20draft-chan-pcn-problem-statement-00.txt; X=v=3Dcisco.com=3B=20h=3DKpZNl53nkXcZrdGvFZTjMQLTl8M=3D; b=hqBE7xKUHFaexcuASj59a8wKdTJZJKGK7H8i19+Rw+fQABtmLROvW6TLSxEXff10onuq9WFV FmJSCmJjEcoZ5hpI+6v0VoLI+r9C/oenHAbqd0G5G/87J7+4OW/K0yBj; Authentication-Results: sj-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ken, First, thanks for the explanation. I think that we are in agreement that pre-emtion is not an obligatory mechanism, and hence if there are circumstances when I should not be iused for regulatory reasons then one should not use it in those cases. So we should make sure we make this clear, and we should definitely discuss and understand regulatory limitations to the use of preemption. On your quetsion on why one may wantto have preemption at a higher level than admission and whether that means additional granularity at the edges (the answer to the latter is no). One way to look at it is as follows. One could assume that in many (most?) cases, voice traffic is using scheduling priority at the router, and that the provisioned amount of this kind of traffic is limited to some amount (e.g. 50% of the link spped as was widely assumed in the DiffServ EF work). In case of a failure or multiple failure, unless the network is fully provisioned to accommodate it, the total amount of traffic on a some link where traffic is rerouted may be over the link speed (this can easily happen in the case of a node failure if indeed all links are 50% utilized under normal conditions). So the question then is whether one wants to limit the traffic on the new link to the same 50% limit (which in the case of preemption would mean prempting at least 50% of the flows on the new link), or whether perhaps a milder reaction is appropriate. One can conceivably decide to not preempt any voice flows at all unless ther is more than, say 80% voice calls on the link). Obviously this is a configurable value. This is consistent with the view that preemption should only be used when things realy go bad, and in case of mild overloads of configured/provisioned "normal" loads one may not want to use preemption at all. Note that the state needed at the edge does not depend on the level of preemption/cac - it is just setting of the cac/preemption threshold at the internal router. Hope that makes it clearer? Anna=20 -----Original Message----- From: ken carlberg [mailto:k.carlberg@cs.ucl.ac.uk]=20 Sent: Tuesday, September 19, 2006 12:14 PM To: pcn@ietf.org Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt Anna, >> maybe we have a different perspective of preemption. as I view it,=20 >> preemption is removing *existing* state (circuit in the PSTN >> world) in >> favor of new state. > > I guess that may be one thing that needs clarification. The way I=20 > view it (and I think the way draft-chan-pcn-problem-statement-00.txt=20 > and related docs view the issue) is that pre-emption should kick in=20 > when for whatever reason provisioning mechanisms fail there simply is=20 > not enough capacity to carry all calls. Setting aside the issue of=20 > precedence for the moment, the expectation is that the level of=20 > traffic needed to trigger premption is typicaly higher (perhaps=20 > substanially higher) than the level triggering to stop admission of=20 > new flows. That means that when preemption does get triggered, there=20 > would actually not really be any new state admitted. I'm sorry, but with that last sentence you lost me :-)...I kind of understood some of the things you were saying, but there were too many things you left out (why does one have an admission control at level X and a preemption level at X+N?, are you implying that the edge is keeping track of the flows it rejects?....that would seem quite granular in keeping measurements). I'm not sure its necessary to clarify the above. Its probably just best that we agree that future work should include a more detailed discussion of what is preemption in the context of your architecture. > The degree of how far apart preemption and admission thresholds are is > of course a mater of configuration, but I would expect that they would > be sufficiently apart to ensure that you do not just toggle preempted=20 > and new flows. Of course if there are higher precedence calls, then=20 > one might expect that a higher precedence call may be established=20 > while lower precedence calls may need to be preempted? > > Perhaps this expectation should be made more transparent in the=20 > drafts? > >> In the US and some other countries, this is not allowed in the PSTN. > > Just wanted to make sure I understand exactly what is not allowed. =20 > Are > you saying that PSTN is not allowed to preempt a lower precedence call > in order to establish a high recedence call? Or are you referring to=20 > the same precedence levels? as an example, in the US PSTN, all calls from the general public are treated with the same level of precedence. the exception are systems like GETS, but they simply increase the probability of call completion -- they do not use preemption. private systems based on MLPP, like Autovon in the DoD and NATO, do allow different levels of priority and subsequent preemption if so needed. rfc-4190 and rfc-4542 provide background on these systems/services along with discussion in the context of IP (since this is the IETF :-) just to recap. I just wanted to point out that there are jurisdictions that do not allow preemption for voice communications used by the general public -- this definitely applies for a number of PSTNs, and I'm sure it will trickle down to certain deployments of VoIP. Hence, I would recommend that the group consider other (re) actions other than preemption....which from the feedback of my original note, seems will be done. regards, -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 19 17:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPn9O-0000WN-8H; Tue, 19 Sep 2006 17:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPn9N-0000Sg-Hh for pcn@ietf.org; Tue, 19 Sep 2006 17:29:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPn7R-0003IB-0U for pcn@ietf.org; Tue, 19 Sep 2006 17:27:06 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8JLQmo20785; Tue, 19 Sep 2006 17:26:49 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 17:26:22 -0400 Message-Id: <6.2.5.6.0.20060919170712.03cfd1a8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Sep 2006 17:26:22 -0400 To: ken carlberg From: "Kwok-Ho Chan" Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Sep 2006 21:26:22.0870 (UTC) FILETIME=[414D5360:01C6DC32] X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken: Thank you for handling so many of our replies at the same time. :) YES, on your point of: >just to recap. I just wanted to point out that there are >jurisdictions that do not allow preemption for voice communications >used by the general public -- this definitely applies for a number of >PSTNs, and I'm sure it will trickle down to certain deployments of >VoIP. Hence, I would recommend that the group consider other (re) >actions other than preemption....which from the feedback of my >original note, seems will be done. We are using the Problem-Statement draft to put out an initial version of what we are thinking, as this is still work in progress, there definitely are area we may have missed. Thank you for pointing out at least one of them. I will write some additional text for -01 version of the Problem Statement draft to try and describe the problem you have indicated (but I will try NOT to indicate any solution in the Problem Statement draft). And we will try to have some text in at least some of our Deployment Model drafts to see if there are good solutions to the problem you indicated. There may be more than one solution as there may be more than one Deployment Model. Please Notice I have changed the subject of the E-Mail thread for issue tracking purpose. Please use this E-Mail Subject for continuing this discussion. Now I have additional questions concerning the use of Preemption for handling Emergency Services. Will Preemption be allowed for Emergency Services? Does some of the jurisdiction you have indicated want to use a separate network for Emergency Services purpose? Will combining Emergency Services with the normal VoIP calls/sessions be a good Problem Statement that we can add to our Problem Statement draft? I am concentrating on Problem Statement instead of Solutions for now because we want to get the Problem Statement cleared away first for the BOF purpose. Thanks! -- Kwok -- At 12:13 PM 9/19/2006, ken carlberg wrote: >Anna, > >>>maybe we have a different perspective of preemption. as I view it, >>>preemption is removing *existing* state (circuit in the PSTN >>>world) in >>>favor of new state. >> >>I guess that may be one thing that needs clarification. The way I >>view >>it (and I think the way draft-chan-pcn-problem-statement-00.txt and >>related docs view the issue) is that pre-emption should kick in >>when for >>whatever reason provisioning mechanisms fail there simply is not >>enough >>capacity to carry all calls. Setting aside the issue of precedence >>for >>the moment, the expectation is that the level of traffic needed to >>trigger premption is typicaly higher (perhaps substanially higher) >>than >>the level triggering to stop admission of new flows. That means that >>when preemption does get triggered, there would actually not really be >>any new state admitted. > >I'm sorry, but with that last sentence you lost me :-)...I kind of >understood some of the things you were saying, but there were too >many things you left out (why does one have an admission control at >level X and a preemption level at X+N?, are you implying that the >edge is keeping track of the flows it rejects?....that would seem >quite granular in keeping measurements). > >I'm not sure its necessary to clarify the above. Its probably just >best that we agree that future work should include a more detailed >discussion of what is preemption in the context of your architecture. > >>The degree of how far apart preemption and >>admission thresholds are is of course a mater of configuration, but I >>would expect that they would be sufficiently apart to ensure that >>you do >>not just toggle preempted and new flows. Of course if there are higher >>precedence calls, then one might expect that a higher precedence call >>may be established while lower precedence calls may need to be >>preempted? >> >>Perhaps this expectation should be made more transparent in the >>drafts? >> >>>In the US and some other countries, this is not >>>allowed in the PSTN. >> >>Just wanted to make sure I understand exactly what is not allowed. >>Are >>you saying that PSTN is not allowed to preempt a lower precedence call >>in order to establish a high recedence call? Or are you referring to >>the same precedence levels? > >as an example, in the US PSTN, all calls from the general public are >treated with the same level of precedence. the exception are systems >like GETS, but they simply increase the probability of call >completion -- they do not use preemption. private systems based on >MLPP, like Autovon in the DoD and NATO, do allow different levels of >priority and subsequent preemption if so needed. rfc-4190 and >rfc-4542 provide background on these systems/services along with >discussion in the context of IP (since this is the IETF :-) > >just to recap. I just wanted to point out that there are >jurisdictions that do not allow preemption for voice communications >used by the general public -- this definitely applies for a number of >PSTNs, and I'm sure it will trickle down to certain deployments of >VoIP. Hence, I would recommend that the group consider other (re) >actions other than preemption....which from the feedback of my >original note, seems will be done. > >regards, > >-ken > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 02:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvoF-0004ZX-9o; Wed, 20 Sep 2006 02:43:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvoE-0004ZS-4n for pcn@ietf.org; Wed, 20 Sep 2006 02:43:50 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPvoA-0003vq-Bh for pcn@ietf.org; Wed, 20 Sep 2006 02:43:50 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 851801405; Wed, 20 Sep 2006 08:43:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 78F481287; Wed, 20 Sep 2006 08:43:41 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 55EF8119A; Wed, 20 Sep 2006 08:43:41 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8K6hfs15478; Wed, 20 Sep 2006 08:43:41 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 9FFDA6F58E; Wed, 20 Sep 2006 08:42:32 +0200 (CEST) Message-ID: <4510E339.6030607@informatik.uni-wuerzburg.de> Date: Wed, 20 Sep 2006 08:44:09 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Anna, > After I wrote this, I read the draft about the markers: > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt > The suggested algorithm implements the preemption marker in fact in such > a way that it respects only non-preemption-marked packets for the > measurement process. This is a requirement which should also be > mentioned in this draft. > > [Anna] I believe that it is understood in the approaches that > were considered for preemption that router meters the packet > aggregates which have not already been preemption-marked. Need to > go through various drafts to make sure this is clear. But again, > one of the issues her is whether in fact there is consensus that > this is a behaviour that is a MUST (and hence needs to be > standardized) or whether this is just a good thing to have (my > personal view here is that it does need to be standardized, but this > is again an issue to reach consensus on). > > > 7) Section 5.5 > > Another potential solution: add the declared rate to the SAR at the > ingress gateway as long as new flows send hardly any traffic. This > information must be obtained from the corresponding policers which are > also under the control of the ingress gateway. Or add it for an initial > period of e.g. 10 s? > > [Anna]Just to understand what you mean: this is a proposal to > solve which aspect of the problem? > This proposal tries to cope with flash crowds, i.e. with many almost simultaneous admission requests. The problem is that the AC can respect the impact of newly admitted flows only after some time when their typical sent rate influences the admission marking in the routers. I think that there should be a mechanism to find out the minimum rate between two border routers that is still admissible. The sum of the overall declared rates of new flows should not consume more than this rate. A flow is new as long as its typical rate has not yet hat an impact on the packet marking, and to keep things simple, for an initial time of maybe 10 s. > 9) Section 5.7.4 > Reminds me of RFC4127: Russian Dolls Bandwidth Constraints Model for > Diffserv-aware MPLS Traffic Engineering (and other models for that > objective) > [Anna] Not sure what point you are trying to make? > I'd like to say that some of the nomenclature in this context can maybe be reused. > > 11) Section 6.8 *NEW* > Other Network Admission Control Approaches Link admission control (LAC) > describes how admission control (AC) can be done on a single link and > comprises, e.g., the calculation of effective bandwidths which may be > the base for a parameter-based AC. > In contrast, network AC (NAC) describes how AC can be done for a network > and focuses on the locations from which data is gathered for the > admission decision. Most approaches implement a link budget based NAC > (LB NAC) where each link has a certain AC-budget. RSVP works according > to that principle, > but also the new concept admits additional flows as long as each link > on > the new flow's path still has resources available. The border-to-border > > budget based NAC (BBB NAC) pre-configures an AC budget for all > border-to- > border relationships (=CL-region-aggregates) and if this capacity budget > is exhausted, new flows are rejected. The TCA-based admission control > which is associated with the DiffServ architecture implements an ingress > > budget based NAC (IB NAC). These basically different concepts have > different flexibility and efficiency with regard to the use of link > bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing the > budgets in such a way that the network will not be congested after > rerouting due to a failure. The efficiency of the approaches is > different > with and without such resilient requirements. > > [NAC-a] Michael Menth: "Efficient Admission Control and Routing in > Resilient Communication Networks", PhD thesis, July 2004, > http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Ment > h04.pdf > > > [NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and Karl > Schrodi: "Resilient Network Admission Control", currently under > submission. > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub- > 3.pdf > > [Anna] Thanks for pointing out this work. We have had some > experience in estimating bandwidth requirements of > mechanisms > similar to the ones you propose in the above paper, and found > that > the bandwidth requirements needed for resiliency depend quite > dramatically on the assumption on which failures one protects > against (just link or node, or shared risk link groups (SRLGs), > and > are also rather topology dependent. We found that for some real > > networks capacity requirements nneeded to provide resiliency to > local failures in the manner you disuss in the above paper is > quite > high. Some of the refereces in various pcn drafts also point to > > similar conclusions albeit the circumstances are slighly > different > that those you consider. This is right. The required (backup) capacity depends on many aspects: the routing, the traffic matrix, the topology, and probably many others. However, it also depends on the network admission control (NAC) approach that is used and the PCN concept implements a specific NAC approach. Therefore, it is of interest how its efficiency relates, e.g., to the one of the TCA approach. And this is done in my PhD thesis and the cited paper. Apart from the TCA approach, there are several other basic NAC approaches that are compared. > This sometimes extensive > capacity needed > for resiliency seems in fact to motivate a lot of the pcn > work, > which tries to address the "normal" operating conditions and > protect against unexpected (and/or expensive to protect > otherwise) > failures in a graceful manner. Hm? - Anyway. I think [IyBh03] provides the best motivation for resilient admission control as it points out that "link overload is rare, and when it occurs, 80% of the time it is caused due to link failures" (see abstract). Conventional AC does not consider a safety margin to accommodate redirected traffic. Therefore, failures will still lead to overload and therefore conventional AC mostly doesn't work when it is needed. This concludes that AC must be resilient to failures, anything else does not make sense. [IyBh03] S. Iyer, S. Bhattacharyya, N. Taft, and C. Diot: "An Approach to Alleviate Link Overload as Observed on an IP Backbone", in proceedings of IEEE Infocom, San Francisco, CA, USA, April 2003 http://klamath.stanford.edu/~sundaes/Papers/infocom2003.pdf > > > > 13) Section 11.3 > By running the EWMA whenever a new packet for a specific > CL-region-aggregate arrives makes the aging process depending on the > arrival rate of the traffic. As a consequence, there is the problem with > the stale information. This can be done in a better way, e.g. > by using the time-exponentially weighted moving average (TEWMA) [TEWMA]. > > [TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness of > Rate Measurements", in proceedings of GI/ITG Conference on Measuring, > Modelling and Evaluation of Computer and Communication Systems (MMB), > Dresden, Germany, September 2004 > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf > > If the TEWMA seems too complex (it requires the calculation of an > exponential function), a rate of the admission- or preemption-marked > packets can be calculated based on a, e.g., 20 ms interval and used as > input for a conventional EWMA. > > [Anna] Thanks - will look into the reference. Again, from the > standartisation point one needs to decide how much detail does > one > have to standardize and in fact at the moment the question of > whether anything that the edges do must be standardized at all > is an > open question. This would be something the BoF/WG would adress > I > presume (assuming of course the WG is created) > Any moving average mechanism has some "memory". For example, if new samples get a high weight relative to the existing average, the memory is short. Both the averaging algorithm and the length of the corresponding memory at the egress routers may be chosen differently in different networks. They have both an impact on the reaction speed of the AC which should carefully be investigated. The same holds for the measurement algorithms and their parameters for the markers. Best wishes, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 03:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwHF-0008WP-L8; Wed, 20 Sep 2006 03:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwHE-0008Op-By for pcn@ietf.org; Wed, 20 Sep 2006 03:13:48 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwHA-0002jy-RE for pcn@ietf.org; Wed, 20 Sep 2006 03:13:48 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 19F68125F; Wed, 20 Sep 2006 09:13:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0AC8515B5; Wed, 20 Sep 2006 09:13:42 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id ADC86125F; Wed, 20 Sep 2006 09:13:41 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8K7Dfs15649; Wed, 20 Sep 2006 09:13:41 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 5C07F6F58E; Wed, 20 Sep 2006 09:12:32 +0200 (CEST) Message-ID: <4510EA40.80702@informatik.uni-wuerzburg.de> Date: Wed, 20 Sep 2006 09:14:08 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: philip.eardley@bt.com, pcn@ietf.org Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCED@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCED@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Philip, > 3) Terminology for "sustainable-aggregate-rate" is not clear. > Suggestion: > rate of non-preemption marked packets measured by an egress gateway for > a > specific ingress gateway; this is the supportable traffic rate between > these gateways if the corresponding path is congested. > > [phil] ok. I don't think the phrase " if the corresponding path is > congested" is needed? > [Michael] I think it is needed and also how it is measured to better understand what it means. This is useful as one looks it up in the terminology section to exactly know what it is. > 7) Section 5.5 > > Another potential solution: add the declared rate to the SAR at the > ingress gateway as long as new flows send hardly any traffic. This > information must be obtained from the corresponding policers which > are also under the control of the ingress gateway. Or add it for an > initial period of e.g. 10 s? > > [phil] not sure about this. would the ingress do both this adm ctrl on > declared rate & adm ctrl based on the adm marking of > draft-briscoe-tsvwg-cl-architecture? [Michael] Yes, as long as the already admitted flows are not reflected in the measurements. Otherwise this would result in problems with flash crowds. I have detailed this issue including the solution in my response to Anna. > How long would your "initial period" be chosen? [Michael] Good question. I think this leaves room for research to be done. > When it ends, what does the ingress gateway have to > do? [worried about it having to remember state, failure modes etc] > [Michael] When the initial period ends, the ingress router just doesn't take the declared rate of the respective flow anymore into account as its rate is now reflected by the measurements. > 13) Section 11.3 > By running the EWMA whenever a new packet for a specific > CL-region-aggregate arrives makes the aging process depending on the > arrival rate of the traffic. As a consequence, there is the problem > with the stale information. This can be done in a better way, e.g. > by using the time-exponentially weighted moving average (TEWMA) [TEWMA]. > > [TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness > of Rate Measurements", in proceedings of GI/ITG Conference on Measuring, > Modelling and Evaluation of Computer and Communication Systems (MMB), > Dresden, Germany, September 2004 > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf > > If the TEWMA seems too complex (it requires the calculation of an > exponential function), a rate of the admission- or preemption-marked > packets can be calculated based on a, e.g., 20 ms interval and used > as input for a conventional EWMA. > > [phil] will read. What's not clear to me at this stage is whether we'll > end up standardising a specific averaging algorithm, or saying something > like "must average, but choice of algorithm is left open", or something > else. [Michael] I think it is good to leave it open, but there should be also a recommendation how to do it in a network. From my perspective, this is an open issue. However, it is probably igood to use the same averaging and metering mechanism together with the same parameters in all network devices for the sake of comparability. Best wishes, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 03:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwXH-0003Aq-5O; Wed, 20 Sep 2006 03:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPwXG-0003Ak-6R for pcn@ietf.org; Wed, 20 Sep 2006 03:30:22 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPwXD-0007Wl-Nu for pcn@ietf.org; Wed, 20 Sep 2006 03:30:22 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 20 Sep 2006 09:30:12 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 09:30:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Sep 2006 09:30:10 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF854@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <4510E339.6030607@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: AcbcgDa6B+R7qvZzRbWG/KLCjSVgWQAAQKOQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Sep 2006 07:30:11.0518 (UTC) FILETIME=[9B424DE0:01C6DC86] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hallo Michael, You are right, dealing with re-route events and other=20 sudden changes in traffic load is a very important=20 issue for any provider trying to produce "Quality of=20 Service". Solving the related planning aspects may be=20 out of scope for a PCN WG. But the PCN design should=20 allow for solutions allowing a once admitted flow=20 to get the promised QoS, regardless of events in the=20 backbone (at least for foreseeable conditions). I'd strongly favour a simple operational scheme in the backbone.=20 Both of your proposals, measuring available bandwidth to then=20 applying reservation based admission control (that's what I'd=20 understand to be meant by using "declared rates" for AC) doesn't seem to be favourable in the backbone.=20 A flash crowd may cause a short term congestion on a link. If=20 you just look at the resulting traffic (not at the cause for=20 it), a re-route event may have to some extent similar=20 consequences. I personally favour to spare some QoS capacity=20 on a link and to stop admitting new sessions for a while to=20 cope with both of them.=20 A smart mechanism to detect whether the bandwidth required by=20 an application is still available within the backbone is the=20 Priority Promotion Scheme (PPS). It is another measurement=20 based admission control method, where end-systems create=20 short bursts of application traffic prior to being admitted.=20 A hyrachical token bucket avoids flows from being admitted=20 once a settable load level has been reached on a link.=20 To me, changes required in end-systems, a hyrachical=20 policer and the consumption of DSCPs make PPS less=20 favourable than PCN. I would however prefer PPS over=20 any "available" capacity measurements in combination=20 with reservation based admission control in the backbone.=20 For PPS see: http://www.ee.kth.se/~nacho/PBAC/ . The PPS=20 ceators work with losses to indicate congestion. I think=20 re-marking is smarter (as applied by ECN/PCN) Regards, R=FCdiger [Michael] |> 7) Section 5.5 |> |> Another potential solution: add the declared rate to the SAR at the |> ingress gateway as long as new flows send hardly any traffic. This |> information must be obtained from the corresponding policers=20 |> which are also under the control of the ingress gateway. Or add=20 |> it for an initial period of e.g. 10 s? [Anna]Just to understand what you mean: this is a proposal=20 to solve which aspect of the problem? =20 [Michael] |This proposal tries to cope with flash crowds, i.e. with many almost=20 |simultaneous admission requests. The problem is that the AC=20 |can respect the impact of newly admitted flows only after some=20 |time when their typical sent rate influences the admission marking=20 |in the routers. I think that there should be a mechanism to find=20 |out the minimum rate between two border routers that is still=20 |admissible. The sum of the overall declared rates of new flows=20 |should not consume more than this rate. A flow is new as long as=20 |its typical rate has not yet hat an impact on the packet marking,=20 |and to keep things simple, for an initial time of maybe 10 s. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 05:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPyST-00027e-Mb; Wed, 20 Sep 2006 05:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPySS-00027Z-NQ for pcn@ietf.org; Wed, 20 Sep 2006 05:33:32 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPySO-0002Rf-3d for pcn@ietf.org; Wed, 20 Sep 2006 05:33:32 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3427C274E; Wed, 20 Sep 2006 11:33:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 25C99271F; Wed, 20 Sep 2006 11:33:21 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C65231758; Wed, 20 Sep 2006 11:33:20 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8K9XKs17017; Wed, 20 Sep 2006 11:33:20 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 5C27C6F58E; Wed, 20 Sep 2006 11:32:11 +0200 (CEST) Message-ID: <45110AFD.3080707@informatik.uni-wuerzburg.de> Date: Wed, 20 Sep 2006 11:33:49 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt References: <6439282641581441A36F7F6F83ED2ED2CBF854@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF854@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, > You are right, dealing with re-route events and other > sudden changes in traffic load is a very important > issue for any provider trying to produce "Quality of > Service". Solving the related planning aspects may be > out of scope for a PCN WG. But the PCN design should > allow for solutions allowing a once admitted flow > to get the promised QoS, regardless of events in the > backbone (at least for foreseeable conditions). > Yes, that's right. We already did that in a former project for a different network admission control approach: http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04d.pdf Capacity budgets (aka configured-admission-rates) are set in such a way that the capacity in the network suffices to carry all admissible traffic patterns in all single failure scenarios. This is a configuration problem and is subject to further research for a PCN-based NAC. > I'd strongly favour a simple operational scheme in the backbone. > Both of your proposals, measuring available bandwidth to then > applying reservation based admission control (that's what I'd > understand to be meant by using "declared rates" for AC) doesn't > seem to be favourable in the backbone. > > A flash crowd may cause a short term congestion on a link. If > you just look at the resulting traffic (not at the cause for > it), a re-route event may have to some extent similar > consequences. I personally favour to spare some QoS capacity > on a link and to stop admitting new sessions for a while to > cope with both of them. That is true. But when I talk about flash crowds, I do not think of uncorrelated users entering the network independently of each other. When a soccer game starts at 3:30 pm and many users simultaneously try to access the network, then the load can increase significantly. And this will possibly lead to a long-term congestion. Hoping that the impact of the flash crowd is not so strong that it does not lead to real congestion since there is extra capacity is one option and is certainly a viable option in core networks with very large link capacities and a small likelihood for uncorrelated flows. Going further to regional networks, it might be good to do something against flash crowds that could lead to physical link congestion. In such a case I see two alternative options: a) Do nothing and preempt flows when the configured-preemption-rate is exceeded. b) Try to avoid overload due to flash crowds and this is what the mechanism I mentioned aims at. > > > A smart mechanism to detect whether the bandwidth required by > an application is still available within the backbone is the > Priority Promotion Scheme (PPS). It is another measurement > based admission control method, where end-systems create > short bursts of application traffic prior to being admitted. > A hyrachical token bucket avoids flows from being admitted > once a settable load level has been reached on a link. > To me, changes required in end-systems, a hyrachical > policer and the consumption of DSCPs make PPS less > favourable than PCN. I would however prefer PPS over > any "available" capacity measurements in combination > with reservation based admission control in the backbone. > For PPS see: http://www.ee.kth.se/~nacho/PBAC/ . The PPS > ceators work with losses to indicate congestion. I think > re-marking is smarter (as applied by ECN/PCN) > I've looked at the draft http://www.ee.kth.se/~nacho/PBAC/draft-morita-tsvwg-pps-01.txt where PPS is described. This admission control works as follows. The origin end system [in our context the ingress router] sends a packet burst of the declared rate of the flow into the network and the destination end system [in our context the egress router] signals back how many of these packets have arrived. The packet burst needs to be sufficiently long, otherwise only large packet loss probabilities can be detected. This mechanism does not support any admission threshold at e.g. 30% link load which is the enormous benefit of the PCN-based NAC as this is a prerequisite for resilient NAC as discussed above. Obviously, I haven't explained the mechanism I had in mind not well enough as "reservations and available bandwidth measurements" sound difficult to you and probably to others. What's behind? The ingress router asks the egress router for the bandwidth that is still available for a specific border-to-border (b2b) CL-region-aggregate: s simple round-trip signaling evaluates the minimum difference between the configured-admission-rate and the currently used rate by CL traffic on each link on the b2b path. The current CL rate on the link should not be too difficult to obtain because the admission and preemption marking have similar complexity. Furthermore, the ingress router holds a table of recently admitted flows for each b2b CL-region aggregate. It adds them after admission and removes them when they terminate or when they are older than 10 s. The latter action can be done whenever the aggregate rate of the recently admitted flows is needed. Such a table is feasible as long as flows declare a rate which is used for the policers. Therefore, it does not significantly increase the complexity of the AC as the ingress routers is an end point for end-to-end signalling (RSVP) anyway. When a new flow requests admission, its declared rate is compared to the available b2b bandwidth minus the aggregate rate of the recently admitted flows. This bandwidth reduction can be further decreased by mechanisms borrowed from experience-based admission control (EBAC), however, I don't like to further explain this at this point to avoid confusion. Best wishes, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 09:34:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2Dx-0000lF-RP; Wed, 20 Sep 2006 09:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2Dw-0000l4-QK for pcn@ietf.org; Wed, 20 Sep 2006 09:34:48 -0400 Received: from mother.pmc-sierra.com ([216.241.224.12] helo=mother.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQ2Du-0006wT-UI for pcn@ietf.org; Wed, 20 Sep 2006 09:34:48 -0400 Received: (qmail 29056 invoked by uid 101); 20 Sep 2006 13:34:36 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 20 Sep 2006 13:34:36 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k8KDYarW020897; Wed, 20 Sep 2006 06:34:36 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Sep 2006 06:34:36 -0700 Message-ID: From: Shahram Davari To: "'Kwok-Ho Chan'" , ken carlberg Subject: RE: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 06:34:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Kwok, Indeed you raised a good subject. The requirements for emergency services should be part of the problem statement, and be dealt with in the proposed solution draft. ITU-T has quite extensive work on the requirements for Emergency services. On a side note, one of the problems identified during a recent school shooting in Canada was that the emergency and police couldn't use the phone or cell phones to communicate because the network was jammed due to high volume of calls between students and their families. Yours, Shahram > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: Tuesday, September 19, 2006 5:26 PM > To: ken carlberg > Cc: pcn@ietf.org > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > Ken: > Thank you for handling so many of our replies at the same time. :) > > YES, on your point of: > > >just to recap. I just wanted to point out that there are > >jurisdictions that do not allow preemption for voice communications > >used by the general public -- this definitely applies for a number of > >PSTNs, and I'm sure it will trickle down to certain deployments of > >VoIP. Hence, I would recommend that the group consider other (re) > >actions other than preemption....which from the feedback of my > >original note, seems will be done. > > We are using the Problem-Statement draft to put out an > initial version of what > we are thinking, as this is still work in progress, there definitely > are area we > may have missed. > > Thank you for pointing out at least one of them. > > I will write some additional text for -01 version of the Problem > Statement draft to try > and describe the problem you have indicated (but I will try NOT to > indicate any solution > in the Problem Statement draft). > > And we will try to have some text in at least some of our Deployment > Model drafts > to see if there are good solutions to the problem you > indicated. There may be > more than one solution as there may be more than one Deployment Model. > > Please Notice I have changed the subject of the E-Mail thread for > issue tracking purpose. > Please use this E-Mail Subject for continuing this discussion. > > Now I have additional questions concerning the use of Preemption for > handling Emergency > Services. Will Preemption be allowed for Emergency Services? > Does some of the > jurisdiction you have indicated want to use a separate network for > Emergency Services > purpose? Will combining Emergency Services with the normal > VoIP calls/sessions > be a good Problem Statement that we can add to our Problem > Statement draft? > > I am concentrating on Problem Statement instead of Solutions > for now because we > want to get the Problem Statement cleared away first for the > BOF purpose. > > Thanks! > -- Kwok -- > > At 12:13 PM 9/19/2006, ken carlberg wrote: > >Anna, > > > >>>maybe we have a different perspective of preemption. as I view it, > >>>preemption is removing *existing* state (circuit in the PSTN > >>>world) in > >>>favor of new state. > >> > >>I guess that may be one thing that needs clarification. The way I > >>view > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt and > >>related docs view the issue) is that pre-emption should kick in > >>when for > >>whatever reason provisioning mechanisms fail there simply is not > >>enough > >>capacity to carry all calls. Setting aside the issue of precedence > >>for > >>the moment, the expectation is that the level of traffic needed to > >>trigger premption is typicaly higher (perhaps substanially higher) > >>than > >>the level triggering to stop admission of new flows. That > means that > >>when preemption does get triggered, there would actually > not really be > >>any new state admitted. > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of > >understood some of the things you were saying, but there were too > >many things you left out (why does one have an admission control at > >level X and a preemption level at X+N?, are you implying that the > >edge is keeping track of the flows it rejects?....that would seem > >quite granular in keeping measurements). > > > >I'm not sure its necessary to clarify the above. Its probably just > >best that we agree that future work should include a more detailed > >discussion of what is preemption in the context of your architecture. > > > >>The degree of how far apart preemption and > >>admission thresholds are is of course a mater of > configuration, but I > >>would expect that they would be sufficiently apart to ensure that > >>you do > >>not just toggle preempted and new flows. Of course if there > are higher > >>precedence calls, then one might expect that a higher > precedence call > >>may be established while lower precedence calls may need to be > >>preempted? > >> > >>Perhaps this expectation should be made more transparent in the > >>drafts? > >> > >>>In the US and some other countries, this is not > >>>allowed in the PSTN. > >> > >>Just wanted to make sure I understand exactly what is not allowed. > >>Are > >>you saying that PSTN is not allowed to preempt a lower > precedence call > >>in order to establish a high recedence call? Or are you > referring to > >>the same precedence levels? > > > >as an example, in the US PSTN, all calls from the general public are > >treated with the same level of precedence. the exception are systems > >like GETS, but they simply increase the probability of call > >completion -- they do not use preemption. private systems based on > >MLPP, like Autovon in the DoD and NATO, do allow different levels of > >priority and subsequent preemption if so needed. rfc-4190 and > >rfc-4542 provide background on these systems/services along with > >discussion in the context of IP (since this is the IETF :-) > > > >just to recap. I just wanted to point out that there are > >jurisdictions that do not allow preemption for voice communications > >used by the general public -- this definitely applies for a number of > >PSTNs, and I'm sure it will trickle down to certain deployments of > >VoIP. Hence, I would recommend that the group consider other (re) > >actions other than preemption....which from the feedback of my > >original note, seems will be done. > > > >regards, > > > >-ken > > > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 09:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2S9-0004Uj-Mk; Wed, 20 Sep 2006 09:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2S8-0004UX-AD for pcn@ietf.org; Wed, 20 Sep 2006 09:49:28 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2S5-00006n-IW for pcn@ietf.org; Wed, 20 Sep 2006 09:49:28 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 20 Sep 2006 15:48:52 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 15:48:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Sep 2006 15:48:51 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF85B@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <45110AFD.3080707@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: Acbcl9tvTmBc5JQCQuCFKDBiLlcb1wAIQ3tg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Sep 2006 13:48:52.0503 (UTC) FILETIME=[82057A70:01C6DCBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hallo Michael, my comments are in line. Regards, R=FCdiger |> You are right, dealing with re-route events and other=20 |> sudden changes in traffic load is a very important=20 |> issue for any provider trying to produce "Quality of=20 |> Service". Solving the related planning aspects may be=20 |> out of scope for a PCN WG. But the PCN design should=20 |> allow for solutions allowing a once admitted flow=20 |> to get the promised QoS, regardless of events in the=20 |> backbone (at least for foreseeable conditions). |> =20 | Yes, that's right. We already did that in a former project for a=20 | different network admission control approach: | = http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04d.pdf | Capacity budgets (aka configured-admission-rates) are set in=20 | such a way that the capacity in the network suffices to carry all=20 | admissible traffic patterns in all single failure scenarios. This is a = | configuration problem and is subject to further research for a=20 | PCN-based NAC. Well, I'd regard the planning issues to be out of scope of PCN. The=20 kind of network planning you describe is in priciple operational=20 in at least one commercial backbone network I'm aware of. |> I'd strongly favour a simple operational scheme in the backbone.=20 |> Both of your proposals, measuring available bandwidth to then=20 |> applying reservation based admission control (that's what I'd=20 |> understand to be meant by using "declared rates" for AC) doesn't |> seem to be favourable in the backbone.=20 |> |> A flash crowd may cause a short term congestion on a link. If=20 |> you just look at the resulting traffic (not at the cause for=20 |> it), a re-route event may have to some extent similar=20 |> consequences. I personally favour to spare some QoS capacity=20 |> on a link and to stop admitting new sessions for a while to=20 |> cope with both of them. | That is true. But when I talk about flash crowds, I do not think of=20 | uncorrelated users entering the network independently of each other.=20 | When a soccer game starts at 3:30 pm and many users simultaneously try = | to access the network, then the load can increase significantly. And=20 | this will possibly lead to a long-term congestion. Hoping that the=20 | impact of the flash crowd is not so strong that it does not=20 | lead to real congestion since there is extra capacity is one option=20 | and is certainly a viable option in core networks with very large=20 | link capacities and a small likelihood for uncorrelated flows.=20 | Going further to regional networks, it might be good to do=20 | something against flash crowds that could lead to physical link=20 | congestion. In such a case I see two alternative options: | a) Do nothing and preempt flows when the configured-preemption-rate is = | exceeded. | b) Try to avoid overload due to flash crowds and this is what the=20 | mechanism I mentioned aims at. IPTV gains a lot of attention these days. I'd expect multicast=20 distribution within a single domain. The Flash crowd should use a=20 communication service rather than a distribution service. Events=20 like catastrophes lend to that, but the demand may not grow as=20 fast as in your example. |> A smart mechanism to detect whether the bandwidth required by=20 |> an application is still available within the backbone is the=20 |> Priority Promotion Scheme (PPS). It is another measurement=20 |> based admission control method, where end-systems create=20 |> short bursts of application traffic prior to being admitted.=20 |> A hyrachical token bucket avoids flows from being admitted=20 |> once a settable load level has been reached on a link.=20 |> To me, changes required in end-systems, a hyrachical=20 |> policer and the consumption of DSCPs make PPS less=20 |> favourable than PCN. I would however prefer PPS over=20 |> any "available" capacity measurements in combination=20 |> with reservation based admission control in the backbone.=20 |> For PPS see: http://www.ee.kth.se/~nacho/PBAC/ . The PPS=20 |> ceators work with losses to indicate congestion. I think=20 |> re-marking is smarter (as applied by ECN/PCN) |> =20 | I've looked at the draft=20 | http://www.ee.kth.se/~nacho/PBAC/draft-morita-tsvwg-pps-01.txt=20 | where PPS=20 | is described. This admission control works as follows. The origin end=20 | system [in our context the ingress router] sends a packet burst of the = | declared rate of the flow into the network and the destination end=20 | system [in our context the egress router] signals back how=20 | many of these=20 | packets have arrived. The packet burst needs to be sufficiently long,=20 | otherwise only large packet loss probabilities can be detected. This=20 | mechanism does not support any admission threshold at e.g. 30%=20 | link load=20 | which is the enormous benefit of the PCN-based NAC as this is a=20 | prerequisite for resilient NAC as discussed above. If PPS works with a hyrachical token bucket policer instead of a=20 queuing mechnism, setting link load levels is quite easy. The=20 problem with nthat is, that no commercial router supports this=20 kind of policing. Further, marking of measurement packets=20 should be applied instead of dropping. | Obviously, I haven't explained the mechanism I had in mind not well=20 | enough as "reservations and available bandwidth measurements" sound=20 | difficult to you and probably to others. What's behind? | | The ingress router asks the egress router for the bandwidth that is=20 | still available for a specific border-to-border (b2b)=20 | CL-region-aggregate: s simple round-trip signaling evaluates=20 | the minimum difference between the configured-admission-rate and the=20 | currently used rate by CL traffic on each link on the b2b path.=20 How do you get information on configured or actual used rates on=20 b2b paths? Do you assume RSVP-TE or the like to be applied?=20 | The current CL rate on=20 | the link should not be too difficult to obtain because the=20 | admission and preemption marking have similar complexity. | Furthermore, the ingress router holds a table of recently=20 | admitted flows=20 | for each b2b CL-region aggregate. It adds them after admission and=20 | removes them when they terminate or when they are older than 10 s. The = | latter action can be done whenever the aggregate rate of the recently=20 | admitted flows is needed. Such a table is feasible as long as flows=20 | declare a rate which is used for the policers. Therefore, it does not=20 | significantly increase the complexity of the AC as the ingress routers = | is an end point for end-to-end signalling (RSVP) anyway. When=20 | a new flow=20 | requests admission, its declared rate is compared to the available b2b = | bandwidth minus the aggregate rate of the recently admitted=20 | flows. This=20 | bandwidth reduction can be further decreased by mechanisms=20 | borrowed from=20 | experience-based admission control (EBAC), however, I don't like to=20 | further explain this at this point to avoid confusion. | |Best wishes, | | Michael | |--=20 |Dr. Michael Menth, Assistant Professor |University of Wuerzburg, Institute of Computer Science |Am Hubland, D-97074 Wuerzburg, Germany, room B206 |phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 |mailto:menth@informatik.uni-wuerzburg.de |http://www3.informatik.uni-wuerzburg.de/research/ngn | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 10:10:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2m7-0002yO-8h; Wed, 20 Sep 2006 10:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2m6-0002yJ-4P for pcn@ietf.org; Wed, 20 Sep 2006 10:10:06 -0400 Received: from athena.hosts.co.uk ([85.233.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2m4-0003G1-OQ for pcn@ietf.org; Wed, 20 Sep 2006 10:10:06 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from ) id 1GQ2lf-0003jr-V0; Wed, 20 Sep 2006 15:09:40 +0100 In-Reply-To: <6.2.5.6.0.20060919170712.03cfd1a8@nortel.com> References: <6.2.5.6.0.20060919170712.03cfd1a8@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 10:09:32 -0400 To: Kwok-Ho Chan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Kwok, > Now I have additional questions concerning the use of Preemption > for handling Emergency > Services. Will Preemption be allowed for Emergency Services? My understanding is that Japan provides a measure of preemption for its 911-type service. However, I don't know the specifics and can't offer any more insight. One thing to keep in mind is that the 911- type system is inherently an any-to-one (any user to PSAP/911- operator) model. As mentioned earlier, the US (and some other countries) have a system called GETS that focuses on increasing the probability of call completion over their PSTN. This represents an an-to-any model. There is also the Wireless Priority System (WPS) in the US that allows "displacement" of other users *during* call setup, versus a call that has been established. People can google GETS and WPS for more info. > Does some of the > jurisdiction you have indicated want to use a separate network for > Emergency Services > purpose? Yes, AUTOVON is one example. Other examples are Land Mobile Radio (LMR) systems used by first responders. From the IP perspective, the bulk of the LMR infrastructure is at Layer 2, but IP providers and vendors are starting to infuse IP into those systems. The key thing to keep in mind is that these are systems that are under a single administrative authority (ie, a single domain). > Will combining Emergency Services with the normal VoIP calls/sessions > be a good Problem Statement that we can add to our Problem > Statement draft? Well, I would view Emergency Services as mostly one motivation for what you are trying to accomplish. Aspects like rapid recovery, prioritization/labeling/coloring of flows, etc. would seem to be of interest to those dealing with emergencies or some other condition. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 10:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3BJ-0006ZQ-HY; Wed, 20 Sep 2006 10:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3BI-0006X1-HL for pcn@ietf.org; Wed, 20 Sep 2006 10:36:08 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3BG-0007PR-0R for pcn@ietf.org; Wed, 20 Sep 2006 10:36:08 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0445F5667; Wed, 20 Sep 2006 16:36:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id EC83F4FB6; Wed, 20 Sep 2006 16:36:00 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CE8F02E64; Wed, 20 Sep 2006 16:36:00 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8KEa0s20367; Wed, 20 Sep 2006 16:36:00 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id C2DAF6F58E; Wed, 20 Sep 2006 16:34:51 +0200 (CEST) Message-ID: <451151EF.7060009@informatik.uni-wuerzburg.de> Date: Wed, 20 Sep 2006 16:36:31 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt References: <6439282641581441A36F7F6F83ED2ED2CBF85B@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF85B@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, > | http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04d.pdf > | Capacity budgets (aka configured-admission-rates) are set in > | such a way that the capacity in the network suffices to carry all > | admissible traffic patterns in all single failure scenarios. This is a > | configuration problem and is subject to further research for a > | PCN-based NAC. > > Well, I'd regard the planning issues to be out of scope of PCN. The > kind of network planning you describe is in priciple operational > in at least one commercial backbone network I'm aware of. > Sure, that is no protocol stuff which requires standardization. > | Obviously, I haven't explained the mechanism I had in mind not well > | enough as "reservations and available bandwidth measurements" sound > | difficult to you and probably to others. What's behind? > | > | The ingress router asks the egress router for the bandwidth that is > | still available for a specific border-to-border (b2b) > | CL-region-aggregate: s simple round-trip signaling evaluates > | the minimum difference between the configured-admission-rate and the > | currently used rate by CL traffic on each link on the b2b path. > > How do you get information on configured or actual used rates on > b2b paths? Do you assume RSVP-TE or the like to be applied? > Well, that's probably a protocol issue that needs to be standardized if this mechanism is of interest. > | The current CL rate on > | the link should not be too difficult to obtain because the > | admission and preemption marking have similar complexity. > Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 11:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3ky-00060W-DB; Wed, 20 Sep 2006 11:13:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3kx-0005zM-Af for pcn@ietf.org; Wed, 20 Sep 2006 11:12:59 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3kv-00059M-Um for pcn@ietf.org; Wed, 20 Sep 2006 11:12:59 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 20 Sep 2006 17:12:56 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 17:12:56 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Sep 2006 17:12:55 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF860@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <451151EF.7060009@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: AcbcwjCSEt4jtFwhRFaKNOszmUUVWwAA7RLw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Sep 2006 15:12:56.0517 (UTC) FILETIME=[407CEF50:01C6DCC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hallo Michael, |> | Obviously, I haven't explained the mechanism I had in mind not well = |> | enough as "reservations and available bandwidth measurements" sound = |> | difficult to you and probably to others. What's behind? |> | |> | The ingress router asks the egress router for the bandwidth that is = |> | still available for a specific border-to-border (b2b)=20 |> | CL-region-aggregate: s simple round-trip signaling evaluates=20 |> | the minimum difference between the configured-admission-rate and = the=20 |> | currently used rate by CL traffic on each link on the b2b path.=20 |> How do you get information on configured or actual used rates on=20 |> b2b paths? Do you assume RSVP-TE or the like to be applied?=20 |> =20 | Well, that's probably a protocol issue that needs to be=20 | standardized if this mechanism is of interest. To me that sounds like tradeoff of between efficiency and complexity. I prefer a stateless backbone network, just DiffServ. It may not=20 provide the most efficient service. But this solution may=20 be deployable within a few years and still perform pretty good. Further improvements should be specified later. So there could=20 be a PCN based AC version 1 and later PCN version 2. Regards, R=FCdiger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 11:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ40m-00030o-GK; Wed, 20 Sep 2006 11:29:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ40l-00030e-QY for pcn@ietf.org; Wed, 20 Sep 2006 11:29:19 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ40j-0007VV-9i for pcn@ietf.org; Wed, 20 Sep 2006 11:29:19 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9A8EB56BA; Wed, 20 Sep 2006 17:29:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8E77F4FB0; Wed, 20 Sep 2006 17:29:14 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 49A432F56; Wed, 20 Sep 2006 17:29:14 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8KFTEs20854; Wed, 20 Sep 2006 17:29:14 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 152F16F58E; Wed, 20 Sep 2006 17:28:05 +0200 (CEST) Message-ID: <45115E68.2040405@informatik.uni-wuerzburg.de> Date: Wed, 20 Sep 2006 17:29:44 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt References: <6439282641581441A36F7F6F83ED2ED2CBF860@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF860@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, Geib, Ruediger wrote: > Hallo Michael, > > |> | Obviously, I haven't explained the mechanism I had in mind not wel= l=20 > |> | enough as "reservations and available bandwidth measurements" soun= d=20 > |> | difficult to you and probably to others. What's behind? > |> | > |> | The ingress router asks the egress router for the bandwidth that i= s=20 > |> | still available for a specific border-to-border (b2b)=20 > |> | CL-region-aggregate: s simple round-trip signaling evaluates=20 > |> | the minimum difference between the configured-admission-rate and t= he=20 > |> | currently used rate by CL traffic on each link on the b2b path.=20 > > |> How do you get information on configured or actual used rates on=20 > |> b2b paths? Do you assume RSVP-TE or the like to be applied?=20 > |> =20 > > | Well, that's probably a protocol issue that needs to be=20 > | standardized if this mechanism is of interest. > > To me that sounds like tradeoff of between efficiency and complexity. > I prefer a stateless backbone network, just DiffServ. It may not=20 > provide the most efficient service. But this solution may=20 > be deployable within a few years and still perform pretty good. > > Further improvements should be specified later. So there could=20 > be a PCN based AC version 1 and later PCN version 2. > =20 As this mechanism against flash crowd is just an add-on to the rest of=20 the architecture and probably with any incompatibilities, this feature=20 can be well separated from the main core and postponed to the future if=20 it is of interest at all. I fully agree. I just want to suggest it as a=20 potential countermeasure against flash crowds in Section 5.5 of the draft http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-0= 3.txt Kind regards, Michael > Regards, > > R=FCdiger > =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 11:55:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4Q5-0004GO-Fr; Wed, 20 Sep 2006 11:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4Q4-0004GJ-Q3 for pcn@ietf.org; Wed, 20 Sep 2006 11:55:28 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4Q4-0004Fc-8C for pcn@ietf.org; Wed, 20 Sep 2006 11:55:28 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8KFsiu26740; Wed, 20 Sep 2006 11:54:44 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 11:54:29 -0400 Message-Id: <6.2.5.6.0.20060920113532.03deadb8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Sep 2006 11:54:28 -0400 To: Shahram Davari From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 15:54:29.0568 (UTC) FILETIME=[0E765400:01C6DCCD] X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: pcn@ietf.org, ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Shahram: I totally agree. The cell phone network was also jammed during 9/11. I was trying to reach my brother who were stuck in the subway ~2 stops from WTC. So I know exactly how this feels like. But I prefer to let the Police and Firemen to use this resource to help the general public at large. The question becomes: - Does the Emergency Services want to use the same physical network as the general public? -- If Yes. Then should the problem statement becomes: "Some controlled preemption functionality is allowed for Emergency purposes in the general public integrated (voice, video, data, etc) network. This controlled preemption functionality needs to be supported by the network mechanisms." -- If Yes. Then we will need some guidance and help wrt the regulations of the different jurisdictions. Also if the different jurisdictions even wants to use the same network infrastructure for both emergency and public usage purposes. If it is technically possible. By this I am not saying a good solution exist or that I am promoting a specific solution. I am just agreeing that this problem needs to be addressed. We may end up saying we can not solve this problem as of yet. But I wish we can solve it. Regards. -- Kwok -- At 09:34 AM 9/20/2006, Shahram Davari wrote: >Kwok, > >Indeed you raised a good subject. The requirements for emergency >services should be part of the problem statement, and be dealt with >in the proposed solution draft. ITU-T has quite extensive work on >the requirements for Emergency services. > >On a side note, one of the problems identified during a recent >school shooting in Canada was that the emergency and police couldn't >use the phone or cell phones to communicate because the network was >jammed due to high volume of calls between students and their families. > >Yours, >Shahram > > > > -----Original Message----- > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > Sent: Tuesday, September 19, 2006 5:26 PM > > To: ken carlberg > > Cc: pcn@ietf.org > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > Ken: > > Thank you for handling so many of our replies at the same time. :) > > > > YES, on your point of: > > > > >just to recap. I just wanted to point out that there are > > >jurisdictions that do not allow preemption for voice communications > > >used by the general public -- this definitely applies for a number of > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > >VoIP. Hence, I would recommend that the group consider other (re) > > >actions other than preemption....which from the feedback of my > > >original note, seems will be done. > > > > We are using the Problem-Statement draft to put out an > > initial version of what > > we are thinking, as this is still work in progress, there definitely > > are area we > > may have missed. > > > > Thank you for pointing out at least one of them. > > > > I will write some additional text for -01 version of the Problem > > Statement draft to try > > and describe the problem you have indicated (but I will try NOT to > > indicate any solution > > in the Problem Statement draft). > > > > And we will try to have some text in at least some of our Deployment > > Model drafts > > to see if there are good solutions to the problem you > > indicated. There may be > > more than one solution as there may be more than one Deployment Model. > > > > Please Notice I have changed the subject of the E-Mail thread for > > issue tracking purpose. > > Please use this E-Mail Subject for continuing this discussion. > > > > Now I have additional questions concerning the use of Preemption for > > handling Emergency > > Services. Will Preemption be allowed for Emergency Services? > > Does some of the > > jurisdiction you have indicated want to use a separate network for > > Emergency Services > > purpose? Will combining Emergency Services with the normal > > VoIP calls/sessions > > be a good Problem Statement that we can add to our Problem > > Statement draft? > > > > I am concentrating on Problem Statement instead of Solutions > > for now because we > > want to get the Problem Statement cleared away first for the > > BOF purpose. > > > > Thanks! > > -- Kwok -- > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > >Anna, > > > > > >>>maybe we have a different perspective of preemption. as I view it, > > >>>preemption is removing *existing* state (circuit in the PSTN > > >>>world) in > > >>>favor of new state. > > >> > > >>I guess that may be one thing that needs clarification. The way I > > >>view > > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt and > > >>related docs view the issue) is that pre-emption should kick in > > >>when for > > >>whatever reason provisioning mechanisms fail there simply is not > > >>enough > > >>capacity to carry all calls. Setting aside the issue of precedence > > >>for > > >>the moment, the expectation is that the level of traffic needed to > > >>trigger premption is typicaly higher (perhaps substanially higher) > > >>than > > >>the level triggering to stop admission of new flows. That > > means that > > >>when preemption does get triggered, there would actually > > not really be > > >>any new state admitted. > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of > > >understood some of the things you were saying, but there were too > > >many things you left out (why does one have an admission control at > > >level X and a preemption level at X+N?, are you implying that the > > >edge is keeping track of the flows it rejects?....that would seem > > >quite granular in keeping measurements). > > > > > >I'm not sure its necessary to clarify the above. Its probably just > > >best that we agree that future work should include a more detailed > > >discussion of what is preemption in the context of your architecture. > > > > > >>The degree of how far apart preemption and > > >>admission thresholds are is of course a mater of > > configuration, but I > > >>would expect that they would be sufficiently apart to ensure that > > >>you do > > >>not just toggle preempted and new flows. Of course if there > > are higher > > >>precedence calls, then one might expect that a higher > > precedence call > > >>may be established while lower precedence calls may need to be > > >>preempted? > > >> > > >>Perhaps this expectation should be made more transparent in the > > >>drafts? > > >> > > >>>In the US and some other countries, this is not > > >>>allowed in the PSTN. > > >> > > >>Just wanted to make sure I understand exactly what is not allowed. > > >>Are > > >>you saying that PSTN is not allowed to preempt a lower > > precedence call > > >>in order to establish a high recedence call? Or are you > > referring to > > >>the same precedence levels? > > > > > >as an example, in the US PSTN, all calls from the general public are > > >treated with the same level of precedence. the exception are systems > > >like GETS, but they simply increase the probability of call > > >completion -- they do not use preemption. private systems based on > > >MLPP, like Autovon in the DoD and NATO, do allow different levels of > > >priority and subsequent preemption if so needed. rfc-4190 and > > >rfc-4542 provide background on these systems/services along with > > >discussion in the context of IP (since this is the IETF :-) > > > > > >just to recap. I just wanted to point out that there are > > >jurisdictions that do not allow preemption for voice communications > > >used by the general public -- this definitely applies for a number of > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > >VoIP. Hence, I would recommend that the group consider other (re) > > >actions other than preemption....which from the feedback of my > > >original note, seems will be done. > > > > > >regards, > > > > > >-ken > > > > > > > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 12:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4bX-0005Lb-Fk; Wed, 20 Sep 2006 12:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4bW-0005LI-DG for pcn@ietf.org; Wed, 20 Sep 2006 12:07:18 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4bV-0006Ph-34 for pcn@ietf.org; Wed, 20 Sep 2006 12:07:18 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8KG76A07624; Wed, 20 Sep 2006 12:07:06 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 12:06:50 -0400 Message-Id: <6.2.5.6.0.20060920115719.033af3d8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Sep 2006 12:06:49 -0400 To: ken carlberg From: "Kwok-Ho Chan" Subject: Re: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: References: <6.2.5.6.0.20060919170712.03cfd1a8@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 16:06:50.0851 (UTC) FILETIME=[C84D2330:01C6DCCE] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken: I think you brought up couple of points below. My interpretation is: 1. There is a need for 911 type (999 in UK?) of calls to get through in a public network. Hence 911 type of calls may be allowed to be admitted while normal calls get preempt as a start of a problem statement. 2. There is a need for dedicated emergency service networks to allow flow/session preemptions. 3. There is a need to allow flow/session preemptions when Emergency Service Networks and General Public Networks share network resources. Each may have a different affect to the mechanism and solution space we want to work on in the PCN BOF/WG. Please correct me if I mis-understand or missed your points. Thank you very much for your insights. -- Kwok -- At 10:09 AM 9/20/2006, ken carlberg wrote: >Kwok, > >>Now I have additional questions concerning the use of Preemption >>for handling Emergency >>Services. Will Preemption be allowed for Emergency Services? > >My understanding is that Japan provides a measure of preemption for >its 911-type service. However, I don't know the specifics and can't >offer any more insight. One thing to keep in mind is that the 911- >type system is inherently an any-to-one (any user to PSAP/911- operator) model. > >As mentioned earlier, the US (and some other countries) have a system >called GETS that focuses on increasing the probability of call >completion over their PSTN. This represents an an-to-any model. >There is also the Wireless Priority System (WPS) in the US that >allows "displacement" of other users *during* call setup, versus a >call that has been established. People can google GETS and WPS for >more info. > >>Does some of the >>jurisdiction you have indicated want to use a separate network for >>Emergency Services >>purpose? > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio >(LMR) systems used by first responders. From the IP perspective, the >bulk of the LMR infrastructure is at Layer 2, but IP providers and >vendors are starting to infuse IP into those systems. The key thing >to keep in mind is that these are systems that are under a single >administrative authority (ie, a single domain). > >>Will combining Emergency Services with the normal VoIP calls/sessions >>be a good Problem Statement that we can add to our Problem >>Statement draft? > >Well, I would view Emergency Services as mostly one motivation for >what you are trying to accomplish. Aspects like rapid recovery, >prioritization/labeling/coloring of flows, etc. would seem to be of >interest to those dealing with emergencies or some other condition. > >-ken > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 12:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ58R-0006Mz-33; Wed, 20 Sep 2006 12:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ58P-0006Mu-ON for pcn@ietf.org; Wed, 20 Sep 2006 12:41:17 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ58K-0002n3-97 for pcn@ietf.org; Wed, 20 Sep 2006 12:41:17 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 17:40:50 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Sep 2006 17:40:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 17:40:44 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <6.2.5.6.0.20060920115719.033af3d8@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbczts+PCOaGSOkTd6BOXppjESJAwAAgbGw From: To: , X-OriginalArrivalTime: 20 Sep 2006 16:40:45.0198 (UTC) FILETIME=[84DDDAE0:01C6DCD3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I'm not sure, but I think maybe the scope is drifting outside what I envisaged the scope of the PCN flow pre-emption mechanism. I don't think it's about: when an emergency call arrives, pre-empting a normal call because the new call would overload the network. This is something that might be done, of course - just I don't think it's in the scope of PCN. My view is that PCN is about "the network" realising that it's overloaded, and by how much, and providing this info [typically] to the relevant ingress node of the PCN-region. this node can then take action based on this info, ie decide which flows to pre-empt. My view is that the scope is really about how to provide the information, rather than detailing the action that should be taken. Agree? phil -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortel.com]=20 Sent: 20 September 2006 17:07 To: ken carlberg Cc: pcn@ietf.org Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Ken: I think you brought up couple of points below. My interpretation is: 1. There is a need for 911 type (999 in UK?) of calls to get through=20 in a public network. Hence 911 type of calls may be allowed to be admitted while=20 normal calls get preempt as a start of a problem statement. 2. There is a need for dedicated emergency service networks to allow=20 flow/session preemptions. 3. There is a need to allow flow/session preemptions when Emergency=20 Service Networks and General Public Networks share network resources. Each may have a different affect to the mechanism and solution space=20 we want to work on in the PCN BOF/WG. Please correct me if I mis-understand or missed your points. Thank you very much for your insights. -- Kwok -- At 10:09 AM 9/20/2006, ken carlberg wrote: >Kwok, > >>Now I have additional questions concerning the use of Preemption >>for handling Emergency >>Services. Will Preemption be allowed for Emergency Services? > >My understanding is that Japan provides a measure of preemption for >its 911-type service. However, I don't know the specifics and can't >offer any more insight. One thing to keep in mind is that the 911-=20 >type system is inherently an any-to-one (any user to PSAP/911- operator) model. > >As mentioned earlier, the US (and some other countries) have a system >called GETS that focuses on increasing the probability of call >completion over their PSTN. This represents an an-to-any model. >There is also the Wireless Priority System (WPS) in the US that >allows "displacement" of other users *during* call setup, versus a >call that has been established. People can google GETS and WPS for >more info. > >>Does some of the >>jurisdiction you have indicated want to use a separate network for >>Emergency Services >>purpose? > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio >(LMR) systems used by first responders. From the IP perspective, the >bulk of the LMR infrastructure is at Layer 2, but IP providers and >vendors are starting to infuse IP into those systems. The key thing >to keep in mind is that these are systems that are under a single >administrative authority (ie, a single domain). > >>Will combining Emergency Services with the normal VoIP calls/sessions >>be a good Problem Statement that we can add to our Problem >>Statement draft? > >Well, I would view Emergency Services as mostly one motivation for >what you are trying to accomplish. Aspects like rapid recovery, >prioritization/labeling/coloring of flows, etc. would seem to be of >interest to those dealing with emergencies or some other condition. > >-ken > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 12:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5IC-0003zL-Im; Wed, 20 Sep 2006 12:51:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5IB-0003zG-BL for pcn@ietf.org; Wed, 20 Sep 2006 12:51:23 -0400 Received: from athena.hosts.co.uk ([85.233.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5IA-0004tu-2I for pcn@ietf.org; Wed, 20 Sep 2006 12:51:23 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1GQ5Hz-0007oH-Ei; Wed, 20 Sep 2006 17:51:12 +0100 In-Reply-To: <6.2.5.6.0.20060920115719.033af3d8@nortel.com> References: <6.2.5.6.0.20060919170712.03cfd1a8@nortel.com> <6.2.5.6.0.20060920115719.033af3d8@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 12:51:02 -0400 To: Kwok-Ho Chan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > I think you brought up couple of points below. > My interpretation is: > 1. There is a need for 911 type (999 in UK?) of calls to get > through in a public network. > Hence 911 type of calls may be allowed to be admitted while > normal calls get preempt > as a start of a problem statement. > 2. There is a need for dedicated emergency service networks to > allow flow/session preemptions. > 3. There is a need to allow flow/session preemptions when Emergency > Service Networks and > General Public Networks share network resources. no, I'm not saying the above at all. and in fact given the snapshot of today, quite the opposite. the fact that only one country has a form of preemption for 911-type calls and most other countries do not implies there is no (or very little) current need for preemption in support of 911-type communications. the fact that there are some deployments of GETS-like service that focus on increasing probability of call completion *without* the use of preemption of existing calls implies that there is a need for a solution space other than preemption. this is of course under the context of infrastructure being shared by the general public and first responders (emergency related personnel). In private networks like AUTOVON, LMR, etc, there is a need/desire for the option of preemptive action. but these are systems that are closed and usually under a single administrative authority, which seems out of scope (or outside) the default inter-domain model of the Briscoe architecture draft. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 12:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5LD-0006XP-Hq; Wed, 20 Sep 2006 12:54:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5LC-0006XK-1A for pcn@ietf.org; Wed, 20 Sep 2006 12:54:30 -0400 Received: from athena.hosts.co.uk ([85.233.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5LA-0005UD-PR for pcn@ietf.org; Wed, 20 Sep 2006 12:54:30 -0400 Received: from [69.250.216.138] (helo=[192.168.1.3]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from ) id 1GQ5L6-0006Ff-QS; Wed, 20 Sep 2006 17:54:25 +0100 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 12:54:16 -0400 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > My view is that PCN is about "the network" realising that it's > overloaded, and by how much, and providing this info [typically] to > the > relevant ingress node of the PCN-region. this node can then take > action > based on this info, ie decide which flows to pre-empt. My view is that > the scope is really about how to provide the information, rather than > detailing the action that should be taken. > > Agree? I feel comfortable with this characterization, though I would change the term "ie" with "eg" :-) -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 13:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5kp-0000GI-FZ; Wed, 20 Sep 2006 13:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5ko-0008RK-Ls for pcn@ietf.org; Wed, 20 Sep 2006 13:20:58 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5bR-000113-Ba for pcn@ietf.org; Wed, 20 Sep 2006 13:11:18 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8KHAvA13636; Wed, 20 Sep 2006 13:10:57 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:10:53 -0400 Message-Id: <6.2.5.6.0.20060920125957.03f3c838@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Sep 2006 13:10:30 -0400 To: From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain 1.systemhost.net> References: <6.2.5.6.0.20060920115719.033af3d8@nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 17:10:53.0793 (UTC) FILETIME=[BADF8D10:01C6DCD7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil: I am not addressing the specific mechanism or the solution that we may be able to do. But the ability of the mechanism we are working on should be able to satisfy/address the problem indicated (and I think it can, as you pointed out) wrt emergency service usage. Hence then why is this out of scope for the Problem Statement draft (I am not (I am refraining myself from) talking about solutions)? We are not working on providing the exact way to solve the emergency usage. But we want to make sure the network mechanism we come up with can be used by emergency service for emergency service deployment usage. Do you think that is the right thing to do in the Problem Statement draft? (Again, I am just talking only about the Problem Statement draft.) Should we take these discussions as inputs to help us formulate the WG? And hopefully get more support for the BOF to become a WG? Thanks! -- Kwok -- At 12:40 PM 9/20/2006, philip.eardley@bt.com wrote: >I'm not sure, but I think maybe the scope is drifting outside what I >envisaged the scope of the PCN flow pre-emption mechanism. > >I don't think it's about: when an emergency call arrives, pre-empting a >normal call because the new call would overload the network. >This is something that might be done, of course - just I don't think >it's in the scope of PCN. > >My view is that PCN is about "the network" realising that it's >overloaded, and by how much, and providing this info [typically] to the >relevant ingress node of the PCN-region. this node can then take action >based on this info, ie decide which flows to pre-empt. My view is that >the scope is really about how to provide the information, rather than >detailing the action that should be taken. > >Agree? > >phil > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: 20 September 2006 17:07 >To: ken carlberg >Cc: pcn@ietf.org >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Ken: >I think you brought up couple of points below. >My interpretation is: >1. There is a need for 911 type (999 in UK?) of calls to get through >in a public network. > Hence 911 type of calls may be allowed to be admitted while >normal calls get preempt > as a start of a problem statement. >2. There is a need for dedicated emergency service networks to allow >flow/session preemptions. >3. There is a need to allow flow/session preemptions when Emergency >Service Networks and > General Public Networks share network resources. > >Each may have a different affect to the mechanism and solution space >we want to work on >in the PCN BOF/WG. > >Please correct me if I mis-understand or missed your points. > >Thank you very much for your insights. >-- Kwok -- > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > >Kwok, > > > >>Now I have additional questions concerning the use of Preemption > >>for handling Emergency > >>Services. Will Preemption be allowed for Emergency Services? > > > >My understanding is that Japan provides a measure of preemption for > >its 911-type service. However, I don't know the specifics and can't > >offer any more insight. One thing to keep in mind is that the 911- > >type system is inherently an any-to-one (any user to PSAP/911- >operator) model. > > > >As mentioned earlier, the US (and some other countries) have a system > >called GETS that focuses on increasing the probability of call > >completion over their PSTN. This represents an an-to-any model. > >There is also the Wireless Priority System (WPS) in the US that > >allows "displacement" of other users *during* call setup, versus a > >call that has been established. People can google GETS and WPS for > >more info. > > > >>Does some of the > >>jurisdiction you have indicated want to use a separate network for > >>Emergency Services > >>purpose? > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > >(LMR) systems used by first responders. From the IP perspective, the > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > >vendors are starting to infuse IP into those systems. The key thing > >to keep in mind is that these are systems that are under a single > >administrative authority (ie, a single domain). > > > >>Will combining Emergency Services with the normal VoIP calls/sessions > >>be a good Problem Statement that we can add to our Problem > >>Statement draft? > > > >Well, I would view Emergency Services as mostly one motivation for > >what you are trying to accomplish. Aspects like rapid recovery, > >prioritization/labeling/coloring of flows, etc. would seem to be of > >interest to those dealing with emergencies or some other condition. > > > >-ken > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 13:38:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ61X-0003zU-Rl; Wed, 20 Sep 2006 13:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ61W-0003xb-Ow for pcn@ietf.org; Wed, 20 Sep 2006 13:38:14 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ61U-0003i5-8r for pcn@ietf.org; Wed, 20 Sep 2006 13:38:14 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k8KHbnVa020857; Wed, 20 Sep 2006 12:37:49 -0500 (CDT) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Sep 2006 12:37:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 12:37:48 -0500 Message-ID: <7D096A439A3D0D48A3D10872022CFD091B4A84@ILEXC1U02.ndc.lucent.com> In-Reply-To: <6.2.5.6.0.20060920113532.03deadb8@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt thread-index: AcbczUHqAMvoZNuHQ2uJo+FvmhLMLwADdWvQ From: "GOLDMAN, STUART O \(STUART\)" To: "Kwok-Ho Chan" , "Shahram Davari" X-OriginalArrivalTime: 20 Sep 2006 17:37:49.0145 (UTC) FILETIME=[7DB2B490:01C6DCDB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: pcn@ietf.org, ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Kwok-Ho, While you seem to have only mentioned preemption, there should be ways to recognize a call deserving higher than normal preference and giving it that preference to the remaining network resources without having to preempt a call in progress. Yes? Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortel.com]=20 Sent: Wednesday, September 20, 2006 8:54 AM To: Shahram Davari Cc: pcn@ietf.org; ken carlberg Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Shahram: I totally agree. The cell phone network was also jammed during 9/11. I was trying to reach my brother who were stuck in the subway ~2 stops from WTC. So I know exactly how this feels like. But I prefer to let the=20 Police and Firemen to use this resource to help the general public at large. The question becomes: - Does the Emergency Services want to use the same physical network=20 as the general public? -- If Yes. Then should the problem statement becomes: "Some controlled preemption functionality is allowed for=20 Emergency purposes in the general public integrated (voice, video, data, etc) network. This=20 controlled preemption functionality needs to be supported by the network mechanisms." -- If Yes. Then we will need some guidance and help wrt the=20 regulations of the different jurisdictions. Also if the different jurisdictions even wants to use the same=20 network infrastructure for both emergency and public usage purposes. If it is technically possible. By this I am not saying a good solution exist or that I am promoting=20 a specific solution. I am just agreeing that this problem needs to be addressed. We may end up saying we can not solve this problem as of yet. But I=20 wish we can solve it. Regards. -- Kwok -- At 09:34 AM 9/20/2006, Shahram Davari wrote: >Kwok, > >Indeed you raised a good subject. The requirements for emergency=20 >services should be part of the problem statement, and be dealt with=20 >in the proposed solution draft. ITU-T has quite extensive work on=20 >the requirements for Emergency services. > >On a side note, one of the problems identified during a recent=20 >school shooting in Canada was that the emergency and police couldn't=20 >use the phone or cell phones to communicate because the network was=20 >jammed due to high volume of calls between students and their families. > >Yours, >Shahram > > > > -----Original Message----- > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > Sent: Tuesday, September 19, 2006 5:26 PM > > To: ken carlberg > > Cc: pcn@ietf.org > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > Ken: > > Thank you for handling so many of our replies at the same time. :) > > > > YES, on your point of: > > > > >just to recap. I just wanted to point out that there are > > >jurisdictions that do not allow preemption for voice communications > > >used by the general public -- this definitely applies for a number of > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > >VoIP. Hence, I would recommend that the group consider other (re) > > >actions other than preemption....which from the feedback of my > > >original note, seems will be done. > > > > We are using the Problem-Statement draft to put out an > > initial version of what > > we are thinking, as this is still work in progress, there definitely > > are area we > > may have missed. > > > > Thank you for pointing out at least one of them. > > > > I will write some additional text for -01 version of the Problem > > Statement draft to try > > and describe the problem you have indicated (but I will try NOT to > > indicate any solution > > in the Problem Statement draft). > > > > And we will try to have some text in at least some of our Deployment > > Model drafts > > to see if there are good solutions to the problem you > > indicated. There may be > > more than one solution as there may be more than one Deployment Model. > > > > Please Notice I have changed the subject of the E-Mail thread for > > issue tracking purpose. > > Please use this E-Mail Subject for continuing this discussion. > > > > Now I have additional questions concerning the use of Preemption for > > handling Emergency > > Services. Will Preemption be allowed for Emergency Services? > > Does some of the > > jurisdiction you have indicated want to use a separate network for > > Emergency Services > > purpose? Will combining Emergency Services with the normal > > VoIP calls/sessions > > be a good Problem Statement that we can add to our Problem > > Statement draft? > > > > I am concentrating on Problem Statement instead of Solutions > > for now because we > > want to get the Problem Statement cleared away first for the > > BOF purpose. > > > > Thanks! > > -- Kwok -- > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > >Anna, > > > > > >>>maybe we have a different perspective of preemption. as I view it, > > >>>preemption is removing *existing* state (circuit in the PSTN > > >>>world) in > > >>>favor of new state. > > >> > > >>I guess that may be one thing that needs clarification. The way I > > >>view > > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt and > > >>related docs view the issue) is that pre-emption should kick in > > >>when for > > >>whatever reason provisioning mechanisms fail there simply is not > > >>enough > > >>capacity to carry all calls. Setting aside the issue of precedence > > >>for > > >>the moment, the expectation is that the level of traffic needed to > > >>trigger premption is typicaly higher (perhaps substanially higher) > > >>than > > >>the level triggering to stop admission of new flows. That > > means that > > >>when preemption does get triggered, there would actually > > not really be > > >>any new state admitted. > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of > > >understood some of the things you were saying, but there were too > > >many things you left out (why does one have an admission control at > > >level X and a preemption level at X+N?, are you implying that the > > >edge is keeping track of the flows it rejects?....that would seem > > >quite granular in keeping measurements). > > > > > >I'm not sure its necessary to clarify the above. Its probably just > > >best that we agree that future work should include a more detailed > > >discussion of what is preemption in the context of your architecture. > > > > > >>The degree of how far apart preemption and > > >>admission thresholds are is of course a mater of > > configuration, but I > > >>would expect that they would be sufficiently apart to ensure that > > >>you do > > >>not just toggle preempted and new flows. Of course if there > > are higher > > >>precedence calls, then one might expect that a higher > > precedence call > > >>may be established while lower precedence calls may need to be > > >>preempted? > > >> > > >>Perhaps this expectation should be made more transparent in the > > >>drafts? > > >> > > >>>In the US and some other countries, this is not > > >>>allowed in the PSTN. > > >> > > >>Just wanted to make sure I understand exactly what is not allowed. > > >>Are > > >>you saying that PSTN is not allowed to preempt a lower > > precedence call > > >>in order to establish a high recedence call? Or are you > > referring to > > >>the same precedence levels? > > > > > >as an example, in the US PSTN, all calls from the general public are > > >treated with the same level of precedence. the exception are systems > > >like GETS, but they simply increase the probability of call > > >completion -- they do not use preemption. private systems based on > > >MLPP, like Autovon in the DoD and NATO, do allow different levels of > > >priority and subsequent preemption if so needed. rfc-4190 and > > >rfc-4542 provide background on these systems/services along with > > >discussion in the context of IP (since this is the IETF :-) > > > > > >just to recap. I just wanted to point out that there are > > >jurisdictions that do not allow preemption for voice communications > > >used by the general public -- this definitely applies for a number of > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > >VoIP. Hence, I would recommend that the group consider other (re) > > >actions other than preemption....which from the feedback of my > > >original note, seems will be done. > > > > > >regards, > > > > > >-ken > > > > > > > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 13:53:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6Fx-0005m2-UI; Wed, 20 Sep 2006 13:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6Fw-0005iu-67 for pcn@ietf.org; Wed, 20 Sep 2006 13:53:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6Fu-0000nh-Qx for pcn@ietf.org; Wed, 20 Sep 2006 13:53:08 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8KHqJA23641; Wed, 20 Sep 2006 13:52:20 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:51:48 -0400 Message-Id: <6.2.5.6.0.20060920131301.032beee8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Sep 2006 13:51:47 -0400 To: ken carlberg From: "Kwok-Ho Chan" Subject: Re: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: References: <6.2.5.6.0.20060919170712.03cfd1a8@nortel.com> <6.2.5.6.0.20060920115719.033af3d8@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 17:51:48.0105 (UTC) FILETIME=[71C1D790:01C6DCDD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken: Thanks for the clarification! On your last point. The Inter-Domain Model of the Briscoe CL Architecture draft is one of a couple of "Deployment Model"/"Framework"/"Architecture" drafts we are proposing to work on in the PCN WG. Please see http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt that we are indicating we will work on at least 2 deployment models in item 2 under Informational drafts the PCN WG plans to produce. We are not ruling out that other Framework/Architecture can or can not handle the problem you are indicating. Hence the network Interior Node (switches or router) function/mechanism we are standardizing can be used to provide network information for the End Nodes (edge routers or proxies or end systems) to make the appropriate decisions (may they be admission control or preemption decisions). And I hope you will support us in creating this WG and further hope you can invest some sweat equity in this WG. Thanks! -- Kwok -- At 12:51 PM 9/20/2006, ken carlberg wrote: >>I think you brought up couple of points below. >>My interpretation is: >>1. There is a need for 911 type (999 in UK?) of calls to get >>through in a public network. >> Hence 911 type of calls may be allowed to be admitted while >>normal calls get preempt >> as a start of a problem statement. >>2. There is a need for dedicated emergency service networks to >>allow flow/session preemptions. >>3. There is a need to allow flow/session preemptions when Emergency >>Service Networks and >> General Public Networks share network resources. > >no, I'm not saying the above at all. and in fact given the snapshot >of today, quite the opposite. the fact that only one country has a >form of preemption for 911-type calls and most other countries do not >implies there is no (or very little) current need for preemption in >support of 911-type communications. > >the fact that there are some deployments of GETS-like service that >focus on increasing probability of call completion *without* the use >of preemption of existing calls implies that there is a need for a >solution space other than preemption. this is of course under the >context of infrastructure being shared by the general public and >first responders (emergency related personnel). > >In private networks like AUTOVON, LMR, etc, there is a need/desire >for the option of preemptive action. but these are systems that are >closed and usually under a single administrative authority, which >seems out of scope (or outside) the default inter-domain model of the >Briscoe architecture draft. > >-ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 13:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6K3-00018V-TF; Wed, 20 Sep 2006 13:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6K2-00018Q-Sq for pcn@ietf.org; Wed, 20 Sep 2006 13:57:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6K1-00020A-5d for pcn@ietf.org; Wed, 20 Sep 2006 13:57:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Sep 2006 10:57:21 -0700 X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="42736882:sNHT71132656" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KHvKFV007175; Wed, 20 Sep 2006 13:57:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8KHvEuM001073; Wed, 20 Sep 2006 13:57:16 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:57:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Usedto be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 13:56:50 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Usedto be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: AcbczUHqAMvoZNuHQ2uJo+FvmhLMLwADdWvQAAB0stA= From: "Anna Charny \(acharny\)" To: "GOLDMAN, STUART O \(STUART\)" , "Kwok-Ho Chan" , "Shahram Davari" X-OriginalArrivalTime: 20 Sep 2006 17:57:14.0071 (UTC) FILETIME=[340C4E70:01C6DCDE] DKIM-Signature: a=rsa-sha1; q=dns; l=10664; t=1158775040; x=1159639040; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20ProblemStatement=20Issue=20B.9=3ACall=20Preemption=20Not=20Allow edIssue.=20Usedto=20be=20Re=3A=20[PCN]=20draft-chan-pcn-problem-statement-0 0.txt |To:=22GOLDMAN, =20STUART=20O=20\(STUART\)=22=20, =0A=20= 20=20=20=20=20=20=20=22Kwok-Ho=20Chan=22=20, =0A=20=20=20 =20=20=20=20=20=22Shahram=20Davari=22=20; X=v=3Dcisco.com=3B=20h=3DDAklK1QBHzzJ6q/+iPPGC0qxgyI=3D; b=UdDiHxXue83ffOTFG/vFgM1segHlTidCOwq8Y1JQhpWf9fY54/reM9kIMG6Zy/p/mn4O8PRA sWSrIjzQqDqCppgzZHFeZu6yXPh+RjgXj+RrQRYJ4jdzveobjXKimNTe; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: pcn@ietf.org, ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Stuart, I think you are referring to giving scheduling/dropping priority to packets based on call precedence - right? Of course that could be done and there is obviously a large body of work on that (i.e. MLEF-related) - but one of the assumptions that has been made in the PCN context is that precedence information may not be available in the core. There is also an issue that even if you could do that, in the case where we assuming the need of preemption in he PCN context (e.g. massive failure) ther may exist a level of precedence that "does not fit" in the bandwidth left over to it. So in that case one has a choice of affecting the QoS of *all* flows at that level of precedence, or preempting some while guaranteeing the necessary QoS to those that remain. Anna -----Original Message----- From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@lucent.com]=20 Sent: Wednesday, September 20, 2006 1:38 PM To: Kwok-Ho Chan; Shahram Davari Cc: pcn@ietf.org; ken carlberg Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Usedto be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Kwok-Ho, While you seem to have only mentioned preemption, there should be ways to recognize a call deserving higher than normal preference and giving it that preference to the remaining network resources without having to preempt a call in progress. Yes? Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortel.com] Sent: Wednesday, September 20, 2006 8:54 AM To: Shahram Davari Cc: pcn@ietf.org; ken carlberg Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Shahram: I totally agree. The cell phone network was also jammed during 9/11. I was trying to reach my brother who were stuck in the subway ~2 stops from WTC. So I know exactly how this feels like. But I prefer to let the Police and Firemen to use this resource to help the general public at large. The question becomes: - Does the Emergency Services want to use the same physical network as the general public? -- If Yes. Then should the problem statement becomes: "Some controlled preemption functionality is allowed for Emergency purposes in the general public integrated (voice, video, data, etc) network. This controlled preemption functionality needs to be supported by the network mechanisms." -- If Yes. Then we will need some guidance and help wrt the regulations of the different jurisdictions. Also if the different jurisdictions even wants to use the same network infrastructure for both emergency and public usage purposes. If it is technically possible. By this I am not saying a good solution exist or that I am promoting a specific solution. I am just agreeing that this problem needs to be addressed. We may end up saying we can not solve this problem as of yet. But I wish we can solve it. Regards. -- Kwok -- At 09:34 AM 9/20/2006, Shahram Davari wrote: >Kwok, > >Indeed you raised a good subject. The requirements for emergency=20 >services should be part of the problem statement, and be dealt with in=20 >the proposed solution draft. ITU-T has quite extensive work on the=20 >requirements for Emergency services. > >On a side note, one of the problems identified during a recent school=20 >shooting in Canada was that the emergency and police couldn't use the=20 >phone or cell phones to communicate because the network was jammed due=20 >to high volume of calls between students and their families. > >Yours, >Shahram > > > > -----Original Message----- > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > Sent: Tuesday, September 19, 2006 5:26 PM > > To: ken carlberg > > Cc: pcn@ietf.org > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed Issue. > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > Ken: > > Thank you for handling so many of our replies at the same time. :) > > > > YES, on your point of: > > > > >just to recap. I just wanted to point out that there are=20 > > >jurisdictions that do not allow preemption for voice communications > > >used by the general public -- this definitely applies for a number of > > >PSTNs, and I'm sure it will trickle down to certain deployments of=20 > > >VoIP. Hence, I would recommend that the group consider other (re)=20 > > >actions other than preemption....which from the feedback of my=20 > > >original note, seems will be done. > > > > We are using the Problem-Statement draft to put out an initial=20 > > version of what we are thinking, as this is still work in progress,=20 > > there definitely are area we may have missed. > > > > Thank you for pointing out at least one of them. > > > > I will write some additional text for -01 version of the Problem=20 > > Statement draft to try and describe the problem you have indicated=20 > > (but I will try NOT to indicate any solution in the Problem=20 > > Statement draft). > > > > And we will try to have some text in at least some of our Deployment > > Model drafts to see if there are good solutions to the problem you=20 > > indicated. There may be more than one solution as there may be more > > than one Deployment Model. > > > > Please Notice I have changed the subject of the E-Mail thread for=20 > > issue tracking purpose. > > Please use this E-Mail Subject for continuing this discussion. > > > > Now I have additional questions concerning the use of Preemption for > > handling Emergency Services. Will Preemption be allowed for=20 > > Emergency Services? > > Does some of the > > jurisdiction you have indicated want to use a separate network for=20 > > Emergency Services purpose? Will combining Emergency Services with=20 > > the normal VoIP calls/sessions be a good Problem Statement that we=20 > > can add to our Problem Statement draft? > > > > I am concentrating on Problem Statement instead of Solutions for now > > because we want to get the Problem Statement cleared away first for=20 > > the BOF purpose. > > > > Thanks! > > -- Kwok -- > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > >Anna, > > > > > >>>maybe we have a different perspective of preemption. as I view it, > > >>>preemption is removing *existing* state (circuit in the PSTN > > >>>world) in > > >>>favor of new state. > > >> > > >>I guess that may be one thing that needs clarification. The way I > > >>view it (and I think the way=20 > > >>draft-chan-pcn-problem-statement-00.txt and > > >>related docs view the issue) is that pre-emption should kick in=20 > > >>when for whatever reason provisioning mechanisms fail there simply > > >>is not enough capacity to carry all calls. Setting aside the=20 > > >>issue of precedence > > >>for > > >>the moment, the expectation is that the level of traffic needed to > > >>trigger premption is typicaly higher (perhaps substanially higher) > > >>than the level triggering to stop admission of new flows. That > > means that > > >>when preemption does get triggered, there would actually > > not really be > > >>any new state admitted. > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of=20 > > >understood some of the things you were saying, but there were too=20 > > >many things you left out (why does one have an admission control at > > >level X and a preemption level at X+N?, are you implying that the=20 > > >edge is keeping track of the flows it rejects?....that would seem=20 > > >quite granular in keeping measurements). > > > > > >I'm not sure its necessary to clarify the above. Its probably just > > >best that we agree that future work should include a more detailed=20 > > >discussion of what is preemption in the context of your architecture. > > > > > >>The degree of how far apart preemption and admission thresholds=20 > > >>are is of course a mater of > > configuration, but I > > >>would expect that they would be sufficiently apart to ensure that=20 > > >>you do not just toggle preempted and new flows. Of course if there > > are higher > > >>precedence calls, then one might expect that a higher > > precedence call > > >>may be established while lower precedence calls may need to be=20 > > >>preempted? > > >> > > >>Perhaps this expectation should be made more transparent in the=20 > > >>drafts? > > >> > > >>>In the US and some other countries, this is not allowed in the=20 > > >>>PSTN. > > >> > > >>Just wanted to make sure I understand exactly what is not allowed. > > >>Are > > >>you saying that PSTN is not allowed to preempt a lower > > precedence call > > >>in order to establish a high recedence call? Or are you > > referring to > > >>the same precedence levels? > > > > > >as an example, in the US PSTN, all calls from the general public are > > >treated with the same level of precedence. the exception are systems > > >like GETS, but they simply increase the probability of call=20 > > >completion -- they do not use preemption. private systems based on > > >MLPP, like Autovon in the DoD and NATO, do allow different levels of > > >priority and subsequent preemption if so needed. rfc-4190 and > > >rfc-4542 provide background on these systems/services along with=20 > > >discussion in the context of IP (since this is the IETF :-) > > > > > >just to recap. I just wanted to point out that there are=20 > > >jurisdictions that do not allow preemption for voice communications > > >used by the general public -- this definitely applies for a number of > > >PSTNs, and I'm sure it will trickle down to certain deployments of=20 > > >VoIP. Hence, I would recommend that the group consider other (re)=20 > > >actions other than preemption....which from the feedback of my=20 > > >original note, seems will be done. > > > > > >regards, > > > > > >-ken > > > > > > > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 13:58:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6LI-0001P5-Ex; Wed, 20 Sep 2006 13:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6LH-0001P0-Pv for pcn@ietf.org; Wed, 20 Sep 2006 13:58:39 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6LG-0002AK-8x for pcn@ietf.org; Wed, 20 Sep 2006 13:58:39 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8KHwZA25365; Wed, 20 Sep 2006 13:58:35 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:58:22 -0400 Message-Id: <6.2.5.6.0.20060920135249.05849ca8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Sep 2006 13:58:22 -0400 To: "GOLDMAN, STUART O \(STUART\)" From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: <7D096A439A3D0D48A3D10872022CFD091B4A84@ILEXC1U02.ndc.lucen t.com> References: <6.2.5.6.0.20060920113532.03deadb8@nortel.com> <7D096A439A3D0D48A3D10872022CFD091B4A84@ILEXC1U02.ndc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 17:58:22.0504 (UTC) FILETIME=[5CD65A80:01C6DCDE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: pcn@ietf.org, Shahram Davari , ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Stuart: Preemption is just one of possibly multiple decisions the End Node function can take. Hence you are right that there may be other decisions that is of value to the system as a whole, possibly depending on the deployment evironment. These discussions we have so far indicates that we may not want to call the network information the Interior Nodes are providing as "Preemption Mark" indication. Hence these discussions are very helpful for our BOF/WG. Thanks! -- Kwok -- At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: >Kwok-Ho, >While you seem to have only mentioned preemption, there should be ways >to recognize a call deserving higher than normal preference and giving >it that preference to the remaining network resources without having to >preempt a call in progress. Yes? > >Stuart Goldman >Lucent Technologies >sgoldman@lucent.com >602 493 8438 > > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: Wednesday, September 20, 2006 8:54 AM >To: Shahram Davari >Cc: pcn@ietf.org; ken carlberg >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Shahram: >I totally agree. >The cell phone network was also jammed during 9/11. >I was trying to reach my brother who were stuck in the subway >~2 stops from WTC. >So I know exactly how this feels like. But I prefer to let the >Police and Firemen to >use this resource to help the general public at large. > >The question becomes: >- Does the Emergency Services want to use the same physical network >as the general public? >-- If Yes. Then should the problem statement becomes: > "Some controlled preemption functionality is allowed for >Emergency purposes in the general > public integrated (voice, video, data, etc) network. This >controlled preemption functionality > needs to be supported by the network mechanisms." >-- If Yes. Then we will need some guidance and help wrt the >regulations of the different jurisdictions. > Also if the different jurisdictions even wants to use the same >network infrastructure for both > emergency and public usage purposes. If it is technically possible. > >By this I am not saying a good solution exist or that I am promoting >a specific solution. >I am just agreeing that this problem needs to be addressed. >We may end up saying we can not solve this problem as of yet. But I >wish we can solve it. > >Regards. >-- Kwok -- > > >At 09:34 AM 9/20/2006, Shahram Davari wrote: > >Kwok, > > > >Indeed you raised a good subject. The requirements for emergency > >services should be part of the problem statement, and be dealt with > >in the proposed solution draft. ITU-T has quite extensive work on > >the requirements for Emergency services. > > > >On a side note, one of the problems identified during a recent > >school shooting in Canada was that the emergency and police couldn't > >use the phone or cell phones to communicate because the network was > >jammed due to high volume of calls between students and their families. > > > >Yours, > >Shahram > > > > > > > -----Original Message----- > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > Sent: Tuesday, September 19, 2006 5:26 PM > > > To: ken carlberg > > > Cc: pcn@ietf.org > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed >Issue. > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > > > > Ken: > > > Thank you for handling so many of our replies at the same time. :) > > > > > > YES, on your point of: > > > > > > >just to recap. I just wanted to point out that there are > > > >jurisdictions that do not allow preemption for voice communications > > > >used by the general public -- this definitely applies for a number >of > > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > > >VoIP. Hence, I would recommend that the group consider other (re) > > > >actions other than preemption....which from the feedback of my > > > >original note, seems will be done. > > > > > > We are using the Problem-Statement draft to put out an > > > initial version of what > > > we are thinking, as this is still work in progress, there definitely > > > are area we > > > may have missed. > > > > > > Thank you for pointing out at least one of them. > > > > > > I will write some additional text for -01 version of the Problem > > > Statement draft to try > > > and describe the problem you have indicated (but I will try NOT to > > > indicate any solution > > > in the Problem Statement draft). > > > > > > And we will try to have some text in at least some of our Deployment > > > Model drafts > > > to see if there are good solutions to the problem you > > > indicated. There may be > > > more than one solution as there may be more than one Deployment >Model. > > > > > > Please Notice I have changed the subject of the E-Mail thread for > > > issue tracking purpose. > > > Please use this E-Mail Subject for continuing this discussion. > > > > > > Now I have additional questions concerning the use of Preemption for > > > handling Emergency > > > Services. Will Preemption be allowed for Emergency Services? > > > Does some of the > > > jurisdiction you have indicated want to use a separate network for > > > Emergency Services > > > purpose? Will combining Emergency Services with the normal > > > VoIP calls/sessions > > > be a good Problem Statement that we can add to our Problem > > > Statement draft? > > > > > > I am concentrating on Problem Statement instead of Solutions > > > for now because we > > > want to get the Problem Statement cleared away first for the > > > BOF purpose. > > > > > > Thanks! > > > -- Kwok -- > > > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > > >Anna, > > > > > > > >>>maybe we have a different perspective of preemption. as I view >it, > > > >>>preemption is removing *existing* state (circuit in the PSTN > > > >>>world) in > > > >>>favor of new state. > > > >> > > > >>I guess that may be one thing that needs clarification. The way I > > > >>view > > > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt >and > > > >>related docs view the issue) is that pre-emption should kick in > > > >>when for > > > >>whatever reason provisioning mechanisms fail there simply is not > > > >>enough > > > >>capacity to carry all calls. Setting aside the issue of >precedence > > > >>for > > > >>the moment, the expectation is that the level of traffic needed to > > > >>trigger premption is typicaly higher (perhaps substanially higher) > > > >>than > > > >>the level triggering to stop admission of new flows. That > > > means that > > > >>when preemption does get triggered, there would actually > > > not really be > > > >>any new state admitted. > > > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of > > > >understood some of the things you were saying, but there were too > > > >many things you left out (why does one have an admission control at > > > >level X and a preemption level at X+N?, are you implying that the > > > >edge is keeping track of the flows it rejects?....that would seem > > > >quite granular in keeping measurements). > > > > > > > >I'm not sure its necessary to clarify the above. Its probably just > > > >best that we agree that future work should include a more detailed > > > >discussion of what is preemption in the context of your >architecture. > > > > > > > >>The degree of how far apart preemption and > > > >>admission thresholds are is of course a mater of > > > configuration, but I > > > >>would expect that they would be sufficiently apart to ensure that > > > >>you do > > > >>not just toggle preempted and new flows. Of course if there > > > are higher > > > >>precedence calls, then one might expect that a higher > > > precedence call > > > >>may be established while lower precedence calls may need to be > > > >>preempted? > > > >> > > > >>Perhaps this expectation should be made more transparent in the > > > >>drafts? > > > >> > > > >>>In the US and some other countries, this is not > > > >>>allowed in the PSTN. > > > >> > > > >>Just wanted to make sure I understand exactly what is not allowed. > > > >>Are > > > >>you saying that PSTN is not allowed to preempt a lower > > > precedence call > > > >>in order to establish a high recedence call? Or are you > > > referring to > > > >>the same precedence levels? > > > > > > > >as an example, in the US PSTN, all calls from the general public >are > > > >treated with the same level of precedence. the exception are >systems > > > >like GETS, but they simply increase the probability of call > > > >completion -- they do not use preemption. private systems based on > > > >MLPP, like Autovon in the DoD and NATO, do allow different levels >of > > > >priority and subsequent preemption if so needed. rfc-4190 and > > > >rfc-4542 provide background on these systems/services along with > > > >discussion in the context of IP (since this is the IETF :-) > > > > > > > >just to recap. I just wanted to point out that there are > > > >jurisdictions that do not allow preemption for voice communications > > > >used by the general public -- this definitely applies for a number >of > > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > > >VoIP. Hence, I would recommend that the group consider other (re) > > > >actions other than preemption....which from the feedback of my > > > >original note, seems will be done. > > > > > > > >regards, > > > > > > > >-ken > > > > > > > > > > > >_______________________________________________ > > > >PCN mailing list > > > >PCN@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 14:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ77o-00061Q-GK; Wed, 20 Sep 2006 14:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ77n-00060y-J7 for pcn@ietf.org; Wed, 20 Sep 2006 14:48:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ77k-0001hs-QL for pcn@ietf.org; Wed, 20 Sep 2006 14:48:47 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2006 11:48:45 -0700 X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="323363419:sNHT38618188" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KImi5J024501; Wed, 20 Sep 2006 11:48:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8KImhif004578; Wed, 20 Sep 2006 11:48:44 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 14:48:43 -0400 Received: from [161.44.70.107] ([161.44.70.107]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 14:48:43 -0400 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9646D5FC-A95A-4BF2-9152-12CFFE7C1BCB@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 20 Sep 2006 14:48:50 -0400 To: "" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Sep 2006 18:48:43.0317 (UTC) FILETIME=[6561D650:01C6DCE5] DKIM-Signature: a=rsa-sha1; q=dns; l=4822; t=1158778124; x=1159642124; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:Bruce=20Davie=20 |Subject:Re=3A=20ProblemStatement=20Issue=20B.9=3ACall=20Preemption=20Not=20Allow edIssue.=20Used=20to=20be=20Re=3A=20[PCN]=20draft-chan-pcn-problem-statemen t-00.txt; X=v=3Dcisco.com=3B=20h=3DhTqlMPjNSQikvfH/5dJezIJwEvk=3D; b=sn0zG+1Qnh0IRRaP4pvq1tczwq9YkE1K2/gB/0GzjY4Se2cdvOA7RFZ28SpsZQ95SGUwOlch EMfuJXPsV18fZrLlFwrz26CAh2c0uW+oBtyt9Ggg1imbhPdsUo09E+0L; Authentication-Results: sj-dkim-6.cisco.com; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Sep 20, 2006, at 12:40 PM, wrote: > I'm not sure, but I think maybe the scope is drifting outside what I > envisaged the scope of the PCN flow pre-emption mechanism. > > I don't think it's about: when an emergency call arrives, pre- > empting a > normal call because the new call would overload the network. > This is something that might be done, of course - just I don't think > it's in the scope of PCN. > > My view is that PCN is about "the network" realising that it's > overloaded, and by how much, and providing this info [typically] to > the > relevant ingress node of the PCN-region. this node can then take > action > based on this info, ie decide which flows to pre-empt. My view is that > the scope is really about how to provide the information, rather than > detailing the action that should be taken. > > Agree? yes, I agree. I think the main take-away from this discussion is that if you have an architecture that *mandates* pre-emption, it may not be possible to deploy it in some regulatory environments. Thus it would seem wise if PCN tries to produce an architecture in which pre-emption is possible but not mandatory. Beyond that, I'm not sure how much we need to discuss all the different flavors of emergency calls etc, which seems more well-suited to the IEPREP WG. Bruce > > phil > > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: 20 September 2006 17:07 > To: ken carlberg > Cc: pcn@ietf.org > Subject: Re: ProblemStatement Issue B.9:Call Preemption Not > AllowedIssue. Used to be Re: [PCN] > draft-chan-pcn-problem-statement-00.txt > > Ken: > I think you brought up couple of points below. > My interpretation is: > 1. There is a need for 911 type (999 in UK?) of calls to get through > in a public network. > Hence 911 type of calls may be allowed to be admitted while > normal calls get preempt > as a start of a problem statement. > 2. There is a need for dedicated emergency service networks to allow > flow/session preemptions. > 3. There is a need to allow flow/session preemptions when Emergency > Service Networks and > General Public Networks share network resources. > > Each may have a different affect to the mechanism and solution space > we want to work on > in the PCN BOF/WG. > > Please correct me if I mis-understand or missed your points. > > Thank you very much for your insights. > -- Kwok -- > > > At 10:09 AM 9/20/2006, ken carlberg wrote: >> Kwok, >> >>> Now I have additional questions concerning the use of Preemption >>> for handling Emergency >>> Services. Will Preemption be allowed for Emergency Services? >> >> My understanding is that Japan provides a measure of preemption for >> its 911-type service. However, I don't know the specifics and can't >> offer any more insight. One thing to keep in mind is that the 911- >> type system is inherently an any-to-one (any user to PSAP/911- > operator) model. >> >> As mentioned earlier, the US (and some other countries) have a system >> called GETS that focuses on increasing the probability of call >> completion over their PSTN. This represents an an-to-any model. >> There is also the Wireless Priority System (WPS) in the US that >> allows "displacement" of other users *during* call setup, versus a >> call that has been established. People can google GETS and WPS for >> more info. >> >>> Does some of the >>> jurisdiction you have indicated want to use a separate network for >>> Emergency Services >>> purpose? >> >> Yes, AUTOVON is one example. Other examples are Land Mobile Radio >> (LMR) systems used by first responders. From the IP perspective, the >> bulk of the LMR infrastructure is at Layer 2, but IP providers and >> vendors are starting to infuse IP into those systems. The key thing >> to keep in mind is that these are systems that are under a single >> administrative authority (ie, a single domain). >> >>> Will combining Emergency Services with the normal VoIP calls/ >>> sessions >>> be a good Problem Statement that we can add to our Problem >>> Statement draft? >> >> Well, I would view Emergency Services as mostly one motivation for >> what you are trying to accomplish. Aspects like rapid recovery, >> prioritization/labeling/coloring of flows, etc. would seem to be of >> interest to those dealing with emergencies or some other condition. >> >> -ken >> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 15:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7LI-0007G0-B9; Wed, 20 Sep 2006 15:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7LH-0007Fv-Gn for pcn@ietf.org; Wed, 20 Sep 2006 15:02:43 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ7LG-0003Mc-2k for pcn@ietf.org; Wed, 20 Sep 2006 15:02:43 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8KItZs13945; Wed, 20 Sep 2006 14:55:35 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 15:01:50 -0400 Message-Id: <6.2.5.6.0.20060920145041.0333ba88@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Sep 2006 15:01:50 -0400 To: From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain 1.systemhost.net> References: <6.2.5.6.0.20060920115719.033af3d8@nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 19:01:50.0603 (UTC) FILETIME=[3AA425B0:01C6DCE7] X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil: Your specific question: >My view is that PCN is about "the network" realising that it's >overloaded, and by how much, and providing this info [typically] to the >relevant ingress node of the PCN-region. this node can then take action >based on this info, ie decide which flows to pre-empt. My view is that >the scope is really about how to provide the information, rather than >detailing the action that should be taken. > >Agree? I totally agree on the point of the network providing the information as the scope of the PCN WG (this is what we want to standardize). And that the decision + action can be separate. And we may not specifically solve the emergency service deployment solution here in PCN WG. But the discussion we have so far is of value to how we put together the Problem Statement draft. For example, our work in PCN WG does (should) not stop the emergency services community to use the network mechanism we standardize to provide an emergency service solution. We should try to help if we can (and I think we can without deviating from our other goals). Thanks! -- Kwok -- At 12:40 PM 9/20/2006, philip.eardley@bt.com wrote: >I'm not sure, but I think maybe the scope is drifting outside what I >envisaged the scope of the PCN flow pre-emption mechanism. > >I don't think it's about: when an emergency call arrives, pre-empting a >normal call because the new call would overload the network. >This is something that might be done, of course - just I don't think >it's in the scope of PCN. > >My view is that PCN is about "the network" realising that it's >overloaded, and by how much, and providing this info [typically] to the >relevant ingress node of the PCN-region. this node can then take action >based on this info, ie decide which flows to pre-empt. My view is that >the scope is really about how to provide the information, rather than >detailing the action that should be taken. > >Agree? > >phil > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: 20 September 2006 17:07 >To: ken carlberg >Cc: pcn@ietf.org >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Ken: >I think you brought up couple of points below. >My interpretation is: >1. There is a need for 911 type (999 in UK?) of calls to get through >in a public network. > Hence 911 type of calls may be allowed to be admitted while >normal calls get preempt > as a start of a problem statement. >2. There is a need for dedicated emergency service networks to allow >flow/session preemptions. >3. There is a need to allow flow/session preemptions when Emergency >Service Networks and > General Public Networks share network resources. > >Each may have a different affect to the mechanism and solution space >we want to work on >in the PCN BOF/WG. > >Please correct me if I mis-understand or missed your points. > >Thank you very much for your insights. >-- Kwok -- > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > >Kwok, > > > >>Now I have additional questions concerning the use of Preemption > >>for handling Emergency > >>Services. Will Preemption be allowed for Emergency Services? > > > >My understanding is that Japan provides a measure of preemption for > >its 911-type service. However, I don't know the specifics and can't > >offer any more insight. One thing to keep in mind is that the 911- > >type system is inherently an any-to-one (any user to PSAP/911- >operator) model. > > > >As mentioned earlier, the US (and some other countries) have a system > >called GETS that focuses on increasing the probability of call > >completion over their PSTN. This represents an an-to-any model. > >There is also the Wireless Priority System (WPS) in the US that > >allows "displacement" of other users *during* call setup, versus a > >call that has been established. People can google GETS and WPS for > >more info. > > > >>Does some of the > >>jurisdiction you have indicated want to use a separate network for > >>Emergency Services > >>purpose? > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > >(LMR) systems used by first responders. From the IP perspective, the > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > >vendors are starting to infuse IP into those systems. The key thing > >to keep in mind is that these are systems that are under a single > >administrative authority (ie, a single domain). > > > >>Will combining Emergency Services with the normal VoIP calls/sessions > >>be a good Problem Statement that we can add to our Problem > >>Statement draft? > > > >Well, I would view Emergency Services as mostly one motivation for > >what you are trying to accomplish. Aspects like rapid recovery, > >prioritization/labeling/coloring of flows, etc. would seem to be of > >interest to those dealing with emergencies or some other condition. > > > >-ken > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 15:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7Nl-000104-LR; Wed, 20 Sep 2006 15:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ7Nj-0000zy-Sv for pcn@ietf.org; Wed, 20 Sep 2006 15:05:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ7Nh-0003e0-8J for pcn@ietf.org; Wed, 20 Sep 2006 15:05:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2006 12:05:12 -0700 X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="342384213:sNHT39045556" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KJ5C0q010212; Wed, 20 Sep 2006 12:05:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8KJ5CQV028666; Wed, 20 Sep 2006 12:05:12 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 12:05:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.89.46]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 12:05:11 -0700 Message-Id: <4.3.2.7.2.20060920134620.03b430a0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Sep 2006 14:05:10 -0500 To: , , From: "James M. Polk" In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain 1.systemhost.net> References: <6.2.5.6.0.20060920115719.033af3d8@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 19:05:11.0494 (UTC) FILETIME=[B261AE60:01C6DCE7] DKIM-Signature: a=rsa-sha1; q=dns; l=6352; t=1158779112; x=1159643112; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Problem=20of=20differentiating=20packets=20by=20flows=20(i.e.=20calls); X=v=3Dcisco.com=3B=20h=3DRE7bwQ9L986wJgfLyCmIKVvLTWw=3D; b=gYKHHBNUz+zYMA5Lf7mYKtUh9UF1KKZw0nTY6iknKytyZ+66oSfPE272jRIhUCqMD/0VSWDA WsxYcRYIWDGD+DuwrYGV7Q4TJU+FnVFQeMqv7X7qp2JH0DvfoanVE+XB; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: pcn@ietf.org Subject: [PCN] Problem of differentiating packets by flows (i.e. calls) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org At 05:40 PM 9/20/2006 +0100, philip.eardley@bt.com wrote: >I'm not sure, but I think maybe the scope is drifting outside what I >envisaged the scope of the PCN flow pre-emption mechanism. > >I don't think it's about: when an emergency call arrives, pre-empting a >normal call because the new call would overload the network. >This is something that might be done, of course - just I don't think >it's in the scope of PCN. > >My view is that PCN is about "the network" realising that it's >overloaded, and by how much, and providing this info [typically] to the >relevant ingress node of the PCN-region. this node can then take action >based on this info, ie decide which flows to pre-empt. My view is that >the scope is really about how to provide the information, rather than >detailing the action that should be taken. Philip (and all) there are several aspects of this that need to be brought up, if any are. Consider this: if "the network" is to "tell" the ingress node it is overloading the core by admitting additional packets, is this with a WFQ, or RED or FIFD (first-in, first-dropped) type of mechanism - until there is no more overload caused by this node? If packets are to be dropped: - are some more important than others? - are some to be considered part of a flow, where others are to be considered part of another flow? - are pacekts to be considered part of a flow (i.e. a call) at all, or is it first-in, first-dealt--with? If flows (meaning the packets associated with the call between Alice and Bob are different than the packets associated between Carol and Dave) are to be treated differently (i.e. packets from one flow are dropped and packets from a parallel flow are not), how is this indicated and loarned by the ingress node? MLEF certainly isn't the answer I hope. Next aspect is wrt emergency calling, what's the indication that Alice's call is to an emergency response center, and Bob's is not (at the ingress node)? Without the ability to identify emergency calls from non-emergency calls, talking about emergency calling getting any preferential treatment is pointless. Next aspect, how is the layer 3 mechanism of packet drops bubbled up to the signaling layer? Or does the affected user(s) just realize their quality is getting poorer? Since the ingress node is not the endpoint within any flow, does this ingress node provide any feedback to the originator of the packet(s)? Or is this merely expected to be learned through the normal course of dropped packets within any network? Final aspect, if how to differentiate one flow from another flow is possible, how does this BoF's effort solve for how this is not hacked and misused for a game of Doom 3 or Quake 4 between users? IMO, anything from this BoF should address (at least in requirements) these "aspects" to be addressed in any solution from those requirements. >Agree? > >phil > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: 20 September 2006 17:07 >To: ken carlberg >Cc: pcn@ietf.org >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Ken: >I think you brought up couple of points below. >My interpretation is: >1. There is a need for 911 type (999 in UK?) of calls to get through >in a public network. > Hence 911 type of calls may be allowed to be admitted while >normal calls get preempt > as a start of a problem statement. >2. There is a need for dedicated emergency service networks to allow >flow/session preemptions. >3. There is a need to allow flow/session preemptions when Emergency >Service Networks and > General Public Networks share network resources. > >Each may have a different affect to the mechanism and solution space >we want to work on >in the PCN BOF/WG. > >Please correct me if I mis-understand or missed your points. > >Thank you very much for your insights. >-- Kwok -- > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > >Kwok, > > > >>Now I have additional questions concerning the use of Preemption > >>for handling Emergency > >>Services. Will Preemption be allowed for Emergency Services? > > > >My understanding is that Japan provides a measure of preemption for > >its 911-type service. However, I don't know the specifics and can't > >offer any more insight. One thing to keep in mind is that the 911- > >type system is inherently an any-to-one (any user to PSAP/911- >operator) model. > > > >As mentioned earlier, the US (and some other countries) have a system > >called GETS that focuses on increasing the probability of call > >completion over their PSTN. This represents an an-to-any model. > >There is also the Wireless Priority System (WPS) in the US that > >allows "displacement" of other users *during* call setup, versus a > >call that has been established. People can google GETS and WPS for > >more info. > > > >>Does some of the > >>jurisdiction you have indicated want to use a separate network for > >>Emergency Services > >>purpose? > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > >(LMR) systems used by first responders. From the IP perspective, the > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > >vendors are starting to infuse IP into those systems. The key thing > >to keep in mind is that these are systems that are under a single > >administrative authority (ie, a single domain). > > > >>Will combining Emergency Services with the normal VoIP calls/sessions > >>be a good Problem Statement that we can add to our Problem > >>Statement draft? > > > >Well, I would view Emergency Services as mostly one motivation for > >what you are trying to accomplish. Aspects like rapid recovery, > >prioritization/labeling/coloring of flows, etc. would seem to be of > >interest to those dealing with emergencies or some other condition. > > > >-ken > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 15:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ82c-0004vb-LW; Wed, 20 Sep 2006 15:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ82b-0004vS-Eg for pcn@ietf.org; Wed, 20 Sep 2006 15:47:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ82Z-0002yE-M4 for pcn@ietf.org; Wed, 20 Sep 2006 15:47:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Sep 2006 12:47:27 -0700 X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="42757599:sNHT50311312" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KJlRYF030041; Wed, 20 Sep 2006 15:47:27 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8KJlQda005873; Wed, 20 Sep 2006 15:47:27 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 15:47:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls) Date: Wed, 20 Sep 2006 15:47:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Problem of differentiating packets by flows (i.e. calls) Thread-Index: Acbc58iEnhmHcDeOS22vqaBPncV1lAAAJqCg From: "Anna Charny \(acharny\)" To: "James Polk \(jmpolk\)" , , , X-OriginalArrivalTime: 20 Sep 2006 19:47:26.0686 (UTC) FILETIME=[997947E0:01C6DCED] DKIM-Signature: a=rsa-sha1; q=dns; l=10280; t=1158781647; x=1159645647; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Problem=20of=20differentiating=20packets=20by=20flows=20 (i.e.=20calls) |To:=22James=20Polk=20\(jmpolk\)=22=20, =20, =0A=20=20=20=20=20=20=20=20, =20; X=v=3Dcisco.com=3B=20h=3DNiyU63bWOuNhawHaMGWRo42UQ/M=3D; b=YI8u6ICysOKxX1jyWXvQIq4Yr7PxJrUpdAQjKLO2MTV0VaUNeOA3cnL2YpKtH3gFpUSCsTrs F+Tr/K2x4bjy/aSIvjg/tqTLFV/gRW13wWRfay/8902i2lDhBv9Ij3DL; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi James, A few comments/answers below:=20 -----Original Message----- From: James Polk (jmpolk)=20 Sent: Wednesday, September 20, 2006 3:05 PM To: philip.eardley@bt.com; khchan@nortel.com; carlberg@g11.org.uk Cc: pcn@ietf.org Subject: [PCN] Problem of differentiating packets by flows (i.e. calls) At 05:40 PM 9/20/2006 +0100, philip.eardley@bt.com wrote: >I'm not sure, but I think maybe the scope is drifting outside what I=20 >envisaged the scope of the PCN flow pre-emption mechanism. > >I don't think it's about: when an emergency call arrives, pre-empting a >normal call because the new call would overload the network. >This is something that might be done, of course - just I don't think=20 >it's in the scope of PCN. > >My view is that PCN is about "the network" realising that it's=20 >overloaded, and by how much, and providing this info [typically] to the >relevant ingress node of the PCN-region. this node can then take action >based on this info, ie decide which flows to pre-empt. My view is that=20 >the scope is really about how to provide the information, rather than=20 >detailing the action that should be taken. Philip (and all) there are several aspects of this that need to be brought up, if any are. Consider this: if "the network" is to "tell" the ingress node it is overloading the core by admitting additional packets, is this with a WFQ, or RED or FIFD (first-in, first-dropped) type of mechanism - until there is no more overload caused by this node? [Anna] There is actually no explicit assumptions of the underlying queueing that (I think) is necessary. The overload is defined based on the "desired" capacity - e.g. the same capacity that would be "provisioned" in, say DiffServ EF context. The simplest assumption then is that the PCN traffic has a queue for itself (could be a priority queue or a queue in a WFQ). A particular solution may use different means of implementing the measurement of overload wrt that "desired" capacity. E.g. draft-brisco-cl-architecture offers to do that based on the virtual queue. But that virtual queue is largely independent of the underlying queueing/scheduling. =20 If packets are to be dropped: - are some more important than others? - are some to be considered part of a flow, where others are to be considered part of another flow? - are pacekts to be considered part of a flow (i.e. a call) at all, or is it first-in, first-dealt--with? [Anna] There are no assumption that "importance" of packets is known, and there are no assumptions that it is known at the core which packets belong to which flows. If flows (meaning the packets associated with the call between Alice and Bob are different than the packets associated between Carol and Dave) are to be treated differently (i.e. packets from one flow are dropped and packets from a parallel flow are not), how is this indicated and loarned by the ingress node? MLEF certainly isn't the answer I hope. [Anna] Again, there is explicitly no assumptions that there is info available at the core to tell which packets are from Alice and which are from Bob, not which of those are more important than others. The assumption is that the core only deals with figuring out whether the total (PCN) traffic is above or below the desired level, and communicates that info to the edge. The edge, on the other hand does have the per-flow info, and can then make a per-flow based decision on who to preempt/accept based on this info. However, IF importance/precedence info is available at the core, then of course additional mechanisms ae available. It seems to me that from the BoF/WG standpoint, discussion of this boils down to work on deployment models. The assumptions relevant to the particular deployment models definely have to work with PCN assumptions and mechanism for PCn to be viable in those models. Next aspect is wrt emergency calling, what's the indication that Alice's call is to an emergency response center, and Bob's is not (at the ingress node)? [Anna] Some discussion of that is already in the draft-briscoe-cl-architecture. A short answer is repeating the above: the ingress node has the flexibility to decide *which* calls to prefer, based on the call/flow info available to it. The core is assumeed to not be able to tell Alice from Bob anyway. Without the ability to identify emergency calls from non-emergency calls, talking about emergency calling getting any preferential treatment is pointless. [Anna] As the ingress has the necessary info to distinguish emergency vs non-emergency calls, it can then make the decisions based on that. =20 Next aspect, how is the layer 3 mechanism of packet drops bubbled up to the signaling layer? Or does the affected user(s) just realize their quality is getting poorer? [Anna] The goal of PCN is to avoid packet drops under normal circumstances by limiting the number of admitted calls to be below the load that can be supported without loss or performance degradation. In the case of failures or other unexpected events, the goal of pcn is to preempt enough flows to make sure the remaining ones do no get QoS degradation. If preemption is not used (or in the short period of time until preemption takes effect), then yes, the quality is just getting poorer for all flows involved. Since the ingress node is not the endpoint within any flow, does this ingress node provide any feedback to the originator of the packet(s)? Or is this merely expected to be learned through the normal course of dropped packets within any network? [Anna] The answer depends on the deployment model. The model assumed in draft-briscoe-cl-architecture (but not the only one possible) is the one where the core is for example an rsvp hop, and so the edges use RSVP to admit or bring down a call end-to-end. =20 Final aspect, if how to differentiate one flow from another flow is possible, how does this BoF's effort solve for how this is not hacked and misused for a game of Doom 3 or Quake 4 between users? [Anna] Well, the problem statement needs to scope the problem that is being dealt with. My answers above correspond to the scope that is currently being proposed (or at least I believe so :-). Feedback on whether it should be broadened (or narrowed) is exactly what we are asking for. I guess I am not entirely sure whether you are arguing whether the "aspects" you are bringing up should or should not be within the scope? Thank you, Anna=20 IMO, anything from this BoF should address (at least in requirements) these "aspects" to be addressed in any solution from those requirements. >Agree? > >phil > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: 20 September 2006 17:07 >To: ken carlberg >Cc: pcn@ietf.org >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Ken: >I think you brought up couple of points below. >My interpretation is: >1. There is a need for 911 type (999 in UK?) of calls to get through >in a public network. > Hence 911 type of calls may be allowed to be admitted while >normal calls get preempt > as a start of a problem statement. >2. There is a need for dedicated emergency service networks to allow >flow/session preemptions. >3. There is a need to allow flow/session preemptions when Emergency >Service Networks and > General Public Networks share network resources. > >Each may have a different affect to the mechanism and solution space >we want to work on >in the PCN BOF/WG. > >Please correct me if I mis-understand or missed your points. > >Thank you very much for your insights. >-- Kwok -- > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > >Kwok, > > > >>Now I have additional questions concerning the use of Preemption > >>for handling Emergency > >>Services. Will Preemption be allowed for Emergency Services? > > > >My understanding is that Japan provides a measure of preemption for > >its 911-type service. However, I don't know the specifics and can't > >offer any more insight. One thing to keep in mind is that the 911- > >type system is inherently an any-to-one (any user to PSAP/911- >operator) model. > > > >As mentioned earlier, the US (and some other countries) have a system > >called GETS that focuses on increasing the probability of call > >completion over their PSTN. This represents an an-to-any model. > >There is also the Wireless Priority System (WPS) in the US that > >allows "displacement" of other users *during* call setup, versus a > >call that has been established. People can google GETS and WPS for > >more info. > > > >>Does some of the > >>jurisdiction you have indicated want to use a separate network for > >>Emergency Services > >>purpose? > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > >(LMR) systems used by first responders. From the IP perspective, the > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > >vendors are starting to infuse IP into those systems. The key thing > >to keep in mind is that these are systems that are under a single > >administrative authority (ie, a single domain). > > > >>Will combining Emergency Services with the normal VoIP calls/sessions > >>be a good Problem Statement that we can add to our Problem > >>Statement draft? > > > >Well, I would view Emergency Services as mostly one motivation for > >what you are trying to accomplish. Aspects like rapid recovery, > >prioritization/labeling/coloring of flows, etc. would seem to be of > >interest to those dealing with emergencies or some other condition. > > > >-ken > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 16:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8LE-0004Jk-7p; Wed, 20 Sep 2006 16:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8LC-0004J7-Rl for pcn@ietf.org; Wed, 20 Sep 2006 16:06:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8LB-0005q9-3P for pcn@ietf.org; Wed, 20 Sep 2006 16:06:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2006 13:06:40 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KK6etO001023; Wed, 20 Sep 2006 13:06:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8KK6eYp006896; Wed, 20 Sep 2006 13:06:40 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:06:40 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.89.46]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:06:39 -0700 Message-Id: <4.3.2.7.2.20060920150045.03a55cf0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Sep 2006 15:06:38 -0500 To: "Anna Charny \(acharny\)" , , , From: "James M. Polk" Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Sep 2006 20:06:39.0774 (UTC) FILETIME=[48C48BE0:01C6DCF0] DKIM-Signature: a=rsa-sha1; q=dns; l=11419; t=1158782800; x=1159646800; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[PCN]=20Problem=20of=20differentiating=20packets=20by=20flows=20 (i.e.=0A=20=20calls); X=v=3Dcisco.com=3B=20h=3Dh3xKT+05dZ+/mSnWW5O4qHZLTyI=3D; b=rGA+dpxmyZAwiTUf8sAuXt/HcQiIY3B1xsnweMog5782oAszNN4q7C8PBbmlXh68dfyiHb4t YmTMT+LQANOj49idB9N7fJ0ZBSZjAWRVN8vUXl1VlggCCeHvugJJescs; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Said below: "The edge, on the other hand does have the per-flow info, and can then make a per-flow based decision on who to preempt/accept based on this info. " How will the ingress node have all the necessary information in it to make a decision that Alice's call is more important than Bob's? Will the edge node have access to SIP signaling (for example)? Without this (or the like) or without there being a reservation to the ingress dge node from the packet originator, what is/are the indicator(s) distinguishing one packet from another (meaning one call from another)? Without this, any discussion of prioritizing one packet over another is pointless (which I said in my original email), and probably out of scope of PCN. At 12:47 PM 9/20/2006 -0700, Anna Charny \(acharny\) wrote: >Hi James, > >A few comments/answers below: > >-----Original Message----- >From: James Polk (jmpolk) >Sent: Wednesday, September 20, 2006 3:05 PM >To: philip.eardley@bt.com; khchan@nortel.com; carlberg@g11.org.uk >Cc: pcn@ietf.org >Subject: [PCN] Problem of differentiating packets by flows (i.e. calls) > >At 05:40 PM 9/20/2006 +0100, philip.eardley@bt.com wrote: > >I'm not sure, but I think maybe the scope is drifting outside what I > >envisaged the scope of the PCN flow pre-emption mechanism. > > > >I don't think it's about: when an emergency call arrives, pre-empting a > > >normal call because the new call would overload the network. > >This is something that might be done, of course - just I don't think > >it's in the scope of PCN. > > > >My view is that PCN is about "the network" realising that it's > >overloaded, and by how much, and providing this info [typically] to the > > >relevant ingress node of the PCN-region. this node can then take action > > >based on this info, ie decide which flows to pre-empt. My view is that > >the scope is really about how to provide the information, rather than > >detailing the action that should be taken. > >Philip (and all) > >there are several aspects of this that need to be brought up, if any >are. Consider this: > >if "the network" is to "tell" the ingress node it is overloading the >core by admitting additional packets, is this with a WFQ, or RED or FIFD >(first-in, first-dropped) type of mechanism - until there is no more >overload caused by this node? > >[Anna] There is actually no explicit assumptions of the underlying >queueing that (I think) is necessary. The overload is defined based on >the "desired" capacity - e.g. the same capacity that would be >"provisioned" in, say DiffServ EF context. The simplest assumption then >is that the PCN traffic has a queue for itself (could be a priority >queue or a queue in a WFQ). A particular solution may use different >means of implementing the measurement of overload wrt that "desired" >capacity. E.g. draft-brisco-cl-architecture offers to do that based on >the virtual queue. But that virtual queue is largely independent of the >underlying queueing/scheduling. > >If packets are to be dropped: > >- are some more important than others? > >- are some to be considered part of a flow, where others are to be >considered part of another flow? > >- are pacekts to be considered part of a flow (i.e. a call) at all, or >is it first-in, first-dealt--with? > >[Anna] There are no assumption that "importance" of packets is known, >and there are no assumptions that it is known at the core which packets >belong to which flows. > >If flows (meaning the packets associated with the call between Alice and >Bob are different than the packets associated between Carol and Dave) >are to be treated differently (i.e. packets from one flow are dropped >and packets from a parallel flow are not), how is this indicated and >loarned by the ingress node? > >MLEF certainly isn't the answer I hope. > >[Anna] Again, there is explicitly no assumptions that there is info >available at the core to tell which packets are from Alice and which are >from Bob, not which of those are more important than others. The >assumption is that the core only deals with figuring out whether the >total (PCN) traffic is above or below the desired level, and >communicates that info to the edge. The edge, on the other hand does >have the per-flow info, and can then make a per-flow based decision on >who to preempt/accept based on this info. However, IF >importance/precedence info is available at the core, then of course >additional mechanisms ae available. It seems to me that from the >BoF/WG standpoint, discussion of this boils down to work on deployment >models. The assumptions relevant to the particular deployment models >definely have to work with PCN assumptions and mechanism for PCn to be >viable in those models. > > >Next aspect is wrt emergency calling, what's the indication that Alice's >call is to an emergency response center, and Bob's is not (at the >ingress node)? > >[Anna] Some discussion of that is already in the >draft-briscoe-cl-architecture. A short answer is repeating the above: >the ingress node has the flexibility to decide *which* calls to prefer, >based on the call/flow info available to it. The core is assumeed to >not be able to tell Alice from Bob anyway. > >Without the ability to identify emergency calls from non-emergency >calls, talking about emergency calling getting any preferential >treatment is pointless. > >[Anna] As the ingress has the necessary info to distinguish emergency >vs non-emergency calls, it can then make the decisions based on that. > >Next aspect, how is the layer 3 mechanism of packet drops bubbled up to >the signaling layer? Or does the affected user(s) just realize their >quality is getting poorer? > >[Anna] The goal of PCN is to avoid packet drops under normal >circumstances by limiting the number of admitted calls to be below the >load that can be supported without loss or performance degradation. In >the case of failures or other unexpected events, the goal of pcn is to >preempt enough flows to make sure the remaining ones do no get QoS >degradation. If preemption is not used (or in the short period of time >until preemption takes effect), then yes, the quality is just getting >poorer for all flows involved. > >Since the ingress node is not the endpoint within any flow, does this >ingress node provide any feedback to the originator of the packet(s)? Or >is this merely expected to be learned through the normal course of >dropped packets within any network? > >[Anna] The answer depends on the deployment model. The model assumed in >draft-briscoe-cl-architecture (but not the only one possible) is the one >where the core is for example an rsvp hop, and so the edges use RSVP to >admit or bring down a call end-to-end. > > >Final aspect, if how to differentiate one flow from another flow is >possible, how does this BoF's effort solve for how this is not hacked >and misused for a game of Doom 3 or Quake 4 between users? > >[Anna] Well, the problem statement needs to scope the problem that is >being dealt with. My answers above correspond to the scope that is >currently being proposed (or at least I believe so :-). Feedback on >whether it should be broadened (or narrowed) is exactly what we are >asking for. I guess I am not entirely sure whether you are arguing >whether the "aspects" you are bringing up should or should not be within >the scope? > >Thank you, >Anna > > > >IMO, anything from this BoF should address (at least in requirements) >these "aspects" to be addressed in any solution from those requirements. > > > >Agree? > > > >phil > > > >-----Original Message----- > >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > >Sent: 20 September 2006 17:07 > >To: ken carlberg > >Cc: pcn@ietf.org > >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not > >AllowedIssue. Used to be Re: [PCN] > >draft-chan-pcn-problem-statement-00.txt > > > >Ken: > >I think you brought up couple of points below. > >My interpretation is: > >1. There is a need for 911 type (999 in UK?) of calls to get through > >in a public network. > > Hence 911 type of calls may be allowed to be admitted while > >normal calls get preempt > > as a start of a problem statement. > >2. There is a need for dedicated emergency service networks to allow > >flow/session preemptions. > >3. There is a need to allow flow/session preemptions when Emergency > >Service Networks and > > General Public Networks share network resources. > > > >Each may have a different affect to the mechanism and solution space > >we want to work on > >in the PCN BOF/WG. > > > >Please correct me if I mis-understand or missed your points. > > > >Thank you very much for your insights. > >-- Kwok -- > > > > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > > >Kwok, > > > > > >>Now I have additional questions concerning the use of Preemption > > >>for handling Emergency > > >>Services. Will Preemption be allowed for Emergency Services? > > > > > >My understanding is that Japan provides a measure of preemption for > > >its 911-type service. However, I don't know the specifics and can't > > >offer any more insight. One thing to keep in mind is that the 911- > > >type system is inherently an any-to-one (any user to PSAP/911- > >operator) model. > > > > > >As mentioned earlier, the US (and some other countries) have a system > > >called GETS that focuses on increasing the probability of call > > >completion over their PSTN. This represents an an-to-any model. > > >There is also the Wireless Priority System (WPS) in the US that > > >allows "displacement" of other users *during* call setup, versus a > > >call that has been established. People can google GETS and WPS for > > >more info. > > > > > >>Does some of the > > >>jurisdiction you have indicated want to use a separate network for > > >>Emergency Services > > >>purpose? > > > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > > >(LMR) systems used by first responders. From the IP perspective, the > > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > > >vendors are starting to infuse IP into those systems. The key thing > > >to keep in mind is that these are systems that are under a single > > >administrative authority (ie, a single domain). > > > > > >>Will combining Emergency Services with the normal VoIP >calls/sessions > > >>be a good Problem Statement that we can add to our Problem > > >>Statement draft? > > > > > >Well, I would view Emergency Services as mostly one motivation for > > >what you are trying to accomplish. Aspects like rapid recovery, > > >prioritization/labeling/coloring of flows, etc. would seem to be of > > >interest to those dealing with emergencies or some other condition. > > > > > >-ken > > > > > > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 17:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9p1-0004ty-Cy; Wed, 20 Sep 2006 17:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9oz-0004t5-Ga for pcn@ietf.org; Wed, 20 Sep 2006 17:41:33 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ9oy-0003jv-Ub for pcn@ietf.org; Wed, 20 Sep 2006 17:41:33 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8KLfKA29171; Wed, 20 Sep 2006 17:41:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls) Date: Wed, 20 Sep 2006 17:41:03 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650C2C31E0@zcarhxm1.corp.nortel.com> In-Reply-To: <4.3.2.7.2.20060920150045.03a55cf0@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Problem of differentiating packets by flows (i.e. calls) Thread-Index: Acbc8GcDTqE/bRiMT1G5jw80dPyMjgACcn2A From: "Jozef Babiarz" To: "James M. Polk" , "Anna Charny \(acharny\)" , , "Kwok-Ho Chan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org James, in one of the deployment models, the pre-congestion information from the network is passed to the SIP endpoints. The SIP endpoint based on its service policy take the appropriate action. Currently, I'm writing the deployment model that explains how this would work. In the deployment model that I'm using the pre-congestion information is passed via the ECN bits in the IP header of packets received by the SIP endpoint. SIP signalling is used to close the control loop with the SIP traffic originating endpoint for admission and flow termination (preemption).=20 Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Wednesday, September 20, 2006 4:07 PM To: Anna Charny (acharny); philip.eardley@bt.com; Chan, Kwok-Ho (BL60:470); carlberg@g11.org.uk Cc: pcn@ietf.org Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls) Said below: "The edge, on the other hand does have the per-flow info, and can then make a per-flow based decision on who to preempt/accept based on this info. " How will the ingress node have all the necessary information in it to make=20 a decision that Alice's call is more important than Bob's? Will the edge node have access to SIP signaling (for example)? Without this=20 (or the like) or without there being a reservation to the ingress dge node=20 from the packet originator, what is/are the indicator(s) distinguishing one=20 packet from another (meaning one call from another)? Without this, any discussion of prioritizing one packet over another is=20 pointless (which I said in my original email), and probably out of scope of=20 PCN. At 12:47 PM 9/20/2006 -0700, Anna Charny \(acharny\) wrote: >Hi James, > >A few comments/answers below: > >-----Original Message----- >From: James Polk (jmpolk) >Sent: Wednesday, September 20, 2006 3:05 PM >To: philip.eardley@bt.com; khchan@nortel.com; carlberg@g11.org.uk >Cc: pcn@ietf.org >Subject: [PCN] Problem of differentiating packets by flows (i.e. calls) > >At 05:40 PM 9/20/2006 +0100, philip.eardley@bt.com wrote: > >I'm not sure, but I think maybe the scope is drifting outside what I > >envisaged the scope of the PCN flow pre-emption mechanism. > > > >I don't think it's about: when an emergency call arrives, pre-empting a > > >normal call because the new call would overload the network. > >This is something that might be done, of course - just I don't think > >it's in the scope of PCN. > > > >My view is that PCN is about "the network" realising that it's > >overloaded, and by how much, and providing this info [typically] to the > > >relevant ingress node of the PCN-region. this node can then take action > > >based on this info, ie decide which flows to pre-empt. My view is that > >the scope is really about how to provide the information, rather than > >detailing the action that should be taken. > >Philip (and all) > >there are several aspects of this that need to be brought up, if any >are. Consider this: > >if "the network" is to "tell" the ingress node it is overloading the >core by admitting additional packets, is this with a WFQ, or RED or FIFD >(first-in, first-dropped) type of mechanism - until there is no more >overload caused by this node? > >[Anna] There is actually no explicit assumptions of the underlying >queueing that (I think) is necessary. The overload is defined based on >the "desired" capacity - e.g. the same capacity that would be >"provisioned" in, say DiffServ EF context. The simplest assumption then >is that the PCN traffic has a queue for itself (could be a priority >queue or a queue in a WFQ). A particular solution may use different >means of implementing the measurement of overload wrt that "desired" >capacity. E.g. draft-brisco-cl-architecture offers to do that based on >the virtual queue. But that virtual queue is largely independent of the >underlying queueing/scheduling. > >If packets are to be dropped: > >- are some more important than others? > >- are some to be considered part of a flow, where others are to be >considered part of another flow? > >- are pacekts to be considered part of a flow (i.e. a call) at all, or >is it first-in, first-dealt--with? > >[Anna] There are no assumption that "importance" of packets is known, >and there are no assumptions that it is known at the core which packets >belong to which flows. > >If flows (meaning the packets associated with the call between Alice and >Bob are different than the packets associated between Carol and Dave) >are to be treated differently (i.e. packets from one flow are dropped >and packets from a parallel flow are not), how is this indicated and >loarned by the ingress node? > >MLEF certainly isn't the answer I hope. > >[Anna] Again, there is explicitly no assumptions that there is info >available at the core to tell which packets are from Alice and which are >from Bob, not which of those are more important than others. The >assumption is that the core only deals with figuring out whether the >total (PCN) traffic is above or below the desired level, and >communicates that info to the edge. The edge, on the other hand does >have the per-flow info, and can then make a per-flow based decision on >who to preempt/accept based on this info. However, IF >importance/precedence info is available at the core, then of course >additional mechanisms ae available. It seems to me that from the >BoF/WG standpoint, discussion of this boils down to work on deployment >models. The assumptions relevant to the particular deployment models >definely have to work with PCN assumptions and mechanism for PCn to be >viable in those models. > > >Next aspect is wrt emergency calling, what's the indication that Alice's >call is to an emergency response center, and Bob's is not (at the >ingress node)? > >[Anna] Some discussion of that is already in the >draft-briscoe-cl-architecture. A short answer is repeating the above: >the ingress node has the flexibility to decide *which* calls to prefer, >based on the call/flow info available to it. The core is assumeed to >not be able to tell Alice from Bob anyway. > >Without the ability to identify emergency calls from non-emergency >calls, talking about emergency calling getting any preferential >treatment is pointless. > >[Anna] As the ingress has the necessary info to distinguish emergency >vs non-emergency calls, it can then make the decisions based on that. > >Next aspect, how is the layer 3 mechanism of packet drops bubbled up to >the signaling layer? Or does the affected user(s) just realize their >quality is getting poorer? > >[Anna] The goal of PCN is to avoid packet drops under normal >circumstances by limiting the number of admitted calls to be below the >load that can be supported without loss or performance degradation. In >the case of failures or other unexpected events, the goal of pcn is to >preempt enough flows to make sure the remaining ones do no get QoS >degradation. If preemption is not used (or in the short period of time >until preemption takes effect), then yes, the quality is just getting >poorer for all flows involved. > >Since the ingress node is not the endpoint within any flow, does this >ingress node provide any feedback to the originator of the packet(s)? Or >is this merely expected to be learned through the normal course of >dropped packets within any network? > >[Anna] The answer depends on the deployment model. The model assumed in >draft-briscoe-cl-architecture (but not the only one possible) is the one >where the core is for example an rsvp hop, and so the edges use RSVP to >admit or bring down a call end-to-end. > > >Final aspect, if how to differentiate one flow from another flow is >possible, how does this BoF's effort solve for how this is not hacked >and misused for a game of Doom 3 or Quake 4 between users? > >[Anna] Well, the problem statement needs to scope the problem that is >being dealt with. My answers above correspond to the scope that is >currently being proposed (or at least I believe so :-). Feedback on >whether it should be broadened (or narrowed) is exactly what we are >asking for. I guess I am not entirely sure whether you are arguing >whether the "aspects" you are bringing up should or should not be within >the scope? > >Thank you, >Anna > > > >IMO, anything from this BoF should address (at least in requirements) >these "aspects" to be addressed in any solution from those requirements. > > > >Agree? > > > >phil > > > >-----Original Message----- > >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > >Sent: 20 September 2006 17:07 > >To: ken carlberg > >Cc: pcn@ietf.org > >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not > >AllowedIssue. Used to be Re: [PCN] > >draft-chan-pcn-problem-statement-00.txt > > > >Ken: > >I think you brought up couple of points below. > >My interpretation is: > >1. There is a need for 911 type (999 in UK?) of calls to get through > >in a public network. > > Hence 911 type of calls may be allowed to be admitted while > >normal calls get preempt > > as a start of a problem statement. > >2. There is a need for dedicated emergency service networks to allow > >flow/session preemptions. > >3. There is a need to allow flow/session preemptions when Emergency > >Service Networks and > > General Public Networks share network resources. > > > >Each may have a different affect to the mechanism and solution space > >we want to work on > >in the PCN BOF/WG. > > > >Please correct me if I mis-understand or missed your points. > > > >Thank you very much for your insights. > >-- Kwok -- > > > > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > > >Kwok, > > > > > >>Now I have additional questions concerning the use of Preemption > > >>for handling Emergency > > >>Services. Will Preemption be allowed for Emergency Services? > > > > > >My understanding is that Japan provides a measure of preemption for > > >its 911-type service. However, I don't know the specifics and can't > > >offer any more insight. One thing to keep in mind is that the 911- > > >type system is inherently an any-to-one (any user to PSAP/911- > >operator) model. > > > > > >As mentioned earlier, the US (and some other countries) have a system > > >called GETS that focuses on increasing the probability of call > > >completion over their PSTN. This represents an an-to-any model. > > >There is also the Wireless Priority System (WPS) in the US that > > >allows "displacement" of other users *during* call setup, versus a > > >call that has been established. People can google GETS and WPS for > > >more info. > > > > > >>Does some of the > > >>jurisdiction you have indicated want to use a separate network for > > >>Emergency Services > > >>purpose? > > > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > > >(LMR) systems used by first responders. From the IP perspective, the > > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > > >vendors are starting to infuse IP into those systems. The key thing > > >to keep in mind is that these are systems that are under a single > > >administrative authority (ie, a single domain). > > > > > >>Will combining Emergency Services with the normal VoIP >calls/sessions > > >>be a good Problem Statement that we can add to our Problem > > >>Statement draft? > > > > > >Well, I would view Emergency Services as mostly one motivation for > > >what you are trying to accomplish. Aspects like rapid recovery, > > >prioritization/labeling/coloring of flows, etc. would seem to be of > > >interest to those dealing with emergencies or some other condition. > > > > > >-ken > > > > > > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 20 22:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQEgN-00006g-93; Wed, 20 Sep 2006 22:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQEgL-00006K-K5 for pcn@ietf.org; Wed, 20 Sep 2006 22:52:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQEgD-0007b0-OZ for pcn@ietf.org; Wed, 20 Sep 2006 22:52:57 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2006 19:19:30 -0700 X-IronPort-AV: i="4.09,194,1157353200"; d="scan'208"; a="323548490:sNHT8893586000" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8L2JUeh028176; Wed, 20 Sep 2006 19:19:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8L2JTML021543; Wed, 20 Sep 2006 19:19:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 19:19:29 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.89.46]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 19:19:28 -0700 Message-Id: <4.3.2.7.2.20060920211811.02f9c948@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Sep 2006 21:19:27 -0500 To: "Jozef Babiarz" , "Anna Charny \(acharny\)" , , "Kwok-Ho Chan" , From: "James M. Polk" Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls) In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650C2C31E0@zcarhxm1.corp.nor tel.com> References: <4.3.2.7.2.20060920150045.03a55cf0@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2006 02:19:29.0058 (UTC) FILETIME=[5DE66820:01C6DD24] DKIM-Signature: a=rsa-sha1; q=dns; l=13376; t=1158805170; x=1159669170; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[PCN]=20Problem=20of=20differentiating=20packets=20by=20flows=20 (i.e.=20=0A=20=20calls); X=v=3Dcisco.com=3B=20h=3Dh3xKT+05dZ+/mSnWW5O4qHZLTyI=3D; b=CDQH9Igj8FLVVNOx4mP2rYfrRRq4lIK7GdqW/jLRiiWURLFm+VcxgXIbIzsWY/e1tm0BqmdS 7Zd4CRObthOX47v7zrpyGm/GIxRjv+P5fp6ypBH1sbg4nXg8HuzRX1n/; Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org At 05:41 PM 9/20/2006 -0400, Jozef Babiarz wrote: >James, in one of the deployment models, the pre-congestion information >from the network is passed to the SIP endpoints. The SIP endpoint based >on its service policy take the appropriate action. Currently, I'm >writing the deployment model that explains how this would work. In the >deployment model that I'm using the pre-congestion information is passed >via the ECN bits in the IP header of packets received by the SIP >endpoint. SIP signalling is used to close the control loop with the SIP >traffic originating endpoint for admission and flow termination >(preemption). cool I just wanted to know/understand how traffic was being differentiated, if it was, especially under emergency situations (which was the topic of this original thread). >Regards, Joe >QoS & Network Architecture >Telephone: 613-763-6098 (ESN 393-6098) >Email: babiarz@nortel.com > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Wednesday, September 20, 2006 4:07 PM >To: Anna Charny (acharny); philip.eardley@bt.com; Chan, Kwok-Ho >(BL60:470); carlberg@g11.org.uk >Cc: pcn@ietf.org >Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. >calls) > >Said below: > > "The edge, on the other hand does have the per-flow info, and can then > >make a per-flow based decision on who to preempt/accept based on this >info. " > >How will the ingress node have all the necessary information in it to >make >a decision that Alice's call is more important than Bob's? > >Will the edge node have access to SIP signaling (for example)? Without >this >(or the like) or without there being a reservation to the ingress dge >node >from the packet originator, what is/are the indicator(s) distinguishing >one >packet from another (meaning one call from another)? > >Without this, any discussion of prioritizing one packet over another is >pointless (which I said in my original email), and probably out of scope >of >PCN. > >At 12:47 PM 9/20/2006 -0700, Anna Charny \(acharny\) wrote: > >Hi James, > > > >A few comments/answers below: > > > >-----Original Message----- > >From: James Polk (jmpolk) > >Sent: Wednesday, September 20, 2006 3:05 PM > >To: philip.eardley@bt.com; khchan@nortel.com; carlberg@g11.org.uk > >Cc: pcn@ietf.org > >Subject: [PCN] Problem of differentiating packets by flows (i.e. calls) > > > >At 05:40 PM 9/20/2006 +0100, philip.eardley@bt.com wrote: > > >I'm not sure, but I think maybe the scope is drifting outside what I > > >envisaged the scope of the PCN flow pre-emption mechanism. > > > > > >I don't think it's about: when an emergency call arrives, pre-empting >a > > > > >normal call because the new call would overload the network. > > >This is something that might be done, of course - just I don't think > > >it's in the scope of PCN. > > > > > >My view is that PCN is about "the network" realising that it's > > >overloaded, and by how much, and providing this info [typically] to >the > > > > >relevant ingress node of the PCN-region. this node can then take >action > > > > >based on this info, ie decide which flows to pre-empt. My view is >that > > >the scope is really about how to provide the information, rather than > > >detailing the action that should be taken. > > > >Philip (and all) > > > >there are several aspects of this that need to be brought up, if any > >are. Consider this: > > > >if "the network" is to "tell" the ingress node it is overloading the > >core by admitting additional packets, is this with a WFQ, or RED or >FIFD > >(first-in, first-dropped) type of mechanism - until there is no more > >overload caused by this node? > > > >[Anna] There is actually no explicit assumptions of the underlying > >queueing that (I think) is necessary. The overload is defined based on > >the "desired" capacity - e.g. the same capacity that would be > >"provisioned" in, say DiffServ EF context. The simplest assumption >then > >is that the PCN traffic has a queue for itself (could be a priority > >queue or a queue in a WFQ). A particular solution may use different > >means of implementing the measurement of overload wrt that "desired" > >capacity. E.g. draft-brisco-cl-architecture offers to do that based on > >the virtual queue. But that virtual queue is largely independent of >the > >underlying queueing/scheduling. > > > >If packets are to be dropped: > > > >- are some more important than others? > > > >- are some to be considered part of a flow, where others are to be > >considered part of another flow? > > > >- are pacekts to be considered part of a flow (i.e. a call) at all, or > >is it first-in, first-dealt--with? > > > >[Anna] There are no assumption that "importance" of packets is known, > >and there are no assumptions that it is known at the core which packets > >belong to which flows. > > > >If flows (meaning the packets associated with the call between Alice >and > >Bob are different than the packets associated between Carol and Dave) > >are to be treated differently (i.e. packets from one flow are dropped > >and packets from a parallel flow are not), how is this indicated and > >loarned by the ingress node? > > > >MLEF certainly isn't the answer I hope. > > > >[Anna] Again, there is explicitly no assumptions that there is info > >available at the core to tell which packets are from Alice and which >are > >from Bob, not which of those are more important than others. The > >assumption is that the core only deals with figuring out whether the > >total (PCN) traffic is above or below the desired level, and > >communicates that info to the edge. The edge, on the other hand does > >have the per-flow info, and can then make a per-flow based decision on > >who to preempt/accept based on this info. However, IF > >importance/precedence info is available at the core, then of course > >additional mechanisms ae available. It seems to me that from the > >BoF/WG standpoint, discussion of this boils down to work on deployment > >models. The assumptions relevant to the particular deployment models > >definely have to work with PCN assumptions and mechanism for PCn to be > >viable in those models. > > > > > >Next aspect is wrt emergency calling, what's the indication that >Alice's > >call is to an emergency response center, and Bob's is not (at the > >ingress node)? > > > >[Anna] Some discussion of that is already in the > >draft-briscoe-cl-architecture. A short answer is repeating the above: > >the ingress node has the flexibility to decide *which* calls to prefer, > >based on the call/flow info available to it. The core is assumeed to > >not be able to tell Alice from Bob anyway. > > > >Without the ability to identify emergency calls from non-emergency > >calls, talking about emergency calling getting any preferential > >treatment is pointless. > > > >[Anna] As the ingress has the necessary info to distinguish emergency > >vs non-emergency calls, it can then make the decisions based on that. > > > >Next aspect, how is the layer 3 mechanism of packet drops bubbled up to > >the signaling layer? Or does the affected user(s) just realize their > >quality is getting poorer? > > > >[Anna] The goal of PCN is to avoid packet drops under normal > >circumstances by limiting the number of admitted calls to be below the > >load that can be supported without loss or performance degradation. In > >the case of failures or other unexpected events, the goal of pcn is to > >preempt enough flows to make sure the remaining ones do no get QoS > >degradation. If preemption is not used (or in the short period of time > >until preemption takes effect), then yes, the quality is just getting > >poorer for all flows involved. > > > >Since the ingress node is not the endpoint within any flow, does this > >ingress node provide any feedback to the originator of the packet(s)? >Or > >is this merely expected to be learned through the normal course of > >dropped packets within any network? > > > >[Anna] The answer depends on the deployment model. The model assumed >in > >draft-briscoe-cl-architecture (but not the only one possible) is the >one > >where the core is for example an rsvp hop, and so the edges use RSVP to > >admit or bring down a call end-to-end. > > > > > >Final aspect, if how to differentiate one flow from another flow is > >possible, how does this BoF's effort solve for how this is not hacked > >and misused for a game of Doom 3 or Quake 4 between users? > > > >[Anna] Well, the problem statement needs to scope the problem that is > >being dealt with. My answers above correspond to the scope that is > >currently being proposed (or at least I believe so :-). Feedback on > >whether it should be broadened (or narrowed) is exactly what we are > >asking for. I guess I am not entirely sure whether you are arguing > >whether the "aspects" you are bringing up should or should not be >within > >the scope? > > > >Thank you, > >Anna > > > > > > > >IMO, anything from this BoF should address (at least in requirements) > >these "aspects" to be addressed in any solution from those >requirements. > > > > > > >Agree? > > > > > >phil > > > > > >-----Original Message----- > > >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > >Sent: 20 September 2006 17:07 > > >To: ken carlberg > > >Cc: pcn@ietf.org > > >Subject: Re: ProblemStatement Issue B.9:Call Preemption Not > > >AllowedIssue. Used to be Re: [PCN] > > >draft-chan-pcn-problem-statement-00.txt > > > > > >Ken: > > >I think you brought up couple of points below. > > >My interpretation is: > > >1. There is a need for 911 type (999 in UK?) of calls to get through > > >in a public network. > > > Hence 911 type of calls may be allowed to be admitted while > > >normal calls get preempt > > > as a start of a problem statement. > > >2. There is a need for dedicated emergency service networks to allow > > >flow/session preemptions. > > >3. There is a need to allow flow/session preemptions when Emergency > > >Service Networks and > > > General Public Networks share network resources. > > > > > >Each may have a different affect to the mechanism and solution space > > >we want to work on > > >in the PCN BOF/WG. > > > > > >Please correct me if I mis-understand or missed your points. > > > > > >Thank you very much for your insights. > > >-- Kwok -- > > > > > > > > >At 10:09 AM 9/20/2006, ken carlberg wrote: > > > >Kwok, > > > > > > > >>Now I have additional questions concerning the use of Preemption > > > >>for handling Emergency > > > >>Services. Will Preemption be allowed for Emergency Services? > > > > > > > >My understanding is that Japan provides a measure of preemption for > > > >its 911-type service. However, I don't know the specifics and can't > > > >offer any more insight. One thing to keep in mind is that the 911- > > > >type system is inherently an any-to-one (any user to PSAP/911- > > >operator) model. > > > > > > > >As mentioned earlier, the US (and some other countries) have a >system > > > >called GETS that focuses on increasing the probability of call > > > >completion over their PSTN. This represents an an-to-any model. > > > >There is also the Wireless Priority System (WPS) in the US that > > > >allows "displacement" of other users *during* call setup, versus a > > > >call that has been established. People can google GETS and WPS for > > > >more info. > > > > > > > >>Does some of the > > > >>jurisdiction you have indicated want to use a separate network for > > > >>Emergency Services > > > >>purpose? > > > > > > > >Yes, AUTOVON is one example. Other examples are Land Mobile Radio > > > >(LMR) systems used by first responders. From the IP perspective, >the > > > >bulk of the LMR infrastructure is at Layer 2, but IP providers and > > > >vendors are starting to infuse IP into those systems. The key >thing > > > >to keep in mind is that these are systems that are under a single > > > >administrative authority (ie, a single domain). > > > > > > > >>Will combining Emergency Services with the normal VoIP > >calls/sessions > > > >>be a good Problem Statement that we can add to our Problem > > > >>Statement draft? > > > > > > > >Well, I would view Emergency Services as mostly one motivation for > > > >what you are trying to accomplish. Aspects like rapid recovery, > > > >prioritization/labeling/coloring of flows, etc. would seem to be of > > > >interest to those dealing with emergencies or some other condition. > > > > > > > >-ken > > > > > > > > > > > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pcn > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 02:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHxc-0005Lq-HH; Thu, 21 Sep 2006 02:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQHxb-0005J2-D9 for pcn@ietf.org; Thu, 21 Sep 2006 02:22:59 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQHxT-0004zw-Ra for pcn@ietf.org; Thu, 21 Sep 2006 02:22:59 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 13EED15FC for ; Thu, 21 Sep 2006 08:22:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 07AB9171E for ; Thu, 21 Sep 2006 08:22:51 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id DE9871171 for ; Thu, 21 Sep 2006 08:22:50 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8L6Mos26602 for ; Thu, 21 Sep 2006 08:22:50 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 2AD086F58E for ; Thu, 21 Sep 2006 08:21:41 +0200 (CEST) Message-ID: <45122FD5.504@informatik.uni-wuerzburg.de> Date: Thu, 21 Sep 2006 08:23:17 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, I quickly browsed through the draft on Pre-Congestion Notification marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt and want to give some comments. 1) I don't understand why Section 2 proposes a virtual queue with a a probability-based marking when the queue size is within two thresholds. What is the benefit of such an approach compared with the one of a queue with a single threshold from which on packets are labelled if they exceed this limit? Is this maybe a relict from an RED-based ECN-labelling which might be useful in the presence of TCP traffic? From my perspective, the task of admission marking is just to mark those packets that exceed the configured admission rate and a virtual queue is used only to account for the burstiness of the traffic and to allow some tolerance regarding the rate. This is similar to the "cell delay variation tolerance (CDVT)" and the "burst tolerance" in ATM. 2) I was puzzled by the fact that the Admission Marker uses a virtual queue and that the preemption marker uses a token bucket. I'd prefer if a solution is given in a similar manner, e.g., two virtual queues that differ with respect to the following issues: - Admission marking considers all realtime packets whereas preemption marking considers only non-preemption-marked packets. - The admission marker wants to find out whether the configured admission rate is exceeded and if so, it wants to label all packets. Therefore, the queue has infinite "buffer size" (probably set to a reasonable value to recognize quickly if the rate has reduced) and all packets beyond a certain threshold are labelled. - In contrast, the preemption marker wants to mark packets that exceed the configured preemption rate. Therefore, - if a virtual queue is also used in this case - only those packets exceeding the threshold are preemption-marked and these packets do not increase the queue size. - As the admission marker cannot be based on a token bucket, I consider the virtual queue as the more appropriate unifying mechanism for both markers. Note that this would only describe the behavior of the markers, the implementation can be done differently. Best wishes, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 02:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIFn-00075j-1V; Thu, 21 Sep 2006 02:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIFl-00075M-Cm for pcn@ietf.org; Thu, 21 Sep 2006 02:41:45 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQIFg-0002Fb-Rf for pcn@ietf.org; Thu, 21 Sep 2006 02:41:45 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 21 Sep 2006 08:41:40 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 08:41:39 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 21 Sep 2006 08:41:39 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF862@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CCFD@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbc06g9M7ZGRsjfQ5q7gaicufkP/wAdSUXw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Sep 2006 06:41:39.0753 (UTC) FILETIME=[FE1FF990:01C6DD48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, I too agree.=20 Regards,=20 Rudiger |-----Original Message----- |From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] |Sent: Wednesday, September 20, 2006 6:41 PM |To: khchan@nortel.com; carlberg@g11.org.uk |Cc: pcn@ietf.org |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |AllowedIssue. Used to be Re: [PCN] |draft-chan-pcn-problem-statement-00.txt | | |I'm not sure, but I think maybe the scope is drifting outside what I |envisaged the scope of the PCN flow pre-emption mechanism. | |I don't think it's about: when an emergency call arrives, pre-empting a |normal call because the new call would overload the network. |This is something that might be done, of course - just I don't think |it's in the scope of PCN. | |My view is that PCN is about "the network" realising that it's |overloaded, and by how much, and providing this info [typically] to the |relevant ingress node of the PCN-region. this node can then take action |based on this info, ie decide which flows to pre-empt. My view is that |the scope is really about how to provide the information, rather than |detailing the action that should be taken. | |Agree? | |phil | |-----Original Message----- |From: Kwok-Ho Chan [mailto:khchan@nortel.com]=20 |Sent: 20 September 2006 17:07 |To: ken carlberg |Cc: pcn@ietf.org |Subject: Re: ProblemStatement Issue B.9:Call Preemption Not |AllowedIssue. Used to be Re: [PCN] |draft-chan-pcn-problem-statement-00.txt | |Ken: |I think you brought up couple of points below. |My interpretation is: |1. There is a need for 911 type (999 in UK?) of calls to get through=20 |in a public network. | Hence 911 type of calls may be allowed to be admitted while=20 |normal calls get preempt | as a start of a problem statement. |2. There is a need for dedicated emergency service networks to allow=20 |flow/session preemptions. |3. There is a need to allow flow/session preemptions when Emergency=20 |Service Networks and | General Public Networks share network resources. | |Each may have a different affect to the mechanism and solution space=20 |we want to work on |in the PCN BOF/WG. | |Please correct me if I mis-understand or missed your points. | |Thank you very much for your insights. |-- Kwok -- | | |At 10:09 AM 9/20/2006, ken carlberg wrote: |>Kwok, |> |>>Now I have additional questions concerning the use of Preemption |>>for handling Emergency |>>Services. Will Preemption be allowed for Emergency Services? |> |>My understanding is that Japan provides a measure of preemption for |>its 911-type service. However, I don't know the specifics and can't |>offer any more insight. One thing to keep in mind is that the 911-=20 |>type system is inherently an any-to-one (any user to PSAP/911- |operator) model. |> |>As mentioned earlier, the US (and some other countries) have a system |>called GETS that focuses on increasing the probability of call |>completion over their PSTN. This represents an an-to-any model. |>There is also the Wireless Priority System (WPS) in the US that |>allows "displacement" of other users *during* call setup, versus a |>call that has been established. People can google GETS and WPS for |>more info. |> |>>Does some of the |>>jurisdiction you have indicated want to use a separate network for |>>Emergency Services |>>purpose? |> |>Yes, AUTOVON is one example. Other examples are Land Mobile Radio |>(LMR) systems used by first responders. From the IP perspective, the |>bulk of the LMR infrastructure is at Layer 2, but IP providers and |>vendors are starting to infuse IP into those systems. The key thing |>to keep in mind is that these are systems that are under a single |>administrative authority (ie, a single domain). |> |>>Will combining Emergency Services with the normal VoIP calls/sessions |>>be a good Problem Statement that we can add to our Problem |>>Statement draft? |> |>Well, I would view Emergency Services as mostly one motivation for |>what you are trying to accomplish. Aspects like rapid recovery, |>prioritization/labeling/coloring of flows, etc. would seem to be of |>interest to those dealing with emergencies or some other condition. |> |>-ken |> | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 02:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIWD-0008Bd-6a; Thu, 21 Sep 2006 02:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIWB-0008BW-Kt for pcn@ietf.org; Thu, 21 Sep 2006 02:58:43 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQIW7-0000qX-7Y for pcn@ietf.org; Thu, 21 Sep 2006 02:58:43 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 21 Sep 2006 08:58:38 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 08:58:38 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Problem of differentiating packets by flows (i.e. calls) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 21 Sep 2006 08:58:37 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF863@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Problem of differentiating packets by flows (i.e. calls) Thread-Index: Acbc7bHP5tnew1VsSvOsN05ZGg6y8QAXC9XA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Sep 2006 06:58:38.0003 (UTC) FILETIME=[5D0C9830:01C6DD4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, |Next aspect, how is the layer 3 mechanism of packet drops bubbled up to |the signaling layer? Or does the affected user(s) just realize their |quality is getting poorer? | |[Anna] The goal of PCN is to avoid packet drops under normal |circumstances by limiting the number of admitted calls to be below the |load that can be supported without loss or performance degradation. In |the case of failures or other unexpected events, the goal of pcn is to |preempt enough flows to make sure the remaining ones do no get QoS |degradation. If preemption is not used (or in the short period of time |until preemption takes effect), then yes, the quality is just getting |poorer for all flows involved. [Rudi] I'd expect that the quality after "expectable" failures could be=20 maintained by provisioning and planning. But I agree, during catastrophic=20 failures, quality degradations will occur. As a result, some folks will=20 end their calls. After a short time (on the order of minutes, I'd=20 assume) standard operation should resume, meaning that the transport=20 quality is ensured again by PCN. Regards,=20 Rudiger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 03:27:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIxz-0000F6-0z; Thu, 21 Sep 2006 03:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQIxx-0000Ec-Ci for pcn@ietf.org; Thu, 21 Sep 2006 03:27:25 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQIxq-0000h8-Rl for pcn@ietf.org; Thu, 21 Sep 2006 03:27:25 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 21 Sep 2006 09:27:15 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 09:27:15 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: FW: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Date: Thu, 21 Sep 2006 09:27:14 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF865@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Thread-Index: AcbdRq2gQl+9RZCHRHepYsQAwIvVywABiQfQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 21 Sep 2006 07:27:15.0535 (UTC) FILETIME=[5CC72DF0:01C6DD4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, while it is obvious that packets should start to get congestion marked = after the admission rate has been passed, it is still not clear to me, = what happens if the average traffic passes the admission rate for a = longer duration. I'd prefer if the following was possible: - settable admission rate, e.g. 50% of the link=20 bandwidth (marking starts after it's passed). - settable maximum pcn rate, e.g. 80% of the=20 link bandwidth (dropping starts after it's passed). If PCN works like that, single link failures would result in busy tones = for new call attempts, but quality degradation for admitted calls could = be avoided by planning (if desired). If I got 1) of your comments right, = you propose to let bursts pass the admission rate, but still drop = traffic after the admission rate is passed for times longer than burst = intervals? Regards, R=FCdiger -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: Thursday, September 21, 2006 8:23 AM To: pcn@ietf.org Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Hi all, I quickly browsed through the draft on Pre-Congestion Notification = marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt and want to give some comments. 1) I don't understand why Section 2 proposes a virtual queue with a a probability-based marking when the queue size is within two = thresholds. What is the benefit of such an approach compared with the one of a queue with a single threshold from which on packets are labelled if they = exceed this limit? Is this maybe a relict from an RED-based ECN-labelling which might be useful in the presence of TCP traffic? From my perspective, the task of admission marking is just to mark those packets that exceed the configured admission rate and a virtual queue is used only to account = for the burstiness of the traffic and to allow some tolerance regarding the rate. This is similar to the "cell delay variation tolerance (CDVT)" and the "burst tolerance" in ATM. 2) I was puzzled by the fact that the Admission Marker uses a virtual queue and that the preemption marker uses a token bucket. I'd prefer if a solution is given in a similar manner, e.g., two virtual queues that differ with respect to the following issues: - Admission marking considers all realtime packets whereas preemption marking considers only non-preemption-marked packets. - The admission marker wants to find out whether the configured = admission rate is exceeded and if so, it wants to label all packets. Therefore, the queue has infinite "buffer size" (probably set to a reasonable value to recognize quickly if the rate has reduced) and all packets beyond a certain threshold are labelled. - In contrast, the preemption marker wants to mark packets that exceed the configured preemption rate. Therefore, - if a virtual queue is also used in this case - only those packets exceeding the threshold are preemption-marked and these packets do not increase the queue size. - As the admission marker cannot be based on a token bucket, I consider the virtual queue as the more appropriate unifying mechanism for both markers. Note that this would only describe the behavior of the markers, the implementation can be done differently. Best wishes, Michael --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 05:21:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKkK-0002Hd-8L; Thu, 21 Sep 2006 05:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKkJ-0002Ef-BJ for pcn@ietf.org; Thu, 21 Sep 2006 05:21:27 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQKkE-0003o8-MV for pcn@ietf.org; Thu, 21 Sep 2006 05:21:27 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F2AE61287; Thu, 21 Sep 2006 11:21:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E63E0126D; Thu, 21 Sep 2006 11:21:19 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A26A8102B; Thu, 21 Sep 2006 11:21:19 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8L9LJs27934; Thu, 21 Sep 2006 11:21:19 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D619B6F58E; Thu, 21 Sep 2006 11:20:09 +0200 (CEST) Message-ID: <451259A7.8060201@informatik.uni-wuerzburg.de> Date: Thu, 21 Sep 2006 11:21:43 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: FW: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt References: <6439282641581441A36F7F6F83ED2ED2CBF865@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF865@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, Geib, Ruediger wrote: > Hi Michael, > > while it is obvious that packets should start to get congestion marked = after the admission rate has been passed, it is still not clear to me, wh= at happens if the average traffic passes the admission rate for a longer = duration. I'd prefer if the following was possible: > > - settable admission rate, e.g. 50% of the link=20 > bandwidth (marking starts after it's passed). > > - settable maximum pcn rate, e.g. 80% of the=20 > link bandwidth (dropping starts after it's passed). > =20 Flow preemption starts - not packet dropping - just to avoid confusion!=20 This is a virtual queue for the only purpose of metering traffic. These=20 mechanisms do not operate on the physical buffer contents. > If PCN works like that, single link failures would result in busy tones= for new call attempts, but quality degradation for admitted calls could = be avoided by planning (if desired).=20 That's perfectly what's intended in the draft - at least I understood it=20 this way - and I find it pretty good. > If I got 1) of your comments right, you propose to let bursts pass the = admission rate, but still drop traffic after the admission rate is passed= for times longer than burst intervals? > =20 The marker tolerates short time burst above the=20 configured-admission-rate and the size of the burst is configurable. If=20 bursts are larger, packets are admission marked - not dropped! Again,=20 this is not my proposal, that's what essentially Section 2.2 in the=20 draft with "min-marking-threshold=3Dmax-marking-threshold". I just=20 wondered what the RED-like queue management should be good for and I=20 don't like the different approaches to explain the two different markers=20 (virtual queue, token bucket). However, I perfectly agree with their=20 behavior. Best wishes, Michael > Regards, > > R=FCdiger > > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Thursday, September 21, 2006 8:23 AM > To: pcn@ietf.org > Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt > > > Hi all, > > I quickly browsed through the draft on Pre-Congestion Notification mark= ing > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt > and want to give some comments. > > 1) I don't understand why Section 2 proposes a virtual queue with a > a probability-based marking when the queue size is within two threshold= s. > What is the benefit of such an approach compared with the one of a queu= e > with a single threshold from which on packets are labelled if they exce= ed > this limit? Is this maybe a relict from an RED-based ECN-labelling whic= h > might be useful in the presence of TCP traffic? From my perspective, th= e > task of admission marking is just to mark those packets that exceed the > configured admission rate and a virtual queue is used only to account f= or > the burstiness of the traffic and to allow some tolerance regarding the > rate. This is similar to the "cell delay variation tolerance (CDVT)" an= d > the "burst tolerance" in ATM. > > 2) I was puzzled by the fact that the Admission Marker uses a virtual > queue and that the preemption marker uses a token bucket. I'd prefer > if a solution is given in a similar manner, e.g., two virtual queues > that differ with respect to the following issues: > - Admission marking considers all realtime packets whereas preemption > marking considers only non-preemption-marked packets. > - The admission marker wants to find out whether the configured admissi= on > rate is exceeded and if so, it wants to label all packets. Therefore, > the queue has infinite "buffer size" (probably set to a reasonable > value to recognize quickly if the rate has reduced) and all packets > beyond a certain threshold are labelled. > - In contrast, the preemption marker wants to mark packets that exceed > the configured preemption rate. Therefore, - if a virtual queue is > also used in this case - only those packets exceeding the threshold > are preemption-marked and these packets do not increase the queue > size. > - As the admission marker cannot be based on a token bucket, I consider > the virtual queue as the more appropriate unifying mechanism for both > markers. > > Note that this would only describe the behavior of the markers, the > implementation can be done differently. > > Best wishes, > > Michael > > =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 07:51:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQN5e-00048I-Ne; Thu, 21 Sep 2006 07:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQN5d-00048C-8x for pcn@ietf.org; Thu, 21 Sep 2006 07:51:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQN5X-0003T3-3d for pcn@ietf.org; Thu, 21 Sep 2006 07:51:37 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2006 04:51:30 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8LBpU0N028261; Thu, 21 Sep 2006 04:51:30 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8LBpT1G029162; Thu, 21 Sep 2006 04:51:29 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 07:51:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Date: Thu, 21 Sep 2006 07:51:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Thread-Index: AcbdRroAYmxTrFBUQtKFxfOOxdqFqQALBELg From: "Anna Charny \(acharny\)" To: , X-OriginalArrivalTime: 21 Sep 2006 11:51:29.0267 (UTC) FILETIME=[4656B430:01C6DD74] DKIM-Signature: a=rsa-sha1; q=dns; l=4125; t=1158839490; x=1159703490; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Feedback=20on=20draft-briscoe-tsvwg-cl-phb-02.txt; X=v=3Dcisco.com=3B=20h=3DxrkZPqyxo4j5hPo2ZgVCD5lklr0=3D; b=WoaWM4nLXciYzzeJRImSWcsysOGKpl6mG3ECtj0qEfG0/z8lkpgIQgbeWTceO3xAoaKB9gQI /I02O7zTxN/513gIA/5pXmuqbjydJtvr2PA1/l8O+34BQ1rS+flVa4Qr; Authentication-Results: sj-dkim-4.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, See below, please...=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Thursday, September 21, 2006 2:23 AM To: pcn@ietf.org Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Hi all, I quickly browsed through the draft on Pre-Congestion Notification marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt and want to give some comments. 1) I don't understand why Section 2 proposes a virtual queue with a a probability-based marking when the queue size is within two thresholds. What is the benefit of such an approach compared with the one of a queue with a single threshold from which on packets are labelled if they exceed this limit?=20 [Anna] there are theoretically some advantages in probabilistic marking relizable over multiple congested hops - but indeed we did not see too much difference in simulation between probabilistic and 'step' marling. Since 'step' is a special case or 'ramp' the draft obviously allows both. In general, the framework may allow multiple ways to mark traffic (which also relates to your question below) - so there is a lot of room to discuss possible solutions to the problem. =20 Is this maybe a relict from an RED-based ECN-labelling which might be useful in the presence of TCP traffic? From my perspective, the task of admission marking is just to mark those packets that exceed the configured admission rate and a virtual queue is used only to account for the burstiness of the traffic and to allow some tolerance regarding the rate. This is similar to the "cell delay variation tolerance (CDVT)" and the "burst tolerance" in ATM. 2) I was puzzled by the fact that the Admission Marker uses a virtual queue and that the preemption marker uses a token bucket. I'd prefer if a solution is given in a similar manner, e.g., two virtual queues that differ with respect to the following issues: - Admission marking considers all realtime packets whereas preemption marking considers only non-preemption-marked packets. - The admission marker wants to find out whether the configured admission rate is exceeded and if so, it wants to label all packets. Therefore, the queue has infinite "buffer size" (probably set to a reasonable value to recognize quickly if the rate has reduced) and all packets beyond a certain threshold are labelled. - In contrast, the preemption marker wants to mark packets that exceed the configured preemption rate. Therefore, - if a virtual queue is also used in this case - only those packets exceeding the threshold are preemption-marked and these packets do not increase the queue size. - As the admission marker cannot be based on a token bucket, I consider the virtual queue as the more appropriate unifying mechanism for both markers. Note that this would only describe the behavior of the markers, the implementation can be done differently. [Anna] I agree that it is tempting to use the same underlying mechanisms for marking for admission and preemption. We actually have done some simulations on the case when both cac and reemption marking are done in a uniform manner (in this case both based on a token bucket implementation) - and we expect to report the results at the next ietf. There are a number of pros and cons for doing so which we hope to address then, but again we hope that ivestigating pros and cons of different solutions (and distilling which are the building blocks requiring standartization) could be done withing the scope of the new WG should it be created. Regards, Anna=20 Best wishes, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 08:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNab-00056h-Fo; Thu, 21 Sep 2006 08:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNaa-00056Z-8w for pcn@ietf.org; Thu, 21 Sep 2006 08:23:36 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNaS-0000sY-KP for pcn@ietf.org; Thu, 21 Sep 2006 08:23:36 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 13:22:58 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 13:23:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Date: Thu, 21 Sep 2006 13:23:05 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD01@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <45122FD5.504@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Thread-Index: AcbdRquaVTGcbMdvRX6qRSqomZ21VwAEGgMg From: To: , X-OriginalArrivalTime: 21 Sep 2006 12:23:06.0439 (UTC) FILETIME=[B1242D70:01C6DD78] X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael Thanks for the comments On 1), we had a lot of discussion amongst the authors without reaching final agreement on this issue. I think (I may have remembered this wrong!) that we were leaning towards there not being that much difference between having two thresholds and having one threshold ("ramp or probabilistic" vs "step" marking), and that we needed to do some more simulations to find out whether it makes any odds A couple of possible reasons for having "ramp" marking: - robustness to worst case traffic - if the aggregate of traffic at a router is very smooth, then "step" marking might not give (hardly) any markings until too many calls are admitted. Whereas "ramp" marking would give some more warning - in particular, if several routers are marking a little, then the marking rate at the egress (which is the sum of the individual routers' marking rates) will be big enough that it starts blocking calls. - "ramp" marking may help http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-ch eat-01.txt to work. this I-D is about enabling a single PCN-region to include networks that don't trust each other - at the borders between the networks, only bulk measurements (of PCN markings) are needed. For the idea to work, it needs a little bit of marking at data rates below the configured-admission-rate. "ramp" marking helps this [there may be alternative ways]. There's also the question of whether it could be left open to operator, ie standard could have 2 thresholds, however in deployment you can set them the same.=20 On 2), as far as I remember there was no particular reason for the description using token buckets rather than virtual queues - just [I think] we found it easier to think about / describe like that.=20 Where you say >>- The admission marker wants to find out whether the configured admission rate is exceeded and if so, it wants to label all packets. Therefore, the queue has infinite "buffer size" (probably set to a reasonable value to recognize quickly if the rate has reduced) and all packets beyond a certain threshold are labelled. >> indeed, we found a problem if the max size of the virtual queue is "infinite" [NB the virtual queue is just a number, not a buffer]. Because then the marking probability can be 100% even when there are no packets in the real queue. Why? After a period of excess traffic the virtual queue grows. Say the arrival rate now drops to 0. It will take about (size-of-virtual-queue / configured-admission-rate) secs for the virtual queue to empty and the marking probability to drop so that calls can once again be admitted. Therefore, if size-of-virtual-queue is too big, after a lengthy period of excess traffic there will be a lengthy recovery period whilst the virtual queue empties. However, the real queue is constrained in length, because it drops packets and so will be able to enqueue packets again much sooner. The value used for size-of-virtual-queue in simulations was, I think, chosen fairly arbitrarily - twice the real buffer size rings a bell.=20 Best wishes, phil -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 21 September 2006 07:23 To: pcn@ietf.org Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt Hi all, I quickly browsed through the draft on Pre-Congestion Notification marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt and want to give some comments. 1) I don't understand why Section 2 proposes a virtual queue with a a probability-based marking when the queue size is within two thresholds. What is the benefit of such an approach compared with the one of a queue with a single threshold from which on packets are labelled if they exceed this limit? Is this maybe a relict from an RED-based ECN-labelling which might be useful in the presence of TCP traffic? From my perspective, the task of admission marking is just to mark those packets that exceed the configured admission rate and a virtual queue is used only to account for the burstiness of the traffic and to allow some tolerance regarding the rate. This is similar to the "cell delay variation tolerance (CDVT)" and the "burst tolerance" in ATM. 2) I was puzzled by the fact that the Admission Marker uses a virtual queue and that the preemption marker uses a token bucket. I'd prefer if a solution is given in a similar manner, e.g., two virtual queues that differ with respect to the following issues: - Admission marking considers all realtime packets whereas preemption marking considers only non-preemption-marked packets. - The admission marker wants to find out whether the configured admission rate is exceeded and if so, it wants to label all packets. Therefore, the queue has infinite "buffer size" (probably set to a reasonable value to recognize quickly if the rate has reduced) and all packets beyond a certain threshold are labelled. - In contrast, the preemption marker wants to mark packets that exceed the configured preemption rate. Therefore, - if a virtual queue is also used in this case - only those packets exceeding the threshold are preemption-marked and these packets do not increase the queue size. - As the admission marker cannot be based on a token bucket, I consider the virtual queue as the more appropriate unifying mechanism for both markers. Note that this would only describe the behavior of the markers, the implementation can be done differently. Best wishes, Michael --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 09:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOOA-0002h4-U2; Thu, 21 Sep 2006 09:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOO8-0002eo-Sb for pcn@ietf.org; Thu, 21 Sep 2006 09:14:48 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOO4-0000M6-7r for pcn@ietf.org; Thu, 21 Sep 2006 09:14:48 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4F1024219; Thu, 21 Sep 2006 15:14:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 435734215; Thu, 21 Sep 2006 15:14:41 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1B1002CF7; Thu, 21 Sep 2006 15:14:40 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8LDEes29970; Thu, 21 Sep 2006 15:14:40 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 1F0F96F58E; Thu, 21 Sep 2006 15:13:31 +0200 (CEST) Message-ID: <45129056.5080709@informatik.uni-wuerzburg.de> Date: Thu, 21 Sep 2006 15:15:02 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD01@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD01@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Philip, philip.eardley@bt.com wrote: > Michael > Thanks for the comments > > On 1), we had a lot of discussion amongst the authors without reaching > final agreement on this issue. I think (I may have remembered this > wrong!) that we were leaning towards there not being that much > difference between having two thresholds and having one threshold ("ramp > or probabilistic" vs "step" marking), and that we needed to do some more > simulations to find out whether it makes any odds > Ok. I don't expect much difference. > A couple of possible reasons for having "ramp" marking: > - robustness to worst case traffic - if the aggregate of traffic at a > router is very smooth, then "step" marking might not give (hardly) any > markings until too many calls are admitted. Whereas "ramp" marking would > give some more warning - in particular, if several routers are marking a > little, then the marking rate at the egress (which is the sum of the > individual routers' marking rates) will be big enough that it starts > blocking calls. > I think that the sensitivity to bursty traffic can be rather controlled by the size of the virtual queue itself. > - "ramp" marking may help > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-ch > eat-01.txt to work. this I-D is about enabling a single PCN-region to > include networks that don't trust each other - at the borders between > the networks, only bulk measurements (of PCN markings) are needed. For > the idea to work, it needs a little bit of marking at data rates below > the configured-admission-rate. "ramp" marking helps this [there may be > alternative ways]. > Hm, not quite understood. Anyway. But again, I think that the size of the virtual queue is enough to control the marking. Simulations could proof or disprove whether probability-based marking has any benefit over a simpler queue with a reasonably set queue size. > > There's also the question of whether it could be left open to operator, > ie standard could have 2 thresholds, however in deployment you can set > them the same. > > > On 2), as far as I remember there was no particular reason for the > description using token buckets rather than virtual queues - just [I > think] we found it easier to think about / describe like that. > > Where you say > >>> - The admission marker wants to find out whether the configured >>> > admission > rate is exceeded and if so, it wants to label all packets. Therefore, > the queue has infinite "buffer size" (probably set to a reasonable > value to recognize quickly if the rate has reduced) and all packets > beyond a certain threshold are labelled. > > indeed, we found a problem if the max size of the virtual queue is > "infinite" [NB the virtual queue is just a number, not a buffer]. > Because then the marking probability can be 100% even when there are no > packets in the real queue. Why? After a period of excess traffic the > virtual queue grows. Say the arrival rate now drops to 0. It will take > about (size-of-virtual-queue / configured-admission-rate) secs for the > virtual queue to empty and the marking probability to drop so that calls > can once again be admitted. Therefore, if size-of-virtual-queue is too > big, after a lengthy period of excess traffic there will be a lengthy > recovery period whilst the virtual queue empties. However, the real > queue is constrained in length, because it drops packets and so will be > able to enqueue packets again much sooner. The value used for > size-of-virtual-queue in simulations was, I think, chosen fairly > arbitrarily - twice the real buffer size rings a bell. > So we think the same about this issue. I can imagine that the quest for a reasonable queue size of the preemption marker is also an open issue and subject to further research. Kind regards, Michael > Best wishes, > phil > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 21 September 2006 07:23 > To: pcn@ietf.org > Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt > > Hi all, > > I quickly browsed through the draft on Pre-Congestion Notification > marking > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt > and want to give some comments. > > 1) I don't understand why Section 2 proposes a virtual queue with a > a probability-based marking when the queue size is within two > thresholds. > What is the benefit of such an approach compared with the one of a queue > with a single threshold from which on packets are labelled if they > exceed > this limit? Is this maybe a relict from an RED-based ECN-labelling which > might be useful in the presence of TCP traffic? From my perspective, the > task of admission marking is just to mark those packets that exceed the > configured admission rate and a virtual queue is used only to account > for > the burstiness of the traffic and to allow some tolerance regarding the > rate. This is similar to the "cell delay variation tolerance (CDVT)" and > the "burst tolerance" in ATM. > > 2) I was puzzled by the fact that the Admission Marker uses a virtual > queue and that the preemption marker uses a token bucket. I'd prefer > if a solution is given in a similar manner, e.g., two virtual queues > that differ with respect to the following issues: > - Admission marking considers all realtime packets whereas preemption > marking considers only non-preemption-marked packets. > - The admission marker wants to find out whether the configured > admission > rate is exceeded and if so, it wants to label all packets. Therefore, > the queue has infinite "buffer size" (probably set to a reasonable > value to recognize quickly if the rate has reduced) and all packets > beyond a certain threshold are labelled. > - In contrast, the preemption marker wants to mark packets that exceed > the configured preemption rate. Therefore, - if a virtual queue is > also used in this case - only those packets exceeding the threshold > are preemption-marked and these packets do not increase the queue > size. > - As the admission marker cannot be based on a token bucket, I consider > the virtual queue as the more appropriate unifying mechanism for both > markers. > > Note that this would only describe the behavior of the markers, the > implementation can be done differently. > > Best wishes, > > Michael > > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 11:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQay-0002PV-0H; Thu, 21 Sep 2006 11:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQaw-0002NG-3M for pcn@ietf.org; Thu, 21 Sep 2006 11:36:10 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQQaa-0004cT-82 for pcn@ietf.org; Thu, 21 Sep 2006 11:36:10 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8LFTDP08825; Thu, 21 Sep 2006 11:29:13 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 11:35:33 -0400 Message-Id: <6.2.5.6.0.20060921112301.0612d030@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Sep 2006 11:35:32 -0400 To: menth@informatik.uni-wuerzburg.de From: "Kwok-Ho Chan" Subject: Re: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt In-Reply-To: <45129056.5080709@informatik.uni-wuerzburg.de> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD01@E03MVZ1-UKDY.domain1.systemhost.net> <45129056.5080709@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2006 15:35:33.0946 (UTC) FILETIME=[93FDE9A0:01C6DD93] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org We actually have been doing simulations on the algorithms. And have been sharing them with the design team (some of our many hours of design meetings during previous IETFs and other mtgs). It may be helpful to have 15-30 minutes of agenda time during the BOF to share some high lights of simulation results. This will help some of discussions we are having on the CL-PHB draft. This is a suggestion and is meant to solicit interest and response. IMHO, this is secondary to the main topic of Problem Statement and Goals and getting the WG started. But this follows right on the heels of creating the WG. Thanks! -- Kwok -- At 09:15 AM 9/21/2006, Michael Menth wrote: >Hi Philip, > >philip.eardley@bt.com wrote: >>Michael >>Thanks for the comments >> >>On 1), we had a lot of discussion amongst the authors without reaching >>final agreement on this issue. I think (I may have remembered this >>wrong!) that we were leaning towards there not being that much >>difference between having two thresholds and having one threshold ("ramp >>or probabilistic" vs "step" marking), and that we needed to do some more >>simulations to find out whether it makes any odds >> >Ok. I don't expect much difference. > >>A couple of possible reasons for having "ramp" marking: >>- robustness to worst case traffic - if the aggregate of traffic at a >>router is very smooth, then "step" marking might not give (hardly) any >>markings until too many calls are admitted. Whereas "ramp" marking would >>give some more warning - in particular, if several routers are marking a >>little, then the marking rate at the egress (which is the sum of the >>individual routers' marking rates) will be big enough that it starts >>blocking calls. >> >I think that the sensitivity to bursty traffic can be rather >controlled by the size of the virtual queue itself. > >>- "ramp" marking may help >>http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-ch >>eat-01.txt to work. this I-D is about enabling a single PCN-region to >>include networks that don't trust each other - at the borders between >>the networks, only bulk measurements (of PCN markings) are needed. For >>the idea to work, it needs a little bit of marking at data rates below >>the configured-admission-rate. "ramp" marking helps this [there may be >>alternative ways]. >> >Hm, not quite understood. Anyway. But again, I think that the size >of the virtual queue is enough to control the marking. Simulations >could proof or disprove whether probability-based marking has any >benefit over a simpler queue with a reasonably set queue size. >> >>There's also the question of whether it could be left open to operator, >>ie standard could have 2 thresholds, however in deployment you can set >>them the same. >> >>On 2), as far as I remember there was no particular reason for the >>description using token buckets rather than virtual queues - just [I >>think] we found it easier to think about / describe like that. >>Where you say >> >>>>- The admission marker wants to find out whether the configured >>>> >>admission >>rate is exceeded and if so, it wants to label all packets. Therefore, >>the queue has infinite "buffer size" (probably set to a reasonable >>value to recognize quickly if the rate has reduced) and all packets >>beyond a certain threshold are labelled. >> >>indeed, we found a problem if the max size of the virtual queue is >>"infinite" [NB the virtual queue is just a number, not a buffer]. >>Because then the marking probability can be 100% even when there are no >>packets in the real queue. Why? After a period of excess traffic the >>virtual queue grows. Say the arrival rate now drops to 0. It will take >>about (size-of-virtual-queue / configured-admission-rate) secs for the >>virtual queue to empty and the marking probability to drop so that calls >>can once again be admitted. Therefore, if size-of-virtual-queue is too >>big, after a lengthy period of excess traffic there will be a lengthy >>recovery period whilst the virtual queue empties. However, the real >>queue is constrained in length, because it drops packets and so will be >>able to enqueue packets again much sooner. The value used for >>size-of-virtual-queue in simulations was, I think, chosen fairly >>arbitrarily - twice the real buffer size rings a bell. >So we think the same about this issue. I can imagine that the quest >for a reasonable queue size of the preemption marker is also an open >issue and subject to further research. > > >Kind regards, > > Michael > >>Best wishes, >>phil >> >>-----Original Message----- >>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>Sent: 21 September 2006 07:23 >>To: pcn@ietf.org >>Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt >> >>Hi all, >> >>I quickly browsed through the draft on Pre-Congestion Notification >>marking >>http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt >>and want to give some comments. >> >>1) I don't understand why Section 2 proposes a virtual queue with a >>a probability-based marking when the queue size is within two >>thresholds. >>What is the benefit of such an approach compared with the one of a queue >>with a single threshold from which on packets are labelled if they >>exceed >>this limit? Is this maybe a relict from an RED-based ECN-labelling which >>might be useful in the presence of TCP traffic? From my perspective, the >>task of admission marking is just to mark those packets that exceed the >>configured admission rate and a virtual queue is used only to account >>for >>the burstiness of the traffic and to allow some tolerance regarding the >>rate. This is similar to the "cell delay variation tolerance (CDVT)" and >>the "burst tolerance" in ATM. >> >>2) I was puzzled by the fact that the Admission Marker uses a virtual >>queue and that the preemption marker uses a token bucket. I'd prefer >>if a solution is given in a similar manner, e.g., two virtual queues >>that differ with respect to the following issues: >>- Admission marking considers all realtime packets whereas preemption >>marking considers only non-preemption-marked packets. >>- The admission marker wants to find out whether the configured >>admission >>rate is exceeded and if so, it wants to label all packets. Therefore, >>the queue has infinite "buffer size" (probably set to a reasonable >>value to recognize quickly if the rate has reduced) and all packets >>beyond a certain threshold are labelled. >>- In contrast, the preemption marker wants to mark packets that exceed >>the configured preemption rate. Therefore, - if a virtual queue is >>also used in this case - only those packets exceeding the threshold >>are preemption-marked and these packets do not increase the queue >>size. >>- As the admission marker cannot be based on a token bucket, I consider >>the virtual queue as the more appropriate unifying mechanism for both >>markers. >> >>Note that this would only describe the behavior of the markers, the >>implementation can be done differently. >> >>Best wishes, >> >> Michael >> >> > >-- >Dr. Michael Menth, Assistant Professor >University of Wuerzburg, Institute of Computer Science >Am Hubland, D-97074 Wuerzburg, Germany, room B206 >phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >mailto:menth@informatik.uni-wuerzburg.de >http://www3.informatik.uni-wuerzburg.de/research/ngn > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 12:17:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRF5-0007Rt-Pd; Thu, 21 Sep 2006 12:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRF4-0007Ro-F3 for pcn@ietf.org; Thu, 21 Sep 2006 12:17:38 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQREz-00017i-QC for pcn@ietf.org; Thu, 21 Sep 2006 12:17:38 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8LGHV129511 for ; Thu, 21 Sep 2006 12:17:31 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 12:17:28 -0400 Message-Id: <6.2.5.6.0.20060921121512.03bdbc30@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Sep 2006 12:17:28 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Subject: Re: [PCN] Request for Pre-Congestion Notification BOF In-Reply-To: References: Mime-Version: 1.0 X-OriginalArrivalTime: 21 Sep 2006 16:17:28.0949 (UTC) FILETIME=[6F0CEA50:01C6DD99] X-Spam-Score: 0.6 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0217859314==" Errors-To: pcn-bounces@ietf.org --===============0217859314== Content-Type: multipart/alternative; boundary="=====================_11196740==.ALT" --=====================_11196740==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed FYI. I have put this Request for Pre-Congestion Notification BOF at: http://standards.nortel.com/pcn/RequestForPCNBOF.txt for ease of access and reference. Thanks! -- Kwok -- At 04:51 PM 9/14/2006, you wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C6D83F.86BCF870" > >Hello Lars and Magnus, > >This message constitutes a formal request for Pre-Congestion >Notification BOF at the November IETF meeting in San Diego. > >The BOF description and its proposed agenda are attached at the end >of this message. > >If this BOF is approved, we would like to request a two-hour slot >that avoids scheduling conflicts with the following working >groups: tsv, nsis, sip, ieprep, ecrit, pwe3, dccp. > >We also ask that you CC agenda@ietf.org with >your decision. > >Of course we welcome any feedback you might have. > >Best Regards, >Anna Charny > >PCN BOF Description > >The Pre-Congestion Notification (PCN) BOF will address the problem >of how to provide scalable and 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 overall approach will be based on a the concept of a PCN-Region, >within which the functionality is separated between the PCN-Interior >Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF >will be the case of a single DiffServ region, which maps to a >PCN-Region. PINs 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". PENs monitor >the markings and that information is used to make flow admission >control and pre-emption decisions. The decisions could be made by >the PENs or by a centralized system (which is informed of the PCN >information). > >The BOF will address the need and the motivation for PCN work in the >context of IETF, provide a brief overview of prior PCN efforts and >related work, and review open issues. The BOF will also discuss >the scope of work and solicit feedback on the proposed >charter. Ultimately, the goal of the BOF is to solicit community >feedback on whether the problem is clear and needs to be addressed, >and consequently whether the creation of a new PCN WG within the >scope of the proposed charter is warranted. > >The draft charter is available from >http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt. The >problem statement and motivation for the PCN work is discussed in >more detail in draft-chan-pcn-problem-statement-00, which has been >submitted to IETF and is also available at >http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt. > >Proposed BOF agenda > >1. Agenda bashing (5 min) >2. Motivation and Problem Statement presentation (15 min) >3. Discussion of motivation and problem statement (30 min) >4. Overview of prior PCN efforts, related work and open issues (15 min) >5. Overview of the proposed charter (10 min) >6. Discussion/bashing of the proposed charter (20 min) >7. General discussion and poll on the WG creation (25 min) >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn --=====================_11196740==.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kp.nortel.com id k8LGHV129511 FYI.
I have put this Request for Pre-Congestion Notification BOF at:
  http://standards.nortel.com/pcn/RequestForPCNBOF.txt
for ease of access and reference.
Thanks!
-- Kwok --

At 04:51 PM 9/14/2006, you wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary=3D"----_=3D_NextPart_001_01C6D83F.86BCF870"

Hello Lars and Magnus,
 
This message constitutes a formal request for Pre-Congesti= on Notification BOF at the November IETF meeting in San Diego. 
 
The BOF description and its proposed agenda are attached a= t the end of this message.
 
If this BOF is approved,  we would like to request a two-hour slot that avoids scheduling conflicts with the following working groups:  tsv, nsis, sip, ieprep, ecrit, pwe3, dccp.
 
We also ask that you CC agenda@ietf.org with your decision.
 
Of course we welcome any feedback you might have.
 
Best Regards,
Anna Charny
 
PCN BOF Description
 
The Pre-Congestion Notification (PCN)  BOF will address the problem of how to provide scalable and 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 overall approach will be based on a the concept of a PCN-Region, within which the functionality is separated between the PCN-Interior Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF will be the case of a single DiffServ region, which maps to a PCN-Region.   PINs mark packet headers when their traffic is above a certain level, as an early warning of incipient congestion (=93pre-congestion=94); this builds on concepts from RFC 3168 "The Addition of Explicit Congestion Notification to IP".  PENs monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the PENs or by a centralized system (which is informed of the PCN information).

The BOF will address the need and the motivation for PCN work in the context of IETF, provide a brief overview of prior PCN efforts and related work,  and review open issues.  The BOF will also discuss the scope of work and solicit feedback on the proposed charter.  Ultimately, the goal of the BOF is to solicit community feedback on whether the problem is clear and needs to be addressed, and consequently whether the creation of a new PCN WG within the scope of the proposed charter is warranted.
 
The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt . The problem statement and motivation for the PCN wo= rk is discussed in more detail in draft-chan-pcn-problem-statement-00, which has been submitted to IETF and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt .
 
Proposed BOF agenda 
 
1.  Agenda bashing  (5 min)
2.  Motivation and Problem Statement presentation  (15 min)
3.  Discussion of motivation and problem statement (30 min)
4.  Overview of prior PCN efforts, related work and open issues (15 min)
5.  Overview of the proposed charter (10 min)
6.  Discussion/bashing of the proposed charter (20 min)
7.  General discussion and poll on the WG creation (25 min)
_______________________________________________
PCN mailing list
PCN@ietf.org
 https://www1.ietf.org/mailman/listinfo/pcn
--=====================_11196740==.ALT-- --===============0217859314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0217859314==-- From pcn-bounces@ietf.org Thu Sep 21 12:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRc0-0001kp-SM; Thu, 21 Sep 2006 12:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRbz-0001kk-U0 for pcn@ietf.org; Thu, 21 Sep 2006 12:41:19 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQRbv-0003xe-4M for pcn@ietf.org; Thu, 21 Sep 2006 12:41:19 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1DF511796; Thu, 21 Sep 2006 18:41:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 11C2F1795; Thu, 21 Sep 2006 18:41:08 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id BEF86171E; Thu, 21 Sep 2006 18:41:07 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8LGf7s31929; Thu, 21 Sep 2006 18:41:07 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 972D86F58E; Thu, 21 Sep 2006 18:39:57 +0200 (CEST) Message-ID: <4512C0B6.3070608@informatik.uni-wuerzburg.de> Date: Thu, 21 Sep 2006 18:41:26 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kwok-Ho Chan Subject: Re: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD01@E03MVZ1-UKDY.domain1.systemhost.net> <45129056.5080709@informatik.uni-wuerzburg.de> <6.2.5.6.0.20060921112301.0612d030@nortel.com> In-Reply-To: <6.2.5.6.0.20060921112301.0612d030@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Kwok-Ho I cannot be at the next meeting but I am interested in your results. Best wishes, Michael Kwok-Ho Chan wrote: > We actually have been doing simulations on the algorithms. > And have been sharing them with the design team (some of our many > hours of design meetings during previous IETFs and other mtgs). > > It may be helpful to have 15-30 minutes of agenda time during > the BOF to share some high lights of simulation results. > This will help some of discussions we are having on the CL-PHB draft. > > This is a suggestion and is meant to solicit interest and response. > IMHO, this is secondary to the main topic of Problem Statement and Goals > and getting the WG started. But this follows right on the heels of > creating the WG. > > Thanks! > -- Kwok -- > > At 09:15 AM 9/21/2006, Michael Menth wrote: >> Hi Philip, >> >> philip.eardley@bt.com wrote: >>> Michael >>> Thanks for the comments >>> >>> On 1), we had a lot of discussion amongst the authors without reaching >>> final agreement on this issue. I think (I may have remembered this >>> wrong!) that we were leaning towards there not being that much >>> difference between having two thresholds and having one threshold >>> ("ramp >>> or probabilistic" vs "step" marking), and that we needed to do some >>> more >>> simulations to find out whether it makes any odds >>> >> Ok. I don't expect much difference. >> >>> A couple of possible reasons for having "ramp" marking: >>> - robustness to worst case traffic - if the aggregate of traffic at a >>> router is very smooth, then "step" marking might not give (hardly) any >>> markings until too many calls are admitted. Whereas "ramp" marking >>> would >>> give some more warning - in particular, if several routers are >>> marking a >>> little, then the marking rate at the egress (which is the sum of the >>> individual routers' marking rates) will be big enough that it starts >>> blocking calls. >>> >> I think that the sensitivity to bursty traffic can be rather >> controlled by the size of the virtual queue itself. >> >>> - "ramp" marking may help >>> http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-ch >>> >>> eat-01.txt to work. this I-D is about enabling a single PCN-region to >>> include networks that don't trust each other - at the borders between >>> the networks, only bulk measurements (of PCN markings) are needed. For >>> the idea to work, it needs a little bit of marking at data rates below >>> the configured-admission-rate. "ramp" marking helps this [there may be >>> alternative ways]. >>> >> Hm, not quite understood. Anyway. But again, I think that the size of >> the virtual queue is enough to control the marking. Simulations could >> proof or disprove whether probability-based marking has any benefit >> over a simpler queue with a reasonably set queue size. >>> >>> There's also the question of whether it could be left open to operator, >>> ie standard could have 2 thresholds, however in deployment you can set >>> them the same. >>> >>> On 2), as far as I remember there was no particular reason for the >>> description using token buckets rather than virtual queues - just [I >>> think] we found it easier to think about / describe like that. >>> Where you say >>> >>>>> - The admission marker wants to find out whether the configured >>>>> >>> admission >>> rate is exceeded and if so, it wants to label all packets. Therefore, >>> the queue has infinite "buffer size" (probably set to a reasonable >>> value to recognize quickly if the rate has reduced) and all packets >>> beyond a certain threshold are labelled. >>> >>> indeed, we found a problem if the max size of the virtual queue is >>> "infinite" [NB the virtual queue is just a number, not a buffer]. >>> Because then the marking probability can be 100% even when there are no >>> packets in the real queue. Why? After a period of excess traffic the >>> virtual queue grows. Say the arrival rate now drops to 0. It will take >>> about (size-of-virtual-queue / configured-admission-rate) secs for the >>> virtual queue to empty and the marking probability to drop so that >>> calls >>> can once again be admitted. Therefore, if size-of-virtual-queue is too >>> big, after a lengthy period of excess traffic there will be a lengthy >>> recovery period whilst the virtual queue empties. However, the real >>> queue is constrained in length, because it drops packets and so will be >>> able to enqueue packets again much sooner. The value used for >>> size-of-virtual-queue in simulations was, I think, chosen fairly >>> arbitrarily - twice the real buffer size rings a bell. >> So we think the same about this issue. I can imagine that the quest >> for a reasonable queue size of the preemption marker is also an open >> issue and subject to further research. >> >> >> Kind regards, >> >> Michael >> >>> Best wishes, >>> phil >>> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: >>> 21 September 2006 07:23 >>> To: pcn@ietf.org >>> Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt >>> >>> Hi all, >>> >>> I quickly browsed through the draft on Pre-Congestion Notification >>> marking >>> http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt >>> and want to give some comments. >>> >>> 1) I don't understand why Section 2 proposes a virtual queue with a >>> a probability-based marking when the queue size is within two >>> thresholds. >>> What is the benefit of such an approach compared with the one of a >>> queue >>> with a single threshold from which on packets are labelled if they >>> exceed >>> this limit? Is this maybe a relict from an RED-based ECN-labelling >>> which >>> might be useful in the presence of TCP traffic? From my perspective, >>> the >>> task of admission marking is just to mark those packets that exceed the >>> configured admission rate and a virtual queue is used only to account >>> for >>> the burstiness of the traffic and to allow some tolerance regarding the >>> rate. This is similar to the "cell delay variation tolerance (CDVT)" >>> and >>> the "burst tolerance" in ATM. >>> >>> 2) I was puzzled by the fact that the Admission Marker uses a virtual >>> queue and that the preemption marker uses a token bucket. I'd prefer >>> if a solution is given in a similar manner, e.g., two virtual queues >>> that differ with respect to the following issues: >>> - Admission marking considers all realtime packets whereas preemption >>> marking considers only non-preemption-marked packets. >>> - The admission marker wants to find out whether the configured >>> admission >>> rate is exceeded and if so, it wants to label all packets. Therefore, >>> the queue has infinite "buffer size" (probably set to a reasonable >>> value to recognize quickly if the rate has reduced) and all packets >>> beyond a certain threshold are labelled. >>> - In contrast, the preemption marker wants to mark packets that exceed >>> the configured preemption rate. Therefore, - if a virtual queue is >>> also used in this case - only those packets exceeding the threshold >>> are preemption-marked and these packets do not increase the queue >>> size. >>> - As the admission marker cannot be based on a token bucket, I consider >>> the virtual queue as the more appropriate unifying mechanism for both >>> markers. >>> >>> Note that this would only describe the behavior of the markers, the >>> implementation can be done differently. >>> >>> Best wishes, >>> >>> Michael >>> >>> >> >> -- >> Dr. Michael Menth, Assistant Professor >> University of Wuerzburg, Institute of Computer Science >> Am Hubland, D-97074 Wuerzburg, Germany, room B206 >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Sep 21 13:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRy4-0008Qb-LN; Thu, 21 Sep 2006 13:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQRy3-0008PK-BL for pcn@ietf.org; Thu, 21 Sep 2006 13:04:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQRxx-0007CX-VO for pcn@ietf.org; Thu, 21 Sep 2006 13:04:07 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8LH3x417015; Thu, 21 Sep 2006 13:03:59 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 13:03:54 -0400 Message-Id: <6.2.5.6.0.20060921125432.03404840@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Sep 2006 13:03:53 -0400 To: menth@informatik.uni-wuerzburg.de From: "Kwok-Ho Chan" Subject: Re: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt In-Reply-To: <4512C0B6.3070608@informatik.uni-wuerzburg.de> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD01@E03MVZ1-UKDY.domain1.systemhost.net> <45129056.5080709@informatik.uni-wuerzburg.de> <6.2.5.6.0.20060921112301.0612d030@nortel.com> <4512C0B6.3070608@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Sep 2006 17:03:54.0365 (UTC) FILETIME=[EB49AAD0:01C6DD9F] X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael: OK. We will post all our presentations and published drafts at: http://standards.nortel.com/pcn/ and notify the pcn@ietf.org list when they are available. IMHO, we need to have these supporting work to push the CL-PHB draft forward. And I am inviting others on this list to join in with this effort. These are the sweat equity we need to create. -- Kwok -- At 12:41 PM 9/21/2006, Michael Menth wrote: >Hi Kwok-Ho > >I cannot be at the next meeting but I am interested in your results. > >Best wishes, > > Michael > >Kwok-Ho Chan wrote: >>We actually have been doing simulations on the algorithms. >>And have been sharing them with the design team (some of our many >>hours of design meetings during previous IETFs and other mtgs). >> >>It may be helpful to have 15-30 minutes of agenda time during >>the BOF to share some high lights of simulation results. >>This will help some of discussions we are having on the CL-PHB draft. >> >>This is a suggestion and is meant to solicit interest and response. >>IMHO, this is secondary to the main topic of Problem Statement and Goals >>and getting the WG started. But this follows right on the heels of >>creating the WG. >> >>Thanks! >>-- Kwok -- >> >>At 09:15 AM 9/21/2006, Michael Menth wrote: >>>Hi Philip, >>> >>>philip.eardley@bt.com wrote: >>>>Michael >>>>Thanks for the comments >>>> >>>>On 1), we had a lot of discussion amongst the authors without reaching >>>>final agreement on this issue. I think (I may have remembered this >>>>wrong!) that we were leaning towards there not being that much >>>>difference between having two thresholds and having one threshold ("ramp >>>>or probabilistic" vs "step" marking), and that we needed to do some more >>>>simulations to find out whether it makes any odds >>>Ok. I don't expect much difference. >>> >>>>A couple of possible reasons for having "ramp" marking: >>>>- robustness to worst case traffic - if the aggregate of traffic at a >>>>router is very smooth, then "step" marking might not give (hardly) any >>>>markings until too many calls are admitted. Whereas "ramp" marking would >>>>give some more warning - in particular, if several routers are marking a >>>>little, then the marking rate at the egress (which is the sum of the >>>>individual routers' marking rates) will be big enough that it starts >>>>blocking calls. >>>I think that the sensitivity to bursty traffic can be rather >>>controlled by the size of the virtual queue itself. >>> >>>>- "ramp" marking may help >>>>http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-ch >>>>eat-01.txt to work. this I-D is about enabling a single PCN-region to >>>>include networks that don't trust each other - at the borders between >>>>the networks, only bulk measurements (of PCN markings) are needed. For >>>>the idea to work, it needs a little bit of marking at data rates below >>>>the configured-admission-rate. "ramp" marking helps this [there may be >>>>alternative ways]. >>>Hm, not quite understood. Anyway. But again, I think that the size >>>of the virtual queue is enough to control the marking. Simulations >>>could proof or disprove whether probability-based marking has any >>>benefit over a simpler queue with a reasonably set queue size. >>>> >>>>There's also the question of whether it could be left open to operator, >>>>ie standard could have 2 thresholds, however in deployment you can set >>>>them the same. >>>> >>>>On 2), as far as I remember there was no particular reason for the >>>>description using token buckets rather than virtual queues - just [I >>>>think] we found it easier to think about / describe like that. >>>>Where you say >>>> >>>>>>- The admission marker wants to find out whether the configured >>>>admission >>>>rate is exceeded and if so, it wants to label all packets. Therefore, >>>>the queue has infinite "buffer size" (probably set to a reasonable >>>>value to recognize quickly if the rate has reduced) and all packets >>>>beyond a certain threshold are labelled. >>>> >>>>indeed, we found a problem if the max size of the virtual queue is >>>>"infinite" [NB the virtual queue is just a number, not a buffer]. >>>>Because then the marking probability can be 100% even when there are no >>>>packets in the real queue. Why? After a period of excess traffic the >>>>virtual queue grows. Say the arrival rate now drops to 0. It will take >>>>about (size-of-virtual-queue / configured-admission-rate) secs for the >>>>virtual queue to empty and the marking probability to drop so that calls >>>>can once again be admitted. Therefore, if size-of-virtual-queue is too >>>>big, after a lengthy period of excess traffic there will be a lengthy >>>>recovery period whilst the virtual queue empties. However, the real >>>>queue is constrained in length, because it drops packets and so will be >>>>able to enqueue packets again much sooner. The value used for >>>>size-of-virtual-queue in simulations was, I think, chosen fairly >>>>arbitrarily - twice the real buffer size rings a bell. >>>So we think the same about this issue. I can imagine that the >>>quest for a reasonable queue size of the preemption marker is also >>>an open issue and subject to further research. >>> >>> >>>Kind regards, >>> >>> Michael >>> >>>>Best wishes, >>>>phil >>>> >>>>-----Original Message----- >>>>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>Sent: 21 September 2006 07:23 >>>>To: pcn@ietf.org >>>>Subject: [PCN] Feedback on draft-briscoe-tsvwg-cl-phb-02.txt >>>> >>>>Hi all, >>>> >>>>I quickly browsed through the draft on Pre-Congestion Notification >>>>marking >>>>http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt >>>>and want to give some comments. >>>> >>>>1) I don't understand why Section 2 proposes a virtual queue with a >>>>a probability-based marking when the queue size is within two >>>>thresholds. >>>>What is the benefit of such an approach compared with the one of a queue >>>>with a single threshold from which on packets are labelled if they >>>>exceed >>>>this limit? Is this maybe a relict from an RED-based ECN-labelling which >>>>might be useful in the presence of TCP traffic? From my perspective, the >>>>task of admission marking is just to mark those packets that exceed the >>>>configured admission rate and a virtual queue is used only to account >>>>for >>>>the burstiness of the traffic and to allow some tolerance regarding the >>>>rate. This is similar to the "cell delay variation tolerance (CDVT)" and >>>>the "burst tolerance" in ATM. >>>> >>>>2) I was puzzled by the fact that the Admission Marker uses a virtual >>>>queue and that the preemption marker uses a token bucket. I'd prefer >>>>if a solution is given in a similar manner, e.g., two virtual queues >>>>that differ with respect to the following issues: >>>>- Admission marking considers all realtime packets whereas preemption >>>>marking considers only non-preemption-marked packets. >>>>- The admission marker wants to find out whether the configured >>>>admission >>>>rate is exceeded and if so, it wants to label all packets. Therefore, >>>>the queue has infinite "buffer size" (probably set to a reasonable >>>>value to recognize quickly if the rate has reduced) and all packets >>>>beyond a certain threshold are labelled. >>>>- In contrast, the preemption marker wants to mark packets that exceed >>>>the configured preemption rate. Therefore, - if a virtual queue is >>>>also used in this case - only those packets exceeding the threshold >>>>are preemption-marked and these packets do not increase the queue >>>>size. >>>>- As the admission marker cannot be based on a token bucket, I consider >>>>the virtual queue as the more appropriate unifying mechanism for both >>>>markers. >>>> >>>>Note that this would only describe the behavior of the markers, the >>>>implementation can be done differently. >>>> >>>>Best wishes, >>>> >>>> Michael >>>> >>> >>>-- >>>Dr. Michael Menth, Assistant Professor >>>University of Wuerzburg, Institute of Computer Science >>>Am Hubland, D-97074 Wuerzburg, Germany, room B206 >>>phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >>>mailto:menth@informatik.uni-wuerzburg.de >>>http://www3.informatik.uni-wuerzburg.de/research/ngn >>> >>> >>>_______________________________________________ >>>PCN mailing list >>>PCN@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pcn > >-- >Dr. Michael Menth, Assistant Professor >University of Wuerzburg, Institute of Computer Science >Am Hubland, D-97074 Wuerzburg, Germany, room B206 >phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >mailto:menth@informatik.uni-wuerzburg.de >http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 22 09:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007b4-Sl; Fri, 22 Sep 2006 09:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007at-6J for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlHp-00062D-Ly for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C7AF142F7 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id BB23A4306 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A77DD42F3 for ; Fri, 22 Sep 2006 15:41:46 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8MDfks08464 for ; Fri, 22 Sep 2006 15:41:46 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id BE8426F58E for ; Fri, 22 Sep 2006 15:40:35 +0200 (CEST) Message-ID: <4513E835.9000506@informatik.uni-wuerzburg.de> Date: Fri, 22 Sep 2006 15:42:13 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [PCN] Feedback to http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, I know that the current focus of this list is more on the problem statement and the charter. However, as I have recently read the drafts, I'd like to share my thoughts with you before lectures start in October and make me more busy than I am now. As I mentioned in previous emails, I consider the technical contents very good, but its presentation could be simplified such that also non-experts get its basic ideas right at first reading. A slightly more precise terminology also helps although I am also already used to the current nomenclature. * I tried an alternative wording of the summary given in Section 1.1 of http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt and hope that I understood the draft correctly. This might be useful to tell people quickly what kind of network admission control (NAC) the PCN list is currently concerned with. * I tried to outline the salient features of the NAC to point out why the solution is good (Simplicity, Scalability, Robustness). I send these issues in two extra emails. Best regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-9From pcn-bounces@ietf.org Fri Sep 22 09:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007b4-Sl; Fri, 22 Sep 2006 09:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007at-6J for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlHp-00062D-Ly for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C7AF142F7 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id BB23A4306 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A77DD42F3 for ; Fri, 22 Sep 2006 15:41:46 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8MDfks08464 for ; Fri, 22 Sep 2006 15:41:46 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id BE8426F58E for ; Fri, 22 Sep 2006 15:40:35 +0200 (CEST) Message-ID: <4513E835.9000506@informatik.uni-wuerzburg.de> Date: Fri, 22 Sep 2006 15:42:13 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [PCN] Feedback to http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, I know that the current focus of this list is more on the problem statement and the charter. However, as I have recently read the drafts, I'd like to share my thoughts with you before lectures start in October and make me more busy than I am now. As I mentioned in previous emails, I consider the technical contents very good, but its presentation could be simplified such that also non-experts get its basic ideas right at first reading. A slightly more precise terminology also helps although I am also already used to the current nomenclature. * I tried an alternative wording of the summary given in Section 1.1 of http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt and hope that I understood the draft correctly. This might be useful to tell people quickly what kind of network admission control (NAC) the PCN list is currently concerned with. * I tried to outline the salient features of the NAC to point out why the solution is good (Simplicity, Scalability, Robustness). I send these issues in two extra emails. Best regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 22 09:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007bB-Vx; Fri, 22 Sep 2006 09:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007ay-9S for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlHp-00062E-Lz for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D257C17B1 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C65C81726 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A6DDB1679 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8MDfms08468 for ; Fri, 22 Sep 2006 15:41:48 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D31A26F58E for ; Fri, 22 Sep 2006 15:40:37 +0200 (CEST) Message-ID: <4513E837.4020301@informatik.uni-wuerzburg.de> Date: Fri, 22 Sep 2006 15:42:15 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [PCN] Summary X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Summary A "controlled load (CL) region" consists of ingress and egress gateways (routers) and of interior routers. An admission control (AC) function explicitly admits flows that want to use the CL service of the CL region and that enter and leave the region at its ingress and egress routers. The ingress and egress gateways are also called border routers and the overall CL traffic between two border routers is called a "border-to-border (b2b) CL aggregate". The flows need traffic descriptors that are enforced by a policing function at the ingress routers and they may also be used for the admission decision. Each link in such a CL region is associated with a configurable "admissible CL link rate" and a configurable "supportable CL link rate" whereby the supportable CL link rate is usually significantly larger than the admissible CL link rate. When a link carries more traffic than its admissible link CL rate, no additional flows should be admitted to the network. Although flows are only admitted as long as the admissible CL link rate is not exceeded, the admitted traffic on a link can exceed the supportabl31/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 22 09:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007bB-Vx; Fri, 22 Sep 2006 09:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHs-0007ay-9S for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlHp-00062E-Lz for pcn@ietf.org; Fri, 22 Sep 2006 09:41:52 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D257C17B1 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C65C81726 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A6DDB1679 for ; Fri, 22 Sep 2006 15:41:48 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8MDfms08468 for ; Fri, 22 Sep 2006 15:41:48 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D31A26F58E for ; Fri, 22 Sep 2006 15:40:37 +0200 (CEST) Message-ID: <4513E837.4020301@informatik.uni-wuerzburg.de> Date: Fri, 22 Sep 2006 15:42:15 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [PCN] Summary X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Summary A "controlled load (CL) region" consists of ingress and egress gateways (routers) and of interior routers. An admission control (AC) function explicitly admits flows that want to use the CL service of the CL region and that enter and leave the region at its ingress and egress routers. The ingress and egress gateways are also called border routers and the overall CL traffic between two border routers is called a "border-to-border (b2b) CL aggregate". The flows need traffic descriptors that are enforced by a policing function at the ingress routers and they may also be used for the admission decision. Each link in such a CL region is associated with a configurable "admissible CL link rate" and a configurable "supportable CL link rate" whereby the supportable CL link rate is usually significantly larger than the admissible CL link rate. When a link carries more traffic than its admissible link CL rate, no additional flows should be admitted to the network. Although flows are only admitted as long as the admissible CL link rate is not exceeded, the admitted traffic on a link can exceed the supportable CL link rate, e.g., due to changed flow behavior or due to redirected traffic after failures. In such a case, counter actions may be taken to reduce the traffic on the link, e.g., by preempting already admitted CL flows in order to restore the QoS of the CL service. The AC function for a new flow entering the network at ingress router R0 and leaving it at egress router R1 relies on feedback from the egress router R1 about the existing b2b CL aggregate between R0 and R1. This feedback is generated as follows. All routers meter the rate of the CL traffic on their outgoing links and mark the packets with "admission saturation" if the admissible CL link rate is exceeded. Egress router R1 controls the admission saturation marks for each of its b2b CL aggregates separately, and if the packets from R0 are admission saturation marked, no further flows from R0 to R1 should be admitted. This must be signaled from the egress R1 to the ingress R0. As the inter-arrival time of CL packets on a link varies, the rate of the CL traffic on the link is also subject to fluctuations. As a consequence, the admissible CL link rate may be sometimes exceeded. To get more stable information about the admission saturation for a b2b aggregate, the egress routers measure the fraction of the traffic that is associated with an admission saturation mark, and provide a "b2b admission saturation estimate" based on a moving average. If this value is large (close to 1), no further flows should be admitted. A potential preemption function relies on the feedback from the egress routers about the b2b CL aggregates. This feedback is generated as follows. All routers meter the rate of the CL traffic on their outgoing links and mark only those packets with "excess traffic" that exceed the respective supportable CL link rate. The egress routers measure for each b2b CL aggregate the rate of all received packets ("b2b received rate") and the rate of received packets with an excess traffic mark ("b2b excess rate"). If the b2b excess rate of an b2b CL aggregate is larger than zero, the rate of the b2b CL aggregate should be reduced by its b2b excess rate under the assumption that no packet loss occurred; otherwise, the b2b sent rate is required from the corresponding ingress router to calculate the required traffic rate reduction: (sent rate - (received rate - excess rate)). Thus, the following mapping of the terminology is used (here : Section 1.2 of the draft): http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt admissible link rate: configured-admission-rate supportable link rate: configured-preemption-rate admission saturation mark: admission mark excess traffic mark: preemption mark b2b CL aggregate: CL-region-aggregate b2b admission saturation estimate: congestion-level-estimate b2b sent rate: ingress-aggregate-rate b2b received rate: no equivalent b2b excess traffic rate: no equivalent An equivalent for sustainable-aggregate-rate is intentionally avoided as this is only what it means if packets of the respective aggregate are preemption marked. I like the new notation better than the old one for the following reasons: - The attributes "b2b" and "link" show the scope of the measured quantities which is of extreme importance for the understanding of how the measurement-based AC works. - "admissible" and "supportable" express a threshold rather than an action (admission, preemption). - The mark "excess traffic" just indicates that the admissible link rate is exceeded, but it does not imply any action like preemption. - The mark "admission saturation" indicates that no further flows should be admitted whereas the mark "admission" can lead to confusion. - This motivates also the "b2b admission saturation estimate". I do not propose this nomenclature as the best one and that it should be copied, but I'd like to point out that the terminology can be made more precise. Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science e CL link rate, e.g., due to changed flow behavior or due to redirected traffic after failures. In such a case, counter actions may be taken to reduce the traffic on the link, e.g., by preempting already admitted CL flows in order to restore the QoS of the CL service. The AC function for a new flow entering the network at ingress router R0 and leaving it at egress router R1 relies on feedback from the egress router R1 about the existing b2b CL aggregate between R0 and R1. This feedback is generated as follows. All routers meter the rate of the CL traffic on their outgoing links and mark the packets with "admission saturation" if the admissible CL link rate is exceeded. Egress router R1 controls the admission saturation marks for each of its b2b CL aggregates separately, and if the packets from R0 are admission saturation marked, no further flows from R0 to R1 should be admitted. This must be signaled from the egress R1 to the ingress R0. As the inter-arrival time of CL packets on a link varies, the rate of the CL traffic on the link is also subject to fluctuations. As a consequence, the admissible CL link rate may be sometimes exceeded. To get more stable information about the admission saturation for a b2b aggregate, the egress routers measure the fraction of the traffic that is associated with an admission saturation mark, and provide a "b2b admission saturation estimate" based on a moving average. If this value is large (close to 1), no further flows should be admitted. A potential preemption function relies on the feedback from the egress routers about the b2b CL aggregates. This feedback is generated as follows. All routers meter the rate of the CL traffic on their outgoing links and mark only those packets with "excess traffic" that exceed the respective supportable CL link rate. The egress routers measure for each b2b CL aggregate the rate of all received packets ("b2b received rate") and the rate of received packets with an excess traffic mark ("b2b excess rate"). If the b2b excess rate of an b2b CL aggregate is larger than zero, the rate of the b2b CL aggregate should be reduced by its b2b excess rate under the assumption that no packet loss occurred; otherwise, the b2b sent rate is required from the corresponding ingress router to calculate the required traffic rate reduction: (sent rate - (received rate - excess rate)). Thus, the following mapping of the terminology is used (here : Section 1.2 of the draft): http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt admissible link rate: configured-admission-rate supportable link rate: configured-preemption-rate admission saturation mark: admission mark excess traffic mark: preemption mark b2b CL aggregate: CL-region-aggregate b2b admission saturation estimate: congestion-level-estimate b2b sent rate: ingress-aggregate-rate b2b received rate: no equivalent b2b excess traffic rate: no equivalent An equivalent for sustainable-aggregate-rate is intentionally avoided as this is only what it means if packets of the respective aggregate are preemption marked. I like the new notation better than the old one for the following reasons: - The attributes "b2b" and "link" show the scope of the measured quantities which is of extreme importance for the understanding of how the measurement-based AC works. - "admissible" and "supportable" express a threshold rather than an action (admission, preemption). - The mark "excess traffic" just indicates that the admissible link rate is exceeded, but it does not imply any action like preemption. - The mark "admission saturation" indicates that no further flows should be admitted whereas the mark "admission" can lead to confusion. - This motivates also the "b2b admission saturation estimate". I do not propose this nomenclature as the best one and that it should be copied, but I'd like to point out that the terminology can be made more precise. Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 22 09:41:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHw-0007cA-40; Fri, 22 Sep 2006 09:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlHu-0007c2-IZ for pcn@ietf.org; Fri, 22 Sep 2006 09:41:54 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlHt-00062l-2c for pcn@ietf.org; Fri, 22 Sep 2006 09:41:54 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9BE9242F7 for ; Fri, 22 Sep 2006 15:41:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 90BAB42F3 for ; Fri, 22 Sep 2006 15:41:52 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7D9FF4284 for ; Fri, 22 Sep 2006 15:41:52 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8MDfqs08472 for ; Fri, 22 Sep 2006 15:41:52 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id B4F656F58E for ; Fri, 22 Sep 2006 15:40:41 +0200 (CEST) Message-ID: <4513E83B.7060204@informatik.uni-wuerzburg.de> Date: Fri, 22 Sep 2006 15:42:19 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [PCN] Simplicity, Scalability, Robustness X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org The proposed network admission control (NAC) method is simple, scalable, and robust because - Per flow states are only required at the ingress routers to prevent non-admitted CL traffic from entering the CL region, other network entities are not aware of individual flows. - Each router has a separate admission saturation and excess traffic marker for each of its links. These markers operate on the overall CL traffic of the respective link. Therefore, there are no scalability concerns. - The information of these measurements is implicitly signaled to the respective egress routers by the marks in the packet headers and no protocol actions are required. - The egress routers measure the rates of all received, admission saturation marked, and excess traffic marked packets separately for each ingress router. These meters operate on the overall CL traffic of the respective link. Therefore, there are no scalability concerns as long as the number of ingress routers is sufficiently small (or at least not overwhelmingly large). - Feedback signaling is required between all pairs of ingress and egress routers and the signaled information is on the basis of the corresponding b2b CL aggregate, i.e., it is also unaware of individual flows. - The admissible link rates can be chosen small enough and the supportable link rates can be chosen large enough that admitted traffic can be carried after a rerouting in failure cases. This is an important feature as QoS violations in core networks due to link failures are more likely than QoS violations due to increased traffic volume. - Networks are dimensioned in such a way that packet delay and loss or excessive call blocking are unlikely. Thus, the effect of admission control is usually not visible. It can be viewed as an insurance to prevent congestion in exceptional scenarios such as excessive user load or redirected traffic due to single link failures (see point above). - The preemption function complements AC to recover from sudden unexpected surges of already admitted CL traffic on the links. Such scenarios are very unlikely but not impossible. They can be caused by large network failures that redirect lots of admitted CL traffic to other links, by malfunction of the measurement-based AC in the presence of a flash crowd of new admission requests, or by malfunction of the measurement-based AC in the presence of admitted flows that send for a while with an atypically low rate and increase their rates in a concerted way. -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 22 12:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQoIg-0002kc-CF; Fri, 22 Sep 2006 12:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQoIf-0002kX-6v for pcn@ietf.org; Fri, 22 Sep 2006 12:54:53 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQoIW-0007EL-PE for pcn@ietf.org; Fri, 22 Sep 2006 12:54:53 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 17:54:43 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Sep 2006 17:54:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback tohttp://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt Date: Fri, 22 Sep 2006 17:54:42 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD08@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <4513E835.9000506@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback tohttp://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: AcbeTOmyOLhj4aPySd2hzV57uN/V+AADjxkg From: To: , X-OriginalArrivalTime: 22 Sep 2006 16:54:43.0175 (UTC) FILETIME=[CD2A7F70:01C6DE67] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Thanks!=20 I basically like your Summary & your comments on simplicity, scalability, robustness.=20 Will comment on some detailed points when back on-line [away next week], if they haven't already been covered.=20 Best wishes, Phil=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 22 September 2006 14:42 To: pcn@ietf.org Subject: [PCN] Feedback tohttp://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architectur e-03.txt Hi all, I know that the current focus of this list is more on the problem=20 statement and the charter. However, as I have recently read the drafts,=20 I'd like to share my thoughts with you before lectures start in October=20 and make me more busy than I am now. As I mentioned in previous emails, I consider the technical contents=20 very good, but its presentation could be simplified such that also=20 non-experts get its basic ideas right at first reading. A slightly more=20 precise terminology also helps although I am also already used to the=20 current nomenclature. * I tried an alternative wording of the summary given in Section 1.1 of http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 03.txt=20 and hope that I understood the draft correctly. This might be useful to=20 tell people quickly what kind of network admission control (NAC) the PCN list is currently concerned with. * I tried to outline the salient features of the NAC to point out why=20 the solution is good (Simplicity, Scalability, Robustness). I send these issues in two extra emails. Best regards, Michael --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Sep 24 19:34:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRdUx-0007iI-0k; Sun, 24 Sep 2006 19:34:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRdUw-0007fr-20 for pcn@ietf.org; Sun, 24 Sep 2006 19:34:58 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRdUt-0007UC-H4 for pcn@ietf.org; Sun, 24 Sep 2006 19:34:58 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k8ONYa3B006044; Sun, 24 Sep 2006 18:34:41 -0500 (CDT) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Sep 2006 18:34:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Sun, 24 Sep 2006 18:34:35 -0500 Message-ID: <7D096A439A3D0D48A3D10872022CFD091B580E@ILEXC1U02.ndc.lucent.com> In-Reply-To: <6.2.5.6.0.20060920135249.05849ca8@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt thread-index: Acbc3mF7tDmF84ycRC+LYUqwZtMemgDUwgTg From: "GOLDMAN, STUART O \(STUART\)" To: "Kwok-Ho Chan" X-OriginalArrivalTime: 24 Sep 2006 23:34:36.0750 (UTC) FILETIME=[FF46FEE0:01C6E031] X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: pcn@ietf.org, Shahram Davari , ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Kwok, Sorry to have taken so long to respond, but my day job got in the way.=20 As I understood the topic, we are addressing pre-congestion. In that light, I assumed that congestion has not yet occurred, but that we are approaching congestion. So, I further assumed that there was still some capacity available, although this remaining capacity needs to be conserved as best as possible. Am I am the right wavelength? Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortel.com]=20 Sent: Wednesday, September 20, 2006 10:58 AM To: GOLDMAN, STUART O (STUART) Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Stuart: Preemption is just one of possibly multiple decisions the End Node function can take. Hence you are right that there may be other decisions that is of value to the system as a whole, possibly depending on the deployment evironment. These discussions we have so far indicates that we may not want to call the network information the Interior Nodes are providing as "Preemption Mark" indication. Hence these discussions are very helpful for our BOF/WG. Thanks! -- Kwok -- At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: >Kwok-Ho, >While you seem to have only mentioned preemption, there should be ways >to recognize a call deserving higher than normal preference and giving >it that preference to the remaining network resources without having to >preempt a call in progress. Yes? > >Stuart Goldman >Lucent Technologies >sgoldman@lucent.com >602 493 8438 > > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: Wednesday, September 20, 2006 8:54 AM >To: Shahram Davari >Cc: pcn@ietf.org; ken carlberg >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Shahram: >I totally agree. >The cell phone network was also jammed during 9/11. >I was trying to reach my brother who were stuck in the subway >~2 stops from WTC. >So I know exactly how this feels like. But I prefer to let the >Police and Firemen to >use this resource to help the general public at large. > >The question becomes: >- Does the Emergency Services want to use the same physical network >as the general public? >-- If Yes. Then should the problem statement becomes: > "Some controlled preemption functionality is allowed for >Emergency purposes in the general > public integrated (voice, video, data, etc) network. This >controlled preemption functionality > needs to be supported by the network mechanisms." >-- If Yes. Then we will need some guidance and help wrt the >regulations of the different jurisdictions. > Also if the different jurisdictions even wants to use the same >network infrastructure for both > emergency and public usage purposes. If it is technically possible. > >By this I am not saying a good solution exist or that I am promoting >a specific solution. >I am just agreeing that this problem needs to be addressed. >We may end up saying we can not solve this problem as of yet. But I >wish we can solve it. > >Regards. >-- Kwok -- > > >At 09:34 AM 9/20/2006, Shahram Davari wrote: > >Kwok, > > > >Indeed you raised a good subject. The requirements for emergency > >services should be part of the problem statement, and be dealt with > >in the proposed solution draft. ITU-T has quite extensive work on > >the requirements for Emergency services. > > > >On a side note, one of the problems identified during a recent > >school shooting in Canada was that the emergency and police couldn't > >use the phone or cell phones to communicate because the network was > >jammed due to high volume of calls between students and their families. > > > >Yours, > >Shahram > > > > > > > -----Original Message----- > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > Sent: Tuesday, September 19, 2006 5:26 PM > > > To: ken carlberg > > > Cc: pcn@ietf.org > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed >Issue. > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > > > > Ken: > > > Thank you for handling so many of our replies at the same time. :) > > > > > > YES, on your point of: > > > > > > >just to recap. I just wanted to point out that there are > > > >jurisdictions that do not allow preemption for voice communications > > > >used by the general public -- this definitely applies for a number >of > > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > > >VoIP. Hence, I would recommend that the group consider other (re) > > > >actions other than preemption....which from the feedback of my > > > >original note, seems will be done. > > > > > > We are using the Problem-Statement draft to put out an > > > initial version of what > > > we are thinking, as this is still work in progress, there definitely > > > are area we > > > may have missed. > > > > > > Thank you for pointing out at least one of them. > > > > > > I will write some additional text for -01 version of the Problem > > > Statement draft to try > > > and describe the problem you have indicated (but I will try NOT to > > > indicate any solution > > > in the Problem Statement draft). > > > > > > And we will try to have some text in at least some of our Deployment > > > Model drafts > > > to see if there are good solutions to the problem you > > > indicated. There may be > > > more than one solution as there may be more than one Deployment >Model. > > > > > > Please Notice I have changed the subject of the E-Mail thread for > > > issue tracking purpose. > > > Please use this E-Mail Subject for continuing this discussion. > > > > > > Now I have additional questions concerning the use of Preemption for > > > handling Emergency > > > Services. Will Preemption be allowed for Emergency Services? > > > Does some of the > > > jurisdiction you have indicated want to use a separate network for > > > Emergency Services > > > purpose? Will combining Emergency Services with the normal > > > VoIP calls/sessions > > > be a good Problem Statement that we can add to our Problem > > > Statement draft? > > > > > > I am concentrating on Problem Statement instead of Solutions > > > for now because we > > > want to get the Problem Statement cleared away first for the > > > BOF purpose. > > > > > > Thanks! > > > -- Kwok -- > > > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > > >Anna, > > > > > > > >>>maybe we have a different perspective of preemption. as I view >it, > > > >>>preemption is removing *existing* state (circuit in the PSTN > > > >>>world) in > > > >>>favor of new state. > > > >> > > > >>I guess that may be one thing that needs clarification. The way I > > > >>view > > > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt >and > > > >>related docs view the issue) is that pre-emption should kick in > > > >>when for > > > >>whatever reason provisioning mechanisms fail there simply is not > > > >>enough > > > >>capacity to carry all calls. Setting aside the issue of >precedence > > > >>for > > > >>the moment, the expectation is that the level of traffic needed to > > > >>trigger premption is typicaly higher (perhaps substanially higher) > > > >>than > > > >>the level triggering to stop admission of new flows. That > > > means that > > > >>when preemption does get triggered, there would actually > > > not really be > > > >>any new state admitted. > > > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of > > > >understood some of the things you were saying, but there were too > > > >many things you left out (why does one have an admission control at > > > >level X and a preemption level at X+N?, are you implying that the > > > >edge is keeping track of the flows it rejects?....that would seem > > > >quite granular in keeping measurements). > > > > > > > >I'm not sure its necessary to clarify the above. Its probably just > > > >best that we agree that future work should include a more detailed > > > >discussion of what is preemption in the context of your >architecture. > > > > > > > >>The degree of how far apart preemption and > > > >>admission thresholds are is of course a mater of > > > configuration, but I > > > >>would expect that they would be sufficiently apart to ensure that > > > >>you do > > > >>not just toggle preempted and new flows. Of course if there > > > are higher > > > >>precedence calls, then one might expect that a higher > > > precedence call > > > >>may be established while lower precedence calls may need to be > > > >>preempted? > > > >> > > > >>Perhaps this expectation should be made more transparent in the > > > >>drafts? > > > >> > > > >>>In the US and some other countries, this is not > > > >>>allowed in the PSTN. > > > >> > > > >>Just wanted to make sure I understand exactly what is not allowed. > > > >>Are > > > >>you saying that PSTN is not allowed to preempt a lower > > > precedence call > > > >>in order to establish a high recedence call? Or are you > > > referring to > > > >>the same precedence levels? > > > > > > > >as an example, in the US PSTN, all calls from the general public >are > > > >treated with the same level of precedence. the exception are >systems > > > >like GETS, but they simply increase the probability of call > > > >completion -- they do not use preemption. private systems based on > > > >MLPP, like Autovon in the DoD and NATO, do allow different levels >of > > > >priority and subsequent preemption if so needed. rfc-4190 and > > > >rfc-4542 provide background on these systems/services along with > > > >discussion in the context of IP (since this is the IETF :-) > > > > > > > >just to recap. I just wanted to point out that there are > > > >jurisdictions that do not allow preemption for voice communications > > > >used by the general public -- this definitely applies for a number >of > > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > > >VoIP. Hence, I would recommend that the group consider other (re) > > > >actions other than preemption....which from the feedback of my > > > >original note, seems will be done. > > > > > > > >regards, > > > > > > > >-ken > > > > > > > > > > > >_______________________________________________ > > > >PCN mailing list > > > >PCN@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 25 07:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRod5-0004JK-Nw; Mon, 25 Sep 2006 07:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRod4-0004JD-ER; Mon, 25 Sep 2006 07:28:06 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRocr-0004cv-P9; Mon, 25 Sep 2006 07:28:06 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 598A21068; Mon, 25 Sep 2006 13:27:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 13:27:32 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 13:27:20 +0200 Message-ID: <4517BD18.4080400@ericsson.com> Date: Mon, 25 Sep 2006 13:27:20 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: agenda@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2006 11:27:20.0567 (UTC) FILETIME=[907FA070:01C6E095] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Lars Eggert , pcn@ietf.org Subject: [PCN] Re: Request for Pre-Congestion Notification BOF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, This BOF is approved. Chairs for the BOF is TBD. Best Regards Magnus Westerlund TSV AD Anna Charny (acharny) skrev: > Hello Lars and Magnus, > > This message constitutes a formal request for Pre-Congestion Notification BOF at the November IETF meeting in San Diego. > > The BOF description and its proposed agenda are attached at the end of this message. > > If this BOF is approved, we would like to request a two-hour slot that avoids scheduling conflicts with the following working groups: tsv, nsis, sip, ieprep, ecrit, pwe3, dccp. > > We also ask that you CC agenda@ietf.org with your decision. > > Of course we welcome any feedback you might have. > > Best Regards, > Anna Charny > > PCN BOF Description > > The Pre-Congestion Notification (PCN) BOF will address the problem of how to provide scalable and 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 overall approach will be based on a the concept of a PCN-Region, within which the functionality is separated between the PCN-Interior Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF will be the case of a single DiffServ region, which maps to a PCN-Region. PINs 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". PENs monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the PENs or by a centralized system (which is informed of the PCN information). > > The BOF will address the need and the motivation for PCN work in the context of IETF, provide a brief overview of prior PCN efforts and related work, and review open issues. The BOF will also discuss the scope of work and solicit feedback on the proposed charter. Ultimately, the goal of the BOF is to solicit community feedback on whether the problem is clear and needs to be addressed, and consequently whether the creation of a new PCN WG within the scope of the proposed charter is warranted. > > The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt . The problem statement and motivation for the PCN work is discussed in more detail in draft-chan-pcn-problem-statement-00, which has been submitted to IETF and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt . > > Proposed BOF agenda > > 1. Agenda bashing (5 min) > 2. Motivation and Problem Statement presentation (15 min) > 3. Discussion of motivation and problem statement (30 min) > 4. Overview of prior PCN efforts, related work and open issues (15 min) > 5. Overview of the proposed charter (10 min) > 6. Discussion/bashing of the proposed charter (20 min) > 7. General discussion and poll on the WG creation (25 min) > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 25 11:24:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsJx-0004g8-UZ; Mon, 25 Sep 2006 11:24:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrny-000258-97; Mon, 25 Sep 2006 10:51:34 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRriz-0001Xe-3r; Mon, 25 Sep 2006 10:46:27 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8PEkCT23916; Mon, 25 Sep 2006 10:46:12 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 10:46:05 -0400 Message-Id: <6.2.5.6.0.20060925104536.05c26538@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Sep 2006 10:46:04 -0400 To: Magnus Westerlund From: "Kwok-Ho Chan" Subject: Re: [PCN] Re: Request for Pre-Congestion Notification BOF In-Reply-To: <4517BD18.4080400@ericsson.com> References: <4517BD18.4080400@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Sep 2006 14:46:05.0598 (UTC) FILETIME=[545EF3E0:01C6E0B1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Lars Eggert , pcn@ietf.org, agenda@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Magnus: Thank you very much! -- Kwok -- At 07:27 AM 9/25/2006, Magnus Westerlund wrote: >Hi, > >This BOF is approved. Chairs for the BOF is TBD. > >Best Regards > >Magnus Westerlund >TSV AD > >Anna Charny (acharny) skrev: >>Hello Lars and Magnus, >> >>This message constitutes a formal request for Pre-Congestion >>Notification BOF at the November IETF meeting in San Diego. >> >>The BOF description and its proposed agenda are attached at the end >>of this message. >> >>If this BOF is approved, we would like to request a two-hour slot >>that avoids scheduling conflicts with the following working >>groups: tsv, nsis, sip, ieprep, ecrit, pwe3, dccp. >> >>We also ask that you CC agenda@ietf.org with your decision. >> >>Of course we welcome any feedback you might have. >> >>Best Regards, >>Anna Charny >> >>PCN BOF Description >> >>The Pre-Congestion Notification (PCN) BOF will address the problem >>of how to provide scalable and 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 overall approach will be based on a the concept of a >>PCN-Region, within which the functionality is separated between the >>PCN-Interior Node (PIN) and the PCN-End Node (PEN). The initial >>scope of the BOF will be the case of a single DiffServ region, >>which maps to a PCN-Region. PINs 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". PENs monitor the markings and that information is used to >>make flow admission control and pre-emption decisions. The >>decisions could be made by the PENs or by a centralized system >>(which is informed of the PCN information). >>The BOF will address the need and the motivation for PCN work in >>the context of IETF, provide a brief overview of prior PCN efforts >>and related work, and review open issues. The BOF will also >>discuss the scope of work and solicit feedback on the proposed >>charter. Ultimately, the goal of the BOF is to solicit community >>feedback on whether the problem is clear and needs to be addressed, >>and consequently whether the creation of a new PCN WG within the >>scope of the proposed charter is warranted. >> >>The draft charter is available from >>http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt >> . The >>problem statement and motivation for the PCN work is discussed in >>more detail in draft-chan-pcn-problem-statement-00, which has been >>submitted to IETF and is also available at >>http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt >> . >> >>Proposed BOF agenda >> >>1. Agenda bashing (5 min) >>2. Motivation and Problem Statement presentation (15 min) >>3. Discussion of motivation and problem statement (30 min) >>4. Overview of prior PCN efforts, related work and open issues (15 min) >>5. Overview of the proposed charter (10 min) >>6. Discussion/bashing of the proposed charter (20 min) 7. General >>discussion and poll on the WG creation (25 min) > > >-- > >Magnus Westerlund > >Multimedia Technologies, Ericsson Research EAB/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 25 11:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsPR-0006uw-Eu; Mon, 25 Sep 2006 11:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsPQ-0006ug-5N for pcn@ietf.org; Mon, 25 Sep 2006 11:30:16 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsP9-0007kz-Fm for pcn@ietf.org; Mon, 25 Sep 2006 11:30:16 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k8PFNWW25767; Mon, 25 Sep 2006 11:23:32 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 11:29:36 -0400 Message-Id: <6.2.5.6.0.20060925104843.05c26160@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Sep 2006 11:29:35 -0400 To: "GOLDMAN, STUART O \(STUART\)" From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: <7D096A439A3D0D48A3D10872022CFD091B580E@ILEXC1U02.ndc.lucen t.com> References: <6.2.5.6.0.20060920135249.05849ca8@nortel.com> <7D096A439A3D0D48A3D10872022CFD091B580E@ILEXC1U02.ndc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Sep 2006 15:29:36.0047 (UTC) FILETIME=[6851DBF0:01C6E0B7] X-Spam-Score: 0.1 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Cc: pcn@ietf.org, Shahram Davari , ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Stuart: No problem. By "Pre-Congestion", we mean: "if additional IP packet traffic is admitted (into the traffic class handling this traffic), then already admitted traffic (of the same traffic class) will experience degraded QoS. This degraded QoS happens at specific nodes (or diffserv hops) of the end-to-end path because we are working with IP packet network. This degraded QoS may affect the end-to-end service required of the network by the Using Application." Of course there are many factors that defines what is (and what is not) acceptable "degraded QoS" and how much additional traffic will cause the degraded QoS to be not acceptable, for example: - the Using Application and the requirements it have on the network. --- hence we are looking at inelastic, interactive, Real-Time use of the network (first). - the ratio of the total shared (by the traffic class) network resource at specific network nodes with respect to each admitted traffic flow and each to-be-admitted traffic flow. This indicates how each additional traffic flow over some limit will impact already admitted traffic flows. In both space and time dimensions. --- hence we are looking into amount of network resource, e.g. size of network pipes. We first look at the easier one (we think), large network pipes. Then the harder ones of smaller and smaller network pipes. - the characteristic of the traffic flows, for example are they constant bit rate? Or close to constant bit rate?, etc. - the promised service to the Using Application. On this Issue B.9, we are talking about promised service of NO PREEMPTION (but may be with some condition). As you indicated, the network resource we are discussing allows provisioning of detection before congestion, before the packet forwarding queues gets backed up. And we want to have some capacity still available (this may be view as one of the ways on HOW we can do this). But you are right that we may need to conserve this head-room capacity, but again depending on for what reasons. Is it because we can not preempt any admitted flows? Is it because we need to handle emergency services? Is it because we need to handle none-constant bit rate traffic? Some other reasons or combinations of them? These are still topics of discussions and additional work we hope we can do together in this WG (hopeful result of the PCN BOF). Sorry for such a long reply, just want to indicate some of the thinkings I have and working toward/down the path of agreements. Thanks! -- Kwok -- At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: >Kwok, > >Sorry to have taken so long to respond, but my day job got in the way. > >As I understood the topic, we are addressing pre-congestion. In that >light, I assumed that congestion has not yet occurred, but that we are >approaching congestion. So, I further assumed that there was still some >capacity available, although this remaining capacity needs to be >conserved as best as possible. > >Am I am the right wavelength? > >Stuart Goldman >Lucent Technologies >sgoldman@lucent.com >602 493 8438 > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: Wednesday, September 20, 2006 10:58 AM >To: GOLDMAN, STUART O (STUART) >Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Stuart: >Preemption is just one of possibly multiple decisions the End Node >function >can take. >Hence you are right that there may be other decisions that is of value >to the >system as a whole, possibly depending on the deployment evironment. > >These discussions we have so far indicates that we may not want to call >the network information the Interior Nodes are providing as "Preemption >Mark" >indication. > >Hence these discussions are very helpful for our BOF/WG. > >Thanks! >-- Kwok -- > > >At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: > >Kwok-Ho, > >While you seem to have only mentioned preemption, there should be ways > >to recognize a call deserving higher than normal preference and giving > >it that preference to the remaining network resources without having to > >preempt a call in progress. Yes? > > > >Stuart Goldman > >Lucent Technologies > >sgoldman@lucent.com > >602 493 8438 > > > > > >-----Original Message----- > >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > >Sent: Wednesday, September 20, 2006 8:54 AM > >To: Shahram Davari > >Cc: pcn@ietf.org; ken carlberg > >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > >AllowedIssue. Used to be Re: [PCN] > >draft-chan-pcn-problem-statement-00.txt > > > >Shahram: > >I totally agree. > >The cell phone network was also jammed during 9/11. > >I was trying to reach my brother who were stuck in the subway > >~2 stops from WTC. > >So I know exactly how this feels like. But I prefer to let the > >Police and Firemen to > >use this resource to help the general public at large. > > > >The question becomes: > >- Does the Emergency Services want to use the same physical network > >as the general public? > >-- If Yes. Then should the problem statement becomes: > > "Some controlled preemption functionality is allowed for > >Emergency purposes in the general > > public integrated (voice, video, data, etc) network. This > >controlled preemption functionality > > needs to be supported by the network mechanisms." > >-- If Yes. Then we will need some guidance and help wrt the > >regulations of the different jurisdictions. > > Also if the different jurisdictions even wants to use the same > >network infrastructure for both > > emergency and public usage purposes. If it is technically >possible. > > > >By this I am not saying a good solution exist or that I am promoting > >a specific solution. > >I am just agreeing that this problem needs to be addressed. > >We may end up saying we can not solve this problem as of yet. But I > >wish we can solve it. > > > >Regards. > >-- Kwok -- > > > > > >At 09:34 AM 9/20/2006, Shahram Davari wrote: > > >Kwok, > > > > > >Indeed you raised a good subject. The requirements for emergency > > >services should be part of the problem statement, and be dealt with > > >in the proposed solution draft. ITU-T has quite extensive work on > > >the requirements for Emergency services. > > > > > >On a side note, one of the problems identified during a recent > > >school shooting in Canada was that the emergency and police couldn't > > >use the phone or cell phones to communicate because the network was > > >jammed due to high volume of calls between students and their >families. > > > > > >Yours, > > >Shahram > > > > > > > > > > -----Original Message----- > > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > > Sent: Tuesday, September 19, 2006 5:26 PM > > > > To: ken carlberg > > > > Cc: pcn@ietf.org > > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed > >Issue. > > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > > > > > > > Ken: > > > > Thank you for handling so many of our replies at the same time. :) > > > > > > > > YES, on your point of: > > > > > > > > >just to recap. I just wanted to point out that there are > > > > >jurisdictions that do not allow preemption for voice >communications > > > > >used by the general public -- this definitely applies for a >number > >of > > > > >PSTNs, and I'm sure it will trickle down to certain deployments >of > > > > >VoIP. Hence, I would recommend that the group consider other >(re) > > > > >actions other than preemption....which from the feedback of my > > > > >original note, seems will be done. > > > > > > > > We are using the Problem-Statement draft to put out an > > > > initial version of what > > > > we are thinking, as this is still work in progress, there >definitely > > > > are area we > > > > may have missed. > > > > > > > > Thank you for pointing out at least one of them. > > > > > > > > I will write some additional text for -01 version of the Problem > > > > Statement draft to try > > > > and describe the problem you have indicated (but I will try NOT to > > > > indicate any solution > > > > in the Problem Statement draft). > > > > > > > > And we will try to have some text in at least some of our >Deployment > > > > Model drafts > > > > to see if there are good solutions to the problem you > > > > indicated. There may be > > > > more than one solution as there may be more than one Deployment > >Model. > > > > > > > > Please Notice I have changed the subject of the E-Mail thread for > > > > issue tracking purpose. > > > > Please use this E-Mail Subject for continuing this discussion. > > > > > > > > Now I have additional questions concerning the use of Preemption >for > > > > handling Emergency > > > > Services. Will Preemption be allowed for Emergency Services? > > > > Does some of the > > > > jurisdiction you have indicated want to use a separate network for > > > > Emergency Services > > > > purpose? Will combining Emergency Services with the normal > > > > VoIP calls/sessions > > > > be a good Problem Statement that we can add to our Problem > > > > Statement draft? > > > > > > > > I am concentrating on Problem Statement instead of Solutions > > > > for now because we > > > > want to get the Problem Statement cleared away first for the > > > > BOF purpose. > > > > > > > > Thanks! > > > > -- Kwok -- > > > > > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > > > >Anna, > > > > > > > > > >>>maybe we have a different perspective of preemption. as I view > >it, > > > > >>>preemption is removing *existing* state (circuit in the PSTN > > > > >>>world) in > > > > >>>favor of new state. > > > > >> > > > > >>I guess that may be one thing that needs clarification. The way >I > > > > >>view > > > > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt > >and > > > > >>related docs view the issue) is that pre-emption should kick in > > > > >>when for > > > > >>whatever reason provisioning mechanisms fail there simply is not > > > > >>enough > > > > >>capacity to carry all calls. Setting aside the issue of > >precedence > > > > >>for > > > > >>the moment, the expectation is that the level of traffic needed >to > > > > >>trigger premption is typicaly higher (perhaps substanially >higher) > > > > >>than > > > > >>the level triggering to stop admission of new flows. That > > > > means that > > > > >>when preemption does get triggered, there would actually > > > > not really be > > > > >>any new state admitted. > > > > > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind >of > > > > >understood some of the things you were saying, but there were too > > > > >many things you left out (why does one have an admission control >at > > > > >level X and a preemption level at X+N?, are you implying that the > > > > >edge is keeping track of the flows it rejects?....that would seem > > > > >quite granular in keeping measurements). > > > > > > > > > >I'm not sure its necessary to clarify the above. Its probably >just > > > > >best that we agree that future work should include a more >detailed > > > > >discussion of what is preemption in the context of your > >architecture. > > > > > > > > > >>The degree of how far apart preemption and > > > > >>admission thresholds are is of course a mater of > > > > configuration, but I > > > > >>would expect that they would be sufficiently apart to ensure >that > > > > >>you do > > > > >>not just toggle preempted and new flows. Of course if there > > > > are higher > > > > >>precedence calls, then one might expect that a higher > > > > precedence call > > > > >>may be established while lower precedence calls may need to be > > > > >>preempted? > > > > >> > > > > >>Perhaps this expectation should be made more transparent in the > > > > >>drafts? > > > > >> > > > > >>>In the US and some other countries, this is not > > > > >>>allowed in the PSTN. > > > > >> > > > > >>Just wanted to make sure I understand exactly what is not >allowed. > > > > >>Are > > > > >>you saying that PSTN is not allowed to preempt a lower > > > > precedence call > > > > >>in order to establish a high recedence call? Or are you > > > > referring to > > > > >>the same precedence levels? > > > > > > > > > >as an example, in the US PSTN, all calls from the general public > >are > > > > >treated with the same level of precedence. the exception are > >systems > > > > >like GETS, but they simply increase the probability of call > > > > >completion -- they do not use preemption. private systems based >on > > > > >MLPP, like Autovon in the DoD and NATO, do allow different levels > >of > > > > >priority and subsequent preemption if so needed. rfc-4190 and > > > > >rfc-4542 provide background on these systems/services along with > > > > >discussion in the context of IP (since this is the IETF :-) > > > > > > > > > >just to recap. I just wanted to point out that there are > > > > >jurisdictions that do not allow preemption for voice >communications > > > > >used by the general public -- this definitely applies for a >number > >of > > > > >PSTNs, and I'm sure it will trickle down to certain deployments >of > > > > >VoIP. Hence, I would recommend that the group consider other >(re) > > > > >actions other than preemption....which from the feedback of my > > > > >original note, seems will be done. > > > > > > > > > >regards, > > > > > > > > > >-ken > > > > > > > > > > > > > > >_______________________________________________ > > > > >PCN mailing list > > > > >PCN@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > > > > _______________________________________________ > > > > PCN mailing list > > > > PCN@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Sep 25 13:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRuD3-0000xL-Hn; Mon, 25 Sep 2006 13:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRuD1-0000x1-Lu; Mon, 25 Sep 2006 13:25:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsZm-0000jP-FO; Mon, 25 Sep 2006 11:40:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GRsOL-0002m9-5i; Mon, 25 Sep 2006 11:29:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Sep 2006 11:29:09 -0400 X-IronPort-AV: i="4.09,215,1157342400"; d="scan'208"; a="104341812:sNHT43594816" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PFT8tw003258; Mon, 25 Sep 2006 11:29:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8PFT8uI021235; Mon, 25 Sep 2006 11:29:08 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 11:29:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 11:29:07 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Pre-Congestion Notification BOF Thread-Index: AcbglcODqZIMzf1JTsaWo0uCM3+A9gAIVS8A From: "Anna Charny \(acharny\)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 25 Sep 2006 15:29:08.0570 (UTC) FILETIME=[57F133A0:01C6E0B7] DKIM-Signature: a=rsa-sha1; q=dns; l=4476; t=1159198148; x=1160062148; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20Request=20for=20Pre-Congestion=20Notification=20BOF |To:=22Magnus=20Westerlund=22=20, =20; X=v=3Dcisco.com=3B=20h=3D/JB/Xwz9ZvZiIilgjei6TSlEmNc=3D; b=IisKJvdsNKh69G3phto0nQvqMW0wUpTNt5+ROTO0l91MUU24b5O9PDtd08+XhtHkpjugzkAx b1xdN9SoVhrrgisE/P48pbY5/Nwj8hAHA2oFxV8nvDIjPFbMwuobk9K9; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.0 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Lars Eggert , pcn@ietf.org Subject: [PCN] RE: Request for Pre-Congestion Notification BOF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Thanks Magnus, great news. =20 When should we expect to know the chair appoinment? Thanks, Anna =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, September 25, 2006 7:27 AM To: agenda@ietf.org Cc: Anna Charny (acharny); Lars Eggert; pcn@ietf.org Subject: Re: Request for Pre-Congestion Notification BOF Hi, This BOF is approved. Chairs for the BOF is TBD. Best Regards Magnus Westerlund TSV AD Anna Charny (acharny) skrev: > Hello Lars and Magnus, > =20 > This message constitutes a formal request for Pre-Congestion Notification BOF at the November IETF meeting in San Diego. =20 > =20 > The BOF description and its proposed agenda are attached at the end of this message. > =20 > If this BOF is approved, we would like to request a two-hour slot that avoids scheduling conflicts with the following working groups: tsv, nsis, sip, ieprep, ecrit, pwe3, dccp. > =20 > We also ask that you CC agenda@ietf.org with your decision. > =20 > Of course we welcome any feedback you might have. > =20 > Best Regards, > Anna Charny > =20 > PCN BOF Description > =20 > The Pre-Congestion Notification (PCN) BOF will address the problem of how to provide scalable and 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. > =20 > The overall approach will be based on a the concept of a PCN-Region, within which the functionality is separated between the PCN-Interior Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF will be the case of a single DiffServ region, which maps to a PCN-Region. PINs 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". PENs monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the PENs or by a centralized system (which is informed of the PCN information).=20 >=20 > The BOF will address the need and the motivation for PCN work in the context of IETF, provide a brief overview of prior PCN efforts and related work, and review open issues. The BOF will also discuss the scope of work and solicit feedback on the proposed charter. Ultimately, the goal of the BOF is to solicit community feedback on whether the problem is clear and needs to be addressed, and consequently whether the creation of a new PCN WG within the scope of the proposed charter is warranted. > =20 > The draft charter is available from http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt . The problem statement and motivation for the PCN work is discussed in more detail in draft-chan-pcn-problem-statement-00, which has been submitted to IETF and is also available at http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt . > =20 > Proposed BOF agenda > =20 > 1. Agenda bashing (5 min) > 2. Motivation and Problem Statement presentation (15 min) 3. =20 > Discussion of motivation and problem statement (30 min) 4. Overview=20 > of prior PCN efforts, related work and open issues (15 min) 5. =20 > Overview of the proposed charter (10 min) 6. Discussion/bashing of=20 > the proposed charter (20 min) 7. General discussion and poll on the=20 > WG creation (25 min) >=20 >=20 --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 26 03:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7N8-0003Xx-T1; Tue, 26 Sep 2006 03:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7N6-0003Xo-RA for pcn@ietf.org; Tue, 26 Sep 2006 03:28:52 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS7N5-0005F7-Tl for pcn@ietf.org; Tue, 26 Sep 2006 03:28:52 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 26 Sep 2006 09:28:48 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 09:28:47 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 26 Sep 2006 09:28:46 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF880@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <6.2.5.6.0.20060925104843.05c26160@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbgt4cT4A4LvvsWRB2zYG1jOrwBvwAgKv2g From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 26 Sep 2006 07:28:47.0785 (UTC) FILETIME=[67D42990:01C6E13D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Kwok, Stuart, my take may be a slightly different one. PCN allows to mark packets once a settable load level has been reached on a particular link and prior to any of these packets being discarded due to the traffic rate crossing a second settable rate.=20 The former of both rates is the admissible link rate or configured-admission-rate. The latter is the supportable link rate or configured-preemption-rate. My understanding is that PCN doesn't specify "service" to more detail then demanding CL like performance for admitted traffic. To reach this aim, the preemption-rate must be chosen sufficiently bigger than the admission-rate. How the rates are set exactly is left to operators and depends on the network planning philosophy applied by each of them and the characteristics of the traffic being forwarded by PCN. A second condition is that PCN traffic should consist of a large number of multiplexed flows whose individual peak rate is small as compared to the admission-rate. What PCN should do is provide simulation results and measurements prooving that the mechanism works under todays "common" load and network conditions. Giving guidance on operational settings for a variety of networks and traffic mixes to me is a research topic, which is out of scope of the PCN WG. A BCP may be published, once sufficient "P" is available.=20 Regards, Rudiger |-----Original Message----- |From: Kwok-Ho Chan [mailto:khchan@nortel.com] |Sent: Monday, September 25, 2006 5:30 PM |To: GOLDMAN, STUART O (STUART) |Cc: pcn@ietf.org; Shahram Davari; ken carlberg |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |AllowedIssue. Used to be Re: [PCN] |draft-chan-pcn-problem-statement-00.txt | | |Stuart: |No problem. |By "Pre-Congestion", we mean: |"if additional IP packet traffic is admitted (into the traffic class=20 |handling this traffic), |then already admitted traffic (of the same traffic class) will=20 |experience degraded QoS. |This degraded QoS happens at specific nodes (or diffserv hops) of the=20 |end-to-end path |because we are working with IP packet network. This degraded QoS may=20 |affect the |end-to-end service required of the network by the Using Application." | |Of course there are many factors that defines what is (and what is=20 |not) acceptable |"degraded QoS" and how much additional traffic will cause the=20 |degraded QoS to |be not acceptable, for example: |- the Using Application and the requirements it have on the network. |--- hence we are looking at inelastic, interactive, Real-Time use of=20 |the network (first). |- the ratio of the total shared (by the traffic class) network=20 |resource at specific network | nodes with respect to each admitted traffic flow and each=20 |to-be-admitted traffic flow. | This indicates how each additional traffic flow over some limit=20 |will impact already | admitted traffic flows. In both space and time dimensions. |--- hence we are looking into amount of network resource, e.g. size=20 |of network pipes. | We first look at the easier one (we think), large network=20 |pipes. Then the harder ones | of smaller and smaller network pipes. |- the characteristic of the traffic flows, for example are they=20 |constant bit rate? Or close | to constant bit rate?, etc. |- the promised service to the Using Application. | On this Issue B.9, we are talking about promised service of=20 |NO PREEMPTION | (but may be with some condition). | |As you indicated, the network resource we are discussing allows=20 |provisioning of |detection before congestion, before the packet forwarding queues gets=20 |backed up. |And we want to have some capacity still available (this may be view=20 |as one of the |ways on HOW we can do this). But you are right that we may=20 |need to conserve |this head-room capacity, but again depending on for what reasons. |Is it because we can not preempt any admitted flows? |Is it because we need to handle emergency services? |Is it because we need to handle none-constant bit rate traffic? |Some other reasons or combinations of them? | |These are still topics of discussions and additional work we hope we=20 |can do together |in this WG (hopeful result of the PCN BOF). | |Sorry for such a long reply, just want to indicate some of the=20 |thinkings I have and |working toward/down the path of agreements. |Thanks! |-- Kwok -- | | |At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: |>Kwok, |> |>Sorry to have taken so long to respond, but my day job got in the way. |> |>As I understood the topic, we are addressing pre-congestion. In that |>light, I assumed that congestion has not yet occurred, but that we are |>approaching congestion. So, I further assumed that there was=20 |still some |>capacity available, although this remaining capacity needs to be |>conserved as best as possible. |> |>Am I am the right wavelength? |> |>Stuart Goldman |>Lucent Technologies |>sgoldman@lucent.com |>602 493 8438 |> |>-----Original Message----- |>From: Kwok-Ho Chan [mailto:khchan@nortel.com] |>Sent: Wednesday, September 20, 2006 10:58 AM |>To: GOLDMAN, STUART O (STUART) |>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg |>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |>AllowedIssue. Used to be Re: [PCN] |>draft-chan-pcn-problem-statement-00.txt |> |>Stuart: |>Preemption is just one of possibly multiple decisions the End Node |>function |>can take. |>Hence you are right that there may be other decisions that is of value |>to the |>system as a whole, possibly depending on the deployment evironment. |> |>These discussions we have so far indicates that we may not=20 |want to call |>the network information the Interior Nodes are providing as=20 |"Preemption |>Mark" |>indication. |> |>Hence these discussions are very helpful for our BOF/WG. |> |>Thanks! |>-- Kwok -- |> |> |>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: |> >Kwok-Ho, |> >While you seem to have only mentioned preemption, there=20 |should be ways |> >to recognize a call deserving higher than normal preference=20 |and giving |> >it that preference to the remaining network resources=20 |without having to |> >preempt a call in progress. Yes? |> > |> >Stuart Goldman |> >Lucent Technologies |> >sgoldman@lucent.com |> >602 493 8438 |> > |> > |> >-----Original Message----- |> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] |> >Sent: Wednesday, September 20, 2006 8:54 AM |> >To: Shahram Davari |> >Cc: pcn@ietf.org; ken carlberg |> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |> >AllowedIssue. Used to be Re: [PCN] |> >draft-chan-pcn-problem-statement-00.txt |> > |> >Shahram: |> >I totally agree. |> >The cell phone network was also jammed during 9/11. |> >I was trying to reach my brother who were stuck in the subway |> >~2 stops from WTC. |> >So I know exactly how this feels like. But I prefer to let the |> >Police and Firemen to |> >use this resource to help the general public at large. |> > |> >The question becomes: |> >- Does the Emergency Services want to use the same physical network |> >as the general public? |> >-- If Yes. Then should the problem statement becomes: |> > "Some controlled preemption functionality is allowed for |> >Emergency purposes in the general |> > public integrated (voice, video, data, etc) network. This |> >controlled preemption functionality |> > needs to be supported by the network mechanisms." |> >-- If Yes. Then we will need some guidance and help wrt the |> >regulations of the different jurisdictions. |> > Also if the different jurisdictions even wants to use the same |> >network infrastructure for both |> > emergency and public usage purposes. If it is technically |>possible. |> > |> >By this I am not saying a good solution exist or that I am promoting |> >a specific solution. |> >I am just agreeing that this problem needs to be addressed. |> >We may end up saying we can not solve this problem as of yet. But I |> >wish we can solve it. |> > |> >Regards. |> >-- Kwok -- |> > |> > |> >At 09:34 AM 9/20/2006, Shahram Davari wrote: |> > >Kwok, |> > > |> > >Indeed you raised a good subject. The requirements for emergency |> > >services should be part of the problem statement, and be=20 |dealt with |> > >in the proposed solution draft. ITU-T has quite extensive work on |> > >the requirements for Emergency services. |> > > |> > >On a side note, one of the problems identified during a recent |> > >school shooting in Canada was that the emergency and=20 |police couldn't |> > >use the phone or cell phones to communicate because the=20 |network was |> > >jammed due to high volume of calls between students and their |>families. |> > > |> > >Yours, |> > >Shahram |> > > |> > > |> > > > -----Original Message----- |> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] |> > > > Sent: Tuesday, September 19, 2006 5:26 PM |> > > > To: ken carlberg |> > > > Cc: pcn@ietf.org |> > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed |> >Issue. |> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt |> > > > |> > > > |> > > > Ken: |> > > > Thank you for handling so many of our replies at the=20 |same time. :) |> > > > |> > > > YES, on your point of: |> > > > |> > > > >just to recap. I just wanted to point out that there are |> > > > >jurisdictions that do not allow preemption for voice |>communications |> > > > >used by the general public -- this definitely applies for a |>number |> >of |> > > > >PSTNs, and I'm sure it will trickle down to certain=20 |deployments |>of |> > > > >VoIP. Hence, I would recommend that the group consider other |>(re) |> > > > >actions other than preemption....which from the feedback of my |> > > > >original note, seems will be done. |> > > > |> > > > We are using the Problem-Statement draft to put out an |> > > > initial version of what |> > > > we are thinking, as this is still work in progress, there |>definitely |> > > > are area we |> > > > may have missed. |> > > > |> > > > Thank you for pointing out at least one of them. |> > > > |> > > > I will write some additional text for -01 version of=20 |the Problem |> > > > Statement draft to try |> > > > and describe the problem you have indicated (but I=20 |will try NOT to |> > > > indicate any solution |> > > > in the Problem Statement draft). |> > > > |> > > > And we will try to have some text in at least some of our |>Deployment |> > > > Model drafts |> > > > to see if there are good solutions to the problem you |> > > > indicated. There may be |> > > > more than one solution as there may be more than one Deployment |> >Model. |> > > > |> > > > Please Notice I have changed the subject of the E-Mail=20 |thread for |> > > > issue tracking purpose. |> > > > Please use this E-Mail Subject for continuing this discussion. |> > > > |> > > > Now I have additional questions concerning the use of=20 |Preemption |>for |> > > > handling Emergency |> > > > Services. Will Preemption be allowed for Emergency Services? |> > > > Does some of the |> > > > jurisdiction you have indicated want to use a separate=20 |network for |> > > > Emergency Services |> > > > purpose? Will combining Emergency Services with the normal |> > > > VoIP calls/sessions |> > > > be a good Problem Statement that we can add to our Problem |> > > > Statement draft? |> > > > |> > > > I am concentrating on Problem Statement instead of Solutions |> > > > for now because we |> > > > want to get the Problem Statement cleared away first for the |> > > > BOF purpose. |> > > > |> > > > Thanks! |> > > > -- Kwok -- |> > > > |> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: |> > > > >Anna, |> > > > > |> > > > >>>maybe we have a different perspective of=20 |preemption. as I view |> >it, |> > > > >>>preemption is removing *existing* state (circuit in the PSTN |> > > > >>>world) in |> > > > >>>favor of new state. |> > > > >> |> > > > >>I guess that may be one thing that needs=20 |clarification. The way |>I |> > > > >>view |> > > > >>it (and I think the way=20 |draft-chan-pcn-problem-statement-00.txt |> >and |> > > > >>related docs view the issue) is that pre-emption=20 |should kick in |> > > > >>when for |> > > > >>whatever reason provisioning mechanisms fail there=20 |simply is not |> > > > >>enough |> > > > >>capacity to carry all calls. Setting aside the issue of |> >precedence |> > > > >>for |> > > > >>the moment, the expectation is that the level of=20 |traffic needed |>to |> > > > >>trigger premption is typicaly higher (perhaps substanially |>higher) |> > > > >>than |> > > > >>the level triggering to stop admission of new flows. That |> > > > means that |> > > > >>when preemption does get triggered, there would actually |> > > > not really be |> > > > >>any new state admitted. |> > > > > |> > > > >I'm sorry, but with that last sentence you lost me=20 |:-)...I kind |>of |> > > > >understood some of the things you were saying, but=20 |there were too |> > > > >many things you left out (why does one have an=20 |admission control |>at |> > > > >level X and a preemption level at X+N?, are you=20 |implying that the |> > > > >edge is keeping track of the flows it=20 |rejects?....that would seem |> > > > >quite granular in keeping measurements). |> > > > > |> > > > >I'm not sure its necessary to clarify the above. Its probably |>just |> > > > >best that we agree that future work should include a more |>detailed |> > > > >discussion of what is preemption in the context of your |> >architecture. |> > > > > |> > > > >>The degree of how far apart preemption and |> > > > >>admission thresholds are is of course a mater of |> > > > configuration, but I |> > > > >>would expect that they would be sufficiently apart to ensure |>that |> > > > >>you do |> > > > >>not just toggle preempted and new flows. Of course if there |> > > > are higher |> > > > >>precedence calls, then one might expect that a higher |> > > > precedence call |> > > > >>may be established while lower precedence calls may=20 |need to be |> > > > >>preempted? |> > > > >> |> > > > >>Perhaps this expectation should be made more=20 |transparent in the |> > > > >>drafts? |> > > > >> |> > > > >>>In the US and some other countries, this is not |> > > > >>>allowed in the PSTN. |> > > > >> |> > > > >>Just wanted to make sure I understand exactly what is not |>allowed. |> > > > >>Are |> > > > >>you saying that PSTN is not allowed to preempt a lower |> > > > precedence call |> > > > >>in order to establish a high recedence call? Or are you |> > > > referring to |> > > > >>the same precedence levels? |> > > > > |> > > > >as an example, in the US PSTN, all calls from the=20 |general public |> >are |> > > > >treated with the same level of precedence. the exception are |> >systems |> > > > >like GETS, but they simply increase the probability of call |> > > > >completion -- they do not use preemption. private=20 |systems based |>on |> > > > >MLPP, like Autovon in the DoD and NATO, do allow=20 |different levels |> >of |> > > > >priority and subsequent preemption if so needed. rfc-4190 and |> > > > >rfc-4542 provide background on these systems/services=20 |along with |> > > > >discussion in the context of IP (since this is the IETF :-) |> > > > > |> > > > >just to recap. I just wanted to point out that there are |> > > > >jurisdictions that do not allow preemption for voice |>communications |> > > > >used by the general public -- this definitely applies for a |>number |> >of |> > > > >PSTNs, and I'm sure it will trickle down to certain=20 |deployments |>of |> > > > >VoIP. Hence, I would recommend that the group consider other |>(re) |> > > > >actions other than preemption....which from the feedback of my |> > > > >original note, seems will be done. |> > > > > |> > > > >regards, |> > > > > |> > > > >-ken |> > > > > |> > > > > |> > > > >_______________________________________________ |> > > > >PCN mailing list |> > > > >PCN@ietf.org |> > > > >https://www1.ietf.org/mailman/listinfo/pcn |> > > > |> > > > |> > > > _______________________________________________ |> > > > PCN mailing list |> > > > PCN@ietf.org |> > > > https://www1.ietf.org/mailman/listinfo/pcn |> > > > |> > |> > |> >_______________________________________________ |> >PCN mailing list |> >PCN@ietf.org |> >https://www1.ietf.org/mailman/listinfo/pcn | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 26 11:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEuL-00089r-NV; Tue, 26 Sep 2006 11:31:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEuL-00089k-50 for pcn@ietf.org; Tue, 26 Sep 2006 11:31:41 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSEuK-0001R9-B6 for pcn@ietf.org; Tue, 26 Sep 2006 11:31:41 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8QFVZN27095; Tue, 26 Sep 2006 11:31:35 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 11:31:35 -0400 Message-Id: <6.2.5.6.0.20060926101250.03e7bc40@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Sep 2006 11:31:33 -0400 To: "Geib, Ruediger" From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF880@S4DE8PSAAFQ.mitte.t -com.de> References: <6.2.5.6.0.20060925104843.05c26160@nortel.com> <6439282641581441A36F7F6F83ED2ED2CBF880@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Sep 2006 15:31:35.0269 (UTC) FILETIME=[D9CB7150:01C6E180] X-Spam-Score: 0.1 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger: I think we agree on most points, please see inline below for details. Regards. -- Kwok -- At 03:28 AM 9/26/2006, Geib, Ruediger wrote: >Kwok, Stuart, > >my take may be a slightly different one. PCN allows to mark packets once >a settable load level has been reached on a particular link and prior to >any of these packets being discarded due to the traffic rate crossing a >second settable rate. You may want to think of the level/condition at which packets start to be discarded a third/another load level, for example the policy+drop rate for EF or the tail drop of a queue or link. But this is not the same as the second set-able PCN load level we have been thinking about. >The former of both rates is the admissible link rate or >configured-admission-rate. The latter is the supportable link rate or >configured-preemption-rate. Agree. >My understanding is that PCN doesn't specify >"service" to more detail then demanding CL like performance for admitted >traffic. To reach this aim, the preemption-rate must be chosen >sufficiently bigger than the admission-rate. How the rates are set >exactly is left to operators and depends on the network planning >philosophy applied by each of them and the characteristics of the >traffic being forwarded by PCN. We are actually working on and have some results on these details. I have been refraining from diving into details of the HOWs. We were just focusing on the WHATs and WHYs for the BOF. May be we should start talking about some details on the mailing list before the BOF? >A second condition is that PCN traffic >should consist of a large number of multiplexed flows whose individual >peak rate is small as compared to the admission-rate. I agree that this is one possibility we should start with wrt simulation traffic sources. >What PCN should do >is provide simulation results and measurements prooving that the >mechanism works under todays "common" load and network conditions. Agree. But we are also targeting specific type of traffic flows, real-time flows to start. Hence, we may think of "common real-time flow" load and network conditions. >Giving guidance on operational settings for a variety of networks and >traffic mixes to me is a research topic, which is out of scope of the >PCN WG. A BCP may be published, once sufficient "P" is available. We don't have such BCP on our proposed WG work item list currently. So I think we agree. >Regards, > >Rudiger > >|-----Original Message----- >|From: Kwok-Ho Chan [mailto:khchan@nortel.com] >|Sent: Monday, September 25, 2006 5:30 PM >|To: GOLDMAN, STUART O (STUART) >|Cc: pcn@ietf.org; Shahram Davari; ken carlberg >|Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >|AllowedIssue. Used to be Re: [PCN] >|draft-chan-pcn-problem-statement-00.txt >| >| >|Stuart: >|No problem. >|By "Pre-Congestion", we mean: >|"if additional IP packet traffic is admitted (into the traffic class >|handling this traffic), >|then already admitted traffic (of the same traffic class) will >|experience degraded QoS. >|This degraded QoS happens at specific nodes (or diffserv hops) of the >|end-to-end path >|because we are working with IP packet network. This degraded QoS may >|affect the >|end-to-end service required of the network by the Using Application." >| >|Of course there are many factors that defines what is (and what is >|not) acceptable >|"degraded QoS" and how much additional traffic will cause the >|degraded QoS to >|be not acceptable, for example: >|- the Using Application and the requirements it have on the network. >|--- hence we are looking at inelastic, interactive, Real-Time use of >|the network (first). >|- the ratio of the total shared (by the traffic class) network >|resource at specific network >| nodes with respect to each admitted traffic flow and each >|to-be-admitted traffic flow. >| This indicates how each additional traffic flow over some limit >|will impact already >| admitted traffic flows. In both space and time dimensions. >|--- hence we are looking into amount of network resource, e.g. size >|of network pipes. >| We first look at the easier one (we think), large network >|pipes. Then the harder ones >| of smaller and smaller network pipes. >|- the characteristic of the traffic flows, for example are they >|constant bit rate? Or close >| to constant bit rate?, etc. >|- the promised service to the Using Application. >| On this Issue B.9, we are talking about promised service of >|NO PREEMPTION >| (but may be with some condition). >| >|As you indicated, the network resource we are discussing allows >|provisioning of >|detection before congestion, before the packet forwarding queues gets >|backed up. >|And we want to have some capacity still available (this may be view >|as one of the >|ways on HOW we can do this). But you are right that we may >|need to conserve >|this head-room capacity, but again depending on for what reasons. >|Is it because we can not preempt any admitted flows? >|Is it because we need to handle emergency services? >|Is it because we need to handle none-constant bit rate traffic? >|Some other reasons or combinations of them? >| >|These are still topics of discussions and additional work we hope we >|can do together >|in this WG (hopeful result of the PCN BOF). >| >|Sorry for such a long reply, just want to indicate some of the >|thinkings I have and >|working toward/down the path of agreements. >|Thanks! >|-- Kwok -- >| >| >|At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: >|>Kwok, >|> >|>Sorry to have taken so long to respond, but my day job got in the way. >|> >|>As I understood the topic, we are addressing pre-congestion. In that >|>light, I assumed that congestion has not yet occurred, but that we are >|>approaching congestion. So, I further assumed that there was >|still some >|>capacity available, although this remaining capacity needs to be >|>conserved as best as possible. >|> >|>Am I am the right wavelength? >|> >|>Stuart Goldman >|>Lucent Technologies >|>sgoldman@lucent.com >|>602 493 8438 >|> >|>-----Original Message----- >|>From: Kwok-Ho Chan [mailto:khchan@nortel.com] >|>Sent: Wednesday, September 20, 2006 10:58 AM >|>To: GOLDMAN, STUART O (STUART) >|>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg >|>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >|>AllowedIssue. Used to be Re: [PCN] >|>draft-chan-pcn-problem-statement-00.txt >|> >|>Stuart: >|>Preemption is just one of possibly multiple decisions the End Node >|>function >|>can take. >|>Hence you are right that there may be other decisions that is of value >|>to the >|>system as a whole, possibly depending on the deployment evironment. >|> >|>These discussions we have so far indicates that we may not >|want to call >|>the network information the Interior Nodes are providing as >|"Preemption >|>Mark" >|>indication. >|> >|>Hence these discussions are very helpful for our BOF/WG. >|> >|>Thanks! >|>-- Kwok -- >|> >|> >|>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: >|> >Kwok-Ho, >|> >While you seem to have only mentioned preemption, there >|should be ways >|> >to recognize a call deserving higher than normal preference >|and giving >|> >it that preference to the remaining network resources >|without having to >|> >preempt a call in progress. Yes? >|> > >|> >Stuart Goldman >|> >Lucent Technologies >|> >sgoldman@lucent.com >|> >602 493 8438 >|> > >|> > >|> >-----Original Message----- >|> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >|> >Sent: Wednesday, September 20, 2006 8:54 AM >|> >To: Shahram Davari >|> >Cc: pcn@ietf.org; ken carlberg >|> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >|> >AllowedIssue. Used to be Re: [PCN] >|> >draft-chan-pcn-problem-statement-00.txt >|> > >|> >Shahram: >|> >I totally agree. >|> >The cell phone network was also jammed during 9/11. >|> >I was trying to reach my brother who were stuck in the subway >|> >~2 stops from WTC. >|> >So I know exactly how this feels like. But I prefer to let the >|> >Police and Firemen to >|> >use this resource to help the general public at large. >|> > >|> >The question becomes: >|> >- Does the Emergency Services want to use the same physical network >|> >as the general public? >|> >-- If Yes. Then should the problem statement becomes: >|> > "Some controlled preemption functionality is allowed for >|> >Emergency purposes in the general >|> > public integrated (voice, video, data, etc) network. This >|> >controlled preemption functionality >|> > needs to be supported by the network mechanisms." >|> >-- If Yes. Then we will need some guidance and help wrt the >|> >regulations of the different jurisdictions. >|> > Also if the different jurisdictions even wants to use the same >|> >network infrastructure for both >|> > emergency and public usage purposes. If it is technically >|>possible. >|> > >|> >By this I am not saying a good solution exist or that I am promoting >|> >a specific solution. >|> >I am just agreeing that this problem needs to be addressed. >|> >We may end up saying we can not solve this problem as of yet. But I >|> >wish we can solve it. >|> > >|> >Regards. >|> >-- Kwok -- >|> > >|> > >|> >At 09:34 AM 9/20/2006, Shahram Davari wrote: >|> > >Kwok, >|> > > >|> > >Indeed you raised a good subject. The requirements for emergency >|> > >services should be part of the problem statement, and be >|dealt with >|> > >in the proposed solution draft. ITU-T has quite extensive work on >|> > >the requirements for Emergency services. >|> > > >|> > >On a side note, one of the problems identified during a recent >|> > >school shooting in Canada was that the emergency and >|police couldn't >|> > >use the phone or cell phones to communicate because the >|network was >|> > >jammed due to high volume of calls between students and their >|>families. >|> > > >|> > >Yours, >|> > >Shahram >|> > > >|> > > >|> > > > -----Original Message----- >|> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] >|> > > > Sent: Tuesday, September 19, 2006 5:26 PM >|> > > > To: ken carlberg >|> > > > Cc: pcn@ietf.org >|> > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed >|> >Issue. >|> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt >|> > > > >|> > > > >|> > > > Ken: >|> > > > Thank you for handling so many of our replies at the >|same time. :) >|> > > > >|> > > > YES, on your point of: >|> > > > >|> > > > >just to recap. I just wanted to point out that there are >|> > > > >jurisdictions that do not allow preemption for voice >|>communications >|> > > > >used by the general public -- this definitely applies for a >|>number >|> >of >|> > > > >PSTNs, and I'm sure it will trickle down to certain >|deployments >|>of >|> > > > >VoIP. Hence, I would recommend that the group consider other >|>(re) >|> > > > >actions other than preemption....which from the feedback of my >|> > > > >original note, seems will be done. >|> > > > >|> > > > We are using the Problem-Statement draft to put out an >|> > > > initial version of what >|> > > > we are thinking, as this is still work in progress, there >|>definitely >|> > > > are area we >|> > > > may have missed. >|> > > > >|> > > > Thank you for pointing out at least one of them. >|> > > > >|> > > > I will write some additional text for -01 version of >|the Problem >|> > > > Statement draft to try >|> > > > and describe the problem you have indicated (but I >|will try NOT to >|> > > > indicate any solution >|> > > > in the Problem Statement draft). >|> > > > >|> > > > And we will try to have some text in at least some of our >|>Deployment >|> > > > Model drafts >|> > > > to see if there are good solutions to the problem you >|> > > > indicated. There may be >|> > > > more than one solution as there may be more than one Deployment >|> >Model. >|> > > > >|> > > > Please Notice I have changed the subject of the E-Mail >|thread for >|> > > > issue tracking purpose. >|> > > > Please use this E-Mail Subject for continuing this discussion. >|> > > > >|> > > > Now I have additional questions concerning the use of >|Preemption >|>for >|> > > > handling Emergency >|> > > > Services. Will Preemption be allowed for Emergency Services? >|> > > > Does some of the >|> > > > jurisdiction you have indicated want to use a separate >|network for >|> > > > Emergency Services >|> > > > purpose? Will combining Emergency Services with the normal >|> > > > VoIP calls/sessions >|> > > > be a good Problem Statement that we can add to our Problem >|> > > > Statement draft? >|> > > > >|> > > > I am concentrating on Problem Statement instead of Solutions >|> > > > for now because we >|> > > > want to get the Problem Statement cleared away first for the >|> > > > BOF purpose. >|> > > > >|> > > > Thanks! >|> > > > -- Kwok -- >|> > > > >|> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: >|> > > > >Anna, >|> > > > > >|> > > > >>>maybe we have a different perspective of >|preemption. as I view >|> >it, >|> > > > >>>preemption is removing *existing* state (circuit in the PSTN >|> > > > >>>world) in >|> > > > >>>favor of new state. >|> > > > >> >|> > > > >>I guess that may be one thing that needs >|clarification. The way >|>I >|> > > > >>view >|> > > > >>it (and I think the way >|draft-chan-pcn-problem-statement-00.txt >|> >and >|> > > > >>related docs view the issue) is that pre-emption >|should kick in >|> > > > >>when for >|> > > > >>whatever reason provisioning mechanisms fail there >|simply is not >|> > > > >>enough >|> > > > >>capacity to carry all calls. Setting aside the issue of >|> >precedence >|> > > > >>for >|> > > > >>the moment, the expectation is that the level of >|traffic needed >|>to >|> > > > >>trigger premption is typicaly higher (perhaps substanially >|>higher) >|> > > > >>than >|> > > > >>the level triggering to stop admission of new flows. That >|> > > > means that >|> > > > >>when preemption does get triggered, there would actually >|> > > > not really be >|> > > > >>any new state admitted. >|> > > > > >|> > > > >I'm sorry, but with that last sentence you lost me >|:-)...I kind >|>of >|> > > > >understood some of the things you were saying, but >|there were too >|> > > > >many things you left out (why does one have an >|admission control >|>at >|> > > > >level X and a preemption level at X+N?, are you >|implying that the >|> > > > >edge is keeping track of the flows it >|rejects?....that would seem >|> > > > >quite granular in keeping measurements). >|> > > > > >|> > > > >I'm not sure its necessary to clarify the above. Its probably >|>just >|> > > > >best that we agree that future work should include a more >|>detailed >|> > > > >discussion of what is preemption in the context of your >|> >architecture. >|> > > > > >|> > > > >>The degree of how far apart preemption and >|> > > > >>admission thresholds are is of course a mater of >|> > > > configuration, but I >|> > > > >>would expect that they would be sufficiently apart to ensure >|>that >|> > > > >>you do >|> > > > >>not just toggle preempted and new flows. Of course if there >|> > > > are higher >|> > > > >>precedence calls, then one might expect that a higher >|> > > > precedence call >|> > > > >>may be established while lower precedence calls may >|need to be >|> > > > >>preempted? >|> > > > >> >|> > > > >>Perhaps this expectation should be made more >|transparent in the >|> > > > >>drafts? >|> > > > >> >|> > > > >>>In the US and some other countries, this is not >|> > > > >>>allowed in the PSTN. >|> > > > >> >|> > > > >>Just wanted to make sure I understand exactly what is not >|>allowed. >|> > > > >>Are >|> > > > >>you saying that PSTN is not allowed to preempt a lower >|> > > > precedence call >|> > > > >>in order to establish a high recedence call? Or are you >|> > > > referring to >|> > > > >>the same precedence levels? >|> > > > > >|> > > > >as an example, in the US PSTN, all calls from the >|general public >|> >are >|> > > > >treated with the same level of precedence. the exception are >|> >systems >|> > > > >like GETS, but they simply increase the probability of call >|> > > > >completion -- they do not use preemption. private >|systems based >|>on >|> > > > >MLPP, like Autovon in the DoD and NATO, do allow >|different levels >|> >of >|> > > > >priority and subsequent preemption if so needed. rfc-4190 and >|> > > > >rfc-4542 provide background on these systems/services >|along with >|> > > > >discussion in the context of IP (since this is the IETF :-) >|> > > > > >|> > > > >just to recap. I just wanted to point out that there are >|> > > > >jurisdictions that do not allow preemption for voice >|>communications >|> > > > >used by the general public -- this definitely applies for a >|>number >|> >of >|> > > > >PSTNs, and I'm sure it will trickle down to certain >|deployments >|>of >|> > > > >VoIP. Hence, I would recommend that the group consider other >|>(re) >|> > > > >actions other than preemption....which from the feedback of my >|> > > > >original note, seems will be done. >|> > > > > >|> > > > >regards, >|> > > > > >|> > > > >-ken >|> > > > > >|> > > > > >|> > > > >_______________________________________________ >|> > > > >PCN mailing list >|> > > > >PCN@ietf.org >|> > > > >https://www1.ietf.org/mailman/listinfo/pcn >|> > > > >|> > > > >|> > > > _______________________________________________ >|> > > > PCN mailing list >|> > > > PCN@ietf.org >|> > > > https://www1.ietf.org/mailman/listinfo/pcn >|> > > > >|> > >|> > >|> >_______________________________________________ >|> >PCN mailing list >|> >PCN@ietf.org >|> >https://www1.ietf.org/mailman/listinfo/pcn >| >| >|_______________________________________________ >|PCN mailing list >|PCN@ietf.org >|https://www1.ietf.org/mailman/listinfo/pcn >| _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Sep 26 12:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFvI-0007GV-7h; Tue, 26 Sep 2006 12:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFvG-0007GL-KT for pcn@ietf.org; Tue, 26 Sep 2006 12:36:42 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSFvD-00046T-Tl for pcn@ietf.org; Tue, 26 Sep 2006 12:36:42 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k8QGaF4g019834; Tue, 26 Sep 2006 11:36:39 -0500 (CDT) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Sep 2006 11:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Tue, 26 Sep 2006 11:36:27 -0500 Message-ID: <7D096A439A3D0D48A3D10872022CFD092003D6@ILEXC1U02.ndc.lucent.com> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF880@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt thread-index: Acbgt4cT4A4LvvsWRB2zYG1jOrwBvwAgKv2gABRV60A= From: "GOLDMAN, STUART O \(STUART\)" To: "Geib, Ruediger" , X-OriginalArrivalTime: 26 Sep 2006 16:36:28.0646 (UTC) FILETIME=[EA6DA060:01C6E189] X-Spam-Score: 0.0 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediqer, I think my mental picture is close to your view of having the two level settings. I would hope that the pre-congestion level while relatively high still leaves enough excess capacity so that the actions taken are more likely to prevent the second level from actually being crossed. Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: Tuesday, September 26, 2006 12:29 AM To: khchan@nortel.com; GOLDMAN, STUART O (STUART) Cc: pcn@ietf.org Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Kwok, Stuart, my take may be a slightly different one. PCN allows to mark packets once a settable load level has been reached on a particular link and prior to any of these packets being discarded due to the traffic rate crossing a second settable rate.=20 The former of both rates is the admissible link rate or configured-admission-rate. The latter is the supportable link rate or configured-preemption-rate. My understanding is that PCN doesn't specify "service" to more detail then demanding CL like performance for admitted traffic. To reach this aim, the preemption-rate must be chosen sufficiently bigger than the admission-rate. How the rates are set exactly is left to operators and depends on the network planning philosophy applied by each of them and the characteristics of the traffic being forwarded by PCN. A second condition is that PCN traffic should consist of a large number of multiplexed flows whose individual peak rate is small as compared to the admission-rate. What PCN should do is provide simulation results and measurements prooving that the mechanism works under todays "common" load and network conditions. Giving guidance on operational settings for a variety of networks and traffic mixes to me is a research topic, which is out of scope of the PCN WG. A BCP may be published, once sufficient "P" is available.=20 Regards, Rudiger |-----Original Message----- |From: Kwok-Ho Chan [mailto:khchan@nortel.com] |Sent: Monday, September 25, 2006 5:30 PM |To: GOLDMAN, STUART O (STUART) |Cc: pcn@ietf.org; Shahram Davari; ken carlberg |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |AllowedIssue. Used to be Re: [PCN] |draft-chan-pcn-problem-statement-00.txt | | |Stuart: |No problem. |By "Pre-Congestion", we mean: |"if additional IP packet traffic is admitted (into the traffic class=20 |handling this traffic), |then already admitted traffic (of the same traffic class) will=20 |experience degraded QoS. |This degraded QoS happens at specific nodes (or diffserv hops) of the=20 |end-to-end path |because we are working with IP packet network. This degraded QoS may=20 |affect the |end-to-end service required of the network by the Using Application." | |Of course there are many factors that defines what is (and what is=20 |not) acceptable |"degraded QoS" and how much additional traffic will cause the=20 |degraded QoS to |be not acceptable, for example: |- the Using Application and the requirements it have on the network. |--- hence we are looking at inelastic, interactive, Real-Time use of=20 |the network (first). |- the ratio of the total shared (by the traffic class) network=20 |resource at specific network | nodes with respect to each admitted traffic flow and each=20 |to-be-admitted traffic flow. | This indicates how each additional traffic flow over some limit=20 |will impact already | admitted traffic flows. In both space and time dimensions. |--- hence we are looking into amount of network resource, e.g. size=20 |of network pipes. | We first look at the easier one (we think), large network=20 |pipes. Then the harder ones | of smaller and smaller network pipes. |- the characteristic of the traffic flows, for example are they=20 |constant bit rate? Or close | to constant bit rate?, etc. |- the promised service to the Using Application. | On this Issue B.9, we are talking about promised service of=20 |NO PREEMPTION | (but may be with some condition). | |As you indicated, the network resource we are discussing allows=20 |provisioning of |detection before congestion, before the packet forwarding queues gets=20 |backed up. |And we want to have some capacity still available (this may be view=20 |as one of the |ways on HOW we can do this). But you are right that we may=20 |need to conserve |this head-room capacity, but again depending on for what reasons. |Is it because we can not preempt any admitted flows? |Is it because we need to handle emergency services? |Is it because we need to handle none-constant bit rate traffic? |Some other reasons or combinations of them? | |These are still topics of discussions and additional work we hope we=20 |can do together |in this WG (hopeful result of the PCN BOF). | |Sorry for such a long reply, just want to indicate some of the=20 |thinkings I have and |working toward/down the path of agreements. |Thanks! |-- Kwok -- | | |At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: |>Kwok, |> |>Sorry to have taken so long to respond, but my day job got in the way. |> |>As I understood the topic, we are addressing pre-congestion. In that |>light, I assumed that congestion has not yet occurred, but that we are |>approaching congestion. So, I further assumed that there was=20 |still some |>capacity available, although this remaining capacity needs to be |>conserved as best as possible. |> |>Am I am the right wavelength? |> |>Stuart Goldman |>Lucent Technologies |>sgoldman@lucent.com |>602 493 8438 |> |>-----Original Message----- |>From: Kwok-Ho Chan [mailto:khchan@nortel.com] |>Sent: Wednesday, September 20, 2006 10:58 AM |>To: GOLDMAN, STUART O (STUART) |>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg |>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |>AllowedIssue. Used to be Re: [PCN] |>draft-chan-pcn-problem-statement-00.txt |> |>Stuart: |>Preemption is just one of possibly multiple decisions the End Node |>function |>can take. |>Hence you are right that there may be other decisions that is of value |>to the |>system as a whole, possibly depending on the deployment evironment. |> |>These discussions we have so far indicates that we may not=20 |want to call |>the network information the Interior Nodes are providing as=20 |"Preemption |>Mark" |>indication. |> |>Hence these discussions are very helpful for our BOF/WG. |> |>Thanks! |>-- Kwok -- |> |> |>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: |> >Kwok-Ho, |> >While you seem to have only mentioned preemption, there=20 |should be ways |> >to recognize a call deserving higher than normal preference=20 |and giving |> >it that preference to the remaining network resources=20 |without having to |> >preempt a call in progress. Yes? |> > |> >Stuart Goldman |> >Lucent Technologies |> >sgoldman@lucent.com |> >602 493 8438 |> > |> > |> >-----Original Message----- |> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] |> >Sent: Wednesday, September 20, 2006 8:54 AM |> >To: Shahram Davari |> >Cc: pcn@ietf.org; ken carlberg |> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |> >AllowedIssue. Used to be Re: [PCN] |> >draft-chan-pcn-problem-statement-00.txt |> > |> >Shahram: |> >I totally agree. |> >The cell phone network was also jammed during 9/11. |> >I was trying to reach my brother who were stuck in the subway |> >~2 stops from WTC. |> >So I know exactly how this feels like. But I prefer to let the |> >Police and Firemen to |> >use this resource to help the general public at large. |> > |> >The question becomes: |> >- Does the Emergency Services want to use the same physical network |> >as the general public? |> >-- If Yes. Then should the problem statement becomes: |> > "Some controlled preemption functionality is allowed for |> >Emergency purposes in the general |> > public integrated (voice, video, data, etc) network. This |> >controlled preemption functionality |> > needs to be supported by the network mechanisms." |> >-- If Yes. Then we will need some guidance and help wrt the |> >regulations of the different jurisdictions. |> > Also if the different jurisdictions even wants to use the same |> >network infrastructure for both |> > emergency and public usage purposes. If it is technically |>possible. |> > |> >By this I am not saying a good solution exist or that I am promoting |> >a specific solution. |> >I am just agreeing that this problem needs to be addressed. |> >We may end up saying we can not solve this problem as of yet. But I |> >wish we can solve it. |> > |> >Regards. |> >-- Kwok -- |> > |> > |> >At 09:34 AM 9/20/2006, Shahram Davari wrote: |> > >Kwok, |> > > |> > >Indeed you raised a good subject. The requirements for emergency |> > >services should be part of the problem statement, and be=20 |dealt with |> > >in the proposed solution draft. ITU-T has quite extensive work on |> > >the requirements for Emergency services. |> > > |> > >On a side note, one of the problems identified during a recent |> > >school shooting in Canada was that the emergency and=20 |police couldn't |> > >use the phone or cell phones to communicate because the=20 |network was |> > >jammed due to high volume of calls between students and their |>families. |> > > |> > >Yours, |> > >Shahram |> > > |> > > |> > > > -----Original Message----- |> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] |> > > > Sent: Tuesday, September 19, 2006 5:26 PM |> > > > To: ken carlberg |> > > > Cc: pcn@ietf.org |> > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed |> >Issue. |> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt |> > > > |> > > > |> > > > Ken: |> > > > Thank you for handling so many of our replies at the=20 |same time. :) |> > > > |> > > > YES, on your point of: |> > > > |> > > > >just to recap. I just wanted to point out that there are |> > > > >jurisdictions that do not allow preemption for voice |>communications |> > > > >used by the general public -- this definitely applies for a |>number |> >of |> > > > >PSTNs, and I'm sure it will trickle down to certain=20 |deployments |>of |> > > > >VoIP. Hence, I would recommend that the group consider other |>(re) |> > > > >actions other than preemption....which from the feedback of my |> > > > >original note, seems will be done. |> > > > |> > > > We are using the Problem-Statement draft to put out an |> > > > initial version of what |> > > > we are thinking, as this is still work in progress, there |>definitely |> > > > are area we |> > > > may have missed. |> > > > |> > > > Thank you for pointing out at least one of them. |> > > > |> > > > I will write some additional text for -01 version of=20 |the Problem |> > > > Statement draft to try |> > > > and describe the problem you have indicated (but I=20 |will try NOT to |> > > > indicate any solution |> > > > in the Problem Statement draft). |> > > > |> > > > And we will try to have some text in at least some of our |>Deployment |> > > > Model drafts |> > > > to see if there are good solutions to the problem you |> > > > indicated. There may be |> > > > more than one solution as there may be more than one Deployment |> >Model. |> > > > |> > > > Please Notice I have changed the subject of the E-Mail=20 |thread for |> > > > issue tracking purpose. |> > > > Please use this E-Mail Subject for continuing this discussion. |> > > > |> > > > Now I have additional questions concerning the use of=20 |Preemption |>for |> > > > handling Emergency |> > > > Services. Will Preemption be allowed for Emergency Services? |> > > > Does some of the |> > > > jurisdiction you have indicated want to use a separate=20 |network for |> > > > Emergency Services |> > > > purpose? Will combining Emergency Services with the normal |> > > > VoIP calls/sessions |> > > > be a good Problem Statement that we can add to our Problem |> > > > Statement draft? |> > > > |> > > > I am concentrating on Problem Statement instead of Solutions |> > > > for now because we |> > > > want to get the Problem Statement cleared away first for the |> > > > BOF purpose. |> > > > |> > > > Thanks! |> > > > -- Kwok -- |> > > > |> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: |> > > > >Anna, |> > > > > |> > > > >>>maybe we have a different perspective of=20 |preemption. as I view |> >it, |> > > > >>>preemption is removing *existing* state (circuit in the PSTN |> > > > >>>world) in |> > > > >>>favor of new state. |> > > > >> |> > > > >>I guess that may be one thing that needs=20 |clarification. The way |>I |> > > > >>view |> > > > >>it (and I think the way=20 |draft-chan-pcn-problem-statement-00.txt |> >and |> > > > >>related docs view the issue) is that pre-emption=20 |should kick in |> > > > >>when for |> > > > >>whatever reason provisioning mechanisms fail there=20 |simply is not |> > > > >>enough |> > > > >>capacity to carry all calls. Setting aside the issue of |> >precedence |> > > > >>for |> > > > >>the moment, the expectation is that the level of=20 |traffic needed |>to |> > > > >>trigger premption is typicaly higher (perhaps substanially |>higher) |> > > > >>than |> > > > >>the level triggering to stop admission of new flows. That |> > > > means that |> > > > >>when preemption does get triggered, there would actually |> > > > not really be |> > > > >>any new state admitted. |> > > > > |> > > > >I'm sorry, but with that last sentence you lost me=20 |:-)...I kind |>of |> > > > >understood some of the things you were saying, but=20 |there were too |> > > > >many things you left out (why does one have an=20 |admission control |>at |> > > > >level X and a preemption level at X+N?, are you=20 |implying that the |> > > > >edge is keeping track of the flows it=20 |rejects?....that would seem |> > > > >quite granular in keeping measurements). |> > > > > |> > > > >I'm not sure its necessary to clarify the above. Its probably |>just |> > > > >best that we agree that future work should include a more |>detailed |> > > > >discussion of what is preemption in the context of your |> >architecture. |> > > > > |> > > > >>The degree of how far apart preemption and |> > > > >>admission thresholds are is of course a mater of |> > > > configuration, but I |> > > > >>would expect that they would be sufficiently apart to ensure |>that |> > > > >>you do |> > > > >>not just toggle preempted and new flows. Of course if there |> > > > are higher |> > > > >>precedence calls, then one might expect that a higher |> > > > precedence call |> > > > >>may be established while lower precedence calls may=20 |need to be |> > > > >>preempted? |> > > > >> |> > > > >>Perhaps this expectation should be made more=20 |transparent in the |> > > > >>drafts? |> > > > >> |> > > > >>>In the US and some other countries, this is not |> > > > >>>allowed in the PSTN. |> > > > >> |> > > > >>Just wanted to make sure I understand exactly what is not |>allowed. |> > > > >>Are |> > > > >>you saying that PSTN is not allowed to preempt a lower |> > > > precedence call |> > > > >>in order to establish a high recedence call? Or are you |> > > > referring to |> > > > >>the same precedence levels? |> > > > > |> > > > >as an example, in the US PSTN, all calls from the=20 |general public |> >are |> > > > >treated with the same level of precedence. the exception are |> >systems |> > > > >like GETS, but they simply increase the probability of call |> > > > >completion -- they do not use preemption. private=20 |systems based |>on |> > > > >MLPP, like Autovon in the DoD and NATO, do allow=20 |different levels |> >of |> > > > >priority and subsequent preemption if so needed. rfc-4190 and |> > > > >rfc-4542 provide background on these systems/services=20 |along with |> > > > >discussion in the context of IP (since this is the IETF :-) |> > > > > |> > > > >just to recap. I just wanted to point out that there are |> > > > >jurisdictions that do not allow preemption for voice |>communications |> > > > >used by the general public -- this definitely applies for a |>number |> >of |> > > > >PSTNs, and I'm sure it will trickle down to certain=20 |deployments |>of |> > > > >VoIP. Hence, I would recommend that the group consider other |>(re) |> > > > >actions other than preemption....which from the feedback of my |> > > > >original note, seems will be done. |> > > > > |> > > > >regards, |> > > > > |> > > > >-ken |> > > > > |> > > > > |> > > > >_______________________________________________ |> > > > >PCN mailing list |> > > > >PCN@ietf.org |> > > > >https://www1.ietf.org/mailman/listinfo/pcn |> > > > |> > > > |> > > > _______________________________________________ |> > > > PCN mailing list |> > > > PCN@ietf.org |> > > > https://www1.ietf.org/mailman/listinfo/pcn |> > > > |> > |> > |> >_______________________________________________ |> >PCN mailing list |> >PCN@ietf.org |> >https://www1.ietf.org/mailman/listinfo/pcn | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 27 02:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSSmI-0000qC-5P; Wed, 27 Sep 2006 02:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSSmG-0000pm-A7 for pcn@ietf.org; Wed, 27 Sep 2006 02:20:16 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSSmE-0000CQ-Ue for pcn@ietf.org; Wed, 27 Sep 2006 02:20:16 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 27 Sep 2006 08:20:09 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 08:20:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 27 Sep 2006 08:20:08 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF88B@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <7D096A439A3D0D48A3D10872022CFD092003D6@ILEXC1U02.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Thread-Index: AcbhigCyo2dSPf6KQSezbNH8aVdhPwAb6zOQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 27 Sep 2006 06:20:09.0087 (UTC) FILETIME=[FB4E78F0:01C6E1FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Stuart, if "pre-congestion level" is the configured-admission-rate,=20 then "leaving enough excess capacity" is, at least from my=20 point of view, a planning task. PCN should make sure=20 that vendors have sufficient guidance to implement the=20 knobs allowing network operators to fulfill this task.=20 As I mentioned, what a "relatively high (CL load) level"=20 on a particular PCN link is, should for his network=20 entirely be the decision of a carrier. As long as the=20 SLA's defining the CL service commercially are kept,=20 it is nobody else' matter how it is produced. Regards,=20 Rudiger |-----Original Message----- |From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@lucent.com] |Sent: Tuesday, September 26, 2006 6:36 PM |To: Geib, Rudiger; khchan@nortel.com |Cc: pcn@ietf.org |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |AllowedIssue. Used to be Re: [PCN] |draft-chan-pcn-problem-statement-00.txt | | |Ruediqer, | |I think my mental picture is close to your view of having the two level |settings. I would hope that the pre-congestion level while relatively |high still leaves enough excess capacity so that the actions taken are |more likely to prevent the second level from actually being crossed. | |Stuart Goldman |Lucent Technologies |sgoldman@lucent.com |602 493 8438 | | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: Tuesday, September 26, 2006 12:29 AM |To: khchan@nortel.com; GOLDMAN, STUART O (STUART) |Cc: pcn@ietf.org |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not |AllowedIssue. Used to be Re: [PCN] |draft-chan-pcn-problem-statement-00.txt | |Kwok, Stuart, | |my take may be a slightly different one. PCN allows to mark=20 |packets once |a settable load level has been reached on a particular link=20 |and prior to |any of these packets being discarded due to the traffic rate crossing a |second settable rate.=20 | |The former of both rates is the admissible link rate or |configured-admission-rate. The latter is the supportable link rate or |configured-preemption-rate. My understanding is that PCN=20 |doesn't specify |"service" to more detail then demanding CL like performance=20 |for admitted |traffic. To reach this aim, the preemption-rate must be chosen |sufficiently bigger than the admission-rate. How the rates are set |exactly is left to operators and depends on the network planning |philosophy applied by each of them and the characteristics of the |traffic being forwarded by PCN. A second condition is that PCN traffic |should consist of a large number of multiplexed flows whose individual |peak rate is small as compared to the admission-rate. What PCN=20 |should do |is provide simulation results and measurements prooving that the |mechanism works under todays "common" load and network conditions. |Giving guidance on operational settings for a variety of networks and |traffic mixes to me is a research topic, which is out of scope of the |PCN WG. A BCP may be published, once sufficient "P" is available.=20 | |Regards, | |Rudiger | ||-----Original Message----- ||From: Kwok-Ho Chan [mailto:khchan@nortel.com] ||Sent: Monday, September 25, 2006 5:30 PM ||To: GOLDMAN, STUART O (STUART) ||Cc: pcn@ietf.org; Shahram Davari; ken carlberg ||Subject: RE: ProblemStatement Issue B.9:Call Preemption Not ||AllowedIssue. Used to be Re: [PCN] ||draft-chan-pcn-problem-statement-00.txt || || ||Stuart: ||No problem. ||By "Pre-Congestion", we mean: ||"if additional IP packet traffic is admitted (into the traffic class=20 ||handling this traffic), ||then already admitted traffic (of the same traffic class) will=20 ||experience degraded QoS. ||This degraded QoS happens at specific nodes (or diffserv hops) of the=20 ||end-to-end path ||because we are working with IP packet network. This degraded QoS may=20 ||affect the ||end-to-end service required of the network by the Using Application." || ||Of course there are many factors that defines what is (and what is=20 ||not) acceptable ||"degraded QoS" and how much additional traffic will cause the=20 ||degraded QoS to ||be not acceptable, for example: ||- the Using Application and the requirements it have on the network. ||--- hence we are looking at inelastic, interactive, Real-Time use of=20 ||the network (first). ||- the ratio of the total shared (by the traffic class) network=20 ||resource at specific network || nodes with respect to each admitted traffic flow and each=20 ||to-be-admitted traffic flow. || This indicates how each additional traffic flow over some limit=20 ||will impact already || admitted traffic flows. In both space and time dimensions. ||--- hence we are looking into amount of network resource, e.g. size=20 ||of network pipes. || We first look at the easier one (we think), large network=20 ||pipes. Then the harder ones || of smaller and smaller network pipes. ||- the characteristic of the traffic flows, for example are they=20 ||constant bit rate? Or close || to constant bit rate?, etc. ||- the promised service to the Using Application. || On this Issue B.9, we are talking about promised service of=20 ||NO PREEMPTION || (but may be with some condition). || ||As you indicated, the network resource we are discussing allows=20 ||provisioning of ||detection before congestion, before the packet forwarding queues gets=20 ||backed up. ||And we want to have some capacity still available (this may be view=20 ||as one of the ||ways on HOW we can do this). But you are right that we may=20 ||need to conserve ||this head-room capacity, but again depending on for what reasons. ||Is it because we can not preempt any admitted flows? ||Is it because we need to handle emergency services? ||Is it because we need to handle none-constant bit rate traffic? ||Some other reasons or combinations of them? || ||These are still topics of discussions and additional work we hope we=20 ||can do together ||in this WG (hopeful result of the PCN BOF). || ||Sorry for such a long reply, just want to indicate some of the=20 ||thinkings I have and ||working toward/down the path of agreements. ||Thanks! ||-- Kwok -- || || ||At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: ||>Kwok, ||> ||>Sorry to have taken so long to respond, but my day job got=20 |in the way. ||> ||>As I understood the topic, we are addressing pre-congestion. In that ||>light, I assumed that congestion has not yet occurred, but=20 |that we are ||>approaching congestion. So, I further assumed that there was=20 ||still some ||>capacity available, although this remaining capacity needs to be ||>conserved as best as possible. ||> ||>Am I am the right wavelength? ||> ||>Stuart Goldman ||>Lucent Technologies ||>sgoldman@lucent.com ||>602 493 8438 ||> ||>-----Original Message----- ||>From: Kwok-Ho Chan [mailto:khchan@nortel.com] ||>Sent: Wednesday, September 20, 2006 10:58 AM ||>To: GOLDMAN, STUART O (STUART) ||>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg ||>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not ||>AllowedIssue. Used to be Re: [PCN] ||>draft-chan-pcn-problem-statement-00.txt ||> ||>Stuart: ||>Preemption is just one of possibly multiple decisions the End Node ||>function ||>can take. ||>Hence you are right that there may be other decisions that=20 |is of value ||>to the ||>system as a whole, possibly depending on the deployment evironment. ||> ||>These discussions we have so far indicates that we may not=20 ||want to call ||>the network information the Interior Nodes are providing as=20 ||"Preemption ||>Mark" ||>indication. ||> ||>Hence these discussions are very helpful for our BOF/WG. ||> ||>Thanks! ||>-- Kwok -- ||> ||> ||>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: ||> >Kwok-Ho, ||> >While you seem to have only mentioned preemption, there=20 ||should be ways ||> >to recognize a call deserving higher than normal preference=20 ||and giving ||> >it that preference to the remaining network resources=20 ||without having to ||> >preempt a call in progress. Yes? ||> > ||> >Stuart Goldman ||> >Lucent Technologies ||> >sgoldman@lucent.com ||> >602 493 8438 ||> > ||> > ||> >-----Original Message----- ||> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] ||> >Sent: Wednesday, September 20, 2006 8:54 AM ||> >To: Shahram Davari ||> >Cc: pcn@ietf.org; ken carlberg ||> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not ||> >AllowedIssue. Used to be Re: [PCN] ||> >draft-chan-pcn-problem-statement-00.txt ||> > ||> >Shahram: ||> >I totally agree. ||> >The cell phone network was also jammed during 9/11. ||> >I was trying to reach my brother who were stuck in the subway ||> >~2 stops from WTC. ||> >So I know exactly how this feels like. But I prefer to let the ||> >Police and Firemen to ||> >use this resource to help the general public at large. ||> > ||> >The question becomes: ||> >- Does the Emergency Services want to use the same physical network ||> >as the general public? ||> >-- If Yes. Then should the problem statement becomes: ||> > "Some controlled preemption functionality is allowed for ||> >Emergency purposes in the general ||> > public integrated (voice, video, data, etc) network. This ||> >controlled preemption functionality ||> > needs to be supported by the network mechanisms." ||> >-- If Yes. Then we will need some guidance and help wrt the ||> >regulations of the different jurisdictions. ||> > Also if the different jurisdictions even wants to use the same ||> >network infrastructure for both ||> > emergency and public usage purposes. If it is technically ||>possible. ||> > ||> >By this I am not saying a good solution exist or that I am=20 |promoting ||> >a specific solution. ||> >I am just agreeing that this problem needs to be addressed. ||> >We may end up saying we can not solve this problem as of=20 |yet. But I ||> >wish we can solve it. ||> > ||> >Regards. ||> >-- Kwok -- ||> > ||> > ||> >At 09:34 AM 9/20/2006, Shahram Davari wrote: ||> > >Kwok, ||> > > ||> > >Indeed you raised a good subject. The requirements for emergency ||> > >services should be part of the problem statement, and be=20 ||dealt with ||> > >in the proposed solution draft. ITU-T has quite extensive work on ||> > >the requirements for Emergency services. ||> > > ||> > >On a side note, one of the problems identified during a recent ||> > >school shooting in Canada was that the emergency and=20 ||police couldn't ||> > >use the phone or cell phones to communicate because the=20 ||network was ||> > >jammed due to high volume of calls between students and their ||>families. ||> > > ||> > >Yours, ||> > >Shahram ||> > > ||> > > ||> > > > -----Original Message----- ||> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] ||> > > > Sent: Tuesday, September 19, 2006 5:26 PM ||> > > > To: ken carlberg ||> > > > Cc: pcn@ietf.org ||> > > > Subject: ProblemStatement Issue B.9:Call Preemption=20 |Not Allowed ||> >Issue. ||> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt ||> > > > ||> > > > ||> > > > Ken: ||> > > > Thank you for handling so many of our replies at the=20 ||same time. :) ||> > > > ||> > > > YES, on your point of: ||> > > > ||> > > > >just to recap. I just wanted to point out that there are ||> > > > >jurisdictions that do not allow preemption for voice ||>communications ||> > > > >used by the general public -- this definitely applies for a ||>number ||> >of ||> > > > >PSTNs, and I'm sure it will trickle down to certain=20 ||deployments ||>of ||> > > > >VoIP. Hence, I would recommend that the group consider other ||>(re) ||> > > > >actions other than preemption....which from the=20 |feedback of my ||> > > > >original note, seems will be done. ||> > > > ||> > > > We are using the Problem-Statement draft to put out an ||> > > > initial version of what ||> > > > we are thinking, as this is still work in progress, there ||>definitely ||> > > > are area we ||> > > > may have missed. ||> > > > ||> > > > Thank you for pointing out at least one of them. ||> > > > ||> > > > I will write some additional text for -01 version of=20 ||the Problem ||> > > > Statement draft to try ||> > > > and describe the problem you have indicated (but I=20 ||will try NOT to ||> > > > indicate any solution ||> > > > in the Problem Statement draft). ||> > > > ||> > > > And we will try to have some text in at least some of our ||>Deployment ||> > > > Model drafts ||> > > > to see if there are good solutions to the problem you ||> > > > indicated. There may be ||> > > > more than one solution as there may be more than one=20 |Deployment ||> >Model. ||> > > > ||> > > > Please Notice I have changed the subject of the E-Mail=20 ||thread for ||> > > > issue tracking purpose. ||> > > > Please use this E-Mail Subject for continuing this discussion. ||> > > > ||> > > > Now I have additional questions concerning the use of=20 ||Preemption ||>for ||> > > > handling Emergency ||> > > > Services. Will Preemption be allowed for Emergency Services? ||> > > > Does some of the ||> > > > jurisdiction you have indicated want to use a separate=20 ||network for ||> > > > Emergency Services ||> > > > purpose? Will combining Emergency Services with the normal ||> > > > VoIP calls/sessions ||> > > > be a good Problem Statement that we can add to our Problem ||> > > > Statement draft? ||> > > > ||> > > > I am concentrating on Problem Statement instead of Solutions ||> > > > for now because we ||> > > > want to get the Problem Statement cleared away first for the ||> > > > BOF purpose. ||> > > > ||> > > > Thanks! ||> > > > -- Kwok -- ||> > > > ||> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: ||> > > > >Anna, ||> > > > > ||> > > > >>>maybe we have a different perspective of=20 ||preemption. as I view ||> >it, ||> > > > >>>preemption is removing *existing* state (circuit=20 |in the PSTN ||> > > > >>>world) in ||> > > > >>>favor of new state. ||> > > > >> ||> > > > >>I guess that may be one thing that needs=20 ||clarification. The way ||>I ||> > > > >>view ||> > > > >>it (and I think the way=20 ||draft-chan-pcn-problem-statement-00.txt ||> >and ||> > > > >>related docs view the issue) is that pre-emption=20 ||should kick in ||> > > > >>when for ||> > > > >>whatever reason provisioning mechanisms fail there=20 ||simply is not ||> > > > >>enough ||> > > > >>capacity to carry all calls. Setting aside the issue of ||> >precedence ||> > > > >>for ||> > > > >>the moment, the expectation is that the level of=20 ||traffic needed ||>to ||> > > > >>trigger premption is typicaly higher (perhaps substanially ||>higher) ||> > > > >>than ||> > > > >>the level triggering to stop admission of new flows. That ||> > > > means that ||> > > > >>when preemption does get triggered, there would actually ||> > > > not really be ||> > > > >>any new state admitted. ||> > > > > ||> > > > >I'm sorry, but with that last sentence you lost me=20 ||:-)...I kind ||>of ||> > > > >understood some of the things you were saying, but=20 ||there were too ||> > > > >many things you left out (why does one have an=20 ||admission control ||>at ||> > > > >level X and a preemption level at X+N?, are you=20 ||implying that the ||> > > > >edge is keeping track of the flows it=20 ||rejects?....that would seem ||> > > > >quite granular in keeping measurements). ||> > > > > ||> > > > >I'm not sure its necessary to clarify the above. =20 |Its probably ||>just ||> > > > >best that we agree that future work should include a more ||>detailed ||> > > > >discussion of what is preemption in the context of your ||> >architecture. ||> > > > > ||> > > > >>The degree of how far apart preemption and ||> > > > >>admission thresholds are is of course a mater of ||> > > > configuration, but I ||> > > > >>would expect that they would be sufficiently apart to ensure ||>that ||> > > > >>you do ||> > > > >>not just toggle preempted and new flows. Of course if there ||> > > > are higher ||> > > > >>precedence calls, then one might expect that a higher ||> > > > precedence call ||> > > > >>may be established while lower precedence calls may=20 ||need to be ||> > > > >>preempted? ||> > > > >> ||> > > > >>Perhaps this expectation should be made more=20 ||transparent in the ||> > > > >>drafts? ||> > > > >> ||> > > > >>>In the US and some other countries, this is not ||> > > > >>>allowed in the PSTN. ||> > > > >> ||> > > > >>Just wanted to make sure I understand exactly what is not ||>allowed. ||> > > > >>Are ||> > > > >>you saying that PSTN is not allowed to preempt a lower ||> > > > precedence call ||> > > > >>in order to establish a high recedence call? Or are you ||> > > > referring to ||> > > > >>the same precedence levels? ||> > > > > ||> > > > >as an example, in the US PSTN, all calls from the=20 ||general public ||> >are ||> > > > >treated with the same level of precedence. the exception are ||> >systems ||> > > > >like GETS, but they simply increase the probability of call ||> > > > >completion -- they do not use preemption. private=20 ||systems based ||>on ||> > > > >MLPP, like Autovon in the DoD and NATO, do allow=20 ||different levels ||> >of ||> > > > >priority and subsequent preemption if so needed. =20 |rfc-4190 and ||> > > > >rfc-4542 provide background on these systems/services=20 ||along with ||> > > > >discussion in the context of IP (since this is the IETF :-) ||> > > > > ||> > > > >just to recap. I just wanted to point out that there are ||> > > > >jurisdictions that do not allow preemption for voice ||>communications ||> > > > >used by the general public -- this definitely applies for a ||>number ||> >of ||> > > > >PSTNs, and I'm sure it will trickle down to certain=20 ||deployments ||>of ||> > > > >VoIP. Hence, I would recommend that the group consider other ||>(re) ||> > > > >actions other than preemption....which from the=20 |feedback of my ||> > > > >original note, seems will be done. ||> > > > > ||> > > > >regards, ||> > > > > ||> > > > >-ken ||> > > > > ||> > > > > ||> > > > >_______________________________________________ ||> > > > >PCN mailing list ||> > > > >PCN@ietf.org ||> > > > >https://www1.ietf.org/mailman/listinfo/pcn ||> > > > ||> > > > ||> > > > _______________________________________________ ||> > > > PCN mailing list ||> > > > PCN@ietf.org ||> > > > https://www1.ietf.org/mailman/listinfo/pcn ||> > > > ||> > ||> > ||> >_______________________________________________ ||> >PCN mailing list ||> >PCN@ietf.org ||> >https://www1.ietf.org/mailman/listinfo/pcn || || ||_______________________________________________ ||PCN mailing list ||PCN@ietf.org ||https://www1.ietf.org/mailman/listinfo/pcn || | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 27 02:35:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GST10-0000Nv-FI; Wed, 27 Sep 2006 02:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GST0z-0000Np-EM for pcn@ietf.org; Wed, 27 Sep 2006 02:35:29 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GST0x-0002F7-8W for pcn@ietf.org; Wed, 27 Sep 2006 02:35:29 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3B53C17F5; Wed, 27 Sep 2006 08:35:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2CB5917AD; Wed, 27 Sep 2006 08:35:24 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B454215C4; Wed, 27 Sep 2006 08:35:23 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8R6ZNs17514; Wed, 27 Sep 2006 08:35:23 +0200 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 8AA1B6F58E; Wed, 27 Sep 2006 08:34:08 +0200 (CEST) Message-ID: <451A1BC6.4080200@informatik.uni-wuerzburg.de> Date: Wed, 27 Sep 2006 08:35:50 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt References: <6439282641581441A36F7F6F83ED2ED2CBF88B@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF88B@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, Stuart, I think that the question is the following: How large should the admissible and supportable link rates be that QoS can be maintained in spite of (1) bursty traffic (2) admission errors due to the measurement-based nature of the AC (flash crowds) (3) redirected traffic due to likely network outages like single link failures The answer depends on the traffic model and the link capacity. I think this defines plenty of work for academic parametric studies to give guidelines for operators. This is a feasible thing to do. We addressed issue (3) in previous work for a different NAC approach. If the network is configured to copy with (1)-(3), QoS is quite well protected. And if all the assumptions for (1)-(3) fail that were made for the configuration, then preemption kicks in, but only then. Best wishes, Michael Geib, Ruediger wrote: > Stuart, > > if "pre-congestion level" is the configured-admission-rate, > then "leaving enough excess capacity" is, at least from my > point of view, a planning task. PCN should make sure > that vendors have sufficient guidance to implement the > knobs allowing network operators to fulfill this task. > > As I mentioned, what a "relatively high (CL load) level" > on a particular PCN link is, should for his network > entirely be the decision of a carrier. As long as the > SLA's defining the CL service commercially are kept, > it is nobody else' matter how it is produced. > > Regards, > > Rudiger > > |-----Original Message----- > |From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@lucent.com] > |Sent: Tuesday, September 26, 2006 6:36 PM > |To: Geib, Rudiger; khchan@nortel.com > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > |AllowedIssue. Used to be Re: [PCN] > |draft-chan-pcn-problem-statement-00.txt > | > | > |Ruediqer, > | > |I think my mental picture is close to your view of having the two level > |settings. I would hope that the pre-congestion level while relatively > |high still leaves enough excess capacity so that the actions taken are > |more likely to prevent the second level from actually being crossed. > | > |Stuart Goldman > |Lucent Technologies > |sgoldman@lucent.com > |602 493 8438 > | > | > |-----Original Message----- > |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |Sent: Tuesday, September 26, 2006 12:29 AM > |To: khchan@nortel.com; GOLDMAN, STUART O (STUART) > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > |AllowedIssue. Used to be Re: [PCN] > |draft-chan-pcn-problem-statement-00.txt > | > |Kwok, Stuart, > | > |my take may be a slightly different one. PCN allows to mark > |packets once > |a settable load level has been reached on a particular link > |and prior to > |any of these packets being discarded due to the traffic rate crossing a > |second settable rate. > | > |The former of both rates is the admissible link rate or > |configured-admission-rate. The latter is the supportable link rate or > |configured-preemption-rate. My understanding is that PCN > |doesn't specify > |"service" to more detail then demanding CL like performance > |for admitted > |traffic. To reach this aim, the preemption-rate must be chosen > |sufficiently bigger than the admission-rate. How the rates are set > |exactly is left to operators and depends on the network planning > |philosophy applied by each of them and the characteristics of the > |traffic being forwarded by PCN. A second condition is that PCN traffic > |should consist of a large number of multiplexed flows whose individual > |peak rate is small as compared to the admission-rate. What PCN > |should do > |is provide simulation results and measurements prooving that the > |mechanism works under todays "common" load and network conditions. > |Giving guidance on operational settings for a variety of networks and > |traffic mixes to me is a research topic, which is out of scope of the > |PCN WG. A BCP may be published, once sufficient "P" is available. > | > |Regards, > | > |Rudiger > | > ||-----Original Message----- > ||From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||Sent: Monday, September 25, 2006 5:30 PM > ||To: GOLDMAN, STUART O (STUART) > ||Cc: pcn@ietf.org; Shahram Davari; ken carlberg > ||Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > ||AllowedIssue. Used to be Re: [PCN] > ||draft-chan-pcn-problem-statement-00.txt > || > || > ||Stuart: > ||No problem. > ||By "Pre-Congestion", we mean: > ||"if additional IP packet traffic is admitted (into the traffic class > ||handling this traffic), > ||then already admitted traffic (of the same traffic class) will > ||experience degraded QoS. > ||This degraded QoS happens at specific nodes (or diffserv hops) of the > ||end-to-end path > ||because we are working with IP packet network. This degraded QoS may > ||affect the > ||end-to-end service required of the network by the Using Application." > || > ||Of course there are many factors that defines what is (and what is > ||not) acceptable > ||"degraded QoS" and how much additional traffic will cause the > ||degraded QoS to > ||be not acceptable, for example: > ||- the Using Application and the requirements it have on the network. > ||--- hence we are looking at inelastic, interactive, Real-Time use of > ||the network (first). > ||- the ratio of the total shared (by the traffic class) network > ||resource at specific network > || nodes with respect to each admitted traffic flow and each > ||to-be-admitted traffic flow. > || This indicates how each additional traffic flow over some limit > ||will impact already > || admitted traffic flows. In both space and time dimensions. > ||--- hence we are looking into amount of network resource, e.g. size > ||of network pipes. > || We first look at the easier one (we think), large network > ||pipes. Then the harder ones > || of smaller and smaller network pipes. > ||- the characteristic of the traffic flows, for example are they > ||constant bit rate? Or close > || to constant bit rate?, etc. > ||- the promised service to the Using Application. > || On this Issue B.9, we are talking about promised service of > ||NO PREEMPTION > || (but may be with some condition). > || > ||As you indicated, the network resource we are discussing allows > ||provisioning of > ||detection before congestion, before the packet forwarding queues gets > ||backed up. > ||And we want to have some capacity still available (this may be view > ||as one of the > ||ways on HOW we can do this). But you are right that we may > ||need to conserve > ||this head-room capacity, but again depending on for what reasons. > ||Is it because we can not preempt any admitted flows? > ||Is it because we need to handle emergency services? > ||Is it because we need to handle none-constant bit rate traffic? > ||Some other reasons or combinations of them? > || > ||These are still topics of discussions and additional work we hope we > ||can do together > ||in this WG (hopeful result of the PCN BOF). > || > ||Sorry for such a long reply, just want to indicate some of the > ||thinkings I have and > ||working toward/down the path of agreements. > ||Thanks! > ||-- Kwok -- > || > || > ||At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||>Kwok, > ||> > ||>Sorry to have taken so long to respond, but my day job got > |in the way. > ||> > ||>As I understood the topic, we are addressing pre-congestion. In that > ||>light, I assumed that congestion has not yet occurred, but > |that we are > ||>approaching congestion. So, I further assumed that there was > ||still some > ||>capacity available, although this remaining capacity needs to be > ||>conserved as best as possible. > ||> > ||>Am I am the right wavelength? > ||> > ||>Stuart Goldman > ||>Lucent Technologies > ||>sgoldman@lucent.com > ||>602 493 8438 > ||> > ||>-----Original Message----- > ||>From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||>Sent: Wednesday, September 20, 2006 10:58 AM > ||>To: GOLDMAN, STUART O (STUART) > ||>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg > ||>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > ||>AllowedIssue. Used to be Re: [PCN] > ||>draft-chan-pcn-problem-statement-00.txt > ||> > ||>Stuart: > ||>Preemption is just one of possibly multiple decisions the End Node > ||>function > ||>can take. > ||>Hence you are right that there may be other decisions that > |is of value > ||>to the > ||>system as a whole, possibly depending on the deployment evironment. > ||> > ||>These discussions we have so far indicates that we may not > ||want to call > ||>the network information the Interior Nodes are providing as > ||"Preemption > ||>Mark" > ||>indication. > ||> > ||>Hence these discussions are very helpful for our BOF/WG. > ||> > ||>Thanks! > ||>-- Kwok -- > ||> > ||> > ||>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||> >Kwok-Ho, > ||> >While you seem to have only mentioned preemption, there > ||should be ways > ||> >to recognize a call deserving higher than normal preference > ||and giving > ||> >it that preference to the remaining network resources > ||without having to > ||> >preempt a call in progress. Yes? > ||> > > ||> >Stuart Goldman > ||> >Lucent Technologies > ||> >sgoldman@lucent.com > ||> >602 493 8438 > ||> > > ||> > > ||> >-----Original Message----- > ||> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> >Sent: Wednesday, September 20, 2006 8:54 AM > ||> >To: Shahram Davari > ||> >Cc: pcn@ietf.org; ken carlberg > ||> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > ||> >AllowedIssue. Used to be Re: [PCN] > ||> >draft-chan-pcn-problem-statement-00.txt > ||> > > ||> >Shahram: > ||> >I totally agree. > ||> >The cell phone network was also jammed during 9/11. > ||> >I was trying to reach my brother who were stuck in the subway > ||> >~2 stops from WTC. > ||> >So I know exactly how this feels like. But I prefer to let the > ||> >Police and Firemen to > ||> >use this resource to help the general public at large. > ||> > > ||> >The question becomes: > ||> >- Does the Emergency Services want to use the same physical network > ||> >as the general public? > ||> >-- If Yes. Then should the problem statement becomes: > ||> > "Some controlled preemption functionality is allowed for > ||> >Emergency purposes in the general > ||> > public integrated (voice, video, data, etc) network. This > ||> >controlled preemption functionality > ||> > needs to be supported by the network mechanisms." > ||> >-- If Yes. Then we will need some guidance and help wrt the > ||> >regulations of the different jurisdictions. > ||> > Also if the different jurisdictions even wants to use the same > ||> >network infrastructure for both > ||> > emergency and public usage purposes. If it is technically > ||>possible. > ||> > > ||> >By this I am not saying a good solution exist or that I am > |promoting > ||> >a specific solution. > ||> >I am just agreeing that this problem needs to be addressed. > ||> >We may end up saying we can not solve this problem as of > |yet. But I > ||> >wish we can solve it. > ||> > > ||> >Regards. > ||> >-- Kwok -- > ||> > > ||> > > ||> >At 09:34 AM 9/20/2006, Shahram Davari wrote: > ||> > >Kwok, > ||> > > > ||> > >Indeed you raised a good subject. The requirements for emergency > ||> > >services should be part of the problem statement, and be > ||dealt with > ||> > >in the proposed solution draft. ITU-T has quite extensive work on > ||> > >the requirements for Emergency services. > ||> > > > ||> > >On a side note, one of the problems identified during a recent > ||> > >school shooting in Canada was that the emergency and > ||police couldn't > ||> > >use the phone or cell phones to communicate because the > ||network was > ||> > >jammed due to high volume of calls between students and their > ||>families. > ||> > > > ||> > >Yours, > ||> > >Shahram > ||> > > > ||> > > > ||> > > > -----Original Message----- > ||> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> > > > Sent: Tuesday, September 19, 2006 5:26 PM > ||> > > > To: ken carlberg > ||> > > > Cc: pcn@ietf.org > ||> > > > Subject: ProblemStatement Issue B.9:Call Preemption > |Not Allowed > ||> >Issue. > ||> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > ||> > > > > ||> > > > > ||> > > > Ken: > ||> > > > Thank you for handling so many of our replies at the > ||same time. :) > ||> > > > > ||> > > > YES, on your point of: > ||> > > > > ||> > > > >just to recap. I just wanted to point out that there are > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > ||> > > > We are using the Problem-Statement draft to put out an > ||> > > > initial version of what > ||> > > > we are thinking, as this is still work in progress, there > ||>definitely > ||> > > > are area we > ||> > > > may have missed. > ||> > > > > ||> > > > Thank you for pointing out at least one of them. > ||> > > > > ||> > > > I will write some additional text for -01 version of > ||the Problem > ||> > > > Statement draft to try > ||> > > > and describe the problem you have indicated (but I > ||will try NOT to > ||> > > > indicate any solution > ||> > > > in the Problem Statement draft). > ||> > > > > ||> > > > And we will try to have some text in at least some of our > ||>Deployment > ||> > > > Model drafts > ||> > > > to see if there are good solutions to the problem you > ||> > > > indicated. There may be > ||> > > > more than one solution as there may be more than one > |Deployment > ||> >Model. > ||> > > > > ||> > > > Please Notice I have changed the subject of the E-Mail > ||thread for > ||> > > > issue tracking purpose. > ||> > > > Please use this E-Mail Subject for continuing this discussion. > ||> > > > > ||> > > > Now I have additional questions concerning the use of > ||Preemption > ||>for > ||> > > > handling Emergency > ||> > > > Services. Will Preemption be allowed for Emergency Services? > ||> > > > Does some of the > ||> > > > jurisdiction you have indicated want to use a separate > ||network for > ||> > > > Emergency Services > ||> > > > purpose? Will combining Emergency Services with the normal > ||> > > > VoIP calls/sessions > ||> > > > be a good Problem Statement that we can add to our Problem > ||> > > > Statement draft? > ||> > > > > ||> > > > I am concentrating on Problem Statement instead of Solutions > ||> > > > for now because we > ||> > > > want to get the Problem Statement cleared away first for the > ||> > > > BOF purpose. > ||> > > > > ||> > > > Thanks! > ||> > > > -- Kwok -- > ||> > > > > ||> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > ||> > > > >Anna, > ||> > > > > > ||> > > > >>>maybe we have a different perspective of > ||preemption. as I view > ||> >it, > ||> > > > >>>preemption is removing *existing* state (circuit > |in the PSTN > ||> > > > >>>world) in > ||> > > > >>>favor of new state. > ||> > > > >> > ||> > > > >>I guess that may be one thing that needs > ||clarification. The way > ||>I > ||> > > > >>view > ||> > > > >>it (and I think the way > ||draft-chan-pcn-problem-statement-00.txt > ||> >and > ||> > > > >>related docs view the issue) is that pre-emption > ||should kick in > ||> > > > >>when for > ||> > > > >>whatever reason provisioning mechanisms fail there > ||simply is not > ||> > > > >>enough > ||> > > > >>capacity to carry all calls. Setting aside the issue of > ||> >precedence > ||> > > > >>for > ||> > > > >>the moment, the expectation is that the level of > ||traffic needed > ||>to > ||> > > > >>trigger premption is typicaly higher (perhaps substanially > ||>higher) > ||> > > > >>than > ||> > > > >>the level triggering to stop admission of new flows. That > ||> > > > means that > ||> > > > >>when preemption does get triggered, there would actually > ||> > > > not really be > ||> > > > >>any new state admitted. > ||> > > > > > ||> > > > >I'm sorry, but with that last sentence you lost me > ||:-)...I kind > ||>of > ||> > > > >understood some of the things you were saying, but > ||there were too > ||> > > > >many things you left out (why does one have an > ||admission control > ||>at > ||> > > > >level X and a preemption level at X+N?, are you > ||implying that the > ||> > > > >edge is keeping track of the flows it > ||rejects?....that would seem > ||> > > > >quite granular in keeping measurements). > ||> > > > > > ||> > > > >I'm not sure its necessary to clarify the above. > |Its probably > ||>just > ||> > > > >best that we agree that future work should include a more > ||>detailed > ||> > > > >discussion of what is preemption in the context of your > ||> >architecture. > ||> > > > > > ||> > > > >>The degree of how far apart preemption and > ||> > > > >>admission thresholds are is of course a mater of > ||> > > > configuration, but I > ||> > > > >>would expect that they would be sufficiently apart to ensure > ||>that > ||> > > > >>you do > ||> > > > >>not just toggle preempted and new flows. Of course if there > ||> > > > are higher > ||> > > > >>precedence calls, then one might expect that a higher > ||> > > > precedence call > ||> > > > >>may be established while lower precedence calls may > ||need to be > ||> > > > >>preempted? > ||> > > > >> > ||> > > > >>Perhaps this expectation should be made more > ||transparent in the > ||> > > > >>drafts? > ||> > > > >> > ||> > > > >>>In the US and some other countries, this is not > ||> > > > >>>allowed in the PSTN. > ||> > > > >> > ||> > > > >>Just wanted to make sure I understand exactly what is not > ||>allowed. > ||> > > > >>Are > ||> > > > >>you saying that PSTN is not allowed to preempt a lower > ||> > > > precedence call > ||> > > > >>in order to establish a high recedence call? Or are you > ||> > > > referring to > ||> > > > >>the same precedence levels? > ||> > > > > > ||> > > > >as an example, in the US PSTN, all calls from the > ||general public > ||> >are > ||> > > > >treated with the same level of precedence. the exception are > ||> >systems > ||> > > > >like GETS, but they simply increase the probability of call > ||> > > > >completion -- they do not use preemption. private > ||systems based > ||>on > ||> > > > >MLPP, like Autovon in the DoD and NATO, do allow > ||different levels > ||> >of > ||> > > > >priority and subsequent preemption if so needed. > |rfc-4190 and > ||> > > > >rfc-4542 provide background on these systems/services > ||along with > ||> > > > >discussion in the context of IP (since this is the IETF :-) > ||> > > > > > ||> > > > >just to recap. I just wanted to point out that there are > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > > ||> > > > >regards, > ||> > > > > > ||> > > > >-ken > ||> > > > > > ||> > > > > > ||> > > > >_______________________________________________ > ||> > > > >PCN mailing list > ||> > > > >PCN@ietf.org > ||> > > > >https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > > > ||> > > > _______________________________________________ > ||> > > > PCN mailing list > ||> > > > PCN@ietf.org > ||> > > > https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > ||> > > ||> >_______________________________________________ > ||> >PCN mailing list > ||> >PCN@ietf.org > ||> >https://www1.ietf.org/mailman/listinfo/pcn > || > || > ||_______________________________________________ > ||PCN mailing list > ||PCN@ietf.org > ||https://www1.ietf.org/mailman/listinfo/pcn > || > | > |_______________________________________________ > |PCN mailing list > |PCN@ietf.org > |https://www1.ietf.org/mailman/listinfo/pcn > | > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 27 04:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUqP-0004Q2-Ct; Wed, 27 Sep 2006 04:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUqN-0004Ob-Di for pcn@ietf.org; Wed, 27 Sep 2006 04:32:39 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSUj4-0002oP-Mo for pcn@ietf.org; Wed, 27 Sep 2006 04:25:08 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k8R8OttE008879; Wed, 27 Sep 2006 10:24:58 +0200 (MEST) From: "Georgios Karagiannis" To: Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue.Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Date: Wed, 27 Sep 2006 10:24:52 +0200 Message-ID: <000301c6e20e$6afd1bf0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <451A1BC6.4080200@informatik.uni-wuerzburg.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbh/ydd0EJEyVWoQIiGJfjYiegBswADrfnQ X-Spam-Score: -5.599 () ALL_TRUSTED,BAYES_00,FVGT_s_LONGSUBJECT99 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 27 Sep 2006 10:25:04 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael I think that you are right, we need to somehow provide some quantification of the overprovisioning, which depends on: 1) the time until the calls are admtted: If the response time is long, the overprovisioning is substantial. 2) the statistics of the aggregated traffic. It will work well with traffic that have a nice average behaviour. 3) mass-call events that usually happends in telefony networks. If the number of calls suddenly increases, the PCN will not have time to block the calls. 4) response time for the measurement function. Best Regards, Georgios -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: woensdag 27 september 2006 8:36 To: Geib, Ruediger Cc: pcn@ietf.org Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue.Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Hi Ruediger, Stuart, I think that the question is the following: How large should the admissible and supportable link rates be that QoS can be maintained in spite of (1) bursty traffic (2) admission errors due to the measurement-based nature of the AC (flash crowds) (3) redirected traffic due to likely network outages like single link failures The answer depends on the traffic model and the link capacity. I think this defines plenty of work for academic parametric studies to give guidelines for operators. This is a feasible thing to do. We addressed issue (3) in previous work for a different NAC approach. If the network is configured to copy with (1)-(3), QoS is quite well protected. And if all the assumptions for (1)-(3) fail that were made for the configuration, then preemption kicks in, but only then. Best wishes, Michael Geib, Ruediger wrote: > Stuart, > > if "pre-congestion level" is the configured-admission-rate, then > "leaving enough excess capacity" is, at least from my point of view, a > planning task. PCN should make sure that vendors have sufficient > guidance to implement the knobs allowing network operators to fulfill > this task. > > As I mentioned, what a "relatively high (CL load) level" > on a particular PCN link is, should for his network entirely be the > decision of a carrier. As long as the SLA's defining the CL service > commercially are kept, it is nobody else' matter how it is produced. > > Regards, > > Rudiger > > |-----Original Message----- > |From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@lucent.com] > |Sent: Tuesday, September 26, 2006 6:36 PM > |To: Geib, Rudiger; khchan@nortel.com > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > |AllowedIssue. Used to be Re: [PCN] > |draft-chan-pcn-problem-statement-00.txt > | > | > |Ruediqer, > | > |I think my mental picture is close to your view of having the two > |level settings. I would hope that the pre-congestion level while > |relatively high still leaves enough excess capacity so that the > |actions taken are more likely to prevent the second level from actually being crossed. > | > |Stuart Goldman > |Lucent Technologies > |sgoldman@lucent.com > |602 493 8438 > | > | > |-----Original Message----- > |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |Sent: Tuesday, September 26, 2006 12:29 AM > |To: khchan@nortel.com; GOLDMAN, STUART O (STUART) > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > |AllowedIssue. Used to be Re: [PCN] > |draft-chan-pcn-problem-statement-00.txt > | > |Kwok, Stuart, > | > |my take may be a slightly different one. PCN allows to mark packets > |once a settable load level has been reached on a particular link and > |prior to any of these packets being discarded due to the traffic rate > |crossing a second settable rate. > | > |The former of both rates is the admissible link rate or > |configured-admission-rate. The latter is the supportable link rate or > |configured-preemption-rate. My understanding is that PCN doesn't > |specify "service" to more detail then demanding CL like performance > |for admitted traffic. To reach this aim, the preemption-rate must be > |chosen sufficiently bigger than the admission-rate. How the rates are > |set exactly is left to operators and depends on the network planning > |philosophy applied by each of them and the characteristics of the > |traffic being forwarded by PCN. A second condition is that PCN > |traffic should consist of a large number of multiplexed flows whose > |individual peak rate is small as compared to the admission-rate. What > |PCN should do is provide simulation results and measurements prooving > |that the mechanism works under todays "common" load and network > |conditions. > |Giving guidance on operational settings for a variety of networks and > |traffic mixes to me is a research topic, which is out of scope of the > |PCN WG. A BCP may be published, once sufficient "P" is available. > | > |Regards, > | > |Rudiger > | > ||-----Original Message----- > ||From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||Sent: Monday, September 25, 2006 5:30 PM > ||To: GOLDMAN, STUART O (STUART) > ||Cc: pcn@ietf.org; Shahram Davari; ken carlberg > ||Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > ||AllowedIssue. Used to be Re: [PCN] > ||draft-chan-pcn-problem-statement-00.txt > || > || > ||Stuart: > ||No problem. > ||By "Pre-Congestion", we mean: > ||"if additional IP packet traffic is admitted (into the traffic class > ||handling this traffic), then already admitted traffic (of the same > ||traffic class) will experience degraded QoS. > ||This degraded QoS happens at specific nodes (or diffserv hops) of > ||the end-to-end path because we are working with IP packet network. > ||This degraded QoS may affect the end-to-end service required of the > ||network by the Using Application." > || > ||Of course there are many factors that defines what is (and what is > ||not) acceptable > ||"degraded QoS" and how much additional traffic will cause the > ||degraded QoS to be not acceptable, for example: > ||- the Using Application and the requirements it have on the network. > ||--- hence we are looking at inelastic, interactive, Real-Time use of > ||the network (first). > ||- the ratio of the total shared (by the traffic class) network > ||resource at specific network > || nodes with respect to each admitted traffic flow and each > ||to-be-admitted traffic flow. > || This indicates how each additional traffic flow over some limit > ||will impact already > || admitted traffic flows. In both space and time dimensions. > ||--- hence we are looking into amount of network resource, e.g. size > ||of network pipes. > || We first look at the easier one (we think), large network > ||pipes. Then the harder ones > || of smaller and smaller network pipes. > ||- the characteristic of the traffic flows, for example are they > ||constant bit rate? Or close > || to constant bit rate?, etc. > ||- the promised service to the Using Application. > || On this Issue B.9, we are talking about promised service of NO > ||PREEMPTION > || (but may be with some condition). > || > ||As you indicated, the network resource we are discussing allows > ||provisioning of detection before congestion, before the packet > ||forwarding queues gets backed up. > ||And we want to have some capacity still available (this may be view > ||as one of the ways on HOW we can do this). But you are right that > ||we may need to conserve this head-room capacity, but again depending > ||on for what reasons. > ||Is it because we can not preempt any admitted flows? > ||Is it because we need to handle emergency services? > ||Is it because we need to handle none-constant bit rate traffic? > ||Some other reasons or combinations of them? > || > ||These are still topics of discussions and additional work we hope we > ||can do together in this WG (hopeful result of the PCN BOF). > || > ||Sorry for such a long reply, just want to indicate some of the > ||thinkings I have and working toward/down the path of agreements. > ||Thanks! > ||-- Kwok -- > || > || > ||At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||>Kwok, > ||> > ||>Sorry to have taken so long to respond, but my day job got > |in the way. > ||> > ||>As I understood the topic, we are addressing pre-congestion. In > ||>that light, I assumed that congestion has not yet occurred, but > |that we are > ||>approaching congestion. So, I further assumed that there was > ||still some > ||>capacity available, although this remaining capacity needs to be > ||>conserved as best as possible. > ||> > ||>Am I am the right wavelength? > ||> > ||>Stuart Goldman > ||>Lucent Technologies > ||>sgoldman@lucent.com > ||>602 493 8438 > ||> > ||>-----Original Message----- > ||>From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||>Sent: Wednesday, September 20, 2006 10:58 AM > ||>To: GOLDMAN, STUART O (STUART) > ||>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg > ||>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > ||>AllowedIssue. Used to be Re: [PCN] > ||>draft-chan-pcn-problem-statement-00.txt > ||> > ||>Stuart: > ||>Preemption is just one of possibly multiple decisions the End Node > ||>function can take. > ||>Hence you are right that there may be other decisions that > |is of value > ||>to the > ||>system as a whole, possibly depending on the deployment evironment. > ||> > ||>These discussions we have so far indicates that we may not > ||want to call > ||>the network information the Interior Nodes are providing as > ||"Preemption > ||>Mark" > ||>indication. > ||> > ||>Hence these discussions are very helpful for our BOF/WG. > ||> > ||>Thanks! > ||>-- Kwok -- > ||> > ||> > ||>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||> >Kwok-Ho, > ||> >While you seem to have only mentioned preemption, there > ||should be ways > ||> >to recognize a call deserving higher than normal preference > ||and giving > ||> >it that preference to the remaining network resources > ||without having to > ||> >preempt a call in progress. Yes? > ||> > > ||> >Stuart Goldman > ||> >Lucent Technologies > ||> >sgoldman@lucent.com > ||> >602 493 8438 > ||> > > ||> > > ||> >-----Original Message----- > ||> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> >Sent: Wednesday, September 20, 2006 8:54 AM > ||> >To: Shahram Davari > ||> >Cc: pcn@ietf.org; ken carlberg > ||> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not > ||> >AllowedIssue. Used to be Re: [PCN] > ||> >draft-chan-pcn-problem-statement-00.txt > ||> > > ||> >Shahram: > ||> >I totally agree. > ||> >The cell phone network was also jammed during 9/11. > ||> >I was trying to reach my brother who were stuck in the subway > ||> >~2 stops from WTC. > ||> >So I know exactly how this feels like. But I prefer to let the > ||> >Police and Firemen to use this resource to help the general > ||> >public at large. > ||> > > ||> >The question becomes: > ||> >- Does the Emergency Services want to use the same physical > ||> >network as the general public? > ||> >-- If Yes. Then should the problem statement becomes: > ||> > "Some controlled preemption functionality is allowed for > ||> >Emergency purposes in the general > ||> > public integrated (voice, video, data, etc) network. This > ||> >controlled preemption functionality > ||> > needs to be supported by the network mechanisms." > ||> >-- If Yes. Then we will need some guidance and help wrt the > ||> >regulations of the different jurisdictions. > ||> > Also if the different jurisdictions even wants to use the > ||> >same network infrastructure for both > ||> > emergency and public usage purposes. If it is technically > ||>possible. > ||> > > ||> >By this I am not saying a good solution exist or that I am > |promoting > ||> >a specific solution. > ||> >I am just agreeing that this problem needs to be addressed. > ||> >We may end up saying we can not solve this problem as of > |yet. But I > ||> >wish we can solve it. > ||> > > ||> >Regards. > ||> >-- Kwok -- > ||> > > ||> > > ||> >At 09:34 AM 9/20/2006, Shahram Davari wrote: > ||> > >Kwok, > ||> > > > ||> > >Indeed you raised a good subject. The requirements for > ||> > >emergency services should be part of the problem statement, and > ||> > >be > ||dealt with > ||> > >in the proposed solution draft. ITU-T has quite extensive work > ||> > >on the requirements for Emergency services. > ||> > > > ||> > >On a side note, one of the problems identified during a recent > ||> > >school shooting in Canada was that the emergency and > ||police couldn't > ||> > >use the phone or cell phones to communicate because the > ||network was > ||> > >jammed due to high volume of calls between students and their > ||>families. > ||> > > > ||> > >Yours, > ||> > >Shahram > ||> > > > ||> > > > ||> > > > -----Original Message----- > ||> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> > > > Sent: Tuesday, September 19, 2006 5:26 PM > ||> > > > To: ken carlberg > ||> > > > Cc: pcn@ietf.org > ||> > > > Subject: ProblemStatement Issue B.9:Call Preemption > |Not Allowed > ||> >Issue. > ||> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > ||> > > > > ||> > > > > ||> > > > Ken: > ||> > > > Thank you for handling so many of our replies at the > ||same time. :) > ||> > > > > ||> > > > YES, on your point of: > ||> > > > > ||> > > > >just to recap. I just wanted to point out that there are > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider > ||> > > > >other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > ||> > > > We are using the Problem-Statement draft to put out an > ||> > > > initial version of what we are thinking, as this is still > ||> > > > work in progress, there > ||>definitely > ||> > > > are area we > ||> > > > may have missed. > ||> > > > > ||> > > > Thank you for pointing out at least one of them. > ||> > > > > ||> > > > I will write some additional text for -01 version of > ||the Problem > ||> > > > Statement draft to try > ||> > > > and describe the problem you have indicated (but I > ||will try NOT to > ||> > > > indicate any solution > ||> > > > in the Problem Statement draft). > ||> > > > > ||> > > > And we will try to have some text in at least some of our > ||>Deployment > ||> > > > Model drafts > ||> > > > to see if there are good solutions to the problem you > ||> > > > indicated. There may be more than one solution as there may > ||> > > > be more than one > |Deployment > ||> >Model. > ||> > > > > ||> > > > Please Notice I have changed the subject of the E-Mail > ||thread for > ||> > > > issue tracking purpose. > ||> > > > Please use this E-Mail Subject for continuing this discussion. > ||> > > > > ||> > > > Now I have additional questions concerning the use of > ||Preemption > ||>for > ||> > > > handling Emergency > ||> > > > Services. Will Preemption be allowed for Emergency Services? > ||> > > > Does some of the > ||> > > > jurisdiction you have indicated want to use a separate > ||network for > ||> > > > Emergency Services > ||> > > > purpose? Will combining Emergency Services with the normal > ||> > > > VoIP calls/sessions be a good Problem Statement that we can > ||> > > > add to our Problem Statement draft? > ||> > > > > ||> > > > I am concentrating on Problem Statement instead of Solutions > ||> > > > for now because we want to get the Problem Statement cleared > ||> > > > away first for the BOF purpose. > ||> > > > > ||> > > > Thanks! > ||> > > > -- Kwok -- > ||> > > > > ||> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > ||> > > > >Anna, > ||> > > > > > ||> > > > >>>maybe we have a different perspective of > ||preemption. as I view > ||> >it, > ||> > > > >>>preemption is removing *existing* state (circuit > |in the PSTN > ||> > > > >>>world) in > ||> > > > >>>favor of new state. > ||> > > > >> > ||> > > > >>I guess that may be one thing that needs > ||clarification. The way > ||>I > ||> > > > >>view > ||> > > > >>it (and I think the way > ||draft-chan-pcn-problem-statement-00.txt > ||> >and > ||> > > > >>related docs view the issue) is that pre-emption > ||should kick in > ||> > > > >>when for > ||> > > > >>whatever reason provisioning mechanisms fail there > ||simply is not > ||> > > > >>enough > ||> > > > >>capacity to carry all calls. Setting aside the issue of > ||> >precedence > ||> > > > >>for > ||> > > > >>the moment, the expectation is that the level of > ||traffic needed > ||>to > ||> > > > >>trigger premption is typicaly higher (perhaps substanially > ||>higher) > ||> > > > >>than > ||> > > > >>the level triggering to stop admission of new flows. That > ||> > > > means that > ||> > > > >>when preemption does get triggered, there would actually > ||> > > > not really be > ||> > > > >>any new state admitted. > ||> > > > > > ||> > > > >I'm sorry, but with that last sentence you lost me > ||:-)...I kind > ||>of > ||> > > > >understood some of the things you were saying, but > ||there were too > ||> > > > >many things you left out (why does one have an > ||admission control > ||>at > ||> > > > >level X and a preemption level at X+N?, are you > ||implying that the > ||> > > > >edge is keeping track of the flows it > ||rejects?....that would seem > ||> > > > >quite granular in keeping measurements). > ||> > > > > > ||> > > > >I'm not sure its necessary to clarify the above. > |Its probably > ||>just > ||> > > > >best that we agree that future work should include a more > ||>detailed > ||> > > > >discussion of what is preemption in the context of your > ||> >architecture. > ||> > > > > > ||> > > > >>The degree of how far apart preemption and admission > ||> > > > >>thresholds are is of course a mater of > ||> > > > configuration, but I > ||> > > > >>would expect that they would be sufficiently apart to > ||> > > > >>ensure > ||>that > ||> > > > >>you do > ||> > > > >>not just toggle preempted and new flows. Of course if > ||> > > > >>there > ||> > > > are higher > ||> > > > >>precedence calls, then one might expect that a higher > ||> > > > precedence call > ||> > > > >>may be established while lower precedence calls may > ||need to be > ||> > > > >>preempted? > ||> > > > >> > ||> > > > >>Perhaps this expectation should be made more > ||transparent in the > ||> > > > >>drafts? > ||> > > > >> > ||> > > > >>>In the US and some other countries, this is not allowed > ||> > > > >>>in the PSTN. > ||> > > > >> > ||> > > > >>Just wanted to make sure I understand exactly what is not > ||>allowed. > ||> > > > >>Are > ||> > > > >>you saying that PSTN is not allowed to preempt a lower > ||> > > > precedence call > ||> > > > >>in order to establish a high recedence call? Or are you > ||> > > > referring to > ||> > > > >>the same precedence levels? > ||> > > > > > ||> > > > >as an example, in the US PSTN, all calls from the > ||general public > ||> >are > ||> > > > >treated with the same level of precedence. the exception > ||> > > > >are > ||> >systems > ||> > > > >like GETS, but they simply increase the probability of call > ||> > > > >completion -- they do not use preemption. private > ||systems based > ||>on > ||> > > > >MLPP, like Autovon in the DoD and NATO, do allow > ||different levels > ||> >of > ||> > > > >priority and subsequent preemption if so needed. > |rfc-4190 and > ||> > > > >rfc-4542 provide background on these systems/services > ||along with > ||> > > > >discussion in the context of IP (since this is the IETF :-) > ||> > > > > > ||> > > > >just to recap. I just wanted to point out that there are > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider > ||> > > > >other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > > ||> > > > >regards, > ||> > > > > > ||> > > > >-ken > ||> > > > > > ||> > > > > > ||> > > > >_______________________________________________ > ||> > > > >PCN mailing list > ||> > > > >PCN@ietf.org > ||> > > > >https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > > > ||> > > > _______________________________________________ > ||> > > > PCN mailing list > ||> > > > PCN@ietf.org > ||> > > > https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > ||> > > ||> >_______________________________________________ > ||> >PCN mailing list > ||> >PCN@ietf.org > ||> >https://www1.ietf.org/mailman/listinfo/pcn > || > || > ||_______________________________________________ > ||PCN mailing list > ||PCN@ietf.org > ||https://www1.ietf.org/mailman/listinfo/pcn > || > | > |_______________________________________________ > |PCN mailing list > |PCN@ietf.org > |https://www1.ietf.org/mailman/listinfo/pcn > | > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Sep 27 05:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSVHV-0003yc-Jw; Wed, 27 Sep 2006 05:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSVHU-0003yX-E3 for pcn@ietf.org; Wed, 27 Sep 2006 05:00:40 -0400 Received: from [194.145.62.201] (helo=relay1.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSVHR-0002b7-0Q for pcn@ietf.org; Wed, 27 Sep 2006 05:00:40 -0400 Received: from fw-mta1.siemens.pt (fw-mta-pt1.siemens.pt [141.29.156.201]) by relay1.siemens.pt (8.13.1/8.13.1) with ESMTP id k8R8vsav020253; Wed, 27 Sep 2006 09:57:54 +0100 Received: from PTLISI052MSX.PT001.SIEMENS.NET (ptlisi052n02.pt001.siemens.net [141.29.156.66]) by fw-mta1.siemens.pt (Hvm) with ESMTP id k8R8w2829720; Wed, 27 Sep 2006 09:58:02 +0100 Received: from PTLISI051MSX.PT001.SIEMENS.NET ([141.29.156.78]) by PTLISI052MSX.PT001.SIEMENS.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 09:58:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption NotAllowedIssue.Used to be Re: [PCN]draft-chan-pcn-problem-statement-00.txt Date: Wed, 27 Sep 2006 09:58:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption NotAllowedIssue.Used to be Re: [PCN]draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbh/ydd0EJEyVWoQIiGJfjYiegBswADrfnQAAEDD3A= From: "Garcia, Nuno" To: "Georgios Karagiannis" , X-OriginalArrivalTime: 27 Sep 2006 08:58:03.0073 (UTC) FILETIME=[0A3E0310:01C6E213] X-Spam-Score: 0.1 (/) X-Scan-Signature: ad21aece51aeebf80192250df67eab8a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: I'm sorry to jump in, I've been waiting for some free time to read all = the materials with due attention, but since you're bringing this on, = IMHO we should consider using self-similarity measurement statistics, = e.g. the Hurst parameter, since it is well known that self-similar = bursty traffic does not behave well for statistics such average or = variance. Cheers, Nuno Garcia SIEMENS S.A. INFORMATION and COMMUNICATIONS * RESEARCH and DEVELOPMENT 1 * RESEARCH=20 Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal=20 Phone: +351-21 416 7159 Fax: +351-21 424 2082=20 e-mail: Nuno.MGarcia@siemens.com=20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: quarta-feira, 27 de Setembro de 2006 9:25 To: menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org Subject: RE: ProblemStatement Issue B.9:Call Preemption = NotAllowedIssue.Used to be Re: = [PCN]draft-chan-pcn-problem-statement-00.txt Hi Michael I think that you are right, we need to somehow provide some = quantification=20 of the overprovisioning, which depends on: 1) the time until the calls are admtted: If the response time is long, = the overprovisioning is substantial. 2) the statistics of the aggregated traffic. It will work well with = traffic that have a nice average behaviour. 3) mass-call events that usually happends in telefony networks. If the number of calls suddenly increases, the PCN will not have time to block = the calls. 4) response time for the measurement function. Best Regards, Georgios -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: woensdag 27 september 2006 8:36 To: Geib, Ruediger Cc: pcn@ietf.org Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue.Used to be Re: [PCN] = draft-chan-pcn-problem-statement-00.txt Hi Ruediger, Stuart, I think that the question is the following: How large should the = admissible and supportable link rates be that QoS can be maintained in spite of (1) bursty traffic (2) admission errors due to the measurement-based nature of the AC = (flash crowds) (3) redirected traffic due to likely network outages like single link failures The answer depends on the traffic model and the link capacity. = I think this defines plenty of work for academic parametric studies to = give guidelines for operators. This is a feasible thing to do. We addressed = issue (3) in previous work for a different NAC approach. If the network is configured to copy with (1)-(3), QoS is quite well protected. And if = all the assumptions for (1)-(3) fail that were made for the configuration, = then preemption kicks in, but only then. Best wishes, Michael Geib, Ruediger wrote: > Stuart, > > if "pre-congestion level" is the configured-admission-rate, then=20 > "leaving enough excess capacity" is, at least from my point of view, a = > planning task. PCN should make sure that vendors have sufficient=20 > guidance to implement the knobs allowing network operators to fulfill=20 > this task. > > As I mentioned, what a "relatively high (CL load) level"=20 > on a particular PCN link is, should for his network entirely be the=20 > decision of a carrier. As long as the SLA's defining the CL service=20 > commercially are kept, it is nobody else' matter how it is produced. > > Regards, > > Rudiger > > |-----Original Message----- > |From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@lucent.com] > |Sent: Tuesday, September 26, 2006 6:36 PM > |To: Geib, Rudiger; khchan@nortel.com > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > |AllowedIssue. Used to be Re: [PCN]=20 > |draft-chan-pcn-problem-statement-00.txt > | > | > |Ruediqer, > | > |I think my mental picture is close to your view of having the two=20 > |level settings. I would hope that the pre-congestion level while=20 > |relatively high still leaves enough excess capacity so that the=20 > |actions taken are more likely to prevent the second level from = actually being crossed. > | > |Stuart Goldman > |Lucent Technologies > |sgoldman@lucent.com > |602 493 8438 > | > | > |-----Original Message----- > |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |Sent: Tuesday, September 26, 2006 12:29 AM > |To: khchan@nortel.com; GOLDMAN, STUART O (STUART) > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > |AllowedIssue. Used to be Re: [PCN]=20 > |draft-chan-pcn-problem-statement-00.txt > | > |Kwok, Stuart, > | > |my take may be a slightly different one. PCN allows to mark packets=20 > |once a settable load level has been reached on a particular link and=20 > |prior to any of these packets being discarded due to the traffic rate = > |crossing a second settable rate. > | > |The former of both rates is the admissible link rate or=20 > |configured-admission-rate. The latter is the supportable link rate or = > |configured-preemption-rate. My understanding is that PCN doesn't=20 > |specify "service" to more detail then demanding CL like performance=20 > |for admitted traffic. To reach this aim, the preemption-rate must be=20 > |chosen sufficiently bigger than the admission-rate. How the rates are = > |set exactly is left to operators and depends on the network planning=20 > |philosophy applied by each of them and the characteristics of the=20 > |traffic being forwarded by PCN. A second condition is that PCN=20 > |traffic should consist of a large number of multiplexed flows whose=20 > |individual peak rate is small as compared to the admission-rate. What = > |PCN should do is provide simulation results and measurements prooving = > |that the mechanism works under todays "common" load and network=20 > |conditions. > |Giving guidance on operational settings for a variety of networks and = > |traffic mixes to me is a research topic, which is out of scope of the = > |PCN WG. A BCP may be published, once sufficient "P" is available. > | > |Regards, > | > |Rudiger > | > ||-----Original Message----- > ||From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||Sent: Monday, September 25, 2006 5:30 PM > ||To: GOLDMAN, STUART O (STUART) > ||Cc: pcn@ietf.org; Shahram Davari; ken carlberg > ||Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > ||AllowedIssue. Used to be Re: [PCN]=20 > ||draft-chan-pcn-problem-statement-00.txt > || > || > ||Stuart: > ||No problem. > ||By "Pre-Congestion", we mean: > ||"if additional IP packet traffic is admitted (into the traffic class = > ||handling this traffic), then already admitted traffic (of the same=20 > ||traffic class) will experience degraded QoS. > ||This degraded QoS happens at specific nodes (or diffserv hops) of=20 > ||the end-to-end path because we are working with IP packet network. =20 > ||This degraded QoS may affect the end-to-end service required of the=20 > ||network by the Using Application." > || > ||Of course there are many factors that defines what is (and what is > ||not) acceptable > ||"degraded QoS" and how much additional traffic will cause the=20 > ||degraded QoS to be not acceptable, for example: > ||- the Using Application and the requirements it have on the network. > ||--- hence we are looking at inelastic, interactive, Real-Time use of = > ||the network (first). > ||- the ratio of the total shared (by the traffic class) network=20 > ||resource at specific network > || nodes with respect to each admitted traffic flow and each=20 > ||to-be-admitted traffic flow. > || This indicates how each additional traffic flow over some limit=20 > ||will impact already > || admitted traffic flows. In both space and time dimensions. > ||--- hence we are looking into amount of network resource, e.g. size=20 > ||of network pipes. > || We first look at the easier one (we think), large network=20 > ||pipes. Then the harder ones > || of smaller and smaller network pipes. > ||- the characteristic of the traffic flows, for example are they=20 > ||constant bit rate? Or close > || to constant bit rate?, etc. > ||- the promised service to the Using Application. > || On this Issue B.9, we are talking about promised service of NO=20 > ||PREEMPTION > || (but may be with some condition). > || > ||As you indicated, the network resource we are discussing allows=20 > ||provisioning of detection before congestion, before the packet=20 > ||forwarding queues gets backed up. > ||And we want to have some capacity still available (this may be view=20 > ||as one of the ways on HOW we can do this). But you are right that=20 > ||we may need to conserve this head-room capacity, but again depending = > ||on for what reasons. > ||Is it because we can not preempt any admitted flows? > ||Is it because we need to handle emergency services? > ||Is it because we need to handle none-constant bit rate traffic? > ||Some other reasons or combinations of them? > || > ||These are still topics of discussions and additional work we hope we = > ||can do together in this WG (hopeful result of the PCN BOF). > || > ||Sorry for such a long reply, just want to indicate some of the=20 > ||thinkings I have and working toward/down the path of agreements. > ||Thanks! > ||-- Kwok -- > || > || > ||At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||>Kwok, > ||> > ||>Sorry to have taken so long to respond, but my day job got > |in the way. > ||> > ||>As I understood the topic, we are addressing pre-congestion. In=20 > ||>that light, I assumed that congestion has not yet occurred, but > |that we are > ||>approaching congestion. So, I further assumed that there was > ||still some > ||>capacity available, although this remaining capacity needs to be=20 > ||>conserved as best as possible. > ||> > ||>Am I am the right wavelength? > ||> > ||>Stuart Goldman > ||>Lucent Technologies > ||>sgoldman@lucent.com > ||>602 493 8438 > ||> > ||>-----Original Message----- > ||>From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||>Sent: Wednesday, September 20, 2006 10:58 AM > ||>To: GOLDMAN, STUART O (STUART) > ||>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg > ||>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > ||>AllowedIssue. Used to be Re: [PCN]=20 > ||>draft-chan-pcn-problem-statement-00.txt > ||> > ||>Stuart: > ||>Preemption is just one of possibly multiple decisions the End Node=20 > ||>function can take. > ||>Hence you are right that there may be other decisions that > |is of value > ||>to the > ||>system as a whole, possibly depending on the deployment evironment. > ||> > ||>These discussions we have so far indicates that we may not > ||want to call > ||>the network information the Interior Nodes are providing as > ||"Preemption > ||>Mark" > ||>indication. > ||> > ||>Hence these discussions are very helpful for our BOF/WG. > ||> > ||>Thanks! > ||>-- Kwok -- > ||> > ||> > ||>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||> >Kwok-Ho, > ||> >While you seem to have only mentioned preemption, there > ||should be ways > ||> >to recognize a call deserving higher than normal preference > ||and giving > ||> >it that preference to the remaining network resources > ||without having to > ||> >preempt a call in progress. Yes? > ||> > > ||> >Stuart Goldman > ||> >Lucent Technologies > ||> >sgoldman@lucent.com > ||> >602 493 8438 > ||> > > ||> > > ||> >-----Original Message----- > ||> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> >Sent: Wednesday, September 20, 2006 8:54 AM > ||> >To: Shahram Davari > ||> >Cc: pcn@ietf.org; ken carlberg > ||> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > ||> >AllowedIssue. Used to be Re: [PCN]=20 > ||> >draft-chan-pcn-problem-statement-00.txt > ||> > > ||> >Shahram: > ||> >I totally agree. > ||> >The cell phone network was also jammed during 9/11. > ||> >I was trying to reach my brother who were stuck in the subway > ||> >~2 stops from WTC. > ||> >So I know exactly how this feels like. But I prefer to let the=20 > ||> >Police and Firemen to use this resource to help the general=20 > ||> >public at large. > ||> > > ||> >The question becomes: > ||> >- Does the Emergency Services want to use the same physical=20 > ||> >network as the general public? > ||> >-- If Yes. Then should the problem statement becomes: > ||> > "Some controlled preemption functionality is allowed for=20 > ||> >Emergency purposes in the general > ||> > public integrated (voice, video, data, etc) network. This=20 > ||> >controlled preemption functionality > ||> > needs to be supported by the network mechanisms." > ||> >-- If Yes. Then we will need some guidance and help wrt the=20 > ||> >regulations of the different jurisdictions. > ||> > Also if the different jurisdictions even wants to use the=20 > ||> >same network infrastructure for both > ||> > emergency and public usage purposes. If it is technically > ||>possible. > ||> > > ||> >By this I am not saying a good solution exist or that I am > |promoting > ||> >a specific solution. > ||> >I am just agreeing that this problem needs to be addressed. > ||> >We may end up saying we can not solve this problem as of > |yet. But I > ||> >wish we can solve it. > ||> > > ||> >Regards. > ||> >-- Kwok -- > ||> > > ||> > > ||> >At 09:34 AM 9/20/2006, Shahram Davari wrote: > ||> > >Kwok, > ||> > > > ||> > >Indeed you raised a good subject. The requirements for=20 > ||> > >emergency services should be part of the problem statement, and = > ||> > >be > ||dealt with > ||> > >in the proposed solution draft. ITU-T has quite extensive work=20 > ||> > >on the requirements for Emergency services. > ||> > > > ||> > >On a side note, one of the problems identified during a recent=20 > ||> > >school shooting in Canada was that the emergency and > ||police couldn't > ||> > >use the phone or cell phones to communicate because the > ||network was > ||> > >jammed due to high volume of calls between students and their > ||>families. > ||> > > > ||> > >Yours, > ||> > >Shahram > ||> > > > ||> > > > ||> > > > -----Original Message----- > ||> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> > > > Sent: Tuesday, September 19, 2006 5:26 PM > ||> > > > To: ken carlberg > ||> > > > Cc: pcn@ietf.org > ||> > > > Subject: ProblemStatement Issue B.9:Call Preemption > |Not Allowed > ||> >Issue. > ||> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > ||> > > > > ||> > > > > ||> > > > Ken: > ||> > > > Thank you for handling so many of our replies at the > ||same time. :) > ||> > > > > ||> > > > YES, on your point of: > ||> > > > > ||> > > > >just to recap. I just wanted to point out that there are=20 > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider=20 > ||> > > > >other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > ||> > > > We are using the Problem-Statement draft to put out an=20 > ||> > > > initial version of what we are thinking, as this is still=20 > ||> > > > work in progress, there > ||>definitely > ||> > > > are area we > ||> > > > may have missed. > ||> > > > > ||> > > > Thank you for pointing out at least one of them. > ||> > > > > ||> > > > I will write some additional text for -01 version of > ||the Problem > ||> > > > Statement draft to try > ||> > > > and describe the problem you have indicated (but I > ||will try NOT to > ||> > > > indicate any solution > ||> > > > in the Problem Statement draft). > ||> > > > > ||> > > > And we will try to have some text in at least some of our > ||>Deployment > ||> > > > Model drafts > ||> > > > to see if there are good solutions to the problem you=20 > ||> > > > indicated. There may be more than one solution as there may = > ||> > > > be more than one > |Deployment > ||> >Model. > ||> > > > > ||> > > > Please Notice I have changed the subject of the E-Mail > ||thread for > ||> > > > issue tracking purpose. > ||> > > > Please use this E-Mail Subject for continuing this = discussion. > ||> > > > > ||> > > > Now I have additional questions concerning the use of > ||Preemption > ||>for > ||> > > > handling Emergency > ||> > > > Services. Will Preemption be allowed for Emergency = Services? > ||> > > > Does some of the > ||> > > > jurisdiction you have indicated want to use a separate > ||network for > ||> > > > Emergency Services > ||> > > > purpose? Will combining Emergency Services with the normal=20 > ||> > > > VoIP calls/sessions be a good Problem Statement that we can=20 > ||> > > > add to our Problem Statement draft? > ||> > > > > ||> > > > I am concentrating on Problem Statement instead of Solutions = > ||> > > > for now because we want to get the Problem Statement cleared = > ||> > > > away first for the BOF purpose. > ||> > > > > ||> > > > Thanks! > ||> > > > -- Kwok -- > ||> > > > > ||> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > ||> > > > >Anna, > ||> > > > > > ||> > > > >>>maybe we have a different perspective of > ||preemption. as I view > ||> >it, > ||> > > > >>>preemption is removing *existing* state (circuit > |in the PSTN > ||> > > > >>>world) in > ||> > > > >>>favor of new state. > ||> > > > >> > ||> > > > >>I guess that may be one thing that needs > ||clarification. The way > ||>I > ||> > > > >>view > ||> > > > >>it (and I think the way > ||draft-chan-pcn-problem-statement-00.txt > ||> >and > ||> > > > >>related docs view the issue) is that pre-emption > ||should kick in > ||> > > > >>when for > ||> > > > >>whatever reason provisioning mechanisms fail there > ||simply is not > ||> > > > >>enough > ||> > > > >>capacity to carry all calls. Setting aside the issue of > ||> >precedence > ||> > > > >>for > ||> > > > >>the moment, the expectation is that the level of > ||traffic needed > ||>to > ||> > > > >>trigger premption is typicaly higher (perhaps substanially > ||>higher) > ||> > > > >>than > ||> > > > >>the level triggering to stop admission of new flows. That > ||> > > > means that > ||> > > > >>when preemption does get triggered, there would actually > ||> > > > not really be > ||> > > > >>any new state admitted. > ||> > > > > > ||> > > > >I'm sorry, but with that last sentence you lost me > ||:-)...I kind > ||>of > ||> > > > >understood some of the things you were saying, but > ||there were too > ||> > > > >many things you left out (why does one have an > ||admission control > ||>at > ||> > > > >level X and a preemption level at X+N?, are you > ||implying that the > ||> > > > >edge is keeping track of the flows it > ||rejects?....that would seem > ||> > > > >quite granular in keeping measurements). > ||> > > > > > ||> > > > >I'm not sure its necessary to clarify the above. =20 > |Its probably > ||>just > ||> > > > >best that we agree that future work should include a more > ||>detailed > ||> > > > >discussion of what is preemption in the context of your > ||> >architecture. > ||> > > > > > ||> > > > >>The degree of how far apart preemption and admission=20 > ||> > > > >>thresholds are is of course a mater of > ||> > > > configuration, but I > ||> > > > >>would expect that they would be sufficiently apart to=20 > ||> > > > >>ensure > ||>that > ||> > > > >>you do > ||> > > > >>not just toggle preempted and new flows. Of course if=20 > ||> > > > >>there > ||> > > > are higher > ||> > > > >>precedence calls, then one might expect that a higher > ||> > > > precedence call > ||> > > > >>may be established while lower precedence calls may > ||need to be > ||> > > > >>preempted? > ||> > > > >> > ||> > > > >>Perhaps this expectation should be made more > ||transparent in the > ||> > > > >>drafts? > ||> > > > >> > ||> > > > >>>In the US and some other countries, this is not allowed=20 > ||> > > > >>>in the PSTN. > ||> > > > >> > ||> > > > >>Just wanted to make sure I understand exactly what is not > ||>allowed. > ||> > > > >>Are > ||> > > > >>you saying that PSTN is not allowed to preempt a lower > ||> > > > precedence call > ||> > > > >>in order to establish a high recedence call? Or are you > ||> > > > referring to > ||> > > > >>the same precedence levels? > ||> > > > > > ||> > > > >as an example, in the US PSTN, all calls from the > ||general public > ||> >are > ||> > > > >treated with the same level of precedence. the exception=20 > ||> > > > >are > ||> >systems > ||> > > > >like GETS, but they simply increase the probability of call = > ||> > > > >completion -- they do not use preemption. private > ||systems based > ||>on > ||> > > > >MLPP, like Autovon in the DoD and NATO, do allow > ||different levels > ||> >of > ||> > > > >priority and subsequent preemption if so needed. =20 > |rfc-4190 and > ||> > > > >rfc-4542 provide background on these systems/services > ||along with > ||> > > > >discussion in the context of IP (since this is the IETF :-) > ||> > > > > > ||> > > > >just to recap. I just wanted to point out that there are=20 > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider=20 > ||> > > > >other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > > ||> > > > >regards, > ||> > > > > > ||> > > > >-ken > ||> > > > > > ||> > > > > > ||> > > > >_______________________________________________ > ||> > > > >PCN mailing list > ||> > > > >PCN@ietf.org > ||> > > > >https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > > > ||> > > > _______________________________________________ > ||> > > > PCN mailing list > ||> > > > PCN@ietf.org > ||> > > > https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > ||> > > ||> >_______________________________________________ > ||> >PCN mailing list > ||> >PCN@ietf.org > ||> >https://www1.ietf.org/mailman/listinfo/pcn > || > || > ||_______________________________________________ > ||PCN mailing list > ||PCN@ietf.org > ||https://www1.ietf.org/mailman/listinfo/pcn > || > | > |_______________________________________________ > |PCN mailing list > |PCN@ietf.org > |https://www1.ietf.org/mailman/listinfo/pcn > | > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, = D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Sep 29 05:30:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTEhh-0001mT-3c; Fri, 29 Sep 2006 05:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTEhf-0001mN-7q for pcn@ietf.org; Fri, 29 Sep 2006 05:30:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTEhY-0004Jw-Q4 for pcn@ietf.org; Fri, 29 Sep 2006 05:30:43 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C41F98E0002; Fri, 29 Sep 2006 11:28:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 11:28:08 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 11:28:07 +0200 Message-ID: <451CE728.9040102@ericsson.com> Date: Fri, 29 Sep 2006 11:28:08 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Anna Charny (acharny)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 09:28:07.0723 (UTC) FILETIME=[92B93FB0:01C6E3A9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Lars Eggert , pcn@ietf.org Subject: [PCN] Re: Request for Pre-Congestion Notification BOF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Anna Charny (acharny) skrev: > Thanks Magnus, great news. > > When should we expect to know the chair appoinment? We will try to get someone appointed next week. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn