From pcn-bounces@ietf.org Thu Feb 01 02:50:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCWiX-0000Vi-0a; Thu, 01 Feb 2007 02:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCWiW-0000Vd-1h for pcn@ietf.org; Thu, 01 Feb 2007 02:50:48 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCWiU-0006A6-Kj for pcn@ietf.org; Thu, 01 Feb 2007 02:50:48 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 1 Feb 2007 08:50:40 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 08:50:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter text update Date: Thu, 1 Feb 2007 08:50:39 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAEA@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <9048D4F2-7965-4722-BD29-3D9F573193E5@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update thread-index: AcdFTYAvHFZMgPMKSJOuwNU9YetCRwAhSELQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Feb 2007 07:50:40.0271 (UTC) FILETIME=[AB01A1F0:01C745D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Lars, I think we are rather close. Your remarks and the text you suggest=20 say, that the use of flow admission does not require the use=20 of preemption. If that statement is strong enough to ensure, that=20 an operator is able to activate "PCN flow admission" on a=20 PCN compliant router without by that automatically turning on=20 "PCN preemption" and no chance to disable the latter, then I'm fine. With other words, would your proposed reworded charter statement=20 mean that "..., and the use of one does not require..." expresses "..., and the use of one must not require..." ? If not, I'd be happier with the latter version. Regards, Ruediger |the recent emails by Ken, Phil and you helped a lot. I think we =20 |actually may be in agreement. | |On 2007-1-31, at 16:39, ext Geib, Ruediger wrote: |> what you say is that "preemption" must not be the only reaction |> specified by PCN once an ingress edge router determines that |> the path to a particular egress router reached |> congestion/preemption state? |> |> If yes, I agree. Would the charter have to say so or should |> this be a design constraint to be kept in mind when drafting |> standards? | |The charter already allows a reaction other than preemption, namely, =20 |to prevent admission of new flows. Additionally, there was some =20 |discussion around having a rate-adaptation reaction function. | |Would a slightly-reworded statement taken from an earlier version of =20 |the charter help: | | Although designed to work together, flow admission and | flow preemption are independent mechanisms, and the use | of one does not require or prevent the use of the other. | |> The minimum requirement may be to demand that the deactivation |> of a preemption mechanism must be possible (the PCN domain |> would then always interpret congestion marks in the same way as |> pre-congestion marks ). | |There seems to be an unstated assumption here that congestion marks =20 |will always lead to preemption, while pre-congestion marks will lead =20 |to admission decisions. This is not so - the current charter allows =20 |different policies, i.e., meaning decision algorithms that take =20 |congestion and pre-congestion markers as input and produce preemption =20 |and admission decisions on the set of flows as an output. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 03:45:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXZI-0005Zz-0j; Thu, 01 Feb 2007 03:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXZG-0005YJ-2h for pcn@ietf.org; Thu, 01 Feb 2007 03:45:18 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCXZE-0005Hn-IH for pcn@ietf.org; Thu, 01 Feb 2007 03:45:18 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l118j9mJ005112 for ; Thu, 1 Feb 2007 03:45:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] charter, addition to scope Date: Thu, 1 Feb 2007 10:45:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igABFlM0AAALDecAAAtiiAABrkqnA= References: From: "Romascanu, Dan \(Dan\)" To: "Lee, Richard FTC" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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 Maybe we should stop for a moment and consider what layer should PCN deal with. It looks to me that we are mixing network admission control and call admission control in this discussion. This problem is quite complex, and there are many scenarios that need to be taken into consideration. Sometimes flow =3D call, sometimes call =3DNOT flow and sometimes there is a mix on the same path. In some cases media gateways are collocated with the edge nodes in some other cases not. Even when flow =3D call there are two admission control layers (network and call) that are in dependency but not identical and separate protocols run at transport and session. I am not sure how much of all this falls under what PCN should do.=20 Dan =20 =20 > -----Original Message----- > From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM]=20 > Sent: Wednesday, January 31, 2007 11:28 PM > To: Black_David@emc.com; karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > To all, > I agree that there must be a prioritization of flows=20 > from the aggregation devices However, it's not just the media=20 > gateway that should speak RSVP, but the edge proxy (or=20 > firewall "proxy") as well - it is the signaling proxy at the=20 > edge that reserves the media path. The reservation protocol=20 > request to the network from the VoIP proxy/gateway must=20 > reserve resources to the destination in the network.=20 > The resource reservation request to the network by the edge=20 > proxy/media gateway, must at the very minimum, meet the=20 > following conditions: > 1. it needs to specify the resources required for the IP &=20 > ports (RTP/RTCP & bandwidth) > for example, G.711 and G.729 voice and various MPEG-4=20 > video codecs all have very different requirements 2. it must=20 > be mapped to the signaling request > for SIP, it must map the SDP for media with the=20 > reservation flow - for example something along the lines of RFC 3524 > while not the answer, the mapping of the media flows is a=20 > necessary component > It should be noted that the edge proxies/media gateways=20 > may have a large number of flows (and ports for each =20 > RTP/RTCP flow) from the same source IP. The request is=20 > made for each flow or conversation 3. it must be honored by=20 > the edge network device.=20 > The trust boundary must be extended to the edge=20 > proxy/media gateway for each new flow. > This brings up the issue of security authentication of the=20 > edge proxy/media gateway to the network > Does this happen in EAP, NAC, or just interoperability=20 > and certification among vendors > If the resources are not available, then the signaling=20 > indicates the session is not completed. For example a SIP > CANCEL from the edge proxy >=20 > In addition, the network device must have priority queuing=20 > enabled for input queues from the edge device. > The media flows must not be subject to input buffers being=20 > filled prior to classification >=20 > Thanks, > Richard Lee > Fidelity Investments > Enterprise Technology and Architecture > 617-563-3278 >=20 >=20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, January 31, 2007 2:30 PM > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 >=20 > Georgios wrote: >=20 > > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > > > In the first phase of PCN work to reduce the list of=20 > issues it was >=20 > > > > proposed that the WG focus on network deployment scenario where > all=20 > > > > nodes can be trusted and delay work on deployment=20 > scenarios where > some=20 > > > > of the nodes are not trusted. > > >=20 > > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If > "nodes"=20 > > > include end systems, proxies or other entities, then I don't=20 > > > agree we had agreement on that. > >=20 > > Georgios: This imposes an additional restriction on the scope=20 > > of the charter, which has been not discussed yet. > > >From what I remember before, during and after the PCN BOF=20 > > there was no objection on using > > the term edge node, that could mean something different than a edge > router. > > Please note that this is something different than a scenario covered > by=20 > > an application based deployment model. >=20 > It's certainly not a new restriction based on the discussion in the > BOF engendered about whether a SIP telephone (used on some of the > slides) was a good example. I believe the BOF conclusion was that > a SIP telephone was a bad example. >=20 > IMHO, a SIP telephone causes two sets of issues wrt the proposed work: > (1) It speaks SIP, and=20 > (2) It's a telephone ;-) > The first set of issues has already been discussed extensively - my > understanding is that the SIP scenario is currently out of scope, and > I don't care to reopen that discussion. >=20 > The "telephone" issues come up in two ways: > (2a) Small number of flows may make relatively fine-grained adjustment > on the link to the phone impossible. The PCN work prior to > the BOF relied on the ability to make such adjustments. > (2b) While other sorts of phones may be trusted, a SIP phone (which > may be software-only) is definitely not trustable in general. >=20 > I would observe that Lars Westerberg's suggestion of a Media Gateway: >=20 > > I am referring telecom scenario where MGWs are connected to an > IP-backbone. > > In these scenarios, the admission control function is a part of the > MGW > > and not the routers. The IP-backbone is provisioned by a network > > management system. >=20 > could avoid all of these issues: > (1) The media gateway could speak RSVP to the network=20 > management system, > avoiding any need to deal with SIP here. > (2a) A media gateway is likely to handle enough flows to be consistent > with the fine-grained adjustment assumed by the work done to > date. > (2b) One can plausibly assume/require that media gateways be trusted > with respect to the IP network. > To the extent that one can vest "edge" functionality in a trusted > media gateway, I see no reason to exclude that scenario. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 03:52:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXgR-0006Jq-3A; Thu, 01 Feb 2007 03:52:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXgP-0006Jk-Jn for pcn@ietf.org; Thu, 01 Feb 2007 03:52:41 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCXgH-0006ut-Ff for pcn@ietf.org; Thu, 01 Feb 2007 03:52:41 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1B5E54804B; Thu, 1 Feb 2007 09:52:32 +0100 (CET) X-AuditID: c1b4fb3c-b07c9bb0000007de-2b-45c1aa50ad58 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C2BB20680; Thu, 1 Feb 2007 09:52:32 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:52:23 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:52:13 +0100 Message-ID: <45C1AA3C.3020403@ericsson.com> Date: Thu, 01 Feb 2007 09:52:12 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [PCN] charter, addition to scope References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com><010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com><002001c7452c$291184c0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: X-OriginalArrivalTime: 01 Feb 2007 08:52:13.0097 (UTC) FILETIME=[441A2990:01C745DE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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="===============0510517181==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0510517181== Content-Type: multipart/alternative; boundary="------------060004050403000103070109" This is a multi-part message in MIME format. --------------060004050403000103070109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit thanks for your comment. I think that people are confused about the relation of the application. It is actually a simpler solution because I think we should rely in this scenario on that the MGW has some way of reporting the result of PCN to the application. My suggestion we should exclude: -What type of the application. -internal interaction (signalling between the nodes,...... My suggestion is that we should assume that the MGW can: -metering of marked packets - limit/reduce the traffic when PCN is experienced. I assume that the MGW can do it in some way but how this is done should be out-of-scope. - has an internall application feedback between MGWs. How this is reprted/signalled should be out-of scope. - One single domain (the same scope as diff.serv domain). I am suggesting a scenario when the MGW are "directly" connected to the PCN-domain. The scenario is more or less similar to the edge-router case does it make a difference to the edge-router scenario ? yes, I think so. In the edge-router case, the algortihm and protocol design is limited/aligned by the Eedge-router functionality as defined in Diff.serv. and the protocol design has to interact with RSVP-states. In the this scenario, the protocol implemetation may be simpler and the architecture has to be more open for other usage. regards Lasse Black_David@emc.com wrote: > Georgios wrote: > > > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > > > In the first phase of PCN work to reduce the list of issues it was > > > > > proposed that the WG focus on network deployment scenario where > all > > > > nodes can be trusted and delay work on deployment scenarios where > some > > > > of the nodes are not trusted. > > > > > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If > "nodes" > > > include end systems, proxies or other entities, then I don't > > > agree we had agreement on that. > > > > Georgios: This imposes an additional restriction on the scope > > of the charter, which has been not discussed yet. > > >From what I remember before, during and after the PCN BOF > > there was no objection on using > > the term edge node, that could mean something different than a edge > router. > > Please note that this is something different than a scenario covered > by > > an application based deployment model. > > It's certainly not a new restriction based on the discussion in the > BOF engendered about whether a SIP telephone (used on some of the > slides) was a good example. I believe the BOF conclusion was that > a SIP telephone was a bad example. > > IMHO, a SIP telephone causes two sets of issues wrt the proposed work: > (1) It speaks SIP, and > (2) It's a telephone ;-) > The first set of issues has already been discussed extensively - my > understanding is that the SIP scenario is currently out of scope, and > I don't care to reopen that discussion. > > The "telephone" issues come up in two ways: > (2a) Small number of flows may make relatively fine-grained adjustment > on the link to the phone impossible. The PCN work prior to > the BOF relied on the ability to make such adjustments. > (2b) While other sorts of phones may be trusted, a SIP phone (which > may be software-only) is definitely not trustable in general. > > I would observe that Lars Westerberg's suggestion of a Media Gateway: > > > I am referring telecom scenario where MGWs are connected to an > IP-backbone. > > In these scenarios, the admission control function is a part of the > MGW > > and not the routers. The IP-backbone is provisioned by a network > > management system. > > could avoid all of these issues: > (1) The media gateway could speak RSVP to the network management system, > avoiding any need to deal with SIP here. > (2a) A media gateway is likely to handle enough flows to be consistent > with the fine-grained adjustment assumed by the work done to > date. > (2b) One can plausibly assume/require that media gateways be trusted > with respect to the IP network. > To the extent that one can vest "edge" functionality in a trusted > media gateway, I see no reason to exclude that scenario. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > --------------060004050403000103070109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit thanks for your comment.
I think that people are confused about the relation of the application.
It is actually a simpler solution because I think we should rely in this scenario on that the MGW has some way of reporting the result of PCN to the application.
 My suggestion we should exclude:
       -What type of the application.
       -internal interaction (signalling between the nodes,......


My suggestion is that we should assume that the MGW can:
-metering of marked packets
- limit/reduce the traffic when PCN is experienced. I assume that the MGW can do it in some way but how this is done should be out-of-scope.
- has an  internall application feedback between MGWs. How this is reprted/signalled should be out-of scope.
- One single domain (the same scope as diff.serv domain). I am suggesting a scenario when the MGW are "directly" connected to the PCN-domain.

The scenario is more or less similar to the edge-router case

does it make a difference to the edge-router scenario ?

yes, I think so.
In the edge-router case, the algortihm and protocol design is limited/aligned by the Eedge-router functionality as defined in Diff.serv. and the protocol design has to interact with RSVP-states.
In the  this scenario, the protocol implemetation may be simpler and the architecture has to be more open for other usage.


regards Lasse

Black_David@emc.com wrote:
RE: [PCN] charter, addition to scope

Georgios wrote:

> > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
> > > In the first phase of PCN work to reduce the list of issues it was

> > > proposed that the WG focus on network deployment scenario where
all
> > > nodes can be trusted and delay work on deployment scenarios where
some
> > > of the nodes are not trusted.
> >
> > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If
"nodes"
> > include end systems, proxies or other entities, then I don't
> > agree we had agreement on that.
>
> Georgios: This imposes an additional restriction on the scope
> of the charter, which has been not discussed yet.
> >From what I remember before, during and after the PCN BOF
> there was no objection on using
> the term edge node, that could mean something different than a edge
router.
> Please note that this is something different than a scenario covered
by
> an application based deployment model.

It's certainly not a new restriction based on the discussion in the
BOF engendered about whether a SIP telephone (used on some of the
slides) was a good example.  I believe the BOF conclusion was that
a SIP telephone was a bad example.

IMHO, a SIP telephone causes two sets of issues wrt the proposed work:
        (1) It speaks SIP, and
        (2) It's a telephone ;-)
The first set of issues  has already been discussed extensively - my
understanding is that the SIP scenario is currently out of scope, and
I don't care to reopen that discussion.

The "telephone" issues come up in two ways:
(2a) Small number of flows may make relatively fine-grained adjustment
        on the link to the phone impossible.  The PCN work prior to
        the BOF relied on the ability to make such adjustments.
(2b) While other sorts of phones may be trusted, a SIP phone (which
        may be software-only) is definitely not trustable in general.

I would observe that Lars Westerberg's suggestion of a Media Gateway:

> I am referring telecom scenario where MGWs are connected to an
IP-backbone.
> In these scenarios, the admission control function is a part of the
MGW
> and not the routers. The IP-backbone is provisioned by a network
> management system.

could avoid all of these issues:
(1) The media gateway could speak RSVP to the network management system,
        avoiding any need to deal with SIP here.
(2a) A media gateway is likely to handle enough flows to be consistent
        with the fine-grained adjustment assumed by the work done to
date.
(2b) One can plausibly assume/require that media gateways be trusted
        with respect to the IP network.
To the extent that one can vest "edge" functionality in a trusted
media gateway, I see no reason to exclude that scenario.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn

--------------060004050403000103070109-- --===============0510517181== 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 --===============0510517181==-- From pcn-bounces@ietf.org Thu Feb 01 04:33:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYJn-0006a3-CW; Thu, 01 Feb 2007 04:33:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYJl-0006Y4-H0 for pcn@ietf.org; Thu, 01 Feb 2007 04:33:21 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYJj-0003MO-3M for pcn@ietf.org; Thu, 01 Feb 2007 04:33:21 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l119V2A9028344; Thu, 1 Feb 2007 11:31:09 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:33:02 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Feb 2007 11:33:01 +0200 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E697391@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650E697391@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <07F95EA7-87D4-48EE-9D93-404A0CD180D0@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter text update Date: Thu, 1 Feb 2007 11:32:59 +0200 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Feb 2007 09:33:01.0784 (UTC) FILETIME=[F7A22580:01C745E3] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070201113113-6E31DBB0-6537911C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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="===============0353048897==" Errors-To: pcn-bounces@ietf.org --===============0353048897== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-889134676; protocol="application/pkcs7-signature" --Apple-Mail-17-889134676 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-31, at 19:03, ext Jozef Babiarz wrote: > To some people *preemption*, "means the removal of a call to make room > for a new call to be admitted". In the PCN work we have modified the > meaning of preemption to "the removal of excess (that causes > congestion) > traffic at flow granularity level". > > I think we should think about using a different word or term so that > people directly not involved with PCN WG do not get confused, just a > suggestion. Personally, I like preemption, but if it will make the > charter approval process go faster by using a different term, I'm for > the changing it. I had proposed "flow termination" earlier, but not gotten any feedback on it. For me, that replacement would work. Lars --Apple-Mail-17-889134676 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDEwOTMyNTlaMCMGCSqGSIb3DQEJBDEWBBTg8GLpOAEydk58 ejyIFoC8Bn3soTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAlseN5Y1XPJW7CJcC/A5bD5TsPlX5825x3sAIy4p2iYNkC3G/+iZj J35H2XRp1/Yd52WjLuNRaUngr6Brj6LMNllJdFeC7xvgUXTBURnOW1ktAc6P3wFylJ9dzokDaq9h 86Ss5q3n4J5Dj2BQAYtqO4/SE57xUcoJ4rIdPnkjN0FPZvhliGf1mdR/eKVHXwzTci/4CWqmxGnF fdBWuwFOmYmNku/Trw8xnuBj9TnDJC4B5IkuinifivCOjvT06hhRr5Uisaym6uoh4eHfzbEQQZTW NiRe5R/74C3dAcKQJP7uNk/xoBbof86iaG3gmX7xOQw0yniYsoMA/RTFmBuurQAAAAAAAA== --Apple-Mail-17-889134676-- --===============0353048897== 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 --===============0353048897==-- From pcn-bounces@ietf.org Thu Feb 01 04:44:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYU6-0004KW-8n; Thu, 01 Feb 2007 04:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYU4-0004KE-Gy for pcn@ietf.org; Thu, 01 Feb 2007 04:44:00 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYTj-0006sg-Ls for pcn@ietf.org; Thu, 01 Feb 2007 04:44:00 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l119fRr0023124; Thu, 1 Feb 2007 11:41:28 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:43:17 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Feb 2007 11:43:16 +0200 In-Reply-To: <6.2.5.6.0.20070131163950.03af6318@nortel.com> References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> <6.2.5.6.0.20070131163950.03af6318@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com> From: Lars Eggert Subject: Re: [PCN] 2nd charter text update Date: Thu, 1 Feb 2007 11:43:14 +0200 To: ext Kwok-Ho Chan X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Feb 2007 09:43:16.0487 (UTC) FILETIME=[66066170:01C745E5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070201114128-5A41BBB0-4099ECF7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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="===============0468695365==" Errors-To: pcn-bounces@ietf.org --===============0468695365== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-889749667; protocol="application/pkcs7-signature" --Apple-Mail-18-889749667 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-1, at 1:50, ext Kwok-Ho Chan wrote: > At 04:23 AM 1/31/2007, Lars Eggert wrote: >> Talking about "nodes" and "paths" leaves the door open for other work >> than the routers-within-a-single-DiffServ-domain model that we want >> to focus the work on initially. > > KHC_START> > The use of "IP packet data path" is just to make the proposed charter > more concise. May be it becomes too wordy in the itemized sentences, > hence it will be OK for me if they are removed from the itemized > sentences. > But I think "These mechanisms operate on the IP packet data path" > at the top > is helpful to make the propose charter more clear and concise. But they only operate on a subset of the end-to-end path, namely, the part that falls into the PCN-enabled DiffServ domain. > On the topic of using the words "nodes" and/or "routers". > I don't have a good understanding of why the word "router" must be > there. > Many of today's "routers" perform "switching" instead of "routing". > And many of today's "routers" does more than just "routing". > Is a "blade-center" a "router"? Part of it is a "router"? > And does the output (behavior, mechanism documentations) of this WG > need to be > implemented on a specific hardware implementation? On a specific > physical box? > IMHO, the proposed-standards documents produced by this WG should > indicate > behaviors and functionality. To promote and assure inter-operability. > IMHO, the proposed-standards documents produced by this WG should > NOT dictate > how the implementation is done, or where (which and what kind of > square/round physical box) > the implementation must be done at. Since the initial goal is to PCN-enable a DiffServ region, I agree that it would remove confusion if the charter used the terms from RFC2475. I'll take a stab at the appropriate rephrasings. > "(3) encoding and transport of (pre-)congestion signals (replaced > with information) > to the appropriate ingress routers of the network domain" > confusing because I believe we want to specify in a standards track > document > how the (pre-)congestion information is encoded (the bits and bytes > detail) in > some IP header field (ECN, DSCP, etc). This has already been rephrased in my working copy. Lars --Apple-Mail-18-889749667 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDEwOTQzMTRaMCMGCSqGSIb3DQEJBDEWBBQ0RlsHh4mOGD+S p4sSomwITu2MDDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAL1aj+jgw42HjnpHFGZ/lhp9BL+GnkbskKISRjlnbN8DKTjLoM40m 8d+X6Y5TiStyequM03l4amUdFsVDtgUuv7ATa6smEQQKB0o324Gv1rJTk2orzjP0gQ4AhLs7zKkV xjVWNEsyC8KQ8LDY/ArV5FWItt4Mw/B57UuNHnz4pfNemDjxCDU/YEQTRe9XeWE5CN8kXlqiWt05 pG5myBaVhf1J1rWR1KTAwMyW8DgqmBAr6vsvPnLf+fzMf75vsi+iUDSwVKvYYoNMwZmve7oInbr+ IkAL2u2rqB4A6J2rNHWXu+UL5LttkjngpAKh5b6jr/qoghEkvTOs5dpBiaZNQgAAAAAAAA== --Apple-Mail-18-889749667-- --===============0468695365== 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 --===============0468695365==-- From pcn-bounces@ietf.org Thu Feb 01 04:44:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYUD-0004Xj-Q6; Thu, 01 Feb 2007 04:44:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYUA-0004QD-Ko for pcn@ietf.org; Thu, 01 Feb 2007 04:44:06 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYTt-0006vU-IR for pcn@ietf.org; Thu, 01 Feb 2007 04:44:06 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 1 Feb 2007 10:43:48 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 10:43:48 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter, addition to scope Date: Thu, 1 Feb 2007 10:43:47 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAED@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope thread-index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igABFlM0AAALDecAAAtiiAABrkqnAAAOr1oA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Feb 2007 09:43:48.0064 (UTC) FILETIME=[78D8A600:01C745E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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 Dan, your proposal seems sound to me. My impression is the discussion=20 may have approached consensus on the following issues to get=20 chartered initially: - PCN is limited to a single DiffServ domain. - PCN aware nodes must be "on path". - PCN only standardises PCN related IP layer=20 functionalities including RSVP or NSIS signaling=20 between edge nodes. - PCN only works on "network admission control". If "Edge node" requires further definition to exclude things to=20 close to an "end system", we should add it at appropriate places.=20 "PCN related" would exclude dealing with middleboxes doing anything=20 else with packets than PCN DiffServ forwarding. Another question is, what the reaction of an ingress edge=20 node should be in case of an indicated network congestion. My=20 impression is, that with the initial charter we should just=20 define a desired behaviour in terms of an aggregate traffic=20 reduction (e.g. "stop admission new flows demanding CL=20 forwarding or bandwidth increases of admitted ones" or=20 "reduce CL traffic by x percent").=20 Future work items may be added when the WG is re-chartered after=20 having reached first aims. It may indeed be useful to think about=20 some requirements for future PCN use already now. As I didn't think=20 about particular topics in detail, I don't try to summarise which=20 requirements that could be by this mail. Regards, Ruediger |-----Original Message----- |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |Sent: Thursday, February 01, 2007 9:45 AM |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl |Cc: pcn@ietf.org |Subject: RE: [PCN] charter, addition to scope | | |Maybe we should stop for a moment and consider what layer should PCN |deal with. It looks to me that we are mixing network admission control |and call admission control in this discussion. This problem is quite |complex, and there are many scenarios that need to be taken into |consideration. Sometimes flow =3D call, sometimes call =3DNOT flow and |sometimes there is a mix on the same path. In some cases media gateways |are collocated with the edge nodes in some other cases not. Even when |flow =3D call there are two admission control layers (network and call) |that are in dependency but not identical and separate protocols run at |transport and session. I am not sure how much of all this falls under |what PCN should do.=20 | |Dan | | | | |=20 |=20 | |> -----Original Message----- |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM]=20 |> Sent: Wednesday, January 31, 2007 11:28 PM |> To: Black_David@emc.com; karagian@cs.utwente.nl |> Cc: pcn@ietf.org |> Subject: RE: [PCN] charter, addition to scope |>=20 |> To all, |> I agree that there must be a prioritization of flows=20 |> from the aggregation devices However, it's not just the media=20 |> gateway that should speak RSVP, but the edge proxy (or=20 |> firewall "proxy") as well - it is the signaling proxy at the=20 |> edge that reserves the media path. The reservation protocol=20 |> request to the network from the VoIP proxy/gateway must=20 |> reserve resources to the destination in the network.=20 |> The resource reservation request to the network by the edge=20 |> proxy/media gateway, must at the very minimum, meet the=20 |> following conditions: |> 1. it needs to specify the resources required for the IP &=20 |> ports (RTP/RTCP & bandwidth) |> for example, G.711 and G.729 voice and various MPEG-4=20 |> video codecs all have very different requirements 2. it must=20 |> be mapped to the signaling request |> for SIP, it must map the SDP for media with the=20 |> reservation flow - for example something along the lines of RFC 3524 |> while not the answer, the mapping of the media flows is a=20 |> necessary component |> It should be noted that the edge proxies/media gateways=20 |> may have a large number of flows (and ports for each =20 |> RTP/RTCP flow) from the same source IP. The request is=20 |> made for each flow or conversation 3. it must be honored by=20 |> the edge network device.=20 |> The trust boundary must be extended to the edge=20 |> proxy/media gateway for each new flow. |> This brings up the issue of security authentication of the=20 |> edge proxy/media gateway to the network |> Does this happen in EAP, NAC, or just interoperability=20 |> and certification among vendors |> If the resources are not available, then the signaling=20 |> indicates the session is not completed. For example a SIP |> CANCEL from the edge proxy |>=20 |> In addition, the network device must have priority queuing=20 |> enabled for input queues from the edge device. |> The media flows must not be subject to input buffers being=20 |> filled prior to classification |>=20 |> Thanks, |> Richard Lee |> Fidelity Investments |> Enterprise Technology and Architecture |> 617-563-3278 |>=20 |>=20 |> -----Original Message----- |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> Sent: Wednesday, January 31, 2007 2:30 PM |> To: karagian@cs.utwente.nl |> Cc: pcn@ietf.org |> Subject: RE: [PCN] charter, addition to scope |>=20 |>=20 |> Georgios wrote: |>=20 |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> > > > In the first phase of PCN work to reduce the list of=20 |> issues it was |>=20 |> > > > proposed that the WG focus on network deployment scenario where |> all=20 |> > > > nodes can be trusted and delay work on deployment=20 |> scenarios where |> some=20 |> > > > of the nodes are not trusted. |> > >=20 |> > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If |> "nodes"=20 |> > > include end systems, proxies or other entities, then I don't=20 |> > > agree we had agreement on that. |> >=20 |> > Georgios: This imposes an additional restriction on the scope=20 |> > of the charter, which has been not discussed yet. |> > >From what I remember before, during and after the PCN BOF=20 |> > there was no objection on using |> > the term edge node, that could mean something different than a edge |> router. |> > Please note that this is something different than a=20 |scenario covered |> by=20 |> > an application based deployment model. |>=20 |> It's certainly not a new restriction based on the discussion in the |> BOF engendered about whether a SIP telephone (used on some of the |> slides) was a good example. I believe the BOF conclusion was that |> a SIP telephone was a bad example. |>=20 |> IMHO, a SIP telephone causes two sets of issues wrt the=20 |proposed work: |> (1) It speaks SIP, and=20 |> (2) It's a telephone ;-) |> The first set of issues has already been discussed extensively - my |> understanding is that the SIP scenario is currently out of scope, and |> I don't care to reopen that discussion. |>=20 |> The "telephone" issues come up in two ways: |> (2a) Small number of flows may make relatively fine-grained=20 |adjustment |> on the link to the phone impossible. The PCN work prior to |> the BOF relied on the ability to make such adjustments. |> (2b) While other sorts of phones may be trusted, a SIP phone (which |> may be software-only) is definitely not trustable in general. |>=20 |> I would observe that Lars Westerberg's suggestion of a Media Gateway: |>=20 |> > I am referring telecom scenario where MGWs are connected to an |> IP-backbone. |> > In these scenarios, the admission control function is a part of the |> MGW |> > and not the routers. The IP-backbone is provisioned by a network |> > management system. |>=20 |> could avoid all of these issues: |> (1) The media gateway could speak RSVP to the network=20 |> management system, |> avoiding any need to deal with SIP here. |> (2a) A media gateway is likely to handle enough flows to be=20 |consistent |> with the fine-grained adjustment assumed by the work done to |> date. |> (2b) One can plausibly assume/require that media gateways be trusted |> with respect to the IP network. |> To the extent that one can vest "edge" functionality in a trusted |> media gateway, I see no reason to exclude that scenario. |>=20 |> Thanks, |> --David |> ---------------------------------------------------- |> David L. Black, Senior Technologist |> EMC Corporation, 176 South St., Hopkinton, MA 01748 |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> black_david@emc.com Mobile: +1 (978) 394-7754 |> ---------------------------------------------------- |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=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 Thu Feb 01 04:47:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYXI-0006nP-1f; Thu, 01 Feb 2007 04:47:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYXG-0006kT-PT for pcn@ietf.org; Thu, 01 Feb 2007 04:47:18 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYXA-0007u5-Am for pcn@ietf.org; Thu, 01 Feb 2007 04:47:18 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l119idTT000673; Thu, 1 Feb 2007 11:45:10 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:46:39 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Feb 2007 11:46:53 +0200 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFAEA@S4DE8PSAAFQ.mitte.t-com.de> References: <6439282641581441A36F7F6F83ED2ED2CBFAEA@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] charter text update Date: Thu, 1 Feb 2007 11:46:51 +0200 To: "ext Geib, Ruediger" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Feb 2007 09:46:53.0518 (UTC) FILETIME=[E762AEE0:01C745E5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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="===============1549234419==" Errors-To: pcn-bounces@ietf.org --===============1549234419== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19-889966740; protocol="application/pkcs7-signature" --Apple-Mail-19-889966740 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-1, at 9:50, ext Geib, Ruediger wrote: > I think we are rather close. Your remarks and the text you suggest > say, that the use of flow admission does not require the use > of preemption. If that statement is strong enough to ensure, that > an operator is able to activate "PCN flow admission" on a > PCN compliant router without by that automatically turning on > "PCN preemption" and no chance to disable the latter, then I'm fine. I don't understand "no chance to disable the latter", the latter being preemption - do you mean "the former?" If yes, I agree. > With other words, would your proposed reworded charter statement > mean that > > "..., and the use of one does not require..." > > expresses > > "..., and the use of one must not require..." ? > > If not, I'd be happier with the latter version. It actually says "does not require or prevent the use of the other", meaning a domain is free to use either one of the two, or any combination of the two. Lars --Apple-Mail-19-889966740 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDEwOTQ2NTFaMCMGCSqGSIb3DQEJBDEWBBQtGWoPHPV28gLK fDeoIQ/fF866fTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAkcZTH6BYkMVUvF3WukubHmGTk4so5+x56Rbn6vBJPDCESvqwy8xy XcnDtADFtHP0jVc2wsbF8lb5ona7waY4s2+9qVy56AMXQx/g78M4Oghzn3Ji29QVKmvjG10v5p0g Ja50KJ2Ri0ti6yl5utaJMgiu17tSdkvU6FepFQtv5uGj8DteY3xKSMIWZ5qMLzEGmH2O+JGimc2B f0YTjNkLyS3pil7ZWo+46ZAG4lifWHW8MaJa6NVrYur4f9iabcwZLpGILkcg4o22aFEKeJOqGjZY scoUvDYL5pdz9McTjzloRXrC727Mll7JA5UhAzWJivelSMEF2JV8CjwZJH6VPwAAAAAAAA== --Apple-Mail-19-889966740-- --===============1549234419== 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 --===============1549234419==-- From pcn-bounces@ietf.org Thu Feb 01 04:52:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYcZ-0002xc-M3; Thu, 01 Feb 2007 04:52:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYcY-0002xR-IN for pcn@ietf.org; Thu, 01 Feb 2007 04:52:46 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYcV-0001ON-9n for pcn@ietf.org; Thu, 01 Feb 2007 04:52:46 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 1 Feb 2007 10:52:42 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 10:52:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter text update Date: Thu, 1 Feb 2007 10:52:40 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAEF@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update thread-index: AcdF5f8G4nqWUDwvShiJkAI+yJDdwwAADEQA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Feb 2007 09:52:41.0372 (UTC) FILETIME=[B6B8FDC0:01C745E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Lars, |On 2007-2-1, at 9:50, ext Geib, Ruediger wrote: |> I think we are rather close. Your remarks and the text you suggest |> say, that the use of flow admission does not require the use |> of preemption. If that statement is strong enough to ensure, that |> an operator is able to activate "PCN flow admission" on a |> PCN compliant router without by that automatically turning on |> "PCN preemption" and no chance to disable the latter, then I'm fine. | |I don't understand "no chance to disable the latter", the latter =20 |being preemption - do you mean "the former?" If yes, I agree. | |> With other words, would your proposed reworded charter statement |> mean that |> |> "..., and the use of one does not require..." |> |> expresses |> |> "..., and the use of one must not require..." ? |> |> If not, I'd be happier with the latter version. | |It actually says "does not require or prevent the use of the other", =20 |meaning a domain is free to use either one of the two, or any =20 |combination of the two. Thanks for clarifying. Your proposed charter rewording is allright=20 with me. Regards, Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 05:42:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZOy-00066k-BK; Thu, 01 Feb 2007 05:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZOx-00066e-PW for pcn@ietf.org; Thu, 01 Feb 2007 05:42:47 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZOs-0000eT-Cx for pcn@ietf.org; Thu, 01 Feb 2007 05:42:47 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 10:42:39 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Feb 2007 10:42:39 +0000 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] charter text update Date: Thu, 1 Feb 2007 10:42:38 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC0@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <07F95EA7-87D4-48EE-9D93-404A0CD180D0@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdF5AHdCwc7BxtlSMy/m8xh1IfYBAACaN2g From: To: , X-OriginalArrivalTime: 01 Feb 2007 10:42:39.0092 (UTC) FILETIME=[B180C340:01C745ED] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Flow termination is fine with me.=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 01 February 2007 09:33 > To: ext Jozef Babiarz > Cc: Eardley,PL,Philip,CXR9 R; carlberg@g11.org.uk; pcn@ietf.org > Subject: Re: [PCN] charter text update >=20 > On 2007-1-31, at 19:03, ext Jozef Babiarz wrote: > > To some people *preemption*, "means the removal of a call to make room > > for a new call to be admitted". In the PCN work we have modified the > > meaning of preemption to "the removal of excess (that causes > > congestion) > > traffic at flow granularity level". > > > > I think we should think about using a different word or term so that > > people directly not involved with PCN WG do not get confused, just a > > suggestion. Personally, I like preemption, but if it will make the > > charter approval process go faster by using a different term, I'm for > > the changing it. >=20 > I had proposed "flow termination" earlier, but not gotten any > feedback on it. For me, that replacement would work. >=20 > Lars >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 05:45:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZRP-0007Hk-Op; Thu, 01 Feb 2007 05:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZRP-0007HY-D1 for pcn@ietf.org; Thu, 01 Feb 2007 05:45:19 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZRN-000114-Ur for pcn@ietf.org; Thu, 01 Feb 2007 05:45:19 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l11AiqwN029482; Thu, 1 Feb 2007 11:44:56 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <07F95EA7-87D4-48EE-9D93-404A0CD180D0@nokia.com> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC0@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] charter text update Date: Thu, 1 Feb 2007 11:45:07 +0100 Message-ID: <002301c745ee$0d294550$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdF5AHdCwc7BxtlSMy/m8xh1IfYBAACaN2gAAAT6fA= In-reply-to: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC0@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.384 () AWL,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 01 Feb 2007 11:44:56 +0100 (MET) 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 List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars "Flow termination" is also fine with me! Best Regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 1 februari 2007 11:43 > To: lars.eggert@nokia.com; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] charter text update > > Flow termination is fine with me. > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: 01 February 2007 09:33 > > To: ext Jozef Babiarz > > Cc: Eardley,PL,Philip,CXR9 R; carlberg@g11.org.uk; pcn@ietf.org > > Subject: Re: [PCN] charter text update > > > > On 2007-1-31, at 19:03, ext Jozef Babiarz wrote: > > > To some people *preemption*, "means the removal of a call to make > room > > > for a new call to be admitted". In the PCN work we have > modified the > > > meaning of preemption to "the removal of excess (that causes > > > congestion) > > > traffic at flow granularity level". > > > > > > I think we should think about using a different word or > term so that > > > people directly not involved with PCN WG do not get > confused, just a > > > suggestion. Personally, I like preemption, but if it will > make the > > > charter approval process go faster by using a different term, I'm > for > > > the changing it. > > > > I had proposed "flow termination" earlier, but not gotten > any feedback > > on it. For me, that replacement would work. > > > > Lars > > > > > _______________________________________________ > 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 Feb 01 06:59:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCaaz-00032R-GC; Thu, 01 Feb 2007 06:59:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCaay-00031G-59 for pcn@ietf.org; Thu, 01 Feb 2007 06:59:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCaaa-0007dd-GP for pcn@ietf.org; Thu, 01 Feb 2007 06:59:14 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F0BF921428; Thu, 1 Feb 2007 12:58:49 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-62-45c1d5f930a2 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CCFFC213BF; Thu, 1 Feb 2007 12:58:49 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 12:58:03 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 12:58:02 +0100 Message-ID: <45C1D5CA.9060408@ericsson.com> Date: Thu, 01 Feb 2007 12:58:02 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [PCN] charter, addition to scope References: In-Reply-To: X-OriginalArrivalTime: 01 Feb 2007 11:58:02.0694 (UTC) FILETIME=[39C7A660:01C745F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: pcn@ietf.org, "Lee, Richard FTC" 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="===============1231284958==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1231284958== Content-Type: multipart/alternative; boundary="------------070306010204070700040301" This is a multi-part message in MIME format. --------------070306010204070700040301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit commenst inline. Romascanu, Dan (Dan) wrote: > Maybe we should stop for a moment and consider what layer should PCN > deal with. It looks to me that we are mixing network admission control > and call admission control in this discussion. This problem is quite > complex, and there are many scenarios that need to be taken into > consideration. Sometimes flow = call, sometimes call =NOT flow and > sometimes there is a mix on the same path. In some cases media gateways > are collocated with the edge nodes in some other cases not. Even when > flow = call there are two admission control layers (network and call) > that are in dependency but not identical and separate protocols run at > transport and session. I am not sure how much of all this falls under > what PCN should do. > I agree that this is one of the problem with the discussion. We are mixing definitions. I tried to explain more about the scenario I though of. The scenario I am thinking of is that the MGW has some way to reduce the traffic volume (blocking calls, rejecting call, rate-adaptation....) . How MGW is the interacting with the call-control signalling and all application interaction should be out-of-scope. I would like to avoid the limitations imposed by the assumption of an edge-router such as diff.serv.edge and interactions with RSVP-state-managment. > > > Dan > > > > > > > > > -----Original Message----- > > From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > > Sent: Wednesday, January 31, 2007 11:28 PM > > To: Black_David@emc.com; karagian@cs.utwente.nl > > Cc: pcn@ietf.org > > Subject: RE: [PCN] charter, addition to scope > > > > To all, > > I agree that there must be a prioritization of flows > > from the aggregation devices However, it's not just the media > > gateway that should speak RSVP, but the edge proxy (or > > firewall "proxy") as well - it is the signaling proxy at the > > edge that reserves the media path. The reservation protocol > > request to the network from the VoIP proxy/gateway must > > reserve resources to the destination in the network. > > The resource reservation request to the network by the edge > > proxy/media gateway, must at the very minimum, meet the > > following conditions: > > 1. it needs to specify the resources required for the IP & > > ports (RTP/RTCP & bandwidth) > > for example, G.711 and G.729 voice and various MPEG-4 > > video codecs all have very different requirements 2. it must > > be mapped to the signaling request > > for SIP, it must map the SDP for media with the > > reservation flow - for example something along the lines of RFC 3524 > > while not the answer, the mapping of the media flows is a > > necessary component > > It should be noted that the edge proxies/media gateways > > may have a large number of flows (and ports for each > > RTP/RTCP flow) from the same source IP. The request is > > made for each flow or conversation 3. it must be honored by > > the edge network device. > > The trust boundary must be extended to the edge > > proxy/media gateway for each new flow. > > This brings up the issue of security authentication of the > > edge proxy/media gateway to the network > > Does this happen in EAP, NAC, or just interoperability > > and certification among vendors > > If the resources are not available, then the signaling > > indicates the session is not completed. For example a SIP > > CANCEL from the edge proxy > > > > In addition, the network device must have priority queuing > > enabled for input queues from the edge device. > > The media flows must not be subject to input buffers being > > filled prior to classification > > > > Thanks, > > Richard Lee > > Fidelity Investments > > Enterprise Technology and Architecture > > 617-563-3278 > > > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Wednesday, January 31, 2007 2:30 PM > > To: karagian@cs.utwente.nl > > Cc: pcn@ietf.org > > Subject: RE: [PCN] charter, addition to scope > > > > > > Georgios wrote: > > > > > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > > > > In the first phase of PCN work to reduce the list of > > issues it was > > > > > > > proposed that the WG focus on network deployment scenario where > > all > > > > > nodes can be trusted and delay work on deployment > > scenarios where > > some > > > > > of the nodes are not trusted. > > > > > > > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If > > "nodes" > > > > include end systems, proxies or other entities, then I don't > > > > agree we had agreement on that. > > > > > > Georgios: This imposes an additional restriction on the scope > > > of the charter, which has been not discussed yet. > > > >From what I remember before, during and after the PCN BOF > > > there was no objection on using > > > the term edge node, that could mean something different than a edge > > router. > > > Please note that this is something different than a scenario covered > > by > > > an application based deployment model. > > > > It's certainly not a new restriction based on the discussion in the > > BOF engendered about whether a SIP telephone (used on some of the > > slides) was a good example. I believe the BOF conclusion was that > > a SIP telephone was a bad example. > > > > IMHO, a SIP telephone causes two sets of issues wrt the proposed work: > > (1) It speaks SIP, and > > (2) It's a telephone ;-) > > The first set of issues has already been discussed extensively - my > > understanding is that the SIP scenario is currently out of scope, and > > I don't care to reopen that discussion. > > > > The "telephone" issues come up in two ways: > > (2a) Small number of flows may make relatively fine-grained adjustment > > on the link to the phone impossible. The PCN work prior to > > the BOF relied on the ability to make such adjustments. > > (2b) While other sorts of phones may be trusted, a SIP phone (which > > may be software-only) is definitely not trustable in general. > > > > I would observe that Lars Westerberg's suggestion of a Media Gateway: > > > > > I am referring telecom scenario where MGWs are connected to an > > IP-backbone. > > > In these scenarios, the admission control function is a part of the > > MGW > > > and not the routers. The IP-backbone is provisioned by a network > > > management system. > > > > could avoid all of these issues: > > (1) The media gateway could speak RSVP to the network > > management system, > > avoiding any need to deal with SIP here. > > (2a) A media gateway is likely to handle enough flows to be consistent > > with the fine-grained adjustment assumed by the work done to > > date. > > (2b) One can plausibly assume/require that media gateways be trusted > > with respect to the IP network. > > To the extent that one can vest "edge" functionality in a trusted > > media gateway, I see no reason to exclude that scenario. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > 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 > --------------070306010204070700040301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit commenst inline.

Romascanu, Dan (Dan) wrote:
RE: [PCN] charter, addition to scope

Maybe we should stop for a moment and consider what layer should PCN
deal with. It looks to me that we are mixing network admission control
and call admission control in this discussion. This problem is quite
complex, and there are many scenarios that need to be taken into
consideration. Sometimes flow = call, sometimes call =NOT flow and
sometimes there is a mix on the same path. In some cases media gateways
are collocated with the edge nodes in some other cases not. Even when
flow = call there are two admission control layers (network and call)
that are in dependency but not identical and separate protocols run at
transport and session. I am not sure how much of all this falls under
what PCN should do.


I agree that this is one of the problem with the discussion. We are mixing definitions.
I tried to explain more about the scenario I though of.

The scenario I am thinking of is that the MGW has some way to reduce the traffic volume (blocking calls, rejecting call,  rate-adaptation....) . How MGW is the interacting with the call-control signalling and all application interaction should be out-of-scope.

I would like to avoid the limitations imposed by the assumption of an edge-router such as diff.serv.edge and interactions with RSVP-state-managment.



Dan







> -----Original Message-----
> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM]
> Sent: Wednesday, January 31, 2007 11:28 PM
> To: Black_David@emc.com; karagian@cs.utwente.nl
> Cc: pcn@ietf.org
> Subject: RE: [PCN] charter, addition to scope
>
> To all,
>       I agree that there must be a prioritization of flows
> from the aggregation devices However, it's not just the media
> gateway that should speak RSVP, but the edge proxy (or
> firewall "proxy") as well - it is the signaling proxy at the
> edge that reserves the media path. The reservation protocol
> request to the network from the VoIP proxy/gateway must
> reserve resources to the destination in the network.
> The resource reservation request to the network by the edge
> proxy/media gateway, must at the very minimum, meet the
> following conditions:
> 1. it needs to specify the resources required for the IP &
> ports (RTP/RTCP & bandwidth)
>    for example, G.711 and G.729 voice and various MPEG-4
> video codecs all have very different requirements 2. it must
> be mapped to the signaling request
>    for SIP, it must map the SDP for media with the
> reservation flow - for example something along the lines of RFC 3524
>    while not the answer, the mapping of the media flows is a
> necessary component
>    It should be noted that the edge proxies/media gateways
> may have a large number of flows (and ports for each 
>    RTP/RTCP flow) from the same source IP. The request is
> made for each flow or conversation 3. it must be honored by
> the edge network device.
>    The trust boundary must be extended to the edge
> proxy/media gateway for each new flow.
>    This brings up the issue of security authentication of the
> edge proxy/media gateway to the network
>       Does this happen in EAP, NAC, or just interoperability
> and certification among vendors
>    If the resources are not available, then the signaling
> indicates the session is not completed. For example a SIP
>    CANCEL from the edge proxy
>
> In addition, the network device must have priority queuing
> enabled for input queues from the edge device.
> The media flows must not be subject to input buffers being
> filled prior to classification
>
> Thanks,
> Richard Lee
> Fidelity Investments
> Enterprise Technology and Architecture
> 617-563-3278
>
>
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, January 31, 2007 2:30 PM
> To: karagian@cs.utwente.nl
> Cc: pcn@ietf.org
> Subject: RE: [PCN] charter, addition to scope
>
>
> Georgios wrote:
>
> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
> > > > In the first phase of PCN work to reduce the list of
> issues it was
>
> > > > proposed that the WG focus on network deployment scenario where
> all
> > > > nodes can be trusted and delay work on deployment
> scenarios where
> some
> > > > of the nodes are not trusted.
> > >
> > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If
> "nodes"
> > > include end systems, proxies or other entities, then I don't
> > > agree we had agreement on that.
> >
> > Georgios: This imposes an additional restriction on the scope
> > of the charter, which has been not discussed yet.
> > >From what I remember before, during and after the PCN BOF
> > there was no objection on using
> > the term edge node, that could mean something different than a edge
> router.
> > Please note that this is something different than a scenario covered
> by
> > an application based deployment model.
>
> It's certainly not a new restriction based on the discussion in the
> BOF engendered about whether a SIP telephone (used on some of the
> slides) was a good example.  I believe the BOF conclusion was that
> a SIP telephone was a bad example.
>
> IMHO, a SIP telephone causes two sets of issues wrt the proposed work:
>       (1) It speaks SIP, and
>       (2) It's a telephone ;-)
> The first set of issues  has already been discussed extensively - my
> understanding is that the SIP scenario is currently out of scope, and
> I don't care to reopen that discussion.
>
> The "telephone" issues come up in two ways:
> (2a) Small number of flows may make relatively fine-grained adjustment
>       on the link to the phone impossible.  The PCN work prior to
>       the BOF relied on the ability to make such adjustments.
> (2b) While other sorts of phones may be trusted, a SIP phone (which
>       may be software-only) is definitely not trustable in general.
>
> I would observe that Lars Westerberg's suggestion of a Media Gateway:
>
> > I am referring telecom scenario where MGWs are connected to an
> IP-backbone.
> > In these scenarios, the admission control function is a part of the
> MGW
> > and not the routers. The IP-backbone is provisioned by a network
> > management system.
>
> could avoid all of these issues:
> (1) The media gateway could speak RSVP to the network
> management system,
>       avoiding any need to deal with SIP here.
> (2a) A media gateway is likely to handle enough flows to be consistent
>       with the fine-grained adjustment assumed by the work done to
> date.
> (2b) One can plausibly assume/require that media gateways be trusted
>       with respect to the IP network.
> To the extent that one can vest "edge" functionality in a trusted
> media gateway, I see no reason to exclude that scenario.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
> _______________________________________________
> 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

--------------070306010204070700040301-- --===============1231284958== 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 --===============1231284958==-- From pcn-bounces@ietf.org Thu Feb 01 07:26:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCb1Q-00036v-B1; Thu, 01 Feb 2007 07:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCb1P-00036m-6E for pcn@ietf.org; Thu, 01 Feb 2007 07:26:35 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCb1J-0007rQ-Ey for pcn@ietf.org; Thu, 01 Feb 2007 07:26:35 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 12:26:24 +0000 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, 1 Feb 2007 12:26:21 +0000 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] charter text update Date: Thu, 1 Feb 2007 12:26:20 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC1@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdAUcfdHUrPLGxpTCCsvWg+o0P3vwFnjSMg From: To: , X-OriginalArrivalTime: 01 Feb 2007 12:26:21.0309 (UTC) FILETIME=[2E3BBAD0:01C745FC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d 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 A mixture of significant comments and suggested minor re-phrasings. Best wishes phil > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 25 January 2007 07:23 > To: pcn@ietf.org > Subject: [PCN] charter text update >=20 > (I thought I had sent this several days ago, but it apparently never > made it to the list?) >=20 > Hi, >=20 > below is a modified version of the PCN charter posted to this list a > while ago. I believe it reflects the consensus after the face-to-face > and mailing list discussions in and after Montreal. >=20 > Compared to the earlier version, the major changes are: >=20 > - removal of SIP, application-based and PW deployment scenarios > - stronger language on assumptions and scope > - refactored deliverables and milestones > - name change (don't feel strongly about this) >=20 > Please send your comments to the list. >=20 > Lars >=20 > ------------------------------------------------------------------------ > -- >=20 > Flow Admission and Preemption (flap) > Chair(s): > tbd >=20 >=20 > Description of Working Group: >=20 > The Flow Admission and Preemption (FLAP) working group develops flow > admission and flow preemption mechanisms for deployment along the > edge of a network domain that protect the quality-of-service that > previously-admitted flows experience within the domain during times > of congestion. These mechanisms act on aggregated congestion and pre- > congestion signals from routers within the network domain and control > the admission of new flows into the domain or preempt previously- > admitted flows. Although designed to work together, flow admission > and flow preemption are independent mechanisms, and the use of one > does not require the use of the other. In the above para I think "region" would be better than "domain" I think you're already planning to change "signals" to "information". >=20 > The FLAP WG will specify the following components of an integrated > flow admission and preemption mechanism: I don't like "integrated". Suggest deleting "of an integrated flow admission and preemption mechanism" >=20 > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals >=20 > (2) conditions under which interior routers generate > (pre-)congestion signals >=20 > (3) encoding and transport of (pre-)congestion signals > to the appropriate ingress routers of the network domain I think you're already planning to change (3). I wonder if it's worth splitting in two (3a) encoding of (pre-)congestion information (3b) transport of (pre-)congestion information to the appropriate ingress routers of the network domain I assume in (3b) you're referring to the transport of info from the PCN-region's egress to ingress routers (eg of the congestion-level-estimate, in the language of the CL-drafts). When it's combined in the same bullet as (3a) you could read it as the transport from the router within the PCN-region to the egress router (which is just IP) >=20 > (4) edge router control mechanisms for flow admission and > preemption based on aggregated (pre-)congestion information I believe "(pre-)congestion" means "pre-congestion &/or congestion". Bringing "congestion" in scope is I think a big change compared to what we talked about at the BoF. At least I'm worried that we've had no discussion about it yet. I guess I'm uncomfortable about adding it, at least unless it's a bit clearer how wide we're looking. Is consideration of congestion marking and encoding really in scope? (ie items (2) & (3a)). Or are we just trying to allow something like the following: when calculating the amount of excess traffic, as well as counted the prmpt-marked pkts also take into account the congestion marked pkts.=20 Sorry if I've read far too much into a pair of brackets! >=20 > The WG focuses on the overall architecture and specifically the > signaling interfaces needed to realize it. Standards-track protocols > are only developed when necessary for interoperability. When > algorithms are not necessary for interoperability the WG may document > examples or provide recommended solutions, however such work should > not be done at the expense of normative specifications. One of the 'open issues' at the BoF was what level of detail the WG should specify. For instance (quoting slide 18): Implementation? ("must use virtual queue") <=3DNo! Algorithm? ("use this formula") Behaviour? ("produce this behaviour measured externally", as in DiffServ) Behaviour is good with me (if I understand it correctly - the external behaviour would have to match some formula when measured, but don't care about the internal details to produce it). >=20 >=20 > The initial scope of the FLAP WG is restricted in the following ways: suggest replacing "in the following ways" with "by making the following assumptions" and in (A) replace "develop these components for" by "these components are deployed in". (Note, this suggestion isn't supposed to change meaning, just English suggestion.) >=20 > (A) develop these components for a single DiffServ region, > where all edge and interior routers are FLAP-enabled > and mutually trust each other >=20 > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping >=20 > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective >=20 > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits I think (C) is enough and (D) is not needed.=20 >=20 > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > etc.) > is out of scope given the discussion with ken, I wonder if something like this would be better? (E) assuming that all flows are allowed to be pre-empted. Note that legal/regulatory reasons may prevent pre-emption of some flows in practice (eg emergency, PSTN), but such considerations are out of scope. >=20 > After completion of the initial phase, the FLAP WG may recharter to > develop solutions for scenarios where some of these restrictions are > not in place. It may also recharter to consider applying the FLAP > mechanisms to additional deployment scenarios (operation over > concatenated DiffServ regions, FLAP-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion signals. One example could be > flow-rate adaptation (rather than flow admission/preemption) during > times of congestion. The details of these work items are outside the > scope of the initial phase; but the WG may want to consider their=20 > requirements during the design of the initial components. Ok. Except in the BoF there was consensus to keep the following future case strongly in mind even during the initial charter, by adding the following to the charter: [anna email 17nov06] "In particular, after re-chartering it's expected that the WG will cover the case with multiple, non-trusting domains. However, even during the initial standardization phase, this case needs to be kept in mind, as the anti-cheating solution will have impact on e.g. the choice of encoding." Should something on these lines be in the charter? >=20 > However in the initial scope this mechanism is out-of-scope with the > exception that the developed solution should not, if possible, > prevent a future evolution to support this. replace "this mechanism is" by "these scenarios are" and "support this" by "support them" >=20 >=20 > Goals and Milestones: >=20 > Jul 2007 Flow Admission and Preemption Architecture > (Informational) >=20 > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region > (Informational) >=20 > Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) >=20 > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) >=20 > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed Standard) >=20 > Mar 2008 Transport from Flow Egress in a DiffServ Region of > information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) in items 2, 5 & 6 I assume "transport" refers to the extension to eg RSVP to carry the congestion-level-estimate info from egress to ingress? In item 6, I think this is too vague. Obvious possible transports are rsvp, nsis and sip. Rsvp extensions could be done in PCN WG or in TSVWG but nsis & sip extensions would presumably be done in their WGs.=20 I think the WG could - do rsvp extensions - &/or do a generic analysis of signalling extensions required (ie a doc designed to feed detailed requirements & approach to other WGs that would do the specific protocol extensions). In item 2, I think mention of transport could be deleted (what would the survey of transport choices cover?) In item 5, I think mention of transport could be deleted (not really issue related to encoding) Item 6, tweak wording as eg rsvp extension for ingress-to-egress as well as egress-to-ingress (currently former is in item 5 & latter in item 6, but would be easier to do them together) >=20 > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) > I think this probably needs to be Standards track. Especially when the PCN-region spans multiple domains. Otherwise somehow the edges would have to negotiate with each other to discover what mechanism a particular ingress was using and hence what sort of info this egress should send to it. So for ease of interoperability one normative scheme would be best. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 08:04:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbc9-0001A4-68; Thu, 01 Feb 2007 08:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbc7-00019z-S9 for pcn@ietf.org; Thu, 01 Feb 2007 08:04:31 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCbc7-0001JN-0A for pcn@ietf.org; Thu, 01 Feb 2007 08:04:31 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l11D1Nq8004208; Thu, 1 Feb 2007 15:01:38 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 15:03:56 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Feb 2007 15:04:11 +0200 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC1@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC1@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8094BC15-A48E-4595-83D1-63E7B6987AA6@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter text update Date: Thu, 1 Feb 2007 15:04:08 +0200 To: "ext philip.eardley@bt.com" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Feb 2007 13:04:11.0699 (UTC) FILETIME=[777DC030:01C74601] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 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="===============2025260454==" Errors-To: pcn-bounces@ietf.org --===============2025260454== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-27-901803937; protocol="application/pkcs7-signature" --Apple-Mail-27-901803937 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed >> The Flow Admission and Preemption (FLAP) working group develops flow >> admission and flow preemption mechanisms for deployment along the ... > In the above para I think "region" would be better than "domain" Domain is actually the correct term. A region is a "set of contiguous DS domains" according to RFC2475, which I have brought the latest charter (separate email) in line with. > I think you're already planning to change "signals" to "information". Yup. >> The FLAP WG will specify the following components of an integrated >> flow admission and preemption mechanism: > > I don't like "integrated". Suggest deleting "of an integrated flow > admission and preemption mechanism" Meanwhile changed to: The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain >> (3) encoding and transport of (pre-)congestion signals >> to the appropriate ingress routers of the network domain > > I think you're already planning to change (3). I wonder if it's worth > splitting in two > (3a) encoding of (pre-)congestion information > (3b) transport of (pre-)congestion information to the appropriate > ingress routers of the network domain > I assume in (3b) you're referring to the transport of info from the > PCN-region's egress to ingress routers (eg of the > congestion-level-estimate, in the language of the CL-drafts). When > it's > combined in the same bullet as (3a) you could read it as the transport > from the router within the PCN-region to the egress router (which is > just IP) The milestones had already split this differently, namely: Mar 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) I'm fine with making the same split here. Or do you think that factoring out the marking into a third item, with the other two being only about the transport then, would be better? >> (4) edge router control mechanisms for flow admission and >> preemption based on aggregated (pre-)congestion information > > I believe "(pre-)congestion" means "pre-congestion &/or congestion". > Bringing "congestion" in scope is I think a big change compared to > what > we talked about at the BoF. At least I'm worried that we've had no > discussion about it yet. I guess I'm uncomfortable about adding it, at > least unless it's a bit clearer how wide we're looking. Is > consideration > of congestion marking and encoding really in scope? (ie items (2) & > (3a)). Or are we just trying to allow something like the following: > when > calculating the amount of excess traffic, as well as counted the > prmpt-marked pkts also take into account the congestion marked pkts. > Sorry if I've read far too much into a pair of brackets! The reason for changing this was that a domain can go from equilibrium to full-blown congestion without being in a pre- congestion phase, for example, due to equipment failure. If PCN was only acting on pre-congestion information, would it be able to handle this case? (I might miss something here.) >> The WG focuses on the overall architecture and specifically the >> signaling interfaces needed to realize it. Standards-track protocols >> are only developed when necessary for interoperability. When >> algorithms are not necessary for interoperability the WG may document >> examples or provide recommended solutions, however such work should >> not be done at the expense of normative specifications. > > One of the 'open issues' at the BoF was what level of detail the WG > should specify. For instance (quoting slide 18): > Implementation? ("must use virtual queue") <=No! > Algorithm? ("use this formula") > Behaviour? ("produce this behaviour measured externally", as in > DiffServ) > > Behaviour is good with me (if I understand it correctly - the external > behaviour would have to match some formula when measured, but don't > care > about the internal details to produce it). I sort of assumed behavior. Any idea for an appropriate phrasing? >> (E) flows may have different precedence, but the applicability >> of these mechanisms for emergency use (911, GETS, WPS, MLPP, >> etc.) >> is out of scope > > given the discussion with ken, I wonder if something like this > would be > better? > (E) assuming that all flows are allowed to be pre-empted. Note that > legal/regulatory reasons may prevent pre-emption of some flows in > practice (eg emergency, PSTN), but such considerations are out of > scope. Not sure. Ken? >> After completion of the initial phase, the FLAP WG may recharter to >> develop solutions for scenarios where some of these restrictions are >> not in place. It may also recharter to consider applying the FLAP >> mechanisms to additional deployment scenarios (operation over >> concatenated DiffServ regions, FLAP-aware application mechanisms, >> etc.). The WG may also consider to investigate additional response >> mechanisms that act on (pre-)congestion signals. One example could be >> flow-rate adaptation (rather than flow admission/preemption) during >> times of congestion. The details of these work items are outside the >> scope of the initial phase; but the WG may want to consider their >> requirements during the design of the initial components. > > Ok. Except in the BoF there was consensus to keep the following future > case strongly in mind even during the initial charter, by adding the > following to the charter: > [anna email 17nov06] "In particular, after re-chartering it's expected > that the WG will cover the case with multiple, non-trusting domains. > However, even during the initial standardization phase, this case > needs > to be kept in mind, as the anti-cheating solution will have impact on > e.g. the choice of encoding." > Should something on these lines be in the charter? The last sentence of that paragraph means to say that, but maybe isn't strong enough for your liking? >> However in the initial scope this mechanism is out-of-scope with the >> exception that the developed solution should not, if possible, >> prevent a future evolution to support this. > > replace "this mechanism is" by "these scenarios are" and "support > this" > by "support them" I just removed this sentence. >> Jul 2007 Flow Admission and Preemption Architecture >> (Informational) >> >> Jul 2007 Survey of Encoding and Transport Choices of >> (Pre-)Congestion Signals within a DiffServ Region >> (Informational) >> >> Nov 2007 Flow Admission and Preemption within a DiffServ >> Region (Informational) >> >> Nov 2007 (Pre-)Congestion Detection within a DiffServ Region >> (Proposed Standard) >> >> Mar 2008 Encoding and Transport of (Pre-)Congestion Signals >> within a DiffServ Region to Flow Egress (Proposed > Standard) >> >> Mar 2008 Transport from Flow Egress in a DiffServ Region of >> information >> (possibly aggregated) or Admission/Preemption Signals to >> DiffServ edge devices. (Proposed Standard) > > in items 2, 5 & 6 I assume "transport" refers to the extension to eg > RSVP to carry the congestion-level-estimate info from egress to > ingress? Yes. And from interior router to egress. > In item 6, I think this is too vague. Items 5&6 now read: Mar 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) > Obvious possible transports are > rsvp, nsis and sip. Rsvp extensions could be done in PCN WG or in > TSVWG > but nsis & sip extensions would presumably be done in their WGs. > I think the WG could > - do rsvp extensions > - &/or do a generic analysis of signalling extensions required (ie > a doc > designed to feed detailed requirements & approach to other WGs that > would do the specific protocol extensions). Interaction with other WGs is actually an important thing missing from the charter that I will add. > In item 2, I think mention of transport could be deleted (what > would the > survey of transport choices cover?) How to get the information from the marker to the egress, and then to the ingress. > In item 5, I think mention of transport could be deleted (not really > issue related to encoding) With some encoding schemes, the transport is implicit (e.g., using an IP header bit). For others (NSIS, RSVP), something more needs to be said. > Item 6, tweak wording as eg rsvp extension for ingress-to-egress as > well > as egress-to-ingress (currently former is in item 5 & latter in > item 6, > but would be easier to do them together) I'm not sure if I want to limit this to an RSVP extension in the charter text already. The idea is that item 2 would provide guidance to the WG on what to chose for items 5 and 6. >> Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms >> (Informational) >> > I think this probably needs to be Standards track. Especially when the > PCN-region spans multiple domains. Otherwise somehow the edges would > have to negotiate with each other to discover what mechanism a > particular ingress was using and hence what sort of info this egress > should send to it. So for ease of interoperability one normative > scheme > would be best. We've gone back and forth on this. I was of the same opinion originally, but several people have stated that it wouldn't need to be PS. But I think this isn't critical for now: If the WG decides that it needs to be PS for interoperability, it can be changed later. Lars --Apple-Mail-27-901803937 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDExMzA0MDhaMCMGCSqGSIb3DQEJBDEWBBRW4doWKBPCRj7z LzDoTELnUaFXkzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA2QG7rcP06mTkuMuKQbUREDKjdXd4fEmXcy79uJgv6Rw+aZqQZI8q I015cRHmABU5TYLpQHIgSimCrM2R/9T676rroPMD3LrhE24ilbdaNCGbVExhDyrbQgujeAz9U9Lw 9+Mw/oSKUBs3Z4hqKbwphbBmwBbcvE7AnWnvV/GfNsnhCEZ1YWSKNJwRVfl8P74D+aQbIURT4PMC j9ImzJujalNWpNoZMY8HIIofYqmKAuQQ2AyG7qkzlwrIiY0HKRB44Cpj+6w/i6tqiTGPcI4P3b8t TWN6SsgLeZNjChpBkqUizSubUHWtFPzbXp/OpxQt2M8rFsQK9HrsWh5X/a8mYAAAAAAAAA== --Apple-Mail-27-901803937-- --===============2025260454== 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 --===============2025260454==-- From pcn-bounces@ietf.org Thu Feb 01 08:31:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCc1o-0007yu-BZ; Thu, 01 Feb 2007 08:31:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCc1n-0007tD-0r for pcn@ietf.org; Thu, 01 Feb 2007 08:31:03 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCc1k-0001T1-76 for pcn@ietf.org; Thu, 01 Feb 2007 08:31:02 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 1 Feb 2007 14:30:53 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 14:30:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter text update Date: Thu, 1 Feb 2007 14:30:52 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAF3@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC1@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update thread-index: AcdAUcfdHUrPLGxpTCCsvWg+o0P3vwFnjSMgAAQ5dsA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Feb 2007 13:30:53.0237 (UTC) FILETIME=[32150E50:01C74605] X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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 suggestions are good. Some questions, remarks and personal points of view: - we should clarify whether "congestion" means packet losses, pre-emption=20 marking or just a different interpretation of the rate packets marked=20 as "pre-congested" (assuming a single pre-congestion mark for=20 admission control and pre-emption decision and a rate threshold to=20 decide on the interpretation). I think we should deal with packets marked by a PCN mechanism only and adapt our terminology (I've used "congestion" too, I admit). - (D) which you suggest to be deleted refers to ingress/egress aggregation.=20 The ingress/egress traffic evaluation by the egress gateway is important.=20 I just wanted to mention, but I don't have a strong view whether that=20 should be mentioned by the charter. - your proposal to reword (E) may re-open the pre-emprtion debate. The prior text seems to say that PCN delivers a=20 pre-emption trigger but doesn't demand interpretation. Your proposed=20 text seems to say the pre-emption is active and it's out of scope of=20 PCN to worry about deactivation.=20 If I understood that right, I prefer the original text. - I agree that "transport of admission/preemption information" should=20 be clarified the way you propose. - Trusted DiffServ region is allright with me to. If you can't trust=20 another domain, then the region is just your own domain. I agree to all of your proposals which I didn't comment here. Regards, Ruediger |-----Original Message----- |From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] |Sent: Thursday, February 01, 2007 1:26 PM |To: lars.eggert@nokia.com; pcn@ietf.org |Subject: RE: [PCN] charter text update | | |A mixture of significant comments and suggested minor re-phrasings. |Best wishes |phil | |> -----Original Message----- |> From: Lars Eggert [mailto:lars.eggert@nokia.com] |> Sent: 25 January 2007 07:23 |> To: pcn@ietf.org |> Subject: [PCN] charter text update |>=20 |> (I thought I had sent this several days ago, but it apparently never |> made it to the list?) |>=20 |> Hi, |>=20 |> below is a modified version of the PCN charter posted to this list a |> while ago. I believe it reflects the consensus after the face-to-face |> and mailing list discussions in and after Montreal. |>=20 |> Compared to the earlier version, the major changes are: |>=20 |> - removal of SIP, application-based and PW deployment scenarios |> - stronger language on assumptions and scope |> - refactored deliverables and milestones |> - name change (don't feel strongly about this) |>=20 |> Please send your comments to the list. |>=20 |> Lars |>=20 |> |--------------------------------------------------------------- |--------- |> -- |>=20 |> Flow Admission and Preemption (flap) |> Chair(s): |> tbd |>=20 |>=20 |> Description of Working Group: |>=20 |> The Flow Admission and Preemption (FLAP) working group develops flow |> admission and flow preemption mechanisms for deployment along the |> edge of a network domain that protect the quality-of-service that |> previously-admitted flows experience within the domain during times |> of congestion. These mechanisms act on aggregated congestion and pre- |> congestion signals from routers within the network domain and control |> the admission of new flows into the domain or preempt previously- |> admitted flows. Although designed to work together, flow admission |> and flow preemption are independent mechanisms, and the use of one |> does not require the use of the other. | |In the above para I think "region" would be better than "domain" | |I think you're already planning to change "signals" to "information". | |>=20 |> The FLAP WG will specify the following components of an integrated |> flow admission and preemption mechanism: | |I don't like "integrated". Suggest deleting "of an integrated flow |admission and preemption mechanism" | |>=20 |> (1) a general architecture for flow admission and=20 |preemption based |> on aggregated (pre-)congestion signals |>=20 |> (2) conditions under which interior routers generate |> (pre-)congestion signals |>=20 |> (3) encoding and transport of (pre-)congestion signals |> to the appropriate ingress routers of the network domain | |I think you're already planning to change (3). I wonder if it's worth |splitting in two |(3a) encoding of (pre-)congestion information |(3b) transport of (pre-)congestion information to the appropriate |ingress routers of the network domain |I assume in (3b) you're referring to the transport of info from the |PCN-region's egress to ingress routers (eg of the |congestion-level-estimate, in the language of the CL-drafts). When it's |combined in the same bullet as (3a) you could read it as the transport |from the router within the PCN-region to the egress router (which is |just IP) | |>=20 |> (4) edge router control mechanisms for flow admission and |> preemption based on aggregated (pre-)congestion information | |I believe "(pre-)congestion" means "pre-congestion &/or congestion". |Bringing "congestion" in scope is I think a big change compared to what |we talked about at the BoF. At least I'm worried that we've had no |discussion about it yet. I guess I'm uncomfortable about adding it, at |least unless it's a bit clearer how wide we're looking. Is=20 |consideration |of congestion marking and encoding really in scope? (ie items (2) & |(3a)). Or are we just trying to allow something like the=20 |following: when |calculating the amount of excess traffic, as well as counted the |prmpt-marked pkts also take into account the congestion marked pkts.=20 |Sorry if I've read far too much into a pair of brackets! | |>=20 |> The WG focuses on the overall architecture and specifically the |> signaling interfaces needed to realize it. Standards-track protocols |> are only developed when necessary for interoperability. When |> algorithms are not necessary for interoperability the WG may document |> examples or provide recommended solutions, however such work should |> not be done at the expense of normative specifications. | |One of the 'open issues' at the BoF was what level of detail the WG |should specify. For instance (quoting slide 18): |Implementation? ("must use virtual queue") <=3DNo! |Algorithm? ("use this formula") |Behaviour? ("produce this behaviour measured externally", as in |DiffServ) | |Behaviour is good with me (if I understand it correctly - the external |behaviour would have to match some formula when measured, but=20 |don't care |about the internal details to produce it). | |>=20 |>=20 |> The initial scope of the FLAP WG is restricted in the following ways: | |suggest replacing "in the following ways" with "by making the following |assumptions" and in (A) replace "develop these components for"=20 |by "these |components are deployed in". (Note, this suggestion isn't supposed to |change meaning, just English suggestion.) | |>=20 |> (A) develop these components for a single DiffServ region, |> where all edge and interior routers are FLAP-enabled |> and mutually trust each other |>=20 |> (B) all flows handled by these mechanisms are inelastic and |> constrained to a known maximum rate through policing or |shaping |>=20 |> (C) the number of flows across any potential aggregation |bottleneck |> is sufficiently large for stateless, statistical mechanisms |> to be |> effective |>=20 |> (D) aggregation occurs either on links or ingress/egress pairs; |> mechanisms must further define relevant limits | |I think (C) is enough and (D) is not needed.=20 | |>=20 |> (E) flows may have different precedence, but the applicability |> of these mechanisms for emergency use (911, GETS, WPS, MLPP, |> etc.) |> is out of scope | |given the discussion with ken, I wonder if something like this would be |better? |(E) assuming that all flows are allowed to be pre-empted. Note that |legal/regulatory reasons may prevent pre-emption of some flows in |practice (eg emergency, PSTN), but such considerations are out=20 |of scope. | | |>=20 |> After completion of the initial phase, the FLAP WG may recharter to |> develop solutions for scenarios where some of these restrictions are |> not in place. It may also recharter to consider applying the FLAP |> mechanisms to additional deployment scenarios (operation over |> concatenated DiffServ regions, FLAP-aware application mechanisms, |> etc.). The WG may also consider to investigate additional response |> mechanisms that act on (pre-)congestion signals. One example could be |> flow-rate adaptation (rather than flow admission/preemption) during |> times of congestion. The details of these work items are outside the |> scope of the initial phase; but the WG may want to consider their=20 |> requirements during the design of the initial components. | |Ok. Except in the BoF there was consensus to keep the following future |case strongly in mind even during the initial charter, by adding the |following to the charter: |[anna email 17nov06] "In particular, after re-chartering it's expected |that the WG will cover the case with multiple, non-trusting domains. |However, even during the initial standardization phase, this case needs |to be kept in mind, as the anti-cheating solution will have impact on |e.g. the choice of encoding." |Should something on these lines be in the charter? | |>=20 |> However in the initial scope this mechanism is out-of-scope with the |> exception that the developed solution should not, if possible, |> prevent a future evolution to support this. | |replace "this mechanism is" by "these scenarios are" and "support this" |by "support them" |>=20 |>=20 |> Goals and Milestones: |>=20 |> Jul 2007 Flow Admission and Preemption Architecture |> (Informational) |>=20 |> Jul 2007 Survey of Encoding and Transport Choices of |> (Pre-)Congestion Signals within a DiffServ Region |> (Informational) |>=20 |> Nov 2007 Flow Admission and Preemption within a DiffServ |> Region (Informational) |>=20 |> Nov 2007 (Pre-)Congestion Detection within a DiffServ Region |> (Proposed Standard) |>=20 |> Mar 2008 Encoding and Transport of (Pre-)Congestion Signals |> within a DiffServ Region to Flow Egress (Proposed |Standard) |>=20 |> Mar 2008 Transport from Flow Egress in a DiffServ Region of |> information |> (possibly aggregated) or Admission/Preemption Signals to |> DiffServ edge devices. (Proposed Standard) | |in items 2, 5 & 6 I assume "transport" refers to the extension to eg |RSVP to carry the congestion-level-estimate info from egress=20 |to ingress? |In item 6, I think this is too vague. Obvious possible transports are |rsvp, nsis and sip. Rsvp extensions could be done in PCN WG or in TSVWG |but nsis & sip extensions would presumably be done in their WGs.=20 |I think the WG could |- do rsvp extensions |- &/or do a generic analysis of signalling extensions required=20 |(ie a doc |designed to feed detailed requirements & approach to other WGs that |would do the specific protocol extensions). | |In item 2, I think mention of transport could be deleted (what=20 |would the |survey of transport choices cover?) |In item 5, I think mention of transport could be deleted (not really |issue related to encoding) |Item 6, tweak wording as eg rsvp extension for=20 |ingress-to-egress as well |as egress-to-ingress (currently former is in item 5 & latter in item 6, |but would be easier to do them together) | |>=20 |> Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms |> (Informational) |> |I think this probably needs to be Standards track. Especially when the |PCN-region spans multiple domains. Otherwise somehow the edges would |have to negotiate with each other to discover what mechanism a |particular ingress was using and hence what sort of info this egress |should send to it. So for ease of interoperability one normative scheme |would be best. | | |_______________________________________________ |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 Feb 01 08:40:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCcBL-0003JN-2o; Thu, 01 Feb 2007 08:40:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCcBJ-0003I9-2g for pcn@ietf.org; Thu, 01 Feb 2007 08:40:53 -0500 Received: from smtp.hosts.co.uk ([85.233.160.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCcBG-0004sb-QO for pcn@ietf.org; Thu, 01 Feb 2007 08:40:53 -0500 Received: from [69.255.82.176] (helo=[192.168.1.2]) by smtp.hosts.co.uk with esmtpa (Exim 4.63) (envelope-from ) id 1HCcBF-0003Rx-8d; Thu, 01 Feb 2007 13:40:49 +0000 In-Reply-To: <8094BC15-A48E-4595-83D1-63E7B6987AA6@nokia.com> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEC1@E03MVZ1-UKDY.domain1.systemhost.net> <8094BC15-A48E-4595-83D1-63E7B6987AA6@nokia.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] charter text update Date: Thu, 1 Feb 2007 08:40:47 -0500 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) 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 >>> (E) flows may have different precedence, but the applicability >>> of these mechanisms for emergency use (911, GETS, WPS, MLPP, >>> etc.) >>> is out of scope >> >> given the discussion with ken, I wonder if something like this >> would be >> better? >> (E) assuming that all flows are allowed to be pre-empted. Note that >> legal/regulatory reasons may prevent pre-emption of some flows in >> practice (eg emergency, PSTN), but such considerations are out of >> scope. > > Not sure. Ken? the original was fine by me, and i think the proposed change loses part of the point that was being in the original. And I'm kind of in agreement with what Ruediger just stated. However, if something needs to be stated about pre-emption, perhaps something like this may help. (F) deployment of pre-emption as a (re)action may be subject to legal/ regulatory conditions. But such conditions are out of scope. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 08:44:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCcF8-0002WS-JE; Thu, 01 Feb 2007 08:44:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCcF8-0002WJ-92 for pcn@ietf.org; Thu, 01 Feb 2007 08:44:50 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCcF6-0005sv-R5 for pcn@ietf.org; Thu, 01 Feb 2007 08:44:50 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 1 Feb 2007 14:44:45 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 14:44:45 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter text update Date: Thu, 1 Feb 2007 14:44:45 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAF6@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update thread-index: AcdGBqGMP0qYnZYET4aIPl8lfjZHHQAADwwQ From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 01 Feb 2007 13:44:45.0580 (UTC) FILETIME=[223284C0:01C74607] 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 List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Leaving (E) like suggested by Lars and adding (F) is allright with me too. Regards, Ruediger |-----Original Message----- |From: ken carlberg [mailto:carlberg@g11.org.uk] |Sent: Thursday, February 01, 2007 2:41 PM |To: Lars Eggert |Cc: pcn@ietf.org |Subject: Re: [PCN] charter text update | | |>>> (E) flows may have different precedence, but the applicability |>>> of these mechanisms for emergency use (911, GETS,=20 |WPS, MLPP, |>>> etc.) |>>> is out of scope |>> |>> given the discussion with ken, I wonder if something like this =20 |>> would be |>> better? |>> (E) assuming that all flows are allowed to be pre-empted. Note that |>> legal/regulatory reasons may prevent pre-emption of some flows in |>> practice (eg emergency, PSTN), but such considerations are out of =20 |>> scope. |> |> Not sure. Ken? | |the original was fine by me, and i think the proposed change loses =20 |part of the point that was being in the original. And I'm kind of in =20 |agreement with what Ruediger just stated. However, if something =20 |needs to be stated about pre-emption, perhaps something like this may =20 |help. | |(F) deployment of pre-emption as a (re)action may be subject to legal/=20 |regulatory conditions. But such conditions are out of scope. | |-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 Thu Feb 01 10:22:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdlO-0000Ng-Vn; Thu, 01 Feb 2007 10:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdlN-0000I7-RQ for pcn@ietf.org; Thu, 01 Feb 2007 10:22:13 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdlM-0005Ok-IJ for pcn@ietf.org; Thu, 01 Feb 2007 10:22:13 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l11FMAe00790; Thu, 1 Feb 2007 10:22:10 -0500 (EST) 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, 1 Feb 2007 10:22:10 -0500 Message-Id: <6.2.5.6.0.20070201101329.032ba0e8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Feb 2007 10:22:09 -0500 To: Lars Eggert From: "Kwok-Ho Chan" Subject: Re: [PCN] 2nd charter text update In-Reply-To: <31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com> References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> <6.2.5.6.0.20070131163950.03af6318@nortel.com> <31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Feb 2007 15:22:10.0035 (UTC) FILETIME=[BDC39430:01C74614] X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Please see my comments enclosed by KHC_START> and KHC_END>. Thank you very much for handling the "funnel" (many of us giving you comments)! -- Kwok -- At 04:43 AM 2/1/2007, Lars Eggert wrote: >On 2007-2-1, at 1:50, ext Kwok-Ho Chan wrote: >>At 04:23 AM 1/31/2007, Lars Eggert wrote: >>>Talking about "nodes" and "paths" leaves the door open for other work >>>than the routers-within-a-single-DiffServ-domain model that we want >>>to focus the work on initially. >> >>KHC_START> >>The use of "IP packet data path" is just to make the proposed charter >>more concise. May be it becomes too wordy in the itemized sentences, >>hence it will be OK for me if they are removed from the itemized >>sentences. >>But I think "These mechanisms operate on the IP packet data path" >>at the top >>is helpful to make the propose charter more clear and concise. > >But they only operate on a subset of the end-to-end path, namely, the >part that falls into the PCN-enabled DiffServ domain. KHC_START> Agree. The words "IP packet data path" is intended to indicate the behaviors and mechanisms we are trying to standardize are "on-path" behaviors and mechanisms. I am not trying to say anything about subset of the end-to-end path or end-to-end path. If you feel my intend is not necessary, lets give it a try on not having those words. Or you can add additional clarification that "IP packet data path of the PCN-enabled DiffServ domain/region". KHC_END> >>On the topic of using the words "nodes" and/or "routers". >>I don't have a good understanding of why the word "router" must be >>there. >>Many of today's "routers" perform "switching" instead of "routing". >>And many of today's "routers" does more than just "routing". >>Is a "blade-center" a "router"? Part of it is a "router"? >>And does the output (behavior, mechanism documentations) of this WG >>need to be >>implemented on a specific hardware implementation? On a specific >>physical box? >>IMHO, the proposed-standards documents produced by this WG should >>indicate >>behaviors and functionality. To promote and assure inter-operability. >>IMHO, the proposed-standards documents produced by this WG should >>NOT dictate >>how the implementation is done, or where (which and what kind of >>square/round physical box) >>the implementation must be done at. > >Since the initial goal is to PCN-enable a DiffServ region, I agree >that it would remove confusion if the charter used the terms from >RFC2475. I'll take a stab at the appropriate rephrasings. KHC_START> OK, lets give it a try. Thanks! KHC_END> >>"(3) encoding and transport of (pre-)congestion signals (replaced >>with information) >>to the appropriate ingress routers of the network domain" >>confusing because I believe we want to specify in a standards track >>document >>how the (pre-)congestion information is encoded (the bits and bytes >>detail) in >>some IP header field (ECN, DSCP, etc). > >This has already been rephrased in my working copy. KHC_START> Thanks! KHC_END> >Lars > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 01 13:03:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgHm-0001H9-Q8; Thu, 01 Feb 2007 13:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgHl-0001GO-5h for pcn@ietf.org; Thu, 01 Feb 2007 13:03:49 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgHh-0002vE-Lk for pcn@ietf.org; Thu, 01 Feb 2007 13:03:49 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCS00F72Q68E1@lhrga01-in.huawei.com> for pcn@ietf.org; Thu, 01 Feb 2007 18:03:45 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.116.127]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCS00APHQ6770@lhrga01-in.huawei.com> for pcn@ietf.org; Thu, 01 Feb 2007 18:03:44 +0000 (GMT) Date: Thu, 01 Feb 2007 19:03:37 +0100 From: Tina TSOU Subject: Re: [PCN] 2nd charter text update To: Lars Eggert , Kwok-Ho Chan Message-id: <00ed01c7462b$4c6d5480$7f74a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> <6.2.5.6.0.20070131163950.03af6318@nortel.com> <31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com> <6.2.5.6.0.20070201101329.032ba0e8@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Kwok-Ho, See in line(: ----- Original Message ----- From: "Kwok-Ho Chan" To: "Lars Eggert" Cc: Sent: Thursday, February 01, 2007 4:22 PM Subject: Re: [PCN] 2nd charter text update > Please see my comments enclosed by KHC_START> and KHC_END>. > Thank you very much for handling the "funnel" (many of us giving you > comments)! > -- Kwok -- > > At 04:43 AM 2/1/2007, Lars Eggert wrote: >>On 2007-2-1, at 1:50, ext Kwok-Ho Chan wrote: >>>At 04:23 AM 1/31/2007, Lars Eggert wrote: >>>>Talking about "nodes" and "paths" leaves the door open for other work >>>>than the routers-within-a-single-DiffServ-domain model that we want >>>>to focus the work on initially. >>> >>>KHC_START> >>>The use of "IP packet data path" is just to make the proposed charter >>>more concise. May be it becomes too wordy in the itemized sentences, >>>hence it will be OK for me if they are removed from the itemized >>>sentences. >>>But I think "These mechanisms operate on the IP packet data path" >>>at the top >>>is helpful to make the propose charter more clear and concise. >> >>But they only operate on a subset of the end-to-end path, namely, the >>part that falls into the PCN-enabled DiffServ domain. > > KHC_START> > Agree. The words "IP packet data path" is intended to indicate the > behaviors and > mechanisms we are trying to standardize are "on-path" behaviors and > mechanisms. > I am not trying to say anything about subset of the end-to-end path or > end-to-end path. > If you feel my intend is not necessary, lets give it a try on not having > those words. > Or you can add additional clarification that "IP packet data path of the > PCN-enabled > DiffServ domain/region". > KHC_END> If we still only focus on routers-within-a-single-DiffServ-domain, "IP packet data path of the PCN-enabled DiffServ domain/region" does not reflect this focus. > > >>>On the topic of using the words "nodes" and/or "routers". >>>I don't have a good understanding of why the word "router" must be >>>there. >>>Many of today's "routers" perform "switching" instead of "routing". >>>And many of today's "routers" does more than just "routing". >>>Is a "blade-center" a "router"? Part of it is a "router"? >>>And does the output (behavior, mechanism documentations) of this WG >>>need to be >>>implemented on a specific hardware implementation? On a specific >>>physical box? >>>IMHO, the proposed-standards documents produced by this WG should >>>indicate >>>behaviors and functionality. To promote and assure inter-operability. >>>IMHO, the proposed-standards documents produced by this WG should >>>NOT dictate >>>how the implementation is done, or where (which and what kind of >>>square/round physical box) >>>the implementation must be done at. >> >>Since the initial goal is to PCN-enable a DiffServ region, I agree >>that it would remove confusion if the charter used the terms from >>RFC2475. I'll take a stab at the appropriate rephrasings. > > KHC_START> > OK, lets give it a try. Thanks! > KHC_END> > > >>>"(3) encoding and transport of (pre-)congestion signals (replaced >>>with information) >>>to the appropriate ingress routers of the network domain" >>>confusing because I believe we want to specify in a standards track >>>document >>>how the (pre-)congestion information is encoded (the bits and bytes >>>detail) in >>>some IP header field (ECN, DSCP, etc). >> >>This has already been rephrased in my working copy. > > KHC_START> > Thanks! > KHC_END> > > >>Lars >> >> >> >> > > > _______________________________________________ > 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 Feb 01 13:16:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgU3-0006Dk-OZ; Thu, 01 Feb 2007 13:16:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgU1-0006Cq-TX for pcn@ietf.org; Thu, 01 Feb 2007 13:16:29 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgTy-0005Qn-4E for pcn@ietf.org; Thu, 01 Feb 2007 13:16:29 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l11IGOgk023044 for ; Thu, 1 Feb 2007 13:16:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] charter, addition to scope Date: Thu, 1 Feb 2007 13:16:23 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igABFlM0AAALDecAAAtiiAABrkqnAAAOr1oAANL60g References: <6439282641581441A36F7F6F83ED2ED2CBFAED@S4DE8PSAAFQ.mitte.t-com.de> From: "Rodrig, Benny \(Benny\)" To: "Geib, Ruediger" , "Romascanu, Dan \(Dan\)" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f 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 What I think you mean, and the admission control that PCN deals with, better not be described as "network admission control" since that term often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control) refers to admission based on the identity of the sender, which is probably out of scope for PCN. The flow admission control in PCN scope is based on considerations related to network status i.e. pre-congestion.=20 The PCN flow admission control can be part of a call admission control solution, if it interacts with other mechanisms such as for example with Int-Serv outside the PCN domain and/or with SIP QoS pre-conditions. Such interactions, or assumptions about them, may not be in the scope of PCN. Benny=20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: Thursday, February 01, 2007 4:44 AM To: Romascanu, Dan (Dan) Cc: pcn@ietf.org Subject: RE: [PCN] charter, addition to scope Hi Dan, your proposal seems sound to me. My impression is the discussion may have approached consensus on the following issues to get chartered initially: - PCN is limited to a single DiffServ domain. - PCN aware nodes must be "on path". - PCN only standardises PCN related IP layer functionalities including RSVP or NSIS signaling between edge nodes. - PCN only works on "network admission control". If "Edge node" requires further definition to exclude things to close to an "end system", we should add it at appropriate places.=20 "PCN related" would exclude dealing with middleboxes doing anything else with packets than PCN DiffServ forwarding. Another question is, what the reaction of an ingress edge node should be in case of an indicated network congestion. My impression is, that with the initial charter we should just define a desired behaviour in terms of an aggregate traffic reduction (e.g. "stop admission new flows demanding CL forwarding or bandwidth increases of admitted ones" or "reduce CL traffic by x percent").=20 Future work items may be added when the WG is re-chartered after having reached first aims. It may indeed be useful to think about some requirements for future PCN use already now. As I didn't think about particular topics in detail, I don't try to summarise which requirements that could be by this mail. Regards, Ruediger |-----Original Message----- |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |Sent: Thursday, February 01, 2007 9:45 AM |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl |Cc: pcn@ietf.org |Subject: RE: [PCN] charter, addition to scope | | |Maybe we should stop for a moment and consider what layer should PCN=20 |deal with. It looks to me that we are mixing network admission control=20 |and call admission control in this discussion. This problem is quite=20 |complex, and there are many scenarios that need to be taken into=20 |consideration. Sometimes flow =3D call, sometimes call =3DNOT flow and=20 |sometimes there is a mix on the same path. In some cases media gateways |are collocated with the edge nodes in some other cases not. Even when=20 |flow =3D call there are two admission control layers (network and call) = |that are in dependency but not identical and separate protocols run at=20 |transport and session. I am not sure how much of all this falls under=20 |what PCN should do. | |Dan | | | | |=20 |=20 | |> -----Original Message----- |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |> Sent: Wednesday, January 31, 2007 11:28 PM |> To: Black_David@emc.com; karagian@cs.utwente.nl |> Cc: pcn@ietf.org |> Subject: RE: [PCN] charter, addition to scope |>=20 |> To all, |> I agree that there must be a prioritization of flows from the=20 |> aggregation devices However, it's not just the media gateway that=20 |> should speak RSVP, but the edge proxy (or firewall "proxy") as well - |> it is the signaling proxy at the edge that reserves the media path.=20 |> The reservation protocol request to the network from the VoIP=20 |> proxy/gateway must reserve resources to the destination in the=20 |> network. |> The resource reservation request to the network by the edge=20 |> proxy/media gateway, must at the very minimum, meet the following=20 |> conditions: |> 1. it needs to specify the resources required for the IP & ports=20 |> (RTP/RTCP & bandwidth) |> for example, G.711 and G.729 voice and various MPEG-4 video codecs |> all have very different requirements 2. it must be mapped to the=20 |> signaling request |> for SIP, it must map the SDP for media with the reservation flow - |> for example something along the lines of RFC 3524 |> while not the answer, the mapping of the media flows is a=20 |> necessary component |> It should be noted that the edge proxies/media gateways may have a |> large number of flows (and ports for each |> RTP/RTCP flow) from the same source IP. The request is made for=20 |> each flow or conversation 3. it must be honored by the edge network=20 |> device. |> The trust boundary must be extended to the edge proxy/media=20 |> gateway for each new flow. |> This brings up the issue of security authentication of the edge=20 |> proxy/media gateway to the network |> Does this happen in EAP, NAC, or just interoperability and=20 |> certification among vendors |> If the resources are not available, then the signaling indicates=20 |> the session is not completed. For example a SIP |> CANCEL from the edge proxy |>=20 |> In addition, the network device must have priority queuing enabled=20 |> for input queues from the edge device. |> The media flows must not be subject to input buffers being filled=20 |> prior to classification |>=20 |> Thanks, |> Richard Lee |> Fidelity Investments |> Enterprise Technology and Architecture |> 617-563-3278 |>=20 |>=20 |> -----Original Message----- |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> Sent: Wednesday, January 31, 2007 2:30 PM |> To: karagian@cs.utwente.nl |> Cc: pcn@ietf.org |> Subject: RE: [PCN] charter, addition to scope |>=20 |>=20 |> Georgios wrote: |>=20 |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> > > > In the first phase of PCN work to reduce the list of |> issues it was |>=20 |> > > > proposed that the WG focus on network deployment scenario where |> all |> > > > nodes can be trusted and delay work on deployment |> scenarios where |> some |> > > > of the nodes are not trusted. |> > >=20 |> > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If |> "nodes"=20 |> > > include end systems, proxies or other entities, then I don't=20 |> > > agree we had agreement on that. |> >=20 |> > Georgios: This imposes an additional restriction on the scope of=20 |> > the charter, which has been not discussed yet. |> > >From what I remember before, during and after the PCN BOF |> > there was no objection on using |> > the term edge node, that could mean something different than a edge |> router. |> > Please note that this is something different than a |scenario covered |> by |> > an application based deployment model. |>=20 |> It's certainly not a new restriction based on the discussion in the=20 |> BOF engendered about whether a SIP telephone (used on some of the |> slides) was a good example. I believe the BOF conclusion was that a=20 |> SIP telephone was a bad example. |>=20 |> IMHO, a SIP telephone causes two sets of issues wrt the |proposed work: |> (1) It speaks SIP, and=20 |> (2) It's a telephone ;-) |> The first set of issues has already been discussed extensively - my=20 |> understanding is that the SIP scenario is currently out of scope, and |> I don't care to reopen that discussion. |>=20 |> The "telephone" issues come up in two ways: |> (2a) Small number of flows may make relatively fine-grained |adjustment |> on the link to the phone impossible. The PCN work prior to |> the BOF relied on the ability to make such adjustments. |> (2b) While other sorts of phones may be trusted, a SIP phone (which |> may be software-only) is definitely not trustable in general. |>=20 |> I would observe that Lars Westerberg's suggestion of a Media Gateway: |>=20 |> > I am referring telecom scenario where MGWs are connected to an |> IP-backbone. |> > In these scenarios, the admission control function is a part of the |> MGW |> > and not the routers. The IP-backbone is provisioned by a network=20 |> > management system. |>=20 |> could avoid all of these issues: |> (1) The media gateway could speak RSVP to the network management=20 |> system, |> avoiding any need to deal with SIP here. |> (2a) A media gateway is likely to handle enough flows to be |consistent |> with the fine-grained adjustment assumed by the work done to date. |> (2b) One can plausibly assume/require that media gateways be trusted |> with respect to the IP network. |> To the extent that one can vest "edge" functionality in a trusted=20 |> media gateway, I see no reason to exclude that scenario. |>=20 |> Thanks, |> --David |> ---------------------------------------------------- |> David L. Black, Senior Technologist |> EMC Corporation, 176 South St., Hopkinton, MA 01748 |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> black_david@emc.com Mobile: +1 (978) 394-7754 |> ---------------------------------------------------- |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=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 Thu Feb 01 15:05:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCiBn-00056w-Hx; Thu, 01 Feb 2007 15:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCiBm-00054z-AS for pcn@ietf.org; Thu, 01 Feb 2007 15:05:46 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCiBk-0004wt-Sl for pcn@ietf.org; Thu, 01 Feb 2007 15:05:46 -0500 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 l11K5fD15999; Thu, 1 Feb 2007 15:05:41 -0500 (EST) 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, 1 Feb 2007 15:05:36 -0500 Message-Id: <6.2.5.6.0.20070201144629.032db0e0@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Feb 2007 15:05:37 -0500 To: Tina TSOU From: "Kwok-Ho Chan" Subject: Re: [PCN] 2nd charter text update In-Reply-To: <00ed01c7462b$4c6d5480$7f74a7d9@IBM4307EA0CEF3> References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> <6.2.5.6.0.20070131163950.03af6318@nortel.com> <31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com> <6.2.5.6.0.20070201101329.032ba0e8@nortel.com> <00ed01c7462b$4c6d5480$7f74a7d9@IBM4307EA0CEF3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Feb 2007 20:05:36.0739 (UTC) FILETIME=[568CAB30:01C7463C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Tina: You have indicated: If we still only focus on routers-within-a-single-DiffServ-domain, "IP packet data path of the PCN-enabled DiffServ domain/region" does not reflect this focus. Maybe it is best to put all these back into the full sentence: These mechanisms operate on the IP packet data path of the PCN-enabled DiffServ domain, with network nodes: 1) ... 2) ... I think we agreed we want the first phase of PCN to focus on "within-a-single-DiffServ-domain". And we have agreed "a-single-DiffServ-domain" can be one or more DiffServ-domains (hence I added the /region, and let LarsE use the correct definition of domain or region). So I have equated "within-a-single-DiffServ-domain" = "PCN-enabled DiffServ domain" By your comment, I interpreted you feel this equation is not correct. I don't understand the reasoning and will need some educating by you. May be providing the correct wording to resolve this will help us reach the agreed charter. Thanks! -- Kwok-Ho (Chinese names normally contain both the first and middle name characters) -- At 01:03 PM 2/1/2007, Tina TSOU wrote: >Hi Kwok-Ho, >See in line(: > >----- Original Message ----- From: "Kwok-Ho Chan" >To: "Lars Eggert" >Cc: >Sent: Thursday, February 01, 2007 4:22 PM >Subject: Re: [PCN] 2nd charter text update > > >>Please see my comments enclosed by KHC_START> and KHC_END>. >>Thank you very much for handling the "funnel" (many of us giving >>you comments)! >>-- Kwok -- >> >>At 04:43 AM 2/1/2007, Lars Eggert wrote: >>>On 2007-2-1, at 1:50, ext Kwok-Ho Chan wrote: >>>>At 04:23 AM 1/31/2007, Lars Eggert wrote: >>>>>Talking about "nodes" and "paths" leaves the door open for other work >>>>>than the routers-within-a-single-DiffServ-domain model that we want >>>>>to focus the work on initially. >>>> >>>>KHC_START> >>>>The use of "IP packet data path" is just to make the proposed charter >>>>more concise. May be it becomes too wordy in the itemized sentences, >>>>hence it will be OK for me if they are removed from the itemized >>>>sentences. >>>>But I think "These mechanisms operate on the IP packet data path" >>>>at the top >>>>is helpful to make the propose charter more clear and concise. >>> >>>But they only operate on a subset of the end-to-end path, namely, the >>>part that falls into the PCN-enabled DiffServ domain. >> >>KHC_START> >>Agree. The words "IP packet data path" is intended to indicate the >>behaviors and >>mechanisms we are trying to standardize are "on-path" behaviors and >>mechanisms. >>I am not trying to say anything about subset of the end-to-end path >>or end-to-end path. >>If you feel my intend is not necessary, lets give it a try on not >>having those words. >>Or you can add additional clarification that "IP packet data path >>of the PCN-enabled >>DiffServ domain/region". >>KHC_END> >If we still only focus on routers-within-a-single-DiffServ-domain, >"IP packet data path of the PCN-enabled DiffServ domain/region" does >not reflect this focus. >> >> >>>>On the topic of using the words "nodes" and/or "routers". >>>>I don't have a good understanding of why the word "router" must be >>>>there. >>>>Many of today's "routers" perform "switching" instead of "routing". >>>>And many of today's "routers" does more than just "routing". >>>>Is a "blade-center" a "router"? Part of it is a "router"? >>>>And does the output (behavior, mechanism documentations) of this WG >>>>need to be >>>>implemented on a specific hardware implementation? On a specific >>>>physical box? >>>>IMHO, the proposed-standards documents produced by this WG should >>>>indicate >>>>behaviors and functionality. To promote and assure inter-operability. >>>>IMHO, the proposed-standards documents produced by this WG should >>>>NOT dictate >>>>how the implementation is done, or where (which and what kind of >>>>square/round physical box) >>>>the implementation must be done at. >>> >>>Since the initial goal is to PCN-enable a DiffServ region, I agree >>>that it would remove confusion if the charter used the terms from >>>RFC2475. I'll take a stab at the appropriate rephrasings. >> >>KHC_START> >>OK, lets give it a try. Thanks! >>KHC_END> >> >> >>>>"(3) encoding and transport of (pre-)congestion signals (replaced >>>>with information) >>>>to the appropriate ingress routers of the network domain" >>>>confusing because I believe we want to specify in a standards track >>>>document >>>>how the (pre-)congestion information is encoded (the bits and bytes >>>>detail) in >>>>some IP header field (ECN, DSCP, etc). >>> >>>This has already been rephrased in my working copy. >> >>KHC_START> >>Thanks! >>KHC_END> >> >> >>>Lars >>> >>> >>> >> >> >>_______________________________________________ >>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 Feb 02 02:52:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCtE2-00023n-6x; Fri, 02 Feb 2007 02:52:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCtE1-0001wW-39 for pcn@ietf.org; Fri, 02 Feb 2007 02:52:49 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCtDj-0000FY-Iq for pcn@ietf.org; Fri, 02 Feb 2007 02:52:49 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 2 Feb 2007 08:52:26 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 08:52:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter, addition to scope Date: Fri, 2 Feb 2007 08:52:25 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAFA@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope thread-index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igABFlM0AAALDecAAAtiiAABrkqnAAAOr1oAANL60gACGeQ6A= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 02 Feb 2007 07:52:25.0987 (UTC) FILETIME=[146E5D30:01C7469F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d 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 Benny, thanks for the advice. I think the charter should still highlight the=20 differentiation of the PCN functionalities from "call admission=20 control". To suggest something: "Edge-to-edge admission control"=20 with a definition of "edge-to-edge" in the architecture document. Regards, Ruediger =20 |-----Original Message----- |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |Sent: Thursday, February 01, 2007 7:16 PM |To: Geib, Rudiger; Romascanu, Dan (Dan) |Cc: pcn@ietf.org |Subject: RE: [PCN] charter, addition to scope | | |What I think you mean, and the admission control that PCN deals with, |better not be described as "network admission control" since that term |often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control) |refers to admission based on the identity of the sender, which is |probably out of scope for PCN. The flow admission control in PCN scope |is based on considerations related to network status i.e. |pre-congestion.=20 | |The PCN flow admission control can be part of a call admission control |solution, if it interacts with other mechanisms such as for=20 |example with |Int-Serv outside the PCN domain and/or with SIP QoS=20 |pre-conditions. Such |interactions, or assumptions about them, may not be in the=20 |scope of PCN. | | |Benny=20 | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: Thursday, February 01, 2007 4:44 AM |To: Romascanu, Dan (Dan) |Cc: pcn@ietf.org |Subject: RE: [PCN] charter, addition to scope | |Hi Dan, | |your proposal seems sound to me. My impression is the discussion may |have approached consensus on the following issues to get chartered |initially: | |- PCN is limited to a single DiffServ domain. |- PCN aware nodes must be "on path". |- PCN only standardises PCN related IP layer | functionalities including RSVP or NSIS signaling | between edge nodes. |- PCN only works on "network admission control". | |If "Edge node" requires further definition to exclude things=20 |to close to |an "end system", we should add it at appropriate places.=20 | |"PCN related" would exclude dealing with middleboxes doing=20 |anything else |with packets than PCN DiffServ forwarding. | |Another question is, what the reaction of an ingress edge node=20 |should be |in case of an indicated network congestion. My impression is, that with |the initial charter we should just define a desired behaviour in terms |of an aggregate traffic reduction (e.g. "stop admission new flows |demanding CL forwarding or bandwidth increases of admitted ones" or |"reduce CL traffic by x percent").=20 | |Future work items may be added when the WG is re-chartered after having |reached first aims. It may indeed be useful to think about some |requirements for future PCN use already now. As I didn't think about |particular topics in detail, I don't try to summarise which=20 |requirements |that could be by this mail. | |Regards, | |Ruediger | | ||-----Original Message----- ||From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] ||Sent: Thursday, February 01, 2007 9:45 AM ||To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl ||Cc: pcn@ietf.org ||Subject: RE: [PCN] charter, addition to scope || || ||Maybe we should stop for a moment and consider what layer should PCN=20 ||deal with. It looks to me that we are mixing network=20 |admission control=20 ||and call admission control in this discussion. This problem is quite=20 ||complex, and there are many scenarios that need to be taken into=20 ||consideration. Sometimes flow =3D call, sometimes call =3DNOT flow and = ||sometimes there is a mix on the same path. In some cases=20 |media gateways | ||are collocated with the edge nodes in some other cases not. Even when=20 ||flow =3D call there are two admission control layers (network and = call)=20 ||that are in dependency but not identical and separate=20 |protocols run at=20 ||transport and session. I am not sure how much of all this falls under=20 ||what PCN should do. || ||Dan || || || || ||=20 ||=20 || ||> -----Original Message----- ||> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] ||> Sent: Wednesday, January 31, 2007 11:28 PM ||> To: Black_David@emc.com; karagian@cs.utwente.nl ||> Cc: pcn@ietf.org ||> Subject: RE: [PCN] charter, addition to scope ||>=20 ||> To all, ||> I agree that there must be a prioritization of flows from the=20 ||> aggregation devices However, it's not just the media gateway that=20 ||> should speak RSVP, but the edge proxy (or firewall "proxy")=20 |as well - | ||> it is the signaling proxy at the edge that reserves the media path.=20 ||> The reservation protocol request to the network from the VoIP=20 ||> proxy/gateway must reserve resources to the destination in the=20 ||> network. ||> The resource reservation request to the network by the edge=20 ||> proxy/media gateway, must at the very minimum, meet the following=20 ||> conditions: ||> 1. it needs to specify the resources required for the IP & ports=20 ||> (RTP/RTCP & bandwidth) ||> for example, G.711 and G.729 voice and various MPEG-4=20 |video codecs | ||> all have very different requirements 2. it must be mapped to the=20 ||> signaling request ||> for SIP, it must map the SDP for media with the=20 |reservation flow - | ||> for example something along the lines of RFC 3524 ||> while not the answer, the mapping of the media flows is a=20 ||> necessary component ||> It should be noted that the edge proxies/media gateways=20 |may have a | ||> large number of flows (and ports for each ||> RTP/RTCP flow) from the same source IP. The request is made for=20 ||> each flow or conversation 3. it must be honored by the edge network=20 ||> device. ||> The trust boundary must be extended to the edge proxy/media=20 ||> gateway for each new flow. ||> This brings up the issue of security authentication of the edge=20 ||> proxy/media gateway to the network ||> Does this happen in EAP, NAC, or just interoperability and=20 ||> certification among vendors ||> If the resources are not available, then the signaling indicates=20 ||> the session is not completed. For example a SIP ||> CANCEL from the edge proxy ||>=20 ||> In addition, the network device must have priority queuing enabled=20 ||> for input queues from the edge device. ||> The media flows must not be subject to input buffers being filled=20 ||> prior to classification ||>=20 ||> Thanks, ||> Richard Lee ||> Fidelity Investments ||> Enterprise Technology and Architecture ||> 617-563-3278 ||>=20 ||>=20 ||> -----Original Message----- ||> From: Black_David@emc.com [mailto:Black_David@emc.com] ||> Sent: Wednesday, January 31, 2007 2:30 PM ||> To: karagian@cs.utwente.nl ||> Cc: pcn@ietf.org ||> Subject: RE: [PCN] charter, addition to scope ||>=20 ||>=20 ||> Georgios wrote: ||>=20 ||> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: ||> > > > In the first phase of PCN work to reduce the list of ||> issues it was ||>=20 ||> > > > proposed that the WG focus on network deployment=20 |scenario where ||> all ||> > > > nodes can be trusted and delay work on deployment ||> scenarios where ||> some ||> > > > of the nodes are not trusted. ||> > >=20 ||> > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If ||> "nodes"=20 ||> > > include end systems, proxies or other entities, then I don't=20 ||> > > agree we had agreement on that. ||> >=20 ||> > Georgios: This imposes an additional restriction on the scope of=20 ||> > the charter, which has been not discussed yet. ||> > >From what I remember before, during and after the PCN BOF ||> > there was no objection on using ||> > the term edge node, that could mean something different=20 |than a edge ||> router. ||> > Please note that this is something different than a ||scenario covered ||> by ||> > an application based deployment model. ||>=20 ||> It's certainly not a new restriction based on the discussion in the=20 ||> BOF engendered about whether a SIP telephone (used on some of the ||> slides) was a good example. I believe the BOF conclusion=20 |was that a=20 ||> SIP telephone was a bad example. ||>=20 ||> IMHO, a SIP telephone causes two sets of issues wrt the ||proposed work: ||> (1) It speaks SIP, and=20 ||> (2) It's a telephone ;-) ||> The first set of issues has already been discussed=20 |extensively - my=20 ||> understanding is that the SIP scenario is currently out of=20 |scope, and | ||> I don't care to reopen that discussion. ||>=20 ||> The "telephone" issues come up in two ways: ||> (2a) Small number of flows may make relatively fine-grained ||adjustment ||> on the link to the phone impossible. The PCN work prior to ||> the BOF relied on the ability to make such adjustments. ||> (2b) While other sorts of phones may be trusted, a SIP phone (which ||> may be software-only) is definitely not trustable in general. ||>=20 ||> I would observe that Lars Westerberg's suggestion of a=20 |Media Gateway: ||>=20 ||> > I am referring telecom scenario where MGWs are connected to an ||> IP-backbone. ||> > In these scenarios, the admission control function is a=20 |part of the ||> MGW ||> > and not the routers. The IP-backbone is provisioned by a network=20 ||> > management system. ||>=20 ||> could avoid all of these issues: ||> (1) The media gateway could speak RSVP to the network management=20 ||> system, ||> avoiding any need to deal with SIP here. ||> (2a) A media gateway is likely to handle enough flows to be ||consistent ||> with the fine-grained adjustment assumed by the work done to |date. ||> (2b) One can plausibly assume/require that media gateways be trusted ||> with respect to the IP network. ||> To the extent that one can vest "edge" functionality in a trusted=20 ||> media gateway, I see no reason to exclude that scenario. ||>=20 ||> Thanks, ||> --David ||> ---------------------------------------------------- ||> David L. Black, Senior Technologist ||> EMC Corporation, 176 South St., Hopkinton, MA 01748 ||> +1 (508) 293-7953 FAX: +1 (508) 293-7786 ||> black_david@emc.com Mobile: +1 (978) 394-7754 ||> ---------------------------------------------------- ||>=20 ||> _______________________________________________ ||> PCN mailing list ||> PCN@ietf.org ||> https://www1.ietf.org/mailman/listinfo/pcn ||>=20 ||> _______________________________________________ ||> PCN mailing list ||> PCN@ietf.org ||> https://www1.ietf.org/mailman/listinfo/pcn ||>=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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 02 03:20:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCtee-00035X-8t; Fri, 02 Feb 2007 03:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCtec-00033r-UH for pcn@ietf.org; Fri, 02 Feb 2007 03:20:18 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCteb-0007VT-Gm for pcn@ietf.org; Fri, 02 Feb 2007 03:20:18 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l128HGcp002191; Fri, 2 Feb 2007 10:17:21 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:19:32 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Feb 2007 10:19:31 +0200 In-Reply-To: References: <6439282641581441A36F7F6F83ED2ED2CBFAED@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5F7CB532-E0D1-4472-AFE6-59D7CBD9B3BA@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter, addition to scope Date: Fri, 2 Feb 2007 10:19:44 +0200 To: "ext Rodrig, Benny (Benny)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Feb 2007 08:19:31.0645 (UTC) FILETIME=[DD6616D0:01C746A2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202101721-08447BB0-4C98870A/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Content-Type: multipart/mixed; boundary="===============1226377208==" Errors-To: pcn-bounces@ietf.org --===============1226377208== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-971140526; protocol="application/pkcs7-signature" --Apple-Mail-6-971140526 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-1, at 20:16, ext Rodrig, Benny (Benny) wrote: > What I think you mean, and the admission control that PCN deals with, > better not be described as "network admission control" since that term > often (e.g. see http://en.wikipedia.org/wiki/ > Network_Admission_Control) > refers to admission based on the identity of the sender, which is > probably out of scope for PCN. The flow admission control in PCN scope > is based on considerations related to network status i.e. > pre-congestion. The charter does not contain the phrase "network admission control." It specifically talks about flow admission. Lars --Apple-Mail-6-971140526 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDIwODE5NDVaMCMGCSqGSIb3DQEJBDEWBBRGscH5Ns6Tv/G7 iNKZjlwfyMAYkzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEADm07Nd26ueRwHIdYdmugzdRXE4KFjznLtJdDGKtBrSh9WYrAatmW m8Cg/70tkhN/TV/aomHWBiCiIyx2TTEFO5ZybkVwsgCcziHmzL97IRoNzr+d48hXDotvPQsMgwmP NuN/GQvkO/JErlKZt3UcAS45+uwrYIUKywrCOesumEXwPOCADVVntxV8yXB0bI007gdkYJ14NF26 FEMJdz7EPbHqj1GMGwHiPCGfMmlf5mZnS+K1jN8bo/WW5WJBnDQt5UFaW1kX8k6PoL+xsoDgMRDZ BQG4SvQOcJoKE4zeygpmTS9enn28ZM0+cqZA4ztGfnY8Dvi0c6sorxEt6z3slQAAAAAAAA== --Apple-Mail-6-971140526-- --===============1226377208== 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 --===============1226377208==-- From pcn-bounces@ietf.org Fri Feb 02 03:25:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCtjZ-000561-LO; Fri, 02 Feb 2007 03:25:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCtjY-000531-0t for pcn@ietf.org; Fri, 02 Feb 2007 03:25:24 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCtjX-0008Ey-C3 for pcn@ietf.org; Fri, 02 Feb 2007 03:25:24 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l128MwRH008263 for ; Fri, 2 Feb 2007 10:23:10 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:25:07 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Feb 2007 10:24:50 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: pcn@ietf.org Message-Id: From: Lars Eggert Date: Fri, 2 Feb 2007 10:25:04 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Feb 2007 08:24:50.0880 (UTC) FILETIME=[9BAD7C00:01C746A3] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202102310-1FE29BB0-28092053/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [PCN] 3rd charter text update 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="===============1922033984==" Errors-To: pcn-bounces@ietf.org --===============1922033984== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-971459809; protocol="application/pkcs7-signature" --Apple-Mail-7-971459809 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, attached is another charter text update. I think this is significantly more clear that previous iterations and can be submitted to the IESG and IAB for informal discussion. Lars --- Congestion and Pre-Congestion Notification (PCN) Chair(s): tbd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding transport of the congestion information. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. In consultation with the AD, the WG may produce a small number of informational documents that describe how specific quality- of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior, egress and ingress nodes of the domain (4) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the overall architecture, and specifically on the marking behavior and encoding and transport mechanisms needed to realize it. Standards-track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. If this WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/ termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Jul 2007 Flow Admission and Termination Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain (Informational) Nov 2007 Flow Admission and Termination within a DiffServ Domain (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms (Informational) --Apple-Mail-7-971459809 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDIwODI1MDRaMCMGCSqGSIb3DQEJBDEWBBQY+9QO74je8QTk +WUuWAH/A0YcATCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAa96jhgrQE2NVn6UU5BrTteNqYyrzGkM1hHR/Jfn+q3WZKK4SfZjC 0yqplR0UKnY93/kzrX0IWpZRgNi1mb/h78n46wADXZxHfXShHELHs+cFArdrQfqsRDVgGFYXvHwA OFThyrtC+Br7Ps4t/DxCe8hRIwUP2pKMOChBXMqohi0//cVQXcE/oqnQsbH0hhKzAEG9aYiy+7OL K2MM7bHjaLz9yxSy+R5tBuQ01uL2gfD1LsglGJOvXrs1mHC5bhjbhq74qECBMq1q4/FOk9HAfWaZ IHiOhN9SimxFedgxfzFQL8oyWAv+IO/HzXHkspRaB2XWOePPX2sueNS+Qh7QvwAAAAAAAA== --Apple-Mail-7-971459809-- --===============1922033984== 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 --===============1922033984==-- From pcn-bounces@ietf.org Fri Feb 02 04:13:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuTv-00086i-Ak; Fri, 02 Feb 2007 04:13:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuTt-00082a-Sr for pcn@ietf.org; Fri, 02 Feb 2007 04:13:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCuTT-0006r3-5u for pcn@ietf.org; Fri, 02 Feb 2007 04:13:17 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3022754803C; Fri, 2 Feb 2007 10:12:38 +0100 (CET) X-AuditID: c1b4fb3c-b17cbbb0000007de-06-45c30086e0f6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1076D520001; Fri, 2 Feb 2007 10:12:38 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:12:12 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:12:11 +0100 Message-ID: <45C3006B.8090604@ericsson.com> Date: Fri, 02 Feb 2007 10:12:11 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Subject: Re: [PCN] 3rd charter text update References: In-Reply-To: X-OriginalArrivalTime: 02 Feb 2007 09:12:11.0743 (UTC) FILETIME=[38F6C6F0:01C746AA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad 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="===============1737990924==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1737990924== Content-Type: multipart/alternative; boundary="------------000308010000070002080004" This is a multi-part message in MIME format. --------------000308010000070002080004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In some deplyment scenarios, other methods of adjusting the traffic volume are used. therefore, I see a need for separation of "cornerstone" RFC from RFC that should be optional. Will the PCN working group, require an implementation of all RFC to be compliant to PCN ? If not, what is the minimum set ? regards Lasse Lars Eggert wrote: > Hi, > > attached is another charter text update. I think this is > significantly more clear that previous iterations and can be > submitted to the IESG and IAB for informal discussion. > > Lars > > --- > > Congestion and Pre-Congestion Notification (PCN) > > Chair(s): > tbd > > Transport Area Director(s): > Magnus Westerlund > Lars Eggert > > Transport Area Advisor: > Lars Eggert > > Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > Description of Working Group: > > The Congestion and Pre-Congestion Notification (PCN) working group > develops mechanisms to protect the quality-of-service of established > flows within a DiffServ domain when congestion is imminent or > existing. These mechanisms operate at the domain boundary, based on > aggregated congestion and pre-congestion information from within the > domain. The focus of the WG is on developing standards for the > marking behavior of the interior nodes and the encoding transport of > the congestion information. Reaction mechanisms at the boundary > consist of flow admission and flow termination. Although designed to > work together, flow admission and flow termination are independent > mechanisms, and the use of one does not require or prevent the use of > the other. In consultation with the AD, the WG may produce a small > number of informational documents that describe how specific quality- > of-service policies for a domain can be implemented using these two > mechanisms. > > The PCN WG will specify the following components to protect the > quality-of-service of flows within a DiffServ domain: > > (1) a general architecture for flow admission and termination based > on aggregated (pre-)congestion information > > (2) a specification of conditions under which interior nodes > generate > (pre-)congestion information > > (3) encoding and transport of (pre-)congestion information > between the interior, egress and ingress nodes of the domain > > (4) ingress node control mechanisms for flow admission or > termination, > based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture, and specifically on the > marking behavior and encoding and transport mechanisms needed to > realize it. Standards-track protocols and mechanisms are only > developed where necessary for interoperability. For other components > of the architecture, the WG may document examples or provide > recommended solutions in informational documents. The architecture > document will be comprehensive, and include security, manageability > and operational considerations. If this WG requires extensions or > modifications to protocols that are products of other WGs, it may > motivate their need and describe requirements in informational > documents; design of such extensions and modifications will take > place in the appropriate WGs. > > > The initial scope of the PCN WG is restricted by the following > assumptions: > > (A) these components are deployed in a single DiffServ domain, > where all boundary and interior nodes are PCN-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping > > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective > > (D) flows may have different precedence, but the applicability > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, etc.) > is out of scope > > After completion of the initial phase, the PCN WG may re-charter to > develop solutions for scenarios where some of these restrictions are > not in place. It may also re-charter to consider applying the PCN > mechanisms to additional deployment scenarios (operation over > concatenated DiffServ domains, PCN-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion information. One example > could be flow-rate adaptation (rather than flow admission/ > termination) during times of congestion. The details of these work > items are outside the scope of the initial phase; but the WG may > consider their requirements to design components that are > sufficiently general to support such extensions in the future. > > > Goals and Milestones: > > Jul 2007 Flow Admission and Termination Architecture > (Informational) > > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Information within a DiffServ Domain > (Informational) > > Nov 2007 Flow Admission and Termination within a DiffServ > Domain (Informational) > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from within a DiffServ Domain to the Egress > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from the Domain Egress to the Ingress > (Proposed Standard) > > Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms > (Informational) > > >------------------------------------------------------------------------ > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > > --------------000308010000070002080004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In some deplyment scenarios, other methods of adjusting the traffic volume are used. therefore, I see a need for separation of "cornerstone" RFC from RFC that should be optional.

Will the PCN working group, require an implementation of all RFC to be compliant to PCN ?

If not, what is the minimum set ?

regards Lasse
Lars Eggert wrote:
[PCN] 3rd charter text update

Hi,

attached is another charter text update. I think this is 
significantly more clear that previous iterations and can be 
submitted to the IESG and IAB for informal discussion.

Lars

---

Congestion and Pre-Congestion Notification (PCN)

Chair(s):
    tbd

Transport Area Director(s):
    Magnus Westerlund <magnus.westerlund@ericsson.com>
    Lars Eggert <lars.eggert@nokia.com>

Transport Area Advisor:
    Lars Eggert <lars.eggert@nokia.com>

Mailing Lists:
    General Discussion: pcn@ietf.org
    To Subscribe: pcn-request@ietf.org
    In Body: (un)subscribe
    Archive: http://www.ietf.org/mail-archive/web/pcn/index.html


Description of Working Group:

The Congestion and Pre-Congestion Notification (PCN) working group 
develops mechanisms to protect the quality-of-service of established 
flows within a DiffServ domain when congestion is imminent or 
existing. These mechanisms operate at the domain boundary, based on 
aggregated congestion and pre-congestion information from within the 
domain. The focus of the WG is on developing standards for the 
marking behavior of the interior nodes and the encoding transport of 
the congestion information. Reaction mechanisms at the boundary 
consist of flow admission and flow termination. Although designed to 
work together, flow admission and flow termination are independent 
mechanisms, and the use of one does not require or prevent the use of 
the other. In consultation with the AD, the WG may produce a small 
number of informational documents that describe how specific quality-
of-service policies for a domain can be implemented using these two 
mechanisms.

The PCN WG will specify the following components to protect the 
quality-of-service of flows within a DiffServ domain:

    (1) a general architecture for flow admission and termination based
        on aggregated (pre-)congestion information

    (2) a specification of conditions under which interior nodes 
generate
        (pre-)congestion information

    (3) encoding and transport of (pre-)congestion information
        between the interior, egress and ingress nodes of the domain

    (4) ingress node control mechanisms for flow admission or 
termination,
        based on aggregated (pre-)congestion information

The WG focuses on the overall architecture, and specifically on the 
marking behavior and encoding and transport mechanisms needed to 
realize it. Standards-track protocols and mechanisms are only 
developed where necessary for interoperability. For other components 
of the architecture, the WG may document examples or provide 
recommended solutions in informational documents. The architecture 
document will be comprehensive, and include security, manageability 
and operational considerations. If this WG requires extensions or 
modifications to protocols that are products of other WGs, it may 
motivate their need and describe requirements in informational 
documents; design of such extensions and modifications will take 
place in the appropriate WGs.


The initial scope of the PCN WG is restricted by the following 
assumptions:

    (A) these components are deployed in a single DiffServ domain,
        where all boundary and interior nodes are PCN-enabled
        and mutually trust each other

    (B) all flows handled by these mechanisms are inelastic and
        constrained to a known maximum rate through policing or shaping

    (C) the number of flows across any potential aggregation bottleneck
        is sufficiently large for stateless, statistical mechanisms 
to be
        effective

    (D) flows may have different precedence, but the applicability
        of the PCN mechanisms for emergency use (911, GETS, WPS, 
MLPP, etc.)
        is out of scope

After completion of the initial phase, the PCN WG may re-charter to 
develop solutions for scenarios where some of these restrictions are 
not in place. It may also re-charter to consider applying the PCN 
mechanisms to additional deployment scenarios (operation over 
concatenated DiffServ domains, PCN-aware application mechanisms, 
etc.). The WG may also consider to investigate additional response 
mechanisms that act on (pre-)congestion information. One example 
could be flow-rate adaptation (rather than flow admission/
termination) during times of congestion. The details of these work 
items are outside the scope of the initial phase; but the WG may 
consider their requirements to design components that are 
sufficiently general to support such extensions in the future.


Goals and Milestones:

Jul 2007   Flow Admission and Termination Architecture
            (Informational)

Jul 2007   Survey of Encoding and Transport Choices of
            (Pre-)Congestion Information within a DiffServ Domain
            (Informational)

Nov 2007   Flow Admission and Termination within a DiffServ
            Domain (Informational)

Nov 2007   (Pre-)Congestion Detection within a DiffServ Domain
            (Proposed Standard)

Mar 2008   Encoding and Transport of (Pre-)Congestion Information
            from within a DiffServ Domain to the Egress
            (Proposed Standard)

Mar 2008   Encoding and Transport of (Pre-)Congestion Information
           from the Domain Egress to the Ingress
           (Proposed Standard)

Mar 2008   Suggested Flow Admission and Termination Boundary Mechanisms
            (Informational)


 


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--------------000308010000070002080004-- --===============1737990924== 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 --===============1737990924==-- From pcn-bounces@ietf.org Fri Feb 02 04:29:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCujn-0005rh-Fd; Fri, 02 Feb 2007 04:29:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCujm-0005ra-NX for pcn@ietf.org; Fri, 02 Feb 2007 04:29:42 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCujl-0002YK-Ab for pcn@ietf.org; Fri, 02 Feb 2007 04:29:42 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l129QRSr020359; Fri, 2 Feb 2007 11:26:44 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 11:28:58 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Feb 2007 11:28:57 +0200 In-Reply-To: <45C3006B.8090604@ericsson.com> References: <45C3006B.8090604@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <562A14C3-C74B-42D8-BC47-9132A21C3E97@nokia.com> From: Lars Eggert Subject: Re: [PCN] 3rd charter text update Date: Fri, 2 Feb 2007 11:29:11 +0200 To: ext Lars Westberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Feb 2007 09:28:57.0386 (UTC) FILETIME=[905FB8A0:01C746AC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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="===============0773276429==" Errors-To: pcn-bounces@ietf.org --===============0773276429== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-975306725; protocol="application/pkcs7-signature" --Apple-Mail-12-975306725 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-2, at 11:12, ext Lars Westberg wrote: > In some deplyment scenarios, other methods of adjusting the traffic > volume are used. therefore, I see a need for separation of > "cornerstone" RFC from RFC that should be optional. > > Will the PCN working group, require an implementation of all RFC to > be compliant to PCN ? > > If not, what is the minimum set ? Up to the architecture document to describe. Lars --Apple-Mail-12-975306725 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDIwOTI5MTFaMCMGCSqGSIb3DQEJBDEWBBTeqEnwLAoPvNL5 jwffuL8haiC0ODCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA1LLOjYe9VROGNfaCMZQHabhN3QRRSXGOHagb+AZVZv8nHek5LvnH TYelvm740/iPJmkNCUPDqjgsPTJ+pD3FdcM6VNp/TK32KkuV99E9MVPHKF7S4s2XiKu89O1DbKit vyQnijgSJl5Ko5bQhWzA+fjANMUdt4SF85cPCPA1r5ZTP6C9Tu1E60wGwVZIIQbiYc1ZIhPn/lCa UpmkS5Lbk9LHzCi70rTDAzJQVCt9R/ZxMX62o4rFSgbpvZUz68MRFFNtTaoGnks4BlI8qVfBLLbD K95fOt61dslU7ioIpH+yUVisiS5iygdMgbbWL3bUIehPkQWunuM+GxpFiSeKhQAAAAAAAA== --Apple-Mail-12-975306725-- --===============0773276429== 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 --===============0773276429==-- From pcn-bounces@ietf.org Fri Feb 02 04:33:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCunu-0008A0-Uj; Fri, 02 Feb 2007 04:33:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCunt-00089u-SX for pcn@ietf.org; Fri, 02 Feb 2007 04:33:57 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCunn-0003tx-90 for pcn@ietf.org; Fri, 02 Feb 2007 04:33:57 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81F3B209E6; Fri, 2 Feb 2007 10:33:42 +0100 (CET) X-AuditID: c1b4fb3c-af7c7bb0000007de-4d-45c30576c93b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 74B5D209A2; Fri, 2 Feb 2007 10:33:42 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:33:42 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:33:42 +0100 Message-ID: <45C30576.2020108@ericsson.com> Date: Fri, 02 Feb 2007 10:33:42 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert , Magnus Westerlund Subject: Re: [PCN] 3rd charter text update References: <45C3006B.8090604@ericsson.com> <562A14C3-C74B-42D8-BC47-9132A21C3E97@nokia.com> In-Reply-To: <562A14C3-C74B-42D8-BC47-9132A21C3E97@nokia.com> X-OriginalArrivalTime: 02 Feb 2007 09:33:42.0021 (UTC) FILETIME=[3A079350:01C746AD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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="===============0428614782==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0428614782== Content-Type: multipart/alternative; boundary="------------050401000604010804080106" This is a multi-part message in MIME format. --------------050401000604010804080106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit yes, that's what I am worried about. Can't we add a small text into the charter so we do not required a full-fledge Diff.serv edge functionality in the boundary nodes ??? regards Lasse Lars Eggert wrote: > On 2007-2-2, at 11:12, ext Lars Westberg wrote: > > In some deplyment scenarios, other methods of adjusting the traffic > > volume are used. therefore, I see a need for separation of > > "cornerstone" RFC from RFC that should be optional. > > > > Will the PCN working group, require an implementation of all RFC to > > be compliant to PCN ? > > > > If not, what is the minimum set ? > > Up to the architecture document to describe. > > Lars > > --------------050401000604010804080106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit yes, that's what I am worried about.

Can't we add a small text into the charter so we do not required a full-fledge Diff.serv edge functionality in the boundary nodes ???


regards Lasse

Lars Eggert wrote:
Re: [PCN] 3rd charter text update

On 2007-2-2, at 11:12, ext Lars Westberg wrote:
> In some deplyment scenarios, other methods of adjusting the traffic 
> volume are used. therefore, I see a need for separation of 
> "cornerstone" RFC from RFC that should be optional.
>
> Will the PCN working group, require an implementation of all RFC to 
> be compliant to PCN ?
>
> If not, what is the minimum set ?

Up to the architecture document to describe.

Lars

--------------050401000604010804080106-- --===============0428614782== 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 --===============0428614782==-- From pcn-bounces@ietf.org Fri Feb 02 04:47:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv14-0000NJ-A8; Fri, 02 Feb 2007 04:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv12-0000NB-Q1 for pcn@ietf.org; Fri, 02 Feb 2007 04:47:32 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCv0y-0006Th-C4 for pcn@ietf.org; Fri, 02 Feb 2007 04:47:32 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l129jEwY006868; Fri, 2 Feb 2007 11:45:14 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 11:47:03 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Feb 2007 11:47:01 +0200 In-Reply-To: <45C30576.2020108@ericsson.com> References: <45C3006B.8090604@ericsson.com> <562A14C3-C74B-42D8-BC47-9132A21C3E97@nokia.com> <45C30576.2020108@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] 3rd charter text update Date: Fri, 2 Feb 2007 11:47:15 +0200 To: "ext Lars Westberg" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Feb 2007 09:47:01.0845 (UTC) FILETIME=[16C30850:01C746AF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202114514-1A293BB0-2B4C367C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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="===============0283081488==" Errors-To: pcn-bounces@ietf.org --===============0283081488== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-976391088; protocol="application/pkcs7-signature" --Apple-Mail-13-976391088 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-2, at 11:33, ext Lars Westberg wrote: > yes, that's what I am worried about. > > Can't we add a small text into the charter so we do not required a > full-fledge Diff.serv edge functionality in the boundary nodes ??? I don't see how we can, because the goal is to PCN-enable a DiffServ region, which oviously requires the boundary to implement the DS functionality? Lars --Apple-Mail-13-976391088 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDIwOTQ3MTZaMCMGCSqGSIb3DQEJBDEWBBTnhRPd1TpCh9nD P/tqPQGYd8fWrjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAgTJL9Ds0a8b9tc9kS+ap5gZgAMMVtp6ARV3iP0w2KVKkU94rPmuE fGtl8sRrldMEzrVvieQkZUCdXvMBY7AO3/gwzV86kzieVNNlbj5OISChFXACBq42xnXIKIxNx4Wj o0SIMbMnjQaoRWdStNFEghWq2yRXvRVj60mlTYfTt+pCP1DV6bJcgScGbrUddJzzELQLXosfBh/p DVhuUZ7+7nr0/OMpL55UmRXYCA56S8CVJ0XyhOr9616jdvMz1iqcMDBWBcw5oLgqJB0aaomA4Agb I1v5jbzbW52e2rWhTucIV6zG22HL3Gm8t0YYW3NLjM91rEuXOHrMUoQ8V9RFhwAAAAAAAA== --Apple-Mail-13-976391088-- --===============0283081488== 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 --===============0283081488==-- From pcn-bounces@ietf.org Fri Feb 02 04:54:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv7y-0006qb-QW; Fri, 02 Feb 2007 04:54:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv7x-0006p9-Dq for pcn@ietf.org; Fri, 02 Feb 2007 04:54:41 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCv7u-0007Rx-Ul for pcn@ietf.org; Fri, 02 Feb 2007 04:54:41 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5789521285; Fri, 2 Feb 2007 10:54:34 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-36-45c30a5aea3e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3D07B21234; Fri, 2 Feb 2007 10:54:34 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:54:34 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 10:54:33 +0100 Message-ID: <45C30A59.8060102@ericsson.com> Date: Fri, 02 Feb 2007 10:54:33 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Subject: Re: [PCN] 3rd charter text update References: <45C3006B.8090604@ericsson.com> <562A14C3-C74B-42D8-BC47-9132A21C3E97@nokia.com> <45C30576.2020108@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 02 Feb 2007 09:54:33.0934 (UTC) FILETIME=[243A56E0:01C746B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============0148617859==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0148617859== Content-Type: multipart/alternative; boundary="------------020609060806090305080501" This is a multi-part message in MIME format. --------------020609060806090305080501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit When was that decided ? on the BoF or ???? What I am considering is mainly a reduced set of functionality on the PCN-architecture. Do we need to start-up for a new working group ? regards Lasse Lars Eggert wrote: > On 2007-2-2, at 11:33, ext Lars Westberg wrote: > > yes, that's what I am worried about. > > > > Can't we add a small text into the charter so we do not required a > > full-fledge Diff.serv edge functionality in the boundary nodes ??? > > I don't see how we can, because the goal is to PCN-enable a DiffServ > region, which oviously requires the boundary to implement the DS > functionality? > > Lars > > --------------020609060806090305080501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit When was that decided ?  on the BoF or ????

What I am considering is mainly a reduced set of functionality on the PCN-architecture.

Do we need to start-up for a new working group ?

regards Lasse

Lars Eggert wrote:
Re: [PCN] 3rd charter text update

On 2007-2-2, at 11:33, ext Lars Westberg wrote:
> yes, that's what I am worried about.
>
> Can't we add a small text into the charter so we do not required a 
> full-fledge Diff.serv edge functionality in the boundary nodes ???

I don't see how we can, because the goal is to PCN-enable a DiffServ 
region, which oviously requires the boundary to implement the DS 
functionality?

Lars

--------------020609060806090305080501-- --===============0148617859== 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 --===============0148617859==-- From pcn-bounces@ietf.org Fri Feb 02 06:19:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwRg-0004Fa-0z; Fri, 02 Feb 2007 06:19:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwRf-0004Ei-LU for pcn@ietf.org; Fri, 02 Feb 2007 06:19:07 -0500 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 1HCwRc-0001uD-7U for pcn@ietf.org; Fri, 02 Feb 2007 06:19:07 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 246F040CC; Fri, 2 Feb 2007 12:18:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 16C44473F; Fri, 2 Feb 2007 12:18:59 +0100 (CET) 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 8910040CC; Fri, 2 Feb 2007 12:18:58 +0100 (CET) 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 l12BIws27315; Fri, 2 Feb 2007 12:18:58 +0100 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 C558D6F58E; Fri, 2 Feb 2007 12:15:47 +0100 (CET) Message-ID: <45C31D84.2040306@informatik.uni-wuerzburg.de> Date: Fri, 02 Feb 2007 12:16:20 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Rodrig, Benny (Benny)" References: <6439282641581441A36F7F6F83ED2ED2CBFAED@S4DE8PSAAFQ.mitte.t-com.de> 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: 2d133cc328f58695161c98bb4f4dc213 Cc: pcn@ietf.org, "Geib, Ruediger" Subject: [PCN] "Network Admission Control" (NAC) 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, I've got a comment on the term "Network Admission Control" (NAC). Wikipedia http://en.wikipedia.org/wiki/Network_Admission_Control only knows NAC in the context of restricting access to the network based on identity or security posture (it's essentially a Cisco product). However, most important is the aspect that access is denied to a whole network, subnetwork, domain, region, etc. NAC is in contrast to AC algorithms deciding whether a new flow can be admitted to be transported over a single link which has been studied in depth in the 1990s in the context of ATM systems. Three years ago, I have reviewed and studied different approaches for NAC (based on resource management issues) in my PhD thesis: http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04.pdf The terms connection or flow admission control are less specific than NAC as they do not tell the scope of the AC. Best regards, Michael Rodrig, Benny (Benny) wrote: > What I think you mean, and the admission control that PCN deals with, > better not be described as "network admission control" since that term > often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control) > refers to admission based on the identity of the sender, which is > probably out of scope for PCN. The flow admission control in PCN scope > is based on considerations related to network status i.e. > pre-congestion. > > The PCN flow admission control can be part of a call admission control > solution, if it interacts with other mechanisms such as for example with > Int-Serv outside the PCN domain and/or with SIP QoS pre-conditions. Such > interactions, or assumptions about them, may not be in the scope of PCN. > > > Benny > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Thursday, February 01, 2007 4:44 AM > To: Romascanu, Dan (Dan) > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope > > Hi Dan, > > your proposal seems sound to me. My impression is the discussion may > have approached consensus on the following issues to get chartered > initially: > > - PCN is limited to a single DiffServ domain. > - PCN aware nodes must be "on path". > - PCN only standardises PCN related IP layer > functionalities including RSVP or NSIS signaling > between edge nodes. > - PCN only works on "network admission control". > > If "Edge node" requires further definition to exclude things to close to > an "end system", we should add it at appropriate places. > > "PCN related" would exclude dealing with middleboxes doing anything else > with packets than PCN DiffServ forwarding. > > Another question is, what the reaction of an ingress edge node should be > in case of an indicated network congestion. My impression is, that with > the initial charter we should just define a desired behaviour in terms > of an aggregate traffic reduction (e.g. "stop admission new flows > demanding CL forwarding or bandwidth increases of admitted ones" or > "reduce CL traffic by x percent"). > > Future work items may be added when the WG is re-chartered after having > reached first aims. It may indeed be useful to think about some > requirements for future PCN use already now. As I didn't think about > particular topics in detail, I don't try to summarise which requirements > that could be by this mail. > > Regards, > > Ruediger > > > |-----Original Message----- > |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > |Sent: Thursday, February 01, 2007 9:45 AM > |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl > |Cc: pcn@ietf.org > |Subject: RE: [PCN] charter, addition to scope > | > | > |Maybe we should stop for a moment and consider what layer should PCN > |deal with. It looks to me that we are mixing network admission control > |and call admission control in this discussion. This problem is quite > |complex, and there are many scenarios that need to be taken into > |consideration. Sometimes flow = call, sometimes call =NOT flow and > |sometimes there is a mix on the same path. In some cases media gateways > > |are collocated with the edge nodes in some other cases not. Even when > |flow = call there are two admission control layers (network and call) > |that are in dependency but not identical and separate protocols run at > |transport and session. I am not sure how much of all this falls under > |what PCN should do. > | > |Dan > | > | > | > | > | > | > | > |> -----Original Message----- > |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > |> Sent: Wednesday, January 31, 2007 11:28 PM > |> To: Black_David@emc.com; karagian@cs.utwente.nl > |> Cc: pcn@ietf.org > |> Subject: RE: [PCN] charter, addition to scope > |> > |> To all, > |> I agree that there must be a prioritization of flows from the > |> aggregation devices However, it's not just the media gateway that > |> should speak RSVP, but the edge proxy (or firewall "proxy") as well - > > |> it is the signaling proxy at the edge that reserves the media path. > |> The reservation protocol request to the network from the VoIP > |> proxy/gateway must reserve resources to the destination in the > |> network. > |> The resource reservation request to the network by the edge > |> proxy/media gateway, must at the very minimum, meet the following > |> conditions: > |> 1. it needs to specify the resources required for the IP & ports > |> (RTP/RTCP & bandwidth) > |> for example, G.711 and G.729 voice and various MPEG-4 video codecs > > |> all have very different requirements 2. it must be mapped to the > |> signaling request > |> for SIP, it must map the SDP for media with the reservation flow - > > |> for example something along the lines of RFC 3524 > |> while not the answer, the mapping of the media flows is a > |> necessary component > |> It should be noted that the edge proxies/media gateways may have a > > |> large number of flows (and ports for each > |> RTP/RTCP flow) from the same source IP. The request is made for > |> each flow or conversation 3. it must be honored by the edge network > |> device. > |> The trust boundary must be extended to the edge proxy/media > |> gateway for each new flow. > |> This brings up the issue of security authentication of the edge > |> proxy/media gateway to the network > |> Does this happen in EAP, NAC, or just interoperability and > |> certification among vendors > |> If the resources are not available, then the signaling indicates > |> the session is not completed. For example a SIP > |> CANCEL from the edge proxy > |> > |> In addition, the network device must have priority queuing enabled > |> for input queues from the edge device. > |> The media flows must not be subject to input buffers being filled > |> prior to classification > |> > |> Thanks, > |> Richard Lee > |> Fidelity Investments > |> Enterprise Technology and Architecture > |> 617-563-3278 > |> > |> > |> -----Original Message----- > |> From: Black_David@emc.com [mailto:Black_David@emc.com] > |> Sent: Wednesday, January 31, 2007 2:30 PM > |> To: karagian@cs.utwente.nl > |> Cc: pcn@ietf.org > |> Subject: RE: [PCN] charter, addition to scope > |> > |> > |> Georgios wrote: > |> > |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > |> > > > In the first phase of PCN work to reduce the list of > |> issues it was > |> > |> > > > proposed that the WG focus on network deployment scenario where > |> all > |> > > > nodes can be trusted and delay work on deployment > |> scenarios where > |> some > |> > > > of the nodes are not trusted. > |> > > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If > |> "nodes" > |> > > include end systems, proxies or other entities, then I don't > |> > > agree we had agreement on that. > |> > > |> > Georgios: This imposes an additional restriction on the scope of > |> > the charter, which has been not discussed yet. > |> > >From what I remember before, during and after the PCN BOF > |> > there was no objection on using > |> > the term edge node, that could mean something different than a edge > |> router. > |> > Please note that this is something different than a > |scenario covered > |> by > |> > an application based deployment model. > |> > |> It's certainly not a new restriction based on the discussion in the > |> BOF engendered about whether a SIP telephone (used on some of the > |> slides) was a good example. I believe the BOF conclusion was that a > |> SIP telephone was a bad example. > |> > |> IMHO, a SIP telephone causes two sets of issues wrt the > |proposed work: > |> (1) It speaks SIP, and > |> (2) It's a telephone ;-) > |> The first set of issues has already been discussed extensively - my > |> understanding is that the SIP scenario is currently out of scope, and > > |> I don't care to reopen that discussion. > |> > |> The "telephone" issues come up in two ways: > |> (2a) Small number of flows may make relatively fine-grained > |adjustment > |> on the link to the phone impossible. The PCN work prior to > |> the BOF relied on the ability to make such adjustments. > |> (2b) While other sorts of phones may be trusted, a SIP phone (which > |> may be software-only) is definitely not trustable in general. > |> > |> I would observe that Lars Westerberg's suggestion of a Media Gateway: > |> > |> > I am referring telecom scenario where MGWs are connected to an > |> IP-backbone. > |> > In these scenarios, the admission control function is a part of the > |> MGW > |> > and not the routers. The IP-backbone is provisioned by a network > |> > management system. > |> > |> could avoid all of these issues: > |> (1) The media gateway could speak RSVP to the network management > |> system, > |> avoiding any need to deal with SIP here. > |> (2a) A media gateway is likely to handle enough flows to be > |consistent > |> with the fine-grained adjustment assumed by the work done to > date. > |> (2b) One can plausibly assume/require that media gateways be trusted > |> with respect to the IP network. > |> To the extent that one can vest "edge" functionality in a trusted > |> media gateway, I see no reason to exclude that scenario. > |> > |> Thanks, > |> --David > |> ---------------------------------------------------- > |> David L. Black, Senior Technologist > |> EMC Corporation, 176 South St., Hopkinton, MA 01748 > |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > |> black_david@emc.com Mobile: +1 (978) 394-7754 > |> ---------------------------------------------------- > |> > |> _______________________________________________ > |> 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 Fri Feb 02 09:19:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzGO-0002EU-3i; Fri, 02 Feb 2007 09:19:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzGM-000298-OR for pcn@ietf.org; Fri, 02 Feb 2007 09:19:38 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzGL-0002W6-7g for pcn@ietf.org; Fri, 02 Feb 2007 09:19:38 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCU00LQ9AGMYP@lhrga01-in.huawei.com> for pcn@ietf.org; Fri, 02 Feb 2007 14:19:34 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.116.127]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCU002C3AGLGK@lhrga01-in.huawei.com> for pcn@ietf.org; Fri, 02 Feb 2007 14:19:34 +0000 (GMT) Date: Fri, 02 Feb 2007 15:19:26 +0100 From: Tina TSOU Subject: Re: [PCN] 2nd charter text update To: Kwok-Ho Chan Message-id: <010c01c746d5$25a95060$7f74a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> <6.2.5.6.0.20070131163950.03af6318@nortel.com> <31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com> <6.2.5.6.0.20070201101329.032ba0e8@nortel.com> <00ed01c7462b$4c6d5480$7f74a7d9@IBM4307EA0CEF3> <6.2.5.6.0.20070201144629.032db0e0@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 Kwok, My comments were based on my discussion with LarsE. If "a-single-DiffServ-domain" can be one or more DiffServ-domains, my comments are not valid. Now, I am OK with 3rd charter text. B. R. Tina ----- Original Message ----- From: "Kwok-Ho Chan" To: "Tina TSOU" Cc: "Lars Eggert" ; "Kwok-Ho Chan" ; Sent: Thursday, February 01, 2007 9:05 PM Subject: Re: [PCN] 2nd charter text update > Tina: > You have indicated: > If we still only focus on routers-within-a-single-DiffServ-domain, "IP > packet data path of the PCN-enabled DiffServ domain/region" does not > reflect this focus. > > Maybe it is best to put all these back into the full sentence: > These mechanisms operate on the IP packet data path of the PCN-enabled > DiffServ domain, > with network nodes: > 1) ... > 2) ... > > I think we agreed we want the first phase of PCN to focus on > "within-a-single-DiffServ-domain". > And we have agreed "a-single-DiffServ-domain" can be one or more > DiffServ-domains (hence > I added the /region, and let LarsE use the correct definition of domain or > region). > > So I have equated "within-a-single-DiffServ-domain" = "PCN-enabled > DiffServ domain" > > By your comment, I interpreted you feel this equation is not correct. > I don't understand the reasoning and will need some educating by you. > May be providing the correct wording to resolve this will help us reach > the agreed charter. > > Thanks! > -- Kwok-Ho (Chinese names normally contain both the first and middle name > characters) -- > > > At 01:03 PM 2/1/2007, Tina TSOU wrote: >>Hi Kwok-Ho, >>See in line(: >> >>----- Original Message ----- From: "Kwok-Ho Chan" >>To: "Lars Eggert" >>Cc: >>Sent: Thursday, February 01, 2007 4:22 PM >>Subject: Re: [PCN] 2nd charter text update >> >> >>>Please see my comments enclosed by KHC_START> and KHC_END>. >>>Thank you very much for handling the "funnel" (many of us giving you >>>comments)! >>>-- Kwok -- >>> >>>At 04:43 AM 2/1/2007, Lars Eggert wrote: >>>>On 2007-2-1, at 1:50, ext Kwok-Ho Chan wrote: >>>>>At 04:23 AM 1/31/2007, Lars Eggert wrote: >>>>>>Talking about "nodes" and "paths" leaves the door open for other work >>>>>>than the routers-within-a-single-DiffServ-domain model that we want >>>>>>to focus the work on initially. >>>>> >>>>>KHC_START> >>>>>The use of "IP packet data path" is just to make the proposed charter >>>>>more concise. May be it becomes too wordy in the itemized sentences, >>>>>hence it will be OK for me if they are removed from the itemized >>>>>sentences. >>>>>But I think "These mechanisms operate on the IP packet data path" >>>>>at the top >>>>>is helpful to make the propose charter more clear and concise. >>>> >>>>But they only operate on a subset of the end-to-end path, namely, the >>>>part that falls into the PCN-enabled DiffServ domain. >>> >>>KHC_START> >>>Agree. The words "IP packet data path" is intended to indicate the >>>behaviors and >>>mechanisms we are trying to standardize are "on-path" behaviors and >>>mechanisms. >>>I am not trying to say anything about subset of the end-to-end path or >>>end-to-end path. >>>If you feel my intend is not necessary, lets give it a try on not having >>>those words. >>>Or you can add additional clarification that "IP packet data path of the >>>PCN-enabled >>>DiffServ domain/region". >>>KHC_END> >>If we still only focus on routers-within-a-single-DiffServ-domain, "IP >>packet data path of the PCN-enabled DiffServ domain/region" does not >>reflect this focus. >>> >>> >>>>>On the topic of using the words "nodes" and/or "routers". >>>>>I don't have a good understanding of why the word "router" must be >>>>>there. >>>>>Many of today's "routers" perform "switching" instead of "routing". >>>>>And many of today's "routers" does more than just "routing". >>>>>Is a "blade-center" a "router"? Part of it is a "router"? >>>>>And does the output (behavior, mechanism documentations) of this WG >>>>>need to be >>>>>implemented on a specific hardware implementation? On a specific >>>>>physical box? >>>>>IMHO, the proposed-standards documents produced by this WG should >>>>>indicate >>>>>behaviors and functionality. To promote and assure inter-operability. >>>>>IMHO, the proposed-standards documents produced by this WG should >>>>>NOT dictate >>>>>how the implementation is done, or where (which and what kind of >>>>>square/round physical box) >>>>>the implementation must be done at. >>>> >>>>Since the initial goal is to PCN-enable a DiffServ region, I agree >>>>that it would remove confusion if the charter used the terms from >>>>RFC2475. I'll take a stab at the appropriate rephrasings. >>> >>>KHC_START> >>>OK, lets give it a try. Thanks! >>>KHC_END> >>> >>> >>>>>"(3) encoding and transport of (pre-)congestion signals (replaced >>>>>with information) >>>>>to the appropriate ingress routers of the network domain" >>>>>confusing because I believe we want to specify in a standards track >>>>>document >>>>>how the (pre-)congestion information is encoded (the bits and bytes >>>>>detail) in >>>>>some IP header field (ECN, DSCP, etc). >>>> >>>>This has already been rephrased in my working copy. >>> >>>KHC_START> >>>Thanks! >>>KHC_END> >>> >>> >>>>Lars >>>> >>>> >>>> >>> >>> >>>_______________________________________________ >>>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 Feb 02 09:25:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzML-0007V6-9c; Fri, 02 Feb 2007 09:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzMJ-0007V1-Kw for pcn@ietf.org; Fri, 02 Feb 2007 09:25:47 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzMF-0003nB-TD for pcn@ietf.org; Fri, 02 Feb 2007 09:25:47 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCU008I8AQRK3@lhrga01-in.huawei.com> for pcn@ietf.org; Fri, 02 Feb 2007 14:25:47 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.116.127]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCU002M4AP5GK@lhrga01-in.huawei.com> for pcn@ietf.org; Fri, 02 Feb 2007 14:25:38 +0000 (GMT) Date: Fri, 02 Feb 2007 15:24:34 +0100 From: Tina TSOU Subject: Re: [PCN] "Network Admission Control" (NAC) To: "Rodrig, Benny (Benny)" , menth@informatik.uni-wuerzburg.de Message-id: <011701c746d5$fbe00750$7f74a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6439282641581441A36F7F6F83ED2ED2CBFAED@S4DE8PSAAFQ.mitte.t-com.de> <45C31D84.2040306@informatik.uni-wuerzburg.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca 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 Hi, How about Resource Admission Control or Network Resource Admission Control? I don't have strong opinion on that, just some terms popped up in my mind:) B. R. Tina ----- Original Message ----- From: "Michael Menth" To: "Rodrig, Benny (Benny)" Cc: ; "Geib, Ruediger" Sent: Friday, February 02, 2007 12:16 PM Subject: [PCN] "Network Admission Control" (NAC) > Hi, > > I've got a comment on the term "Network Admission Control" (NAC). > > Wikipedia http://en.wikipedia.org/wiki/Network_Admission_Control only > knows NAC in the context of restricting access to the network based on > identity or security posture (it's essentially a Cisco product). However, > most important is the aspect that access is denied to a whole network, > subnetwork, domain, region, etc. NAC is in contrast to AC algorithms > deciding whether a new flow can be admitted to be transported over a > single link which has been studied in depth in the 1990s in the context of > ATM systems. Three years ago, I have reviewed and studied different > approaches for NAC (based on resource management issues) in my PhD thesis: > http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04.pdf > The terms connection or flow admission control are less specific than NAC > as they do not tell the scope of the AC. > > Best regards, > > Michael > > Rodrig, Benny (Benny) wrote: >> What I think you mean, and the admission control that PCN deals with, >> better not be described as "network admission control" since that term >> often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control) >> refers to admission based on the identity of the sender, which is >> probably out of scope for PCN. The flow admission control in PCN scope >> is based on considerations related to network status i.e. >> pre-congestion. >> The PCN flow admission control can be part of a call admission control >> solution, if it interacts with other mechanisms such as for example with >> Int-Serv outside the PCN domain and/or with SIP QoS pre-conditions. Such >> interactions, or assumptions about them, may not be in the scope of PCN. >> >> >> Benny >> -----Original Message----- >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: Thursday, >> February 01, 2007 4:44 AM >> To: Romascanu, Dan (Dan) >> Cc: pcn@ietf.org >> Subject: RE: [PCN] charter, addition to scope >> >> Hi Dan, >> >> your proposal seems sound to me. My impression is the discussion may >> have approached consensus on the following issues to get chartered >> initially: >> >> - PCN is limited to a single DiffServ domain. >> - PCN aware nodes must be "on path". >> - PCN only standardises PCN related IP layer >> functionalities including RSVP or NSIS signaling >> between edge nodes. >> - PCN only works on "network admission control". >> >> If "Edge node" requires further definition to exclude things to close to >> an "end system", we should add it at appropriate places. >> "PCN related" would exclude dealing with middleboxes doing anything else >> with packets than PCN DiffServ forwarding. >> >> Another question is, what the reaction of an ingress edge node should be >> in case of an indicated network congestion. My impression is, that with >> the initial charter we should just define a desired behaviour in terms >> of an aggregate traffic reduction (e.g. "stop admission new flows >> demanding CL forwarding or bandwidth increases of admitted ones" or >> "reduce CL traffic by x percent"). >> Future work items may be added when the WG is re-chartered after having >> reached first aims. It may indeed be useful to think about some >> requirements for future PCN use already now. As I didn't think about >> particular topics in detail, I don't try to summarise which requirements >> that could be by this mail. >> >> Regards, >> >> Ruediger >> >> >> |-----Original Message----- >> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >> |Sent: Thursday, February 01, 2007 9:45 AM >> |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl >> |Cc: pcn@ietf.org >> |Subject: RE: [PCN] charter, addition to scope >> | >> | >> |Maybe we should stop for a moment and consider what layer should PCN >> |deal with. It looks to me that we are mixing network admission control >> |and call admission control in this discussion. This problem is quite >> |complex, and there are many scenarios that need to be taken into >> |consideration. Sometimes flow = call, sometimes call =NOT flow and >> |sometimes there is a mix on the same path. In some cases media gateways >> >> |are collocated with the edge nodes in some other cases not. Even when >> |flow = call there are two admission control layers (network and call) >> |that are in dependency but not identical and separate protocols run at >> |transport and session. I am not sure how much of all this falls under >> |what PCN should do. >> | >> |Dan >> | >> | >> | >> | >> | | | >> |> -----Original Message----- >> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] >> |> Sent: Wednesday, January 31, 2007 11:28 PM >> |> To: Black_David@emc.com; karagian@cs.utwente.nl >> |> Cc: pcn@ietf.org >> |> Subject: RE: [PCN] charter, addition to scope >> |> |> To all, >> |> I agree that there must be a prioritization of flows from the |> >> aggregation devices However, it's not just the media gateway that |> >> should speak RSVP, but the edge proxy (or firewall "proxy") as well - >> >> |> it is the signaling proxy at the edge that reserves the media path. |> >> The reservation protocol request to the network from the VoIP |> >> proxy/gateway must reserve resources to the destination in the |> >> network. >> |> The resource reservation request to the network by the edge |> >> proxy/media gateway, must at the very minimum, meet the following |> >> conditions: >> |> 1. it needs to specify the resources required for the IP & ports |> >> (RTP/RTCP & bandwidth) >> |> for example, G.711 and G.729 voice and various MPEG-4 video codecs >> >> |> all have very different requirements 2. it must be mapped to the |> >> signaling request >> |> for SIP, it must map the SDP for media with the reservation flow - >> >> |> for example something along the lines of RFC 3524 >> |> while not the answer, the mapping of the media flows is a |> >> necessary component >> |> It should be noted that the edge proxies/media gateways may have a >> >> |> large number of flows (and ports for each >> |> RTP/RTCP flow) from the same source IP. The request is made for |> >> each flow or conversation 3. it must be honored by the edge network |> >> device. >> |> The trust boundary must be extended to the edge proxy/media |> >> gateway for each new flow. >> |> This brings up the issue of security authentication of the edge |> >> proxy/media gateway to the network >> |> Does this happen in EAP, NAC, or just interoperability and |> >> certification among vendors >> |> If the resources are not available, then the signaling indicates |> >> the session is not completed. For example a SIP >> |> CANCEL from the edge proxy >> |> |> In addition, the network device must have priority queuing enabled >> |> for input queues from the edge device. >> |> The media flows must not be subject to input buffers being filled |> >> prior to classification >> |> |> Thanks, >> |> Richard Lee >> |> Fidelity Investments >> |> Enterprise Technology and Architecture >> |> 617-563-3278 >> |> |> |> -----Original Message----- >> |> From: Black_David@emc.com [mailto:Black_David@emc.com] >> |> Sent: Wednesday, January 31, 2007 2:30 PM >> |> To: karagian@cs.utwente.nl >> |> Cc: pcn@ietf.org >> |> Subject: RE: [PCN] charter, addition to scope >> |> |> |> Georgios wrote: >> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: >> |> > > > In the first phase of PCN work to reduce the list of >> |> issues it was >> |> |> > > > proposed that the WG focus on network deployment scenario >> where >> |> all >> |> > > > nodes can be trusted and delay work on deployment >> |> scenarios where >> |> some >> |> > > > of the nodes are not trusted. >> |> > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I >> agree. If >> |> "nodes" |> > > include end systems, proxies or other entities, then I >> don't |> > > agree we had agreement on that. >> |> > |> > Georgios: This imposes an additional restriction on the scope >> of |> > the charter, which has been not discussed yet. >> |> > >From what I remember before, during and after the PCN BOF >> |> > there was no objection on using >> |> > the term edge node, that could mean something different than a edge >> |> router. >> |> > Please note that this is something different than a >> |scenario covered >> |> by >> |> > an application based deployment model. >> |> |> It's certainly not a new restriction based on the discussion in the >> |> BOF engendered about whether a SIP telephone (used on some of the >> |> slides) was a good example. I believe the BOF conclusion was that a >> |> SIP telephone was a bad example. >> |> |> IMHO, a SIP telephone causes two sets of issues wrt the >> |proposed work: >> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) >> |> The first set of issues has already been discussed extensively - my >> |> understanding is that the SIP scenario is currently out of scope, and >> >> |> I don't care to reopen that discussion. >> |> |> The "telephone" issues come up in two ways: >> |> (2a) Small number of flows may make relatively fine-grained >> |adjustment >> |> on the link to the phone impossible. The PCN work prior to >> |> the BOF relied on the ability to make such adjustments. >> |> (2b) While other sorts of phones may be trusted, a SIP phone (which >> |> may be software-only) is definitely not trustable in general. >> |> |> I would observe that Lars Westerberg's suggestion of a Media >> Gateway: >> |> |> > I am referring telecom scenario where MGWs are connected to an >> |> IP-backbone. >> |> > In these scenarios, the admission control function is a part of the >> |> MGW >> |> > and not the routers. The IP-backbone is provisioned by a network |> >> > management system. >> |> |> could avoid all of these issues: >> |> (1) The media gateway could speak RSVP to the network management |> >> system, >> |> avoiding any need to deal with SIP here. >> |> (2a) A media gateway is likely to handle enough flows to be >> |consistent >> |> with the fine-grained adjustment assumed by the work done to >> date. >> |> (2b) One can plausibly assume/require that media gateways be trusted >> |> with respect to the IP network. >> |> To the extent that one can vest "edge" functionality in a trusted |> >> media gateway, I see no reason to exclude that scenario. >> |> |> Thanks, >> |> --David >> |> ---------------------------------------------------- >> |> David L. Black, Senior Technologist >> |> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> |> black_david@emc.com Mobile: +1 (978) 394-7754 >> |> ---------------------------------------------------- >> |> |> _______________________________________________ >> |> 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 Fri Feb 02 09:31:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzRw-0004JO-9J; Fri, 02 Feb 2007 09:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzRv-0004JC-88 for pcn@ietf.org; Fri, 02 Feb 2007 09:31:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzRt-0004sB-Gu for pcn@ietf.org; Fri, 02 Feb 2007 09:31:35 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2007 06:31:33 -0800 X-IronPort-AV: i="4.13,273,1167638400"; d="scan'208,217"; a="385143936:sNHT102712844" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l12EVUqG030064; Fri, 2 Feb 2007 06:31:30 -0800 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 l12EV6nR026517; Fri, 2 Feb 2007 06:31:31 -0800 (PST) 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); Fri, 2 Feb 2007 09:31:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] 3rd charter text update Date: Fri, 2 Feb 2007 09:31:30 -0500 Message-ID: In-Reply-To: <45C30A59.8060102@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter text update Thread-Index: AcdGsDemjdAZ8o/CS0224eZqObGksQAJQboA From: "Anna Charny \(acharny\)" To: "Lars Westberg" , "Lars Eggert" X-OriginalArrivalTime: 02 Feb 2007 14:31:32.0155 (UTC) FILETIME=[D575A0B0:01C746D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4737; t=1170426690; x=1171290690; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=203rd=20charter=20text=20update |Sender:=20; bh=fmhKSiQBfjObIVC2426XT2iefUCToKNaSF9dbUJjvKg=; b=daaewZ2GV+oRerqKUjuI3Fb5jezw9w8dlMJvigv0RgA6L4NodpI7yS7KJ7uDEEuPia7f+PdC dj0Zl+1GTDFLTsXNOOSIffftamH+oQRSSa5OFrR1ePo+RIh87TveiRHX; Authentication-Results: sj-dkim-7; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); 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: , Content-Type: multipart/mixed; boundary="===============0321110218==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0321110218== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C746D6.D49BA763" This is a multi-part message in MIME format. ------_=_NextPart_001_01C746D6.D49BA763 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I agree with Lars (Eggert) - this does seem to me that this issue belongs to the architecture document. The document should clearly explain which functionality is minimally required. If it happens to be less that "full fledge" it should be spelled out clearly. =20 =20 I think the wording of the latest charter text certainly does not prevent at all at the moment specifying a subset functionality necessary.=20 =20 Anna=20 ________________________________ From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: Friday, February 02, 2007 4:55 AM To: Lars Eggert Cc: pcn@ietf.org Subject: Re: [PCN] 3rd charter text update =09 =09 When was that decided ? on the BoF or ???? =09 What I am considering is mainly a reduced set of functionality on the PCN-architecture. =09 Do we need to start-up for a new working group ? =09 regards Lasse =09 Lars Eggert wrote: =09 On 2007-2-2, at 11:33, ext Lars Westberg wrote: > yes, that's what I am worried about. > > Can't we add a small text into the charter so we do not required a=20 > full-fledge Diff.serv edge functionality in the boundary nodes ??? =09 I don't see how we can, because the goal is to PCN-enable a DiffServ=20 region, which oviously requires the boundary to implement the DS=20 functionality? =09 Lars =09 =09 =09 ------_=_NextPart_001_01C746D6.D49BA763 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I agree with Lars (Eggert) - this does = seem to me that=20 this issue belongs to the architecture document.  The document = should=20 clearly explain which functionality is minimally required.  If it = happens=20 to be less that "full fledge" it should be spelled out clearly. =20
 
I think the wording of the latest charter text = certainly=20 does not prevent at all at the moment specifying a subset functionality=20 necessary.
 
Anna

From: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: Friday, February = 02, 2007=20 4:55 AM
To: Lars Eggert
Cc:=20 pcn@ietf.org
Subject: Re: [PCN] 3rd charter text=20 update

When was that decided ?  on the BoF or = ????

What I am=20 considering is mainly a reduced set of functionality on the=20 PCN-architecture.

Do we need to start-up for a new working = group=20 ?

regards Lasse

Lars Eggert wrote:

On 2007-2-2, at 11:33, ext Lars Westberg = wrote:
> yes,=20 that's what I am worried about.
>
> Can't we add a small = text=20 into the charter so we do not required a 
> full-fledge = Diff.serv=20 edge functionality in the boundary nodes ???

I don't see how = we can,=20 because the goal is to PCN-enable a DiffServ 
region, which = oviously=20 requires the boundary to implement the=20 = DS 
functionality?

Lars


------_=_NextPart_001_01C746D6.D49BA763-- --===============0321110218== 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 --===============0321110218==-- From pcn-bounces@ietf.org Fri Feb 02 09:59:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzsn-0003aI-Ct; Fri, 02 Feb 2007 09:59:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzsl-0003Up-7D for pcn@ietf.org; Fri, 02 Feb 2007 09:59:19 -0500 Received: from 103.12.152.198.in-addr.arpa ([198.152.12.103] helo=nj300815-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzsf-0002Sv-76 for pcn@ietf.org; Fri, 02 Feb 2007 09:59:19 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l12Ex1A2029568 for ; Fri, 2 Feb 2007 09:59:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] "Network Admission Control" (NAC) Date: Fri, 2 Feb 2007 09:59:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdG1+Oq5BAEU2cCQwSSlmwnnD98qQAAqC7A From: "Moore, Sean \(Sean\)" To: "Tina TSOU" , "Rodrig, Benny \(Benny\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e 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 Probably shouldn't use "Resource Admission Control" as this term (RAC) is used in IMS and it is not the same as what we are discussing - Sean=20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Friday, February 02, 2007 9:25 AM To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org; Geib, Ruediger Subject: Re: [PCN] "Network Admission Control" (NAC) Hi, How about Resource Admission Control or Network Resource Admission Control? I don't have strong opinion on that, just some terms popped up in my mind:) B. R. Tina ----- Original Message ----- From: "Michael Menth" To: "Rodrig, Benny (Benny)" Cc: ; "Geib, Ruediger" Sent: Friday, February 02, 2007 12:16 PM Subject: [PCN] "Network Admission Control" (NAC) > Hi, > > I've got a comment on the term "Network Admission Control" (NAC). > > Wikipedia http://en.wikipedia.org/wiki/Network_Admission_Control only=20 > knows NAC in the context of restricting access to the network based on > identity or security posture (it's essentially a Cisco product). However,=20 > most important is the aspect that access is denied to a whole network, > subnetwork, domain, region, etc. NAC is in contrast to AC algorithms=20 > deciding whether a new flow can be admitted to be transported over a=20 > single link which has been studied in depth in the 1990s in the context of=20 > ATM systems. Three years ago, I have reviewed and studied different=20 > approaches for NAC (based on resource management issues) in my PhD thesis: > http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04.p df > The terms connection or flow admission control are less specific than NAC=20 > as they do not tell the scope of the AC. > > Best regards, > > Michael > > Rodrig, Benny (Benny) wrote: >> What I think you mean, and the admission control that PCN deals with, >> better not be described as "network admission control" since that term >> often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control) >> refers to admission based on the identity of the sender, which is >> probably out of scope for PCN. The flow admission control in PCN scope >> is based on considerations related to network status i.e. >> pre-congestion. >> The PCN flow admission control can be part of a call admission control >> solution, if it interacts with other mechanisms such as for example with >> Int-Serv outside the PCN domain and/or with SIP QoS pre-conditions. Such >> interactions, or assumptions about them, may not be in the scope of PCN. >> >> >> Benny >> -----Original Message----- >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: Thursday,=20 >> February 01, 2007 4:44 AM >> To: Romascanu, Dan (Dan) >> Cc: pcn@ietf.org >> Subject: RE: [PCN] charter, addition to scope >> >> Hi Dan, >> >> your proposal seems sound to me. My impression is the discussion may >> have approached consensus on the following issues to get chartered >> initially: >> >> - PCN is limited to a single DiffServ domain. >> - PCN aware nodes must be "on path". >> - PCN only standardises PCN related IP layer >> functionalities including RSVP or NSIS signaling >> between edge nodes. >> - PCN only works on "network admission control". >> >> If "Edge node" requires further definition to exclude things to close to >> an "end system", we should add it at appropriate places. >> "PCN related" would exclude dealing with middleboxes doing anything else >> with packets than PCN DiffServ forwarding. >> >> Another question is, what the reaction of an ingress edge node should be >> in case of an indicated network congestion. My impression is, that with >> the initial charter we should just define a desired behaviour in terms >> of an aggregate traffic reduction (e.g. "stop admission new flows >> demanding CL forwarding or bandwidth increases of admitted ones" or >> "reduce CL traffic by x percent"). >> Future work items may be added when the WG is re-chartered after having >> reached first aims. It may indeed be useful to think about some >> requirements for future PCN use already now. As I didn't think about >> particular topics in detail, I don't try to summarise which requirements >> that could be by this mail. >> >> Regards, >> >> Ruediger >> >> >> |-----Original Message----- >> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >> |Sent: Thursday, February 01, 2007 9:45 AM >> |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl >> |Cc: pcn@ietf.org >> |Subject: RE: [PCN] charter, addition to scope >> | >> | >> |Maybe we should stop for a moment and consider what layer should PCN >> |deal with. It looks to me that we are mixing network admission control=20 >> |and call admission control in this discussion. This problem is quite >> |complex, and there are many scenarios that need to be taken into=20 >> |consideration. Sometimes flow =3D call, sometimes call =3DNOT flow = and=20 >> |sometimes there is a mix on the same path. In some cases media gateways >> >> |are collocated with the edge nodes in some other cases not. Even when=20 >> |flow =3D call there are two admission control layers (network and call)=20 >> |that are in dependency but not identical and separate protocols run at=20 >> |transport and session. I am not sure how much of all this falls under=20 >> |what PCN should do. >> | >> |Dan >> | >> | >> | >> | >> | | | >> |> -----Original Message----- >> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] >> |> Sent: Wednesday, January 31, 2007 11:28 PM >> |> To: Black_David@emc.com; karagian@cs.utwente.nl >> |> Cc: pcn@ietf.org >> |> Subject: RE: [PCN] charter, addition to scope >> |> |> To all, >> |> I agree that there must be a prioritization of flows from the |>=20 >> aggregation devices However, it's not just the media gateway that |>=20 >> should speak RSVP, but the edge proxy (or firewall "proxy") as well - >> >> |> it is the signaling proxy at the edge that reserves the media path. |>=20 >> The reservation protocol request to the network from the VoIP |>=20 >> proxy/gateway must reserve resources to the destination in the |>=20 >> network. >> |> The resource reservation request to the network by the edge |>=20 >> proxy/media gateway, must at the very minimum, meet the following |>=20 >> conditions: >> |> 1. it needs to specify the resources required for the IP & ports |>=20 >> (RTP/RTCP & bandwidth) >> |> for example, G.711 and G.729 voice and various MPEG-4 video codecs >> >> |> all have very different requirements 2. it must be mapped to the |>=20 >> signaling request >> |> for SIP, it must map the SDP for media with the reservation flow - >> >> |> for example something along the lines of RFC 3524 >> |> while not the answer, the mapping of the media flows is a |>=20 >> necessary component >> |> It should be noted that the edge proxies/media gateways may have a >> >> |> large number of flows (and ports for each >> |> RTP/RTCP flow) from the same source IP. The request is made for |>=20 >> each flow or conversation 3. it must be honored by the edge network |>=20 >> device. >> |> The trust boundary must be extended to the edge proxy/media |>=20 >> gateway for each new flow. >> |> This brings up the issue of security authentication of the edge |>=20 >> proxy/media gateway to the network >> |> Does this happen in EAP, NAC, or just interoperability and |>=20 >> certification among vendors >> |> If the resources are not available, then the signaling indicates |>=20 >> the session is not completed. For example a SIP >> |> CANCEL from the edge proxy >> |> |> In addition, the network device must have priority queuing enabled=20 >> |> for input queues from the edge device. >> |> The media flows must not be subject to input buffers being filled |>=20 >> prior to classification >> |> |> Thanks, >> |> Richard Lee >> |> Fidelity Investments >> |> Enterprise Technology and Architecture >> |> 617-563-3278 >> |> |> |> -----Original Message----- >> |> From: Black_David@emc.com [mailto:Black_David@emc.com] >> |> Sent: Wednesday, January 31, 2007 2:30 PM >> |> To: karagian@cs.utwente.nl >> |> Cc: pcn@ietf.org >> |> Subject: RE: [PCN] charter, addition to scope >> |> |> |> Georgios wrote: >> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: >> |> > > > In the first phase of PCN work to reduce the list of >> |> issues it was >> |> |> > > > proposed that the WG focus on network deployment scenario >> where >> |> all >> |> > > > nodes can be trusted and delay work on deployment >> |> scenarios where >> |> some >> |> > > > of the nodes are not trusted. >> |> > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I=20 >> agree. If >> |> "nodes" |> > > include end systems, proxies or other entities, then I=20 >> don't |> > > agree we had agreement on that. >> |> > |> > Georgios: This imposes an additional restriction on the scope=20 >> of |> > the charter, which has been not discussed yet. >> |> > >From what I remember before, during and after the PCN BOF >> |> > there was no objection on using >> |> > the term edge node, that could mean something different than a edge >> |> router. >> |> > Please note that this is something different than a >> |scenario covered >> |> by >> |> > an application based deployment model. >> |> |> It's certainly not a new restriction based on the discussion in the=20 >> |> BOF engendered about whether a SIP telephone (used on some of the >> |> slides) was a good example. I believe the BOF conclusion was that a=20 >> |> SIP telephone was a bad example. >> |> |> IMHO, a SIP telephone causes two sets of issues wrt the >> |proposed work: >> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) >> |> The first set of issues has already been discussed extensively - my=20 >> |> understanding is that the SIP scenario is currently out of scope, and >> >> |> I don't care to reopen that discussion. >> |> |> The "telephone" issues come up in two ways: >> |> (2a) Small number of flows may make relatively fine-grained >> |adjustment >> |> on the link to the phone impossible. The PCN work prior to >> |> the BOF relied on the ability to make such adjustments. >> |> (2b) While other sorts of phones may be trusted, a SIP phone (which >> |> may be software-only) is definitely not trustable in general. >> |> |> I would observe that Lars Westerberg's suggestion of a Media=20 >> Gateway: >> |> |> > I am referring telecom scenario where MGWs are connected to an >> |> IP-backbone. >> |> > In these scenarios, the admission control function is a part of the >> |> MGW >> |> > and not the routers. The IP-backbone is provisioned by a network |>=20 >> > management system. >> |> |> could avoid all of these issues: >> |> (1) The media gateway could speak RSVP to the network management |>=20 >> system, >> |> avoiding any need to deal with SIP here. >> |> (2a) A media gateway is likely to handle enough flows to be >> |consistent >> |> with the fine-grained adjustment assumed by the work done to >> date. >> |> (2b) One can plausibly assume/require that media gateways be trusted >> |> with respect to the IP network. >> |> To the extent that one can vest "edge" functionality in a trusted |>=20 >> media gateway, I see no reason to exclude that scenario. >> |> |> Thanks, >> |> --David >> |> ---------------------------------------------------- >> |> David L. Black, Senior Technologist >> |> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> |> black_david@emc.com Mobile: +1 (978) 394-7754 >> |> ---------------------------------------------------- >> |> |> _______________________________________________ >> |> 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=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 Fri Feb 02 10:06:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzze-0007FZ-RF; Fri, 02 Feb 2007 10:06:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzzd-0007FR-Lu for pcn@ietf.org; Fri, 02 Feb 2007 10:06:25 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzzV-0003ws-NT for pcn@ietf.org; Fri, 02 Feb 2007 10:06:25 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2041420FDB; Fri, 2 Feb 2007 16:06:15 +0100 (CET) X-AuditID: c1b4fb3e-ae6d0bb0000007e1-96-45c35367ff9d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F3C8F204EA; Fri, 2 Feb 2007 16:06:14 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 16:06:11 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 16:06:10 +0100 Message-ID: <45C35362.50208@ericsson.com> Date: Fri, 02 Feb 2007 16:06:10 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] 3rd charter text update References: In-Reply-To: X-OriginalArrivalTime: 02 Feb 2007 15:06:10.0468 (UTC) FILETIME=[AC3B0640:01C746DB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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="===============0005659331==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0005659331== Content-Type: multipart/alternative; boundary="------------000804090802060904000408" This is a multi-part message in MIME format. --------------000804090802060904000408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ok, that's good. I had some problem to interprete the statement from LarsE. So, it means that we can have disucssion this scenario as well in the working group. regards Lasse Anna Charny (acharny) wrote: > I agree with Lars (Eggert) - this does seem to me that this issue > belongs to the architecture document. The document should clearly > explain which functionality is minimally required. If it happens to > be less that "full fledge" it should be spelled out clearly. > > I think the wording of the latest charter text certainly does not > prevent at all at the moment specifying a subset functionality necessary. > > Anna > > ------------------------------------------------------------------------ > From: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: Friday, February 02, 2007 4:55 AM > To: Lars Eggert > Cc: pcn@ietf.org > Subject: Re: [PCN] 3rd charter text update > > When was that decided ? on the BoF or ???? > > What I am considering is mainly a reduced set of functionality on > the PCN-architecture. > > Do we need to start-up for a new working group ? > > regards Lasse > > Lars Eggert wrote: > >> On 2007-2-2, at 11:33, ext Lars Westberg wrote: >> > yes, that's what I am worried about. >> > >> > Can't we add a small text into the charter so we do not required a >> > full-fledge Diff.serv edge functionality in the boundary nodes ??? >> >> I don't see how we can, because the goal is to PCN-enable a DiffServ >> region, which oviously requires the boundary to implement the DS >> functionality? >> >> Lars >> >> --------------000804090802060904000408 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ok, that's good. I had some problem to interprete the statement from LarsE.
So, it means that we can have disucssion this scenario as well in the working group.

regards Lasse

Anna Charny (acharny) wrote:
I agree with Lars (Eggert) - this does seem to me that this issue belongs to the architecture document.  The document should clearly explain which functionality is minimally required.  If it happens to be less that "full fledge" it should be spelled out clearly. 
 
I think the wording of the latest charter text certainly does not prevent at all at the moment specifying a subset functionality necessary.
 
Anna

From: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: Friday, February 02, 2007 4:55 AM
To: Lars Eggert
Cc: pcn@ietf.org
Subject: Re: [PCN] 3rd charter text update

When was that decided ?  on the BoF or ????

What I am considering is mainly a reduced set of functionality on the PCN-architecture.

Do we need to start-up for a new working group ?

regards Lasse

Lars Eggert wrote:

On 2007-2-2, at 11:33, ext Lars Westberg wrote:
> yes, that's what I am worried about.
>
> Can't we add a small text into the charter so we do not required a 
> full-fledge Diff.serv edge functionality in the boundary nodes ???

I don't see how we can, because the goal is to PCN-enable a DiffServ 
region, which oviously requires the boundary to implement the DS 
functionality?

Lars


--------------000804090802060904000408-- --===============0005659331== 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 --===============0005659331==-- From pcn-bounces@ietf.org Fri Feb 02 10:29:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0MR-0001UM-4q; Fri, 02 Feb 2007 10:29:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0MQ-0001Ty-R2 for pcn@ietf.org; Fri, 02 Feb 2007 10:29:58 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0M9-00081y-Jb for pcn@ietf.org; Fri, 02 Feb 2007 10:29:58 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D63F8213F1; Fri, 2 Feb 2007 16:29:36 +0100 (CET) X-AuditID: c1b4fb3e-aeed1bb0000007e1-7b-45c358e0f3a5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B84D1210BB; Fri, 2 Feb 2007 16:29:36 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 16:29:36 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 16:29:36 +0100 Message-ID: <45C358E0.7070300@ericsson.com> Date: Fri, 02 Feb 2007 16:29:36 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] 3rd charter text update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 15:29:36.0292 (UTC) FILETIME=[F22ABE40:01C746DE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: pcn@ietf.org, Lars Westberg 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: > I agree with Lars (Eggert) - this does seem to me that this issue > belongs to the architecture document. The document should clearly > explain which functionality is minimally required. If it happens to be > less that "full fledge" it should be spelled out clearly. > > I think the wording of the latest charter text certainly does not > prevent at all at the moment specifying a subset functionality > necessary. > I think it is important we do agree on that there is a possible decomposition in the PCN architecture between the forward path where pre-congestion marking happens, and the metering at the egress, and how one transports that information. Explicitly allowing that decomposition seems to me to be a requirement for allowing PCN to work with some of the other deployment scenarios, such as MGW at the edge nodes as Lars Westberg proposed, or the application aware scenarios that is also proposed. Otherwise they might be stuck with a lot of functionality that is not needed from the int-serv/diff-serv deployment we are taking on as first step. Looking at the future plan section of the charter I think that covers this a bit insufficiently. It talks a lot of removing the restrictions. However changing the post metering transport and encoding would allow PCN to be used in other deployments and is a possible way. Thus I would like to clarify this somehow. However do note that I don't propose that any work should happen in these direction within the proposed WG initially. Only that we consider this and allow in the architecture for such development in the future. Agreement or disagreement? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Fri Feb 02 10:59:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0ov-00032e-AD; Fri, 02 Feb 2007 10:59:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0ot-0002x6-He for pcn@ietf.org; Fri, 02 Feb 2007 10:59:23 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0om-0004d6-Pe for pcn@ietf.org; Fri, 02 Feb 2007 10:59:23 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 19A5420732; Fri, 2 Feb 2007 16:59:10 +0100 (CET) X-AuditID: c1b4fb3c-aefc6bb0000007de-be-45c35fcdeed3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E11162041A; Fri, 2 Feb 2007 16:59:09 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 16:59:09 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 16:59:09 +0100 Message-ID: <45C35FCD.6080004@ericsson.com> Date: Fri, 02 Feb 2007 16:59:09 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [PCN] 3rd charter text update References: <45C358E0.7070300@ericsson.com> In-Reply-To: <45C358E0.7070300@ericsson.com> X-OriginalArrivalTime: 02 Feb 2007 15:59:09.0520 (UTC) FILETIME=[1317DD00:01C746E3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0727028256==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0727028256== Content-Type: multipart/alternative; boundary="------------040503060209000305070406" This is a multi-part message in MIME format. --------------040503060209000305070406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree Magnus Westerlund wrote: > Anna Charny (acharny) skrev: > > I agree with Lars (Eggert) - this does seem to me that this issue > > belongs to the architecture document. The document should clearly > > explain which functionality is minimally required. If it happens to be > > less that "full fledge" it should be spelled out clearly. > > > > I think the wording of the latest charter text certainly does not > > prevent at all at the moment specifying a subset functionality > > necessary. > > > > I think it is important we do agree on that there is a possible > decomposition in the PCN architecture between the forward path where > pre-congestion marking happens, and the metering at the egress, and how > one transports that information. Explicitly allowing that decomposition > seems to me to be a requirement for allowing PCN to work with some of > the other deployment scenarios, such as MGW at the edge nodes as Lars > Westberg proposed, or the application aware scenarios that is also > proposed. Otherwise they might be stuck with a lot of functionality that > is not needed from the int-serv/diff-serv deployment we are taking on as > first step. > > Looking at the future plan section of the charter I think that covers > this a bit insufficiently. It talks a lot of removing the restrictions. > However changing the post metering transport and encoding would allow > PCN to be used in other deployments and is a possible way. Thus I would > like to clarify this somehow. However do note that I don't propose that > any work should happen in these direction within the proposed WG > initially. Only that we consider this and allow in the architecture for > such development in the future. > > Agreement or disagreement? > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- > --------------040503060209000305070406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree

Magnus Westerlund wrote:
Re: [PCN] 3rd charter text update

Anna Charny (acharny) skrev:
> I agree with Lars (Eggert) - this does seem to me that this issue
> belongs to the architecture document.  The document should clearly
> explain which functionality is minimally required.  If it happens to be
> less that "full fledge" it should be spelled out clearly. 
> 
> I think the wording of the latest charter text certainly does not
> prevent at all at the moment specifying a subset functionality
> necessary.
> 

I think it is important we do agree on that there is a possible
decomposition in the PCN architecture between the forward path where
pre-congestion marking happens, and the metering at the egress, and how
one transports that information. Explicitly allowing that decomposition
seems to me to be a requirement for allowing PCN to work with some of
the other deployment scenarios, such as MGW at the edge nodes as Lars
Westberg proposed, or the application aware scenarios that is also
proposed. Otherwise they might be stuck with a lot of functionality that
is not needed from the int-serv/diff-serv deployment we are taking on as
first step.

Looking at the future plan section of the charter I think that covers
this a bit insufficiently. It talks a lot of removing the restrictions.
However changing the post metering transport and encoding would allow
PCN to be used in other deployments and is a possible way. Thus I would
like to clarify this somehow. However do note that I don't propose that
any work should happen in these direction within the proposed WG
initially. Only that we consider this and allow in the architecture for
such development in the future.

Agreement or disagreement?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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
----------------------------------------------------------------------

--------------040503060209000305070406-- --===============0727028256== 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 --===============0727028256==-- From pcn-bounces@ietf.org Fri Feb 02 11:03:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0t0-0000qN-SP; Fri, 02 Feb 2007 11:03:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0sz-0000pk-Hl for pcn@ietf.org; Fri, 02 Feb 2007 11:03:37 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0sw-0005X5-LQ for pcn@ietf.org; Fri, 02 Feb 2007 11:03:37 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l12G3576005185; Fri, 2 Feb 2007 17:03:09 +0100 (MET) From: "Georgios Karagiannis" To: "'Magnus Westerlund'" , "'Anna Charny \(acharny\)'" References: <45C358E0.7070300@ericsson.com> Subject: RE: [PCN] 3rd charter text update Date: Fri, 2 Feb 2007 17:03:21 +0100 Message-ID: <003f01c746e3$ac38c2b0$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: <45C358E0.7070300@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG3wWp2t3/QQytQW6OoYYGGvsf7gABJUhg X-Spam-Score: 0.084 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Feb 2007 17:03:09 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: pcn@ietf.org, 'Lars Westberg' 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 Magnus I agree with your proposal! Best Regards, Georgios > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: vrijdag 2 februari 2007 16:30 > To: Anna Charny (acharny) > Cc: pcn@ietf.org; Lars Westberg > Subject: Re: [PCN] 3rd charter text update > > Anna Charny (acharny) skrev: > > I agree with Lars (Eggert) - this does seem to me that this issue > > belongs to the architecture document. The document should clearly > > explain which functionality is minimally required. If it > happens to > > be less that "full fledge" it should be spelled out clearly. > > > > I think the wording of the latest charter text certainly does not > > prevent at all at the moment specifying a subset functionality > > necessary. > > > > I think it is important we do agree on that there is a > possible decomposition in the PCN architecture between the > forward path where pre-congestion marking happens, and the > metering at the egress, and how one transports that > information. Explicitly allowing that decomposition seems to > me to be a requirement for allowing PCN to work with some of > the other deployment scenarios, such as MGW at the edge nodes > as Lars Westberg proposed, or the application aware scenarios > that is also proposed. Otherwise they might be stuck with a > lot of functionality that is not needed from the > int-serv/diff-serv deployment we are taking on as first step. > > Looking at the future plan section of the charter I think > that covers this a bit insufficiently. It talks a lot of > removing the restrictions. > However changing the post metering transport and encoding > would allow PCN to be used in other deployments and is a > possible way. Thus I would like to clarify this somehow. > However do note that I don't propose that any work should > happen in these direction within the proposed WG initially. > Only that we consider this and allow in the architecture for > such development in the future. > > Agreement or disagreement? > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > 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 Fri Feb 02 11:09:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0yc-00034M-DT; Fri, 02 Feb 2007 11:09:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0yb-00033Z-OG for pcn@ietf.org; Fri, 02 Feb 2007 11:09:25 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0yX-0006lS-VM for pcn@ietf.org; Fri, 02 Feb 2007 11:09:25 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l12G9HaB021078 for ; Fri, 2 Feb 2007 11:09:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] "Network Admission Control" (NAC) Date: Fri, 2 Feb 2007 11:09:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdG1+Oq5BAEU2cCQwSSlmwnnD98qQAAqC7AAAEjOmA= References: <011701c746d5$fbe00750$7f74a7d9@IBM4307EA0CEF3> From: "Rodrig, Benny \(Benny\)" To: "Moore, Sean \(Sean\)" , "Tina TSOU" , , "Geib, Ruediger" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 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 the 'flow admission' wording in the charter is fine and we don't need to choose a more precise term. The charter text explaining that this flow admission happens at the domain boundary in reaction to pre-congestion info from within the domain, etc. seems to describe it sufficiently. Benny -----Original Message----- From: Moore, Sean (Sean)=20 Sent: Friday, February 02, 2007 9:59 AM To: Tina TSOU; Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org; Geib, Ruediger Subject: RE: [PCN] "Network Admission Control" (NAC) Probably shouldn't use "Resource Admission Control" as this term (RAC) is used in IMS and it is not the same as what we are discussing - Sean=20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com] Sent: Friday, February 02, 2007 9:25 AM To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org; Geib, Ruediger Subject: Re: [PCN] "Network Admission Control" (NAC) Hi, How about Resource Admission Control or Network Resource Admission Control? I don't have strong opinion on that, just some terms popped up in my mind:) B. R. Tina ----- Original Message ----- From: "Michael Menth" To: "Rodrig, Benny (Benny)" Cc: ; "Geib, Ruediger" Sent: Friday, February 02, 2007 12:16 PM Subject: [PCN] "Network Admission Control" (NAC) > Hi, > > I've got a comment on the term "Network Admission Control" (NAC). > > Wikipedia http://en.wikipedia.org/wiki/Network_Admission_Control only=20 > knows NAC in the context of restricting access to the network based on > identity or security posture (it's essentially a Cisco product).=20 > However, most important is the aspect that access is denied to a whole > network, subnetwork, domain, region, etc. NAC is in contrast to AC=20 > algorithms deciding whether a new flow can be admitted to be=20 > transported over a single link which has been studied in depth in the=20 > 1990s in the context of ATM systems. Three years ago, I have reviewed=20 > and studied different approaches for NAC (based on resource management issues) in my PhD thesis: > http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04 > .pdf The terms connection or flow admission control are less specific=20 > than NAC as they do not tell the scope of the AC. > > Best regards, > > Michael > > Rodrig, Benny (Benny) wrote: >> What I think you mean, and the admission control that PCN deals with, >> better not be described as "network admission control" since that=20 >> term often (e.g. see=20 >> http://en.wikipedia.org/wiki/Network_Admission_Control) >> refers to admission based on the identity of the sender, which is=20 >> probably out of scope for PCN. The flow admission control in PCN=20 >> scope is based on considerations related to network status i.e. >> pre-congestion. >> The PCN flow admission control can be part of a call admission=20 >> control solution, if it interacts with other mechanisms such as for=20 >> example with Int-Serv outside the PCN domain and/or with SIP QoS=20 >> pre-conditions. Such interactions, or assumptions about them, may not be in the scope of PCN. >> >> >> Benny >> -----Original Message----- >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent:=20 >> Thursday, February 01, 2007 4:44 AM >> To: Romascanu, Dan (Dan) >> Cc: pcn@ietf.org >> Subject: RE: [PCN] charter, addition to scope >> >> Hi Dan, >> >> your proposal seems sound to me. My impression is the discussion may=20 >> have approached consensus on the following issues to get chartered >> initially: >> >> - PCN is limited to a single DiffServ domain. >> - PCN aware nodes must be "on path". >> - PCN only standardises PCN related IP layer >> functionalities including RSVP or NSIS signaling >> between edge nodes. >> - PCN only works on "network admission control". >> >> If "Edge node" requires further definition to exclude things to close >> to an "end system", we should add it at appropriate places. >> "PCN related" would exclude dealing with middleboxes doing anything=20 >> else with packets than PCN DiffServ forwarding. >> >> Another question is, what the reaction of an ingress edge node should >> be in case of an indicated network congestion. My impression is, that >> with the initial charter we should just define a desired behaviour in >> terms of an aggregate traffic reduction (e.g. "stop admission new=20 >> flows demanding CL forwarding or bandwidth increases of admitted=20 >> ones" or "reduce CL traffic by x percent"). >> Future work items may be added when the WG is re-chartered after=20 >> having reached first aims. It may indeed be useful to think about=20 >> some requirements for future PCN use already now. As I didn't think=20 >> about particular topics in detail, I don't try to summarise which=20 >> requirements that could be by this mail. >> >> Regards, >> >> Ruediger >> >> >> |-----Original Message----- >> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >> |Sent: Thursday, February 01, 2007 9:45 AM >> |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl >> |Cc: pcn@ietf.org >> |Subject: RE: [PCN] charter, addition to scope >> | >> | >> |Maybe we should stop for a moment and consider what layer should PCN >> |deal with. It looks to me that we are mixing network admission=20 >> |control and call admission control in this discussion. This problem=20 >> |is quite complex, and there are many scenarios that need to be taken >> |into consideration. Sometimes flow =3D call, sometimes call =3DNOT = flow=20 >> |and sometimes there is a mix on the same path. In some cases media=20 >> |gateways >> >> |are collocated with the edge nodes in some other cases not. Even=20 >> |when flow =3D call there are two admission control layers (network = and >> |call) that are in dependency but not identical and separate=20 >> |protocols run at transport and session. I am not sure how much of=20 >> |all this falls under what PCN should do. >> | >> |Dan >> | >> | >> | >> | >> | | | >> |> -----Original Message----- >> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] >> |> Sent: Wednesday, January 31, 2007 11:28 PM >> |> To: Black_David@emc.com; karagian@cs.utwente.nl >> |> Cc: pcn@ietf.org >> |> Subject: RE: [PCN] charter, addition to scope >> |> |> To all, >> |> I agree that there must be a prioritization of flows from the |> >> aggregation devices However, it's not just the media gateway that |>=20 >> should speak RSVP, but the edge proxy (or firewall "proxy") as well - >> >> |> it is the signaling proxy at the edge that reserves the media=20 >> |> path. |> >> The reservation protocol request to the network from the VoIP |>=20 >> proxy/gateway must reserve resources to the destination in the |>=20 >> network. >> |> The resource reservation request to the network by the edge |> >> proxy/media gateway, must at the very minimum, meet the following |> >> conditions: >> |> 1. it needs to specify the resources required for the IP & ports=20 >> |> |> >> (RTP/RTCP & bandwidth) >> |> for example, G.711 and G.729 voice and various MPEG-4 video=20 >> |> codecs >> >> |> all have very different requirements 2. it must be mapped to the=20 >> |> |> >> signaling request >> |> for SIP, it must map the SDP for media with the reservation=20 >> |> flow - >> >> |> for example something along the lines of RFC 3524 >> |> while not the answer, the mapping of the media flows is a |> >> necessary component >> |> It should be noted that the edge proxies/media gateways may=20 >> |> have a >> >> |> large number of flows (and ports for each >> |> RTP/RTCP flow) from the same source IP. The request is made for >> |> |> >> each flow or conversation 3. it must be honored by the edge network=20 >> |> device. >> |> The trust boundary must be extended to the edge proxy/media |> >> gateway for each new flow. >> |> This brings up the issue of security authentication of the edge >> |> |> >> proxy/media gateway to the network >> |> Does this happen in EAP, NAC, or just interoperability and |> >> certification among vendors >> |> If the resources are not available, then the signaling=20 >> |> indicates |> >> the session is not completed. For example a SIP >> |> CANCEL from the edge proxy >> |> |> In addition, the network device must have priority queuing=20 >> |> |> enabled >> |> for input queues from the edge device. >> |> The media flows must not be subject to input buffers being filled=20 >> |> |> >> prior to classification >> |> |> Thanks, >> |> Richard Lee >> |> Fidelity Investments >> |> Enterprise Technology and Architecture >> |> 617-563-3278 >> |> |> |> -----Original Message----- >> |> From: Black_David@emc.com [mailto:Black_David@emc.com] >> |> Sent: Wednesday, January 31, 2007 2:30 PM >> |> To: karagian@cs.utwente.nl >> |> Cc: pcn@ietf.org >> |> Subject: RE: [PCN] charter, addition to scope >> |> |> |> Georgios wrote: >> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: >> |> > > > In the first phase of PCN work to reduce the list of >> |> issues it was >> |> |> > > > proposed that the WG focus on network deployment scenario >> where >> |> all >> |> > > > nodes can be trusted and delay work on deployment >> |> scenarios where >> |> some >> |> > > > of the nodes are not trusted. >> |> > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I >> agree. If >> |> "nodes" |> > > include end systems, proxies or other entities,=20 >> |> then I >> don't |> > > agree we had agreement on that. >> |> > |> > Georgios: This imposes an additional restriction on the=20 >> |> > |> > scope >> of |> > the charter, which has been not discussed yet. >> |> > >From what I remember before, during and after the PCN BOF >> |> > there was no objection on using >> |> > the term edge node, that could mean something different than a=20 >> |> > edge >> |> router. >> |> > Please note that this is something different than a >> |scenario covered >> |> by >> |> > an application based deployment model. >> |> |> It's certainly not a new restriction based on the discussion in >> |> |> the >> |> BOF engendered about whether a SIP telephone (used on some of the >> |> slides) was a good example. I believe the BOF conclusion was that >> |> a SIP telephone was a bad example. >> |> |> IMHO, a SIP telephone causes two sets of issues wrt the >> |proposed work: >> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) The first set=20 >> |> of issues has already been discussed extensively - my=20 >> |> understanding is that the SIP scenario is currently out of scope,=20 >> |> and >> >> |> I don't care to reopen that discussion. >> |> |> The "telephone" issues come up in two ways: >> |> (2a) Small number of flows may make relatively fine-grained >> |adjustment >> |> on the link to the phone impossible. The PCN work prior to the=20 >> |> BOF relied on the ability to make such adjustments. >> |> (2b) While other sorts of phones may be trusted, a SIP phone=20 >> |> (which may be software-only) is definitely not trustable in general. >> |> |> I would observe that Lars Westerberg's suggestion of a Media >> Gateway: >> |> |> > I am referring telecom scenario where MGWs are connected to=20 >> |> |> > an >> |> IP-backbone. >> |> > In these scenarios, the admission control function is a part of=20 >> |> > the >> |> MGW >> |> > and not the routers. The IP-backbone is provisioned by a network >> |> > |> >> > management system. >> |> |> could avoid all of these issues: >> |> (1) The media gateway could speak RSVP to the network management=20 >> |> |> >> system, >> |> avoiding any need to deal with SIP here. >> |> (2a) A media gateway is likely to handle enough flows to be >> |consistent >> |> with the fine-grained adjustment assumed by the work done to >> date. >> |> (2b) One can plausibly assume/require that media gateways be=20 >> |> trusted with respect to the IP network. >> |> To the extent that one can vest "edge" functionality in a trusted=20 >> |> |> >> media gateway, I see no reason to exclude that scenario. >> |> |> Thanks, >> |> --David >> |> ---------------------------------------------------- >> |> David L. Black, Senior Technologist EMC Corporation, 176 South=20 >> |> St., Hopkinton, MA 01748 >> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> |> black_david@emc.com Mobile: +1 (978) 394-7754 >> |> ---------------------------------------------------- >> |> |> _______________________________________________ >> |> 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,=20 > Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany,=20 > room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > 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 Feb 02 11:51:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1dF-0005lm-I8; Fri, 02 Feb 2007 11:51:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1dE-0005ld-PH for pcn@ietf.org; Fri, 02 Feb 2007 11:51:24 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1dC-0006h5-EB for pcn@ietf.org; Fri, 02 Feb 2007 11:51:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2007 11:51:22 -0500 X-IronPort-AV: i="4.13,273,1167627600"; d="scan'208"; a="113028101:sNHT52920996" 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/8.12.11) with ESMTP id l12GpMo0015055; Fri, 2 Feb 2007 11:51:22 -0500 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 l12GpMOA014926; Fri, 2 Feb 2007 11:51:22 -0500 (EST) 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); Fri, 2 Feb 2007 11:51:20 -0500 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] 3rd charter text update Date: Fri, 2 Feb 2007 11:51:18 -0500 Message-ID: In-Reply-To: <45C358E0.7070300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter text update Thread-Index: AcdG3vaclJPk30X8RLCmNFwg+i28/gACVV+Q From: "Anna Charny \(acharny\)" To: "Magnus Westerlund" X-OriginalArrivalTime: 02 Feb 2007 16:51:20.0097 (UTC) FILETIME=[5D100110:01C746EA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4163; t=1170435082; x=1171299082; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=203rd=20charter=20text=20update |Sender:=20 |To:=20=22Magnus=20Westerlund=22=20; bh=z56XrdoyjXULx/n3bpZ2z8wn4JVCdDm9VA54sKaIz6s=; b=GDRc6LblERTPOkIvb3YAnMh7hCf/cJXEX36uIEsQOmqw43foioVFBNhuJVxnm8tTo0ru4iaz nIftNE8Xzr4unEbO8YuirV9YWLSf9nFijQu+1m/6Z7rVXFHvDv24SXNN; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pcn@ietf.org, Lars Westberg 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 Magnus, I do agree that "there is a possible decomposition in the PCN architecture between the forward path where pre-congestion marking happens, and the metering at the egress, and how one transports that information." However, I want to point out that there is a danger in interpreting the above to imply that one can define markings and edge reactions completely independently of each other. That would not be true. For example, an edge reaction designed to work with excess-rate marking is unlikely to work with "CL-style admission marking" which marks *all* packets with probability 1 once a certain traffic level has been reached. =20 As a result, interoperaility considerations may constrain what combintions of marking and edge behavior pairs end up being defined. I do think that the current wording of the charter allows the WG to consider requirements of other deployment scenarios and extensions to the initial work scope. In fact it explicitly says that the WG may "consider their requirements to design components that are sufficiently general to support such extensions in the future". These consideratoion may (and probably should)limit the choices made in the first pahse of the work. My personal opinion is that the current text of the charter is very good. It provides the scope that seems realistic to address within the set timetable, and yet is flexible enough to allow the WG to be aware of more general requirements. Anna=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Friday, February 02, 2007 10:30 AM > To: Anna Charny (acharny) > Cc: Lars Westberg; Lars Eggert; pcn@ietf.org > Subject: Re: [PCN] 3rd charter text update >=20 > Anna Charny (acharny) skrev: > > I agree with Lars (Eggert) - this does seem to me that this issue=20 > > belongs to the architecture document. The document should clearly=20 > > explain which functionality is minimally required. If it=20 > happens to=20 > > be less that "full fledge" it should be spelled out clearly. > > =20 > > I think the wording of the latest charter text certainly does not=20 > > prevent at all at the moment specifying a subset functionality=20 > > necessary. > > =20 >=20 > I think it is important we do agree on that there is a=20 > possible decomposition in the PCN architecture between the=20 > forward path where pre-congestion marking happens, and the=20 > metering at the egress, and how one transports that=20 > information. Explicitly allowing that decomposition seems to=20 > me to be a requirement for allowing PCN to work with some of=20 > the other deployment scenarios, such as MGW at the edge nodes=20 > as Lars Westberg proposed, or the application aware scenarios=20 > that is also proposed. Otherwise they might be stuck with a=20 > lot of functionality that is not needed from the=20 > int-serv/diff-serv deployment we are taking on as first step. >=20 > Looking at the future plan section of the charter I think=20 > that covers this a bit insufficiently. It talks a lot of=20 > removing the restrictions.=20 > However changing the post metering transport and encoding=20 > would allow PCN to be used in other deployments and is a=20 > possible way. Thus I would like to clarify this somehow.=20 > However do note that I don't propose that any work should=20 > happen in these direction within the proposed WG initially.=20 > Only that we consider this and allow in the architecture for=20 > such development in the future. >=20 > Agreement or disagreement? >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 02 12:09:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1uh-0005BP-BK; Fri, 02 Feb 2007 12:09:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1ue-0005AQ-N6 for pcn@ietf.org; Fri, 02 Feb 2007 12:09:24 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1ud-000195-6v for pcn@ietf.org; Fri, 02 Feb 2007 12:09:24 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l12H8oKC007465; Fri, 2 Feb 2007 18:08:54 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , "'Magnus Westerlund'" References: <45C358E0.7070300@ericsson.com> Subject: RE: [PCN] 3rd charter text update Date: Fri, 2 Feb 2007 18:09:06 +0100 Message-ID: <004d01c746ec$db8940e0$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG3vaclJPk30X8RLCmNFwg+i28/gACVV+QAADoYSA= X-Spam-Score: 0.385 () AWL,J_CHICKENPOX_65 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Feb 2007 18:08:55 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: pcn@ietf.org, 'Lars Westberg' 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 In my opinion it will help to clarify in the PCN charter text that "there is a possible decomposition in the PCN architecture between the forward path where pre-congestion marking happens, and the metering at the egress, and how one transports that information." I think that your concerns stated in the second paragraph of your e-mail can be addressed in the "Flow Admission and Termination Architecture" draft. Best regards, Georgios > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: vrijdag 2 februari 2007 17:51 > To: Magnus Westerlund > Cc: pcn@ietf.org; Lars Westberg > Subject: RE: [PCN] 3rd charter text update > > Hi Magnus, > > I do agree that "there is a possible decomposition in the PCN > architecture between the forward path where pre-congestion > marking happens, and the metering at the egress, and how one > transports that information." > > However, I want to point out that there is a danger in > interpreting the above to imply that one can define markings > and edge reactions completely independently of each other. > That would not be true. For example, an edge reaction > designed to work with excess-rate marking is unlikely to work > with "CL-style admission marking" which marks *all* packets > with probability 1 once a certain traffic level has been reached. > > As a result, interoperaility considerations may constrain > what combintions of marking and edge behavior pairs end up > being defined. > > I do think that the current wording of the charter allows the > WG to consider requirements of other deployment scenarios and > extensions to the initial work scope. In fact it explicitly > says that the WG may "consider their requirements to design > components that are sufficiently general to support such > extensions in the future". These consideratoion may (and > probably should)limit the choices made in the first pahse of the work. > > My personal opinion is that the current text of the charter > is very good. It provides the scope that seems realistic to > address within the set timetable, and yet is flexible enough > to allow the WG to be aware of more general requirements. > > Anna > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Friday, February 02, 2007 10:30 AM > > To: Anna Charny (acharny) > > Cc: Lars Westberg; Lars Eggert; pcn@ietf.org > > Subject: Re: [PCN] 3rd charter text update > > > > Anna Charny (acharny) skrev: > > > I agree with Lars (Eggert) - this does seem to me that this issue > > > belongs to the architecture document. The document > should clearly > > > explain which functionality is minimally required. If it > > happens to > > > be less that "full fledge" it should be spelled out clearly. > > > > > > I think the wording of the latest charter text certainly does not > > > prevent at all at the moment specifying a subset functionality > > > necessary. > > > > > > > I think it is important we do agree on that there is a possible > > decomposition in the PCN architecture between the forward > path where > > pre-congestion marking happens, and the metering at the egress, and > > how one transports that information. Explicitly allowing that > > decomposition seems to me to be a requirement for allowing > PCN to work > > with some of the other deployment scenarios, such as MGW at > the edge > > nodes as Lars Westberg proposed, or the application aware scenarios > > that is also proposed. Otherwise they might be stuck with a lot of > > functionality that is not needed from the int-serv/diff-serv > > deployment we are taking on as first step. > > > > Looking at the future plan section of the charter I think > that covers > > this a bit insufficiently. It talks a lot of removing the > > restrictions. > > However changing the post metering transport and encoding > would allow > > PCN to be used in other deployments and is a possible way. Thus I > > would like to clarify this somehow. > > However do note that I don't propose that any work should happen in > > these direction within the proposed WG initially. > > Only that we consider this and allow in the architecture for such > > development in the future. > > > > Agreement or disagreement? > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > > ---------------------------------------------------------------------- > > 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 Fri Feb 02 14:51:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4Ri-0002FN-In; Fri, 02 Feb 2007 14:51:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4Ri-0002FI-1z for pcn@ietf.org; Fri, 02 Feb 2007 14:51:42 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD4Rf-0002SG-O9 for pcn@ietf.org; Fri, 02 Feb 2007 14:51:42 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l12JpDZ16385; Fri, 2 Feb 2007 14:51:13 -0500 (EST) 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] 3rd charter text update Date: Fri, 2 Feb 2007 14:51:12 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E755187@zcarhxm1.corp.nortel.com> In-Reply-To: <45C358E0.7070300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter text update Thread-Index: AcdG3xO73bq1+2jmSmqrUbRJrxAtWwAIjorA From: "Jozef Babiarz" To: "Magnus Westerlund" , "Anna Charny \(acharny\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: pcn@ietf.org, Lars Westberg 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 in full agreement with Magnus's suggestion in decomposition of the PCN architecture between the forward path, where pre-congestion marking happens, the monitoring of PCN marking at the egress, what information is transports from egress to ingress node and what the ingress node does with the received PCN information. Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: February 2, 2007 10:30 AM To: Anna Charny (acharny) Cc: pcn@ietf.org; Lars Westberg Subject: Re: [PCN] 3rd charter text update Anna Charny (acharny) skrev: > I agree with Lars (Eggert) - this does seem to me that this issue > belongs to the architecture document. The document should clearly > explain which functionality is minimally required. If it happens to be > less that "full fledge" it should be spelled out clearly. =20 > =20 > I think the wording of the latest charter text certainly does not > prevent at all at the moment specifying a subset functionality > necessary.=20 > =20 I think it is important we do agree on that there is a possible=20 decomposition in the PCN architecture between the forward path where=20 pre-congestion marking happens, and the metering at the egress, and how=20 one transports that information. Explicitly allowing that decomposition=20 seems to me to be a requirement for allowing PCN to work with some of=20 the other deployment scenarios, such as MGW at the edge nodes as Lars=20 Westberg proposed, or the application aware scenarios that is also=20 proposed. Otherwise they might be stuck with a lot of functionality that is not needed from the int-serv/diff-serv deployment we are taking on as first step. Looking at the future plan section of the charter I think that covers=20 this a bit insufficiently. It talks a lot of removing the restrictions.=20 However changing the post metering transport and encoding would allow=20 PCN to be used in other deployments and is a possible way. Thus I would=20 like to clarify this somehow. However do note that I don't propose that=20 any work should happen in these direction within the proposed WG=20 initially. Only that we consider this and allow in the architecture for=20 such development in the future. Agreement or disagreement? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Sat Feb 03 04:34:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDHI5-0007LP-BF; Sat, 03 Feb 2007 04:34:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDHI4-0007KD-91 for pcn@ietf.org; Sat, 03 Feb 2007 04:34:36 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDHI2-0005hF-S4 for pcn@ietf.org; Sat, 03 Feb 2007 04:34:36 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l139VUQF026131; Sat, 3 Feb 2007 11:31:30 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Feb 2007 11:34:27 +0200 Received: from [192.168.1.33] ([10.162.253.6]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 3 Feb 2007 11:34:07 +0200 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E755187@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650E755187@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <2819E9F2-53E8-4978-9E79-E83FD27C12C7@nokia.com> From: Lars Eggert Subject: Re: [PCN] 3rd charter text update Date: Sat, 3 Feb 2007 11:34:22 +0200 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Feb 2007 09:34:07.0839 (UTC) FILETIME=[73D4D6F0:01C74776] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070203113130-66002BB0-1ECAE22F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Lars Westberg , 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="===============1705008673==" Errors-To: pcn-bounces@ietf.org --===============1705008673== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-36-1062018463; protocol="application/pkcs7-signature" --Apple-Mail-36-1062018463 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-2, at 21:51, ext Jozef Babiarz wrote: > I'm in full agreement with Magnus's suggestion in decomposition of the > PCN architecture between the forward path, where pre-congestion > marking > happens, the monitoring of PCN marking at the egress, what information > is transports from egress to ingress node and what the ingress node > does > with the received PCN information. I agree that it would be useful to bring this out more clearly. It has been an underlying assumption, but you are right that the text could state this more prominently. Lars --Apple-Mail-36-1062018463 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMDMwOTM0MjNaMCMGCSqGSIb3DQEJBDEWBBToO3FFv/Qzn4PD 18ENvlCuvvziEDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAddxqTI7oGKA3L6IJ5P7YwISXps+ZydkgzF1siesoHBDbs//i5nDB Br1nS4TvWNSh7D1mJIIJyOV4G39z133JeZtCDkcsFGnRUrNHhteUMIPRxiI/MzROpiTIN7q1mXAB ogYrUOrC29z7UY493fq44rVaL/Oxc6MArOy/rgtOwUWklQrtyN3tkvwcAsRkE9Rd/88aHw854MB2 jyzNJHRPxZi+lnFAH2dd3B97DRqB4s1VKEPcVjceOX2xswIfABXLOfBJYMGOjZC2XxVWwSM5/xSP z/qJLUUKHL2lf5Vh30/jnP1t9SYvc2vy6zVcENpueoQjdBjCKn+LR5kLr0PUAAAAAAAAAA== --Apple-Mail-36-1062018463-- --===============1705008673== 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 --===============1705008673==-- From pcn-bounces@ietf.org Sat Feb 03 21:03:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDWij-0007ta-6c; Sat, 03 Feb 2007 21:03:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDWii-0007tV-HG for pcn@ietf.org; Sat, 03 Feb 2007 21:03:08 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDWih-0000H8-8X for pcn@ietf.org; Sat, 03 Feb 2007 21:03:08 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l1422mtT000512; Sat, 3 Feb 2007 21:02:49 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l140vSLr026097; Sat, 3 Feb 2007 19:57:31 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Feb 2007 21:02:41 -0500 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: Sat, 3 Feb 2007 21:02:40 -0500 Message-ID: In-reply-to: <010c01c746d5$25a95060$7f74a7d9@IBM4307EA0CEF3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN and Diffserv issues Thread-Index: AcdG1UtcssiAzjxRTC2vlrRXMXBMgABKX0XQ References: <6.2.5.6.0.20070130100927.056e6750@nortel.com><425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com><6.2.5.6.0.20070131163950.03af6318@nortel.com><31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com><6.2.5.6.0.20070201101329.032ba0e8@nortel.com><00ed01c7462b$4c6d5480$7f74a7d9@IBM4307EA0CEF3><6.2.5.6.0.20070201144629.032db0e0@nortel.com> <010c01c746d5$25a95060$7f74a7d9@IBM4307EA0CEF3> To: , X-OriginalArrivalTime: 04 Feb 2007 02:02:41.0284 (UTC) FILETIME=[8D664C40:01C74800] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.3.171933 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __FRAUD_419_BADTHINGS 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: pcn@ietf.org Subject: [PCN] PCN and Diffserv issues 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 comments were based on my discussion with LarsE. > If "a-single-DiffServ-domain" can be one or more DiffServ-domains, > my comments are not valid. RFC 2475 is reasonably precise about this. A diffserv (DS) domain is "a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions." A diffserv region is "a set of contiguous DS domains which can offer differentiated services over paths across those DS domains." The minimum requirement on PCN is that it must work on a single diffserv domain where edge nodes are edge nodes, interior nodes are interior nodes, and no node is in both categories. That is what I see proposed as immediate work in the charter text. In the longer term, one can look at spanning DS domains (i.e., PCN for DS regions), and that's what's proposed for future work in the charter text (e.g., concatenated DiffServ domains). On a different diffserv topic, I'm somewhat confused by Lars Westberg's request (NB: I spelled his name right this time, and I apologize for mangling it earlier): > Can't we add a small text into the charter so we do not required a > full-fledge Diff.serv edge functionality in the boundary nodes ??? RFC 2474 is the specification of what is minimally required for Diffserv. It doesn't require all that much. What is envisioned by "full-fledge Diff.serv edge functionality" and what piece of it is behind this concern? PCN already requires the edges to be flow-aware which is the major distinction between diffserv edge vs. interior nodes (which are not flow-aware). Thanks, --David (RFC 2474 and 2475 co-author) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Feb 04 15:51:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDoKs-0002N6-3X; Sun, 04 Feb 2007 15:51:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDoKr-0002MQ-2H for pcn@ietf.org; Sun, 04 Feb 2007 15:51:41 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDoKp-0003rx-Kz for pcn@ietf.org; Sun, 04 Feb 2007 15:51:41 -0500 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 l14Kpbv28730; Sun, 4 Feb 2007 15:51:37 -0500 (EST) 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] 3rd charter Goals and Milestones Date: Sun, 4 Feb 2007 15:51:35 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E755617@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones Thread-Index: AcdGo7yOAULbnaeoTQKbK6Cu0sum4wB+ZCFw From: "Jozef Babiarz" To: "Lars Eggert" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 I think the charter wording is good. One suggestion is that we add to the first sentence "inelastic" ... established inelastic flows within DiffServ ... so that it's clear PCN will not be used with elastic flows. However, I think we need additional discussion on Goals and Milestones:=20 >Goals and Milestones: > >Jul 2007 Flow Admission and Termination Architecture > (Informational) Would like to suggest that we allow more time for the completion of the above document as it is to be comprehensive, and include security, manageability and operational considerations as well decomposition of the PCN architecture. Suggest Nov. 2007. >Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Information within a DiffServ Domain > (Informational) I'm OK. > >Nov 2007 Flow Admission and Termination within a DiffServ > Domain (Informational) Suggest that "Flow Admission and Termination within a DiffServ Domain" be moved to Mar 2008. One meeting after the architecture.=20 >Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > (Proposed Standard) > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from within a DiffServ Domain to the Egress > (Proposed Standard) The (Pre-)Congestion Detection within a DiffServ Domain and Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress should be combined into on document.=20 Mar 2008 (Pre-)Congestion Detection and Encoding within a DiffServ Domain (Proposed Standard) > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from the Domain Egress to the Ingress > (Proposed Standard) To reflect the charter "If this WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs." The above deliverable should be change to: Mar 2008 Requirements for Signalling of (Pre-)Congestion information from Egress to Ingress Nodes in a DiffServ Domain (Informational) >Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms > (Informational) I believe that for interoperability, the WG will need to define and agree on standardized behavior for ingress and egress nodes for reaction to PCN information. Specific mechanisms should only be document as examples. The above deliverable should be changed to: =20 Mar 2008 Behavioral definition for Ingress and Egress Nodes for Flow Admission and Termination within a DiffServ Domain=20 (Proposed Standard) Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: February 2, 2007 3:25 AM To: pcn@ietf.org Subject: [PCN] 3rd charter text update Hi, attached is another charter text update. I think this is =20 significantly more clear that previous iterations and can be =20 submitted to the IESG and IAB for informal discussion. Lars --- Congestion and Pre-Congestion Notification (PCN) Chair(s): tbd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group =20 develops mechanisms to protect the quality-of-service of established =20 flows within a DiffServ domain when congestion is imminent or =20 existing. These mechanisms operate at the domain boundary, based on =20 aggregated congestion and pre-congestion information from within the =20 domain. The focus of the WG is on developing standards for the =20 marking behavior of the interior nodes and the encoding transport of =20 the congestion information. Reaction mechanisms at the boundary =20 consist of flow admission and flow termination. Although designed to =20 work together, flow admission and flow termination are independent =20 mechanisms, and the use of one does not require or prevent the use of =20 the other. In consultation with the AD, the WG may produce a small =20 number of informational documents that describe how specific quality-=20 of-service policies for a domain can be implemented using these two =20 mechanisms. The PCN WG will specify the following components to protect the =20 quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes =20 generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior, egress and ingress nodes of the domain (4) ingress node control mechanisms for flow admission or =20 termination, based on aggregated (pre-)congestion information The WG focuses on the overall architecture, and specifically on the =20 marking behavior and encoding and transport mechanisms needed to =20 realize it. Standards-track protocols and mechanisms are only =20 developed where necessary for interoperability. For other components =20 of the architecture, the WG may document examples or provide =20 recommended solutions in informational documents. The architecture =20 document will be comprehensive, and include security, manageability =20 and operational considerations. If this WG requires extensions or =20 modifications to protocols that are products of other WGs, it may =20 motivate their need and describe requirements in informational =20 documents; design of such extensions and modifications will take =20 place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following =20 assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms =20 to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, =20 MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to =20 develop solutions for scenarios where some of these restrictions are =20 not in place. It may also re-charter to consider applying the PCN =20 mechanisms to additional deployment scenarios (operation over =20 concatenated DiffServ domains, PCN-aware application mechanisms, =20 etc.). The WG may also consider to investigate additional response =20 mechanisms that act on (pre-)congestion information. One example =20 could be flow-rate adaptation (rather than flow admission/=20 termination) during times of congestion. The details of these work =20 items are outside the scope of the initial phase; but the WG may =20 consider their requirements to design components that are =20 sufficiently general to support such extensions in the future. Goals and Milestones: Jul 2007 Flow Admission and Termination Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain (Informational) Nov 2007 Flow Admission and Termination within a DiffServ Domain (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms (Informational) _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 05 03:01:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDymr-00040f-P3; Mon, 05 Feb 2007 03:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDymq-00040a-9j for pcn@ietf.org; Mon, 05 Feb 2007 03:01:16 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDymi-0006yE-I7 for pcn@ietf.org; Mon, 05 Feb 2007 03:01:16 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 5 Feb 2007 09:01:02 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:01:01 +0100 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] "Network Admission Control" (NAC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Feb 2007 09:01:01 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAFE@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdG1+Oq5BAEU2cCQwSSlmwnnD98qQAAqC7AAAEjOmAAhtEygA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 05 Feb 2007 08:01:01.0906 (UTC) FILETIME=[C72E9B20:01C748FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 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 whether "flow admission" is the correct description.=20 Wouldn' or couldn't that mean that PCN includes work on the per=20 flow admission control functionality. PCN then is chartered to=20 work on RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it=20 with Network- or Aggregate- or Per Domain Behaviour- Admission=20 Control, then the chartered PCN work could be limited to provide=20 an interface (API?) to the per flow signaling protocol. Isn't=20 the latter sufficient for the initial charter? Regards, Ruediger |-----Original Message----- |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |Sent: Friday, February 02, 2007 5:09 PM |To: Moore, Sean (Sean); Tina TSOU; menth@informatik.uni-wuerzburg.de; |Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] "Network Admission Control" (NAC) | | |I think the 'flow admission' wording in the charter is fine=20 |and we don't |need to choose a more precise term. The charter text explaining that |this flow admission happens at the domain boundary in reaction to |pre-congestion info from within the domain, etc. seems to describe it |sufficiently. | |Benny | |-----Original Message----- |From: Moore, Sean (Sean)=20 |Sent: Friday, February 02, 2007 9:59 AM |To: Tina TSOU; Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |Cc: pcn@ietf.org; Geib, Ruediger |Subject: RE: [PCN] "Network Admission Control" (NAC) | |Probably shouldn't use "Resource Admission Control" as this term (RAC) |is used in IMS and it is not the same as what we are discussing |- Sean=20 | |-----Original Message----- |From: Tina TSOU [mailto:tena@huawei.com] |Sent: Friday, February 02, 2007 9:25 AM |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |Cc: pcn@ietf.org; Geib, Ruediger |Subject: Re: [PCN] "Network Admission Control" (NAC) | |Hi, |How about Resource Admission Control or Network Resource Admission |Control? |I don't have strong opinion on that, just some terms popped up in my |mind:) | |B. R. |Tina | |----- Original Message ----- |From: "Michael Menth" |To: "Rodrig, Benny (Benny)" |Cc: ; "Geib, Ruediger" |Sent: Friday, February 02, 2007 12:16 PM |Subject: [PCN] "Network Admission Control" (NAC) | | |> Hi, |> |> I've got a comment on the term "Network Admission Control" (NAC). |> |> Wikipedia=20 |http://en.wikipedia.org/wiki/Network_Admission_Control only=20 |> knows NAC in the context of restricting access to the=20 |network based on | |> identity or security posture (it's essentially a Cisco product).=20 |> However, most important is the aspect that access is denied=20 |to a whole | |> network, subnetwork, domain, region, etc. NAC is in contrast to AC=20 |> algorithms deciding whether a new flow can be admitted to be=20 |> transported over a single link which has been studied in=20 |depth in the=20 |> 1990s in the context of ATM systems. Three years ago, I have=20 |reviewed=20 |> and studied different approaches for NAC (based on resource=20 |management |issues) in my PhD thesis: |>=20 |http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04 |> .pdf The terms connection or flow admission control are less=20 |specific=20 |> than NAC as they do not tell the scope of the AC. |> |> Best regards, |> |> Michael |> |> Rodrig, Benny (Benny) wrote: |>> What I think you mean, and the admission control that PCN=20 |deals with, | |>> better not be described as "network admission control" since that=20 |>> term often (e.g. see=20 |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |>> refers to admission based on the identity of the sender, which is=20 |>> probably out of scope for PCN. The flow admission control in PCN=20 |>> scope is based on considerations related to network status i.e. |>> pre-congestion. |>> The PCN flow admission control can be part of a call admission=20 |>> control solution, if it interacts with other mechanisms such as for=20 |>> example with Int-Serv outside the PCN domain and/or with SIP QoS=20 |>> pre-conditions. Such interactions, or assumptions about=20 |them, may not |be in the scope of PCN. |>> |>> |>> Benny |>> -----Original Message----- |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent:=20 |>> Thursday, February 01, 2007 4:44 AM |>> To: Romascanu, Dan (Dan) |>> Cc: pcn@ietf.org |>> Subject: RE: [PCN] charter, addition to scope |>> |>> Hi Dan, |>> |>> your proposal seems sound to me. My impression is the=20 |discussion may=20 |>> have approached consensus on the following issues to get chartered |>> initially: |>> |>> - PCN is limited to a single DiffServ domain. |>> - PCN aware nodes must be "on path". |>> - PCN only standardises PCN related IP layer |>> functionalities including RSVP or NSIS signaling |>> between edge nodes. |>> - PCN only works on "network admission control". |>> |>> If "Edge node" requires further definition to exclude=20 |things to close | |>> to an "end system", we should add it at appropriate places. |>> "PCN related" would exclude dealing with middleboxes doing anything=20 |>> else with packets than PCN DiffServ forwarding. |>> |>> Another question is, what the reaction of an ingress edge=20 |node should | |>> be in case of an indicated network congestion. My=20 |impression is, that | |>> with the initial charter we should just define a desired=20 |behaviour in | |>> terms of an aggregate traffic reduction (e.g. "stop admission new=20 |>> flows demanding CL forwarding or bandwidth increases of admitted=20 |>> ones" or "reduce CL traffic by x percent"). |>> Future work items may be added when the WG is re-chartered after=20 |>> having reached first aims. It may indeed be useful to think about=20 |>> some requirements for future PCN use already now. As I didn't think=20 |>> about particular topics in detail, I don't try to summarise which=20 |>> requirements that could be by this mail. |>> |>> Regards, |>> |>> Ruediger |>> |>> |>> |-----Original Message----- |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |>> |Sent: Thursday, February 01, 2007 9:45 AM |>> |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl |>> |Cc: pcn@ietf.org |>> |Subject: RE: [PCN] charter, addition to scope |>> | |>> | |>> |Maybe we should stop for a moment and consider what layer=20 |should PCN | |>> |deal with. It looks to me that we are mixing network admission=20 |>> |control and call admission control in this discussion.=20 |This problem=20 |>> |is quite complex, and there are many scenarios that need=20 |to be taken | |>> |into consideration. Sometimes flow =3D call, sometimes call=20 |=3DNOT flow=20 |>> |and sometimes there is a mix on the same path. In some cases media=20 |>> |gateways |>> |>> |are collocated with the edge nodes in some other cases not. Even=20 |>> |when flow =3D call there are two admission control layers=20 |(network and | |>> |call) that are in dependency but not identical and separate=20 |>> |protocols run at transport and session. I am not sure how much of=20 |>> |all this falls under what PCN should do. |>> | |>> |Dan |>> | |>> | |>> | |>> | |>> | | | |>> |> -----Original Message----- |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |>> |> Cc: pcn@ietf.org |>> |> Subject: RE: [PCN] charter, addition to scope |>> |> |> To all, |>> |> I agree that there must be a prioritization of flows from the |> |>> aggregation devices However, it's not just the media=20 |gateway that |>=20 |>> should speak RSVP, but the edge proxy (or firewall "proxy")=20 |as well - |>> |>> |> it is the signaling proxy at the edge that reserves the media=20 |>> |> path. |> |>> The reservation protocol request to the network from the VoIP |>=20 |>> proxy/gateway must reserve resources to the destination in the |>=20 |>> network. |>> |> The resource reservation request to the network by the edge |> |>> proxy/media gateway, must at the very minimum, meet the following |> |>> conditions: |>> |> 1. it needs to specify the resources required for the IP & ports=20 |>> |> |> |>> (RTP/RTCP & bandwidth) |>> |> for example, G.711 and G.729 voice and various MPEG-4 video=20 |>> |> codecs |>> |>> |> all have very different requirements 2. it must be mapped to the=20 |>> |> |> |>> signaling request |>> |> for SIP, it must map the SDP for media with the reservation=20 |>> |> flow - |>> |>> |> for example something along the lines of RFC 3524 |>> |> while not the answer, the mapping of the media flows is a |> |>> necessary component |>> |> It should be noted that the edge proxies/media gateways may=20 |>> |> have a |>> |>> |> large number of flows (and ports for each |>> |> RTP/RTCP flow) from the same source IP. The request=20 |is made for | |>> |> |> |>> each flow or conversation 3. it must be honored by the edge network=20 |>> |> device. |>> |> The trust boundary must be extended to the edge proxy/media |> |>> gateway for each new flow. |>> |> This brings up the issue of security authentication=20 |of the edge | |>> |> |> |>> proxy/media gateway to the network |>> |> Does this happen in EAP, NAC, or just interoperability and |> |>> certification among vendors |>> |> If the resources are not available, then the signaling=20 |>> |> indicates |> |>> the session is not completed. For example a SIP |>> |> CANCEL from the edge proxy |>> |> |> In addition, the network device must have priority queuing=20 |>> |> |> enabled |>> |> for input queues from the edge device. |>> |> The media flows must not be subject to input buffers=20 |being filled=20 |>> |> |> |>> prior to classification |>> |> |> Thanks, |>> |> Richard Lee |>> |> Fidelity Investments |>> |> Enterprise Technology and Architecture |>> |> 617-563-3278 |>> |> |> |> -----Original Message----- |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |>> |> To: karagian@cs.utwente.nl |>> |> Cc: pcn@ietf.org |>> |> Subject: RE: [PCN] charter, addition to scope |>> |> |> |> Georgios wrote: |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |>> |> > > > In the first phase of PCN work to reduce the list of |>> |> issues it was |>> |> |> > > > proposed that the WG focus on network=20 |deployment scenario |>> where |>> |> all |>> |> > > > nodes can be trusted and delay work on deployment |>> |> scenarios where |>> |> some |>> |> > > > of the nodes are not trusted. |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I |>> agree. If |>> |> "nodes" |> > > include end systems, proxies or other entities,=20 |>> |> then I |>> don't |> > > agree we had agreement on that. |>> |> > |> > Georgios: This imposes an additional restriction on the=20 |>> |> > |> > scope |>> of |> > the charter, which has been not discussed yet. |>> |> > >From what I remember before, during and after the PCN BOF |>> |> > there was no objection on using |>> |> > the term edge node, that could mean something different than a=20 |>> |> > edge |>> |> router. |>> |> > Please note that this is something different than a |>> |scenario covered |>> |> by |>> |> > an application based deployment model. |>> |> |> It's certainly not a new restriction based on the=20 |discussion in | |>> |> |> the |>> |> BOF engendered about whether a SIP telephone (used on some of the |>> |> slides) was a good example. I believe the BOF=20 |conclusion was that | |>> |> a SIP telephone was a bad example. |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |>> |proposed work: |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) The first set=20 |>> |> of issues has already been discussed extensively - my=20 |>> |> understanding is that the SIP scenario is currently out=20 |of scope,=20 |>> |> and |>> |>> |> I don't care to reopen that discussion. |>> |> |> The "telephone" issues come up in two ways: |>> |> (2a) Small number of flows may make relatively fine-grained |>> |adjustment |>> |> on the link to the phone impossible. The PCN work prior to the=20 |>> |> BOF relied on the ability to make such adjustments. |>> |> (2b) While other sorts of phones may be trusted, a SIP phone=20 |>> |> (which may be software-only) is definitely not trustable in |general. |>> |> |> I would observe that Lars Westerberg's suggestion of a Media |>> Gateway: |>> |> |> > I am referring telecom scenario where MGWs are connected to=20 |>> |> |> > an |>> |> IP-backbone. |>> |> > In these scenarios, the admission control function is=20 |a part of=20 |>> |> > the |>> |> MGW |>> |> > and not the routers. The IP-backbone is provisioned by=20 |a network | |>> |> > |> |>> > management system. |>> |> |> could avoid all of these issues: |>> |> (1) The media gateway could speak RSVP to the network management=20 |>> |> |> |>> system, |>> |> avoiding any need to deal with SIP here. |>> |> (2a) A media gateway is likely to handle enough flows to be |>> |consistent |>> |> with the fine-grained adjustment assumed by the work done to |>> date. |>> |> (2b) One can plausibly assume/require that media gateways be=20 |>> |> trusted with respect to the IP network. |>> |> To the extent that one can vest "edge" functionality in=20 |a trusted=20 |>> |> |> |>> media gateway, I see no reason to exclude that scenario. |>> |> |> Thanks, |>> |> --David |>> |> ---------------------------------------------------- |>> |> David L. Black, Senior Technologist EMC Corporation, 176 South=20 |>> |> St., Hopkinton, MA 01748 |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |>> |> ---------------------------------------------------- |>> |> |> _______________________________________________ |>> |> 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,=20 |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg,=20 |Germany,=20 |> room B206 |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 |> 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 Mon Feb 05 03:06:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDyrx-000176-Oi; Mon, 05 Feb 2007 03:06:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDyrx-00016y-DB for pcn@ietf.org; Mon, 05 Feb 2007 03:06:33 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDyrl-0007mz-Lr for pcn@ietf.org; Mon, 05 Feb 2007 03:06:33 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 93815206AA; Mon, 5 Feb 2007 09:06:12 +0100 (CET) X-AuditID: c1b4fb3c-b0fcabb0000007de-71-45c6e5745768 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B4EB20017; Mon, 5 Feb 2007 09:06:12 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:06:12 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:06:12 +0100 Message-ID: <45C6E573.6060101@ericsson.com> Date: Mon, 05 Feb 2007 09:06:11 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [PCN] PCN and Diffserv issues References: <6.2.5.6.0.20070130100927.056e6750@nortel.com><425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com><6.2.5.6.0.20070131163950.03af6318@nortel.com><31CFAAD3-B512-4508-BBE2-9E924E33F007@nokia.com><6.2.5.6.0.20070201101329.032ba0e8@nortel.com><00ed01c7462b$4c6d5480$7f74a7d9@IBM4307EA0CEF3><6.2.5.6.0.20070201144629.032db0e0@nortel.com><010c01c746d5$25a95060$7f74a7d9@IBM4307EA0CEF3> In-Reply-To: X-OriginalArrivalTime: 05 Feb 2007 08:06:12.0076 (UTC) FILETIME=[800ECAC0:01C748FC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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="===============1010507412==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1010507412== Content-Type: multipart/alternative; boundary="------------070304050101000107090402" This is a multi-part message in MIME format. --------------070304050101000107090402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit comments inline Black_David@emc.com wrote: > > > On a different diffserv topic, I'm somewhat confused by Lars > Westberg's request (NB: I spelled his name right this time, and > I apologize for mangling it earlier): > > > Can't we add a small text into the charter so we do not required a > > full-fledge Diff.serv edge functionality in the boundary nodes ??? > > RFC 2474 is the specification of what is minimally required for > Diffserv. It doesn't require all that much. What is envisioned by > "full-fledge Diff.serv edge functionality" and what piece of it > is behind this concern? PCN already requires the edges to be > flow-aware which is the major distinction between diffserv edge > vs. interior nodes (which are not flow-aware). > In PCN-network, I am interested in scenarios, when the marking-functions is used together with a flexible set boundary functions ( a flexible set of feedback and marking aggregation). The feedback and marking aggregation depends on the boundary nodes and deployment scenario. This will probably imply an requirement on the framework document. regards Lasse > > > Thanks, > --David (RFC 2474 and 2475 co-author) > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > --------------070304050101000107090402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit comments inline

Black_David@emc.com wrote:
[PCN] PCN and Diffserv issues



On a different diffserv topic, I'm somewhat confused by Lars
Westberg's request (NB: I spelled his name right this time, and
I apologize for mangling it earlier):

> Can't we add a small text into the charter so we do not required a
> full-fledge Diff.serv edge functionality in the boundary nodes ???

RFC 2474 is the specification of what is minimally required for
Diffserv. It doesn't require all that much.  What is envisioned by
"full-fledge Diff.serv edge functionality" and what piece of it
is behind this concern?  PCN already requires the edges to be
flow-aware which is the major distinction between diffserv edge
vs. interior nodes (which are not flow-aware).


In PCN-network, I am interested in scenarios, when the marking-functions is used together with a flexible set boundary functions ( a flexible set of feedback and marking aggregation).
The feedback and marking aggregation depends on the boundary nodes and deployment scenario.

This will probably imply an requirement on the framework document.

regards Lasse



Thanks,
--David (RFC 2474 and 2475 co-author)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn

--------------070304050101000107090402-- --===============1010507412== 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 --===============1010507412==-- From pcn-bounces@ietf.org Mon Feb 05 03:18:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDz35-0001pr-Ke; Mon, 05 Feb 2007 03:18:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDz34-0001pm-N3 for pcn@ietf.org; Mon, 05 Feb 2007 03:18:02 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDz33-0003rC-6L for pcn@ietf.org; Mon, 05 Feb 2007 03:18:02 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 5 Feb 2007 09:17:59 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:17:59 +0100 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 and Diffserv issues X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Feb 2007 09:17:59 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB00@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN and Diffserv issues Thread-Index: AcdG1UtcssiAzjxRTC2vlrRXMXBMgABKX0XQAD90qBA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 05 Feb 2007 08:17:59.0662 (UTC) FILETIME=[25CFD8E0:01C748FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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'd also like to ask Phil Eardly for comments. He proposed to=20 include work on "trusted DiffServ domains", which I'd interpret=20 as referring to an architecture like CarrierA_Service_Switch=20 performing per flow admission control and being connected to=20 CarrierA_Transport_network by a wholesale PCN interface having=20 no per flow funtionalities (note that Service/Transport=20 divisions could operate separately). I'm interested in looking=20 at such a scenario too. I don't want to propose an extra=20 definition if architectures like the above are covered by "a=20 single DS domain". Regards, Ruediger |-----Original Message----- |From: Black_David@emc.com [mailto:Black_David@emc.com] |Sent: Sunday, February 04, 2007 3:03 AM |To: tena@huawei.com; Lars.westberg@ericsson.com |Cc: pcn@ietf.org |Subject: [PCN] PCN and Diffserv issues | | |> My comments were based on my discussion with LarsE. |> If "a-single-DiffServ-domain" can be one or more DiffServ-domains, |> my comments are not valid. | |RFC 2475 is reasonably precise about this. A diffserv (DS) domain is |"a contiguous set of nodes which operate with a common set of service |provisioning policies and PHB definitions." A diffserv region is |"a set of contiguous DS domains which can offer differentiated |services over paths across those DS domains." | |The minimum requirement on PCN is that it must work on a single |diffserv domain where edge nodes are edge nodes, interior nodes are |interior nodes, and no node is in both categories. That is what I |see proposed as immediate work in the charter text. In the longer |term, one can look at spanning DS domains (i.e., PCN for DS regions), |and that's what's proposed for future work in the charter text |(e.g., concatenated DiffServ domains). | |On a different diffserv topic, I'm somewhat confused by Lars |Westberg's request (NB: I spelled his name right this time, and |I apologize for mangling it earlier): | |> Can't we add a small text into the charter so we do not required a |> full-fledge Diff.serv edge functionality in the boundary nodes ??? | |RFC 2474 is the specification of what is minimally required for |Diffserv. It doesn't require all that much. What is envisioned by |"full-fledge Diff.serv edge functionality" and what piece of it |is behind this concern? PCN already requires the edges to be |flow-aware which is the major distinction between diffserv edge |vs. interior nodes (which are not flow-aware). | |Thanks, |--David (RFC 2474 and 2475 co-author) |---------------------------------------------------- |David L. Black, Senior Technologist |EMC Corporation, 176 South St., Hopkinton, MA 01748 |+1 (508) 293-7953 FAX: +1 (508) 293-7786 |black_david@emc.com Mobile: +1 (978) 394-7754 |---------------------------------------------------- | |_______________________________________________ |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 Feb 05 06:31:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE246-0004Xf-7t; Mon, 05 Feb 2007 06:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE245-0004Xa-9r for pcn@ietf.org; Mon, 05 Feb 2007 06:31:17 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE23t-0001Cw-CZ for pcn@ietf.org; Mon, 05 Feb 2007 06:31:17 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:31:02 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Feb 2007 11:31:01 +0000 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 and Diffserv issues Date: Mon, 5 Feb 2007 11:31:00 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBED3@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFB00@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN and Diffserv issues Thread-Index: AcdG1UtcssiAzjxRTC2vlrRXMXBMgABKX0XQAD90qBAABuiwUA== From: To: , X-OriginalArrivalTime: 05 Feb 2007 11:31:01.0458 (UTC) FILETIME=[1D19AB20:01C74919] X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 If I understand correctly I think this is included OK. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 05 February 2007 08:18 > To: Black_David@emc.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN and Diffserv issues >=20 > I'd also like to ask Phil Eardly for comments. He proposed to > include work on "trusted DiffServ domains", which I'd interpret > as referring to an architecture like CarrierA_Service_Switch > performing per flow admission control and being connected to > CarrierA_Transport_network by a wholesale PCN interface having > no per flow funtionalities (note that Service/Transport > divisions could operate separately). I'm interested in looking > at such a scenario too. I don't want to propose an extra > definition if architectures like the above are covered by "a > single DS domain". >=20 > Regards, >=20 > Ruediger >=20 > |-----Original Message----- > |From: Black_David@emc.com [mailto:Black_David@emc.com] > |Sent: Sunday, February 04, 2007 3:03 AM > |To: tena@huawei.com; Lars.westberg@ericsson.com > |Cc: pcn@ietf.org > |Subject: [PCN] PCN and Diffserv issues > | > | > |> My comments were based on my discussion with LarsE. > |> If "a-single-DiffServ-domain" can be one or more DiffServ-domains, > |> my comments are not valid. > | > |RFC 2475 is reasonably precise about this. A diffserv (DS) domain is > |"a contiguous set of nodes which operate with a common set of service > |provisioning policies and PHB definitions." A diffserv region is > |"a set of contiguous DS domains which can offer differentiated > |services over paths across those DS domains." > | > |The minimum requirement on PCN is that it must work on a single > |diffserv domain where edge nodes are edge nodes, interior nodes are > |interior nodes, and no node is in both categories. That is what I > |see proposed as immediate work in the charter text. In the longer > |term, one can look at spanning DS domains (i.e., PCN for DS regions), > |and that's what's proposed for future work in the charter text > |(e.g., concatenated DiffServ domains). > | > |On a different diffserv topic, I'm somewhat confused by Lars > |Westberg's request (NB: I spelled his name right this time, and > |I apologize for mangling it earlier): > | > |> Can't we add a small text into the charter so we do not required a > |> full-fledge Diff.serv edge functionality in the boundary nodes ??? > | > |RFC 2474 is the specification of what is minimally required for > |Diffserv. It doesn't require all that much. What is envisioned by > |"full-fledge Diff.serv edge functionality" and what piece of it > |is behind this concern? PCN already requires the edges to be > |flow-aware which is the major distinction between diffserv edge > |vs. interior nodes (which are not flow-aware). > | > |Thanks, > |--David (RFC 2474 and 2475 co-author) > |---------------------------------------------------- > |David L. Black, Senior Technologist > |EMC Corporation, 176 South St., Hopkinton, MA 01748 > |+1 (508) 293-7953 FAX: +1 (508) 293-7786 > |black_david@emc.com Mobile: +1 (978) 394-7754 > |---------------------------------------------------- > | > |_______________________________________________ > |PCN mailing list > |PCN@ietf.org > |https://www1.ietf.org/mailman/listinfo/pcn > | >=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 Mon Feb 05 06:40:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2DG-0007ne-Gk; Mon, 05 Feb 2007 06:40:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2DG-0007nA-32 for pcn@ietf.org; Mon, 05 Feb 2007 06:40:46 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE2DC-00046v-Cn for pcn@ietf.org; Mon, 05 Feb 2007 06:40:46 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:40:40 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Feb 2007 11:40:39 +0000 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] 3rd charter Goals and Milestones Date: Mon, 5 Feb 2007 11:40:37 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBED4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E755617@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones Thread-Index: AcdGo7yOAULbnaeoTQKbK6Cu0sum4wB+ZCFwAB8ZU8A= From: To: , , X-OriginalArrivalTime: 05 Feb 2007 11:40:39.0610 (UTC) FILETIME=[75B4A9A0:01C7491A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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 The charter looks good. I agree with joe's suggested wording & Goals changes. On the issue of the timing of the milestones, I prefer the original timescales to joe's changes but either are OK with me. Where joe suggests > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) Note that there will probably be signalling mods also in the direction ingress to egress. Suggest changing "from Egress to Ingress Nodes" to "between boundary nodes" Thanks phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 04 February 2007 20:52 > To: Lars Eggert; pcn@ietf.org > Subject: RE: [PCN] 3rd charter Goals and Milestones >=20 > I think the charter wording is good. One suggestion is that we add to > the first sentence "inelastic" ... established inelastic flows within > DiffServ ... so that it's clear PCN will not be used with elastic flows. >=20 > However, I think we need additional discussion on Goals and Milestones: >=20 > >Goals and Milestones: > > > >Jul 2007 Flow Admission and Termination Architecture > > (Informational) >=20 > Would like to suggest that we allow more time for the completion of the > above document as it is to be comprehensive, and include security, > manageability and operational considerations as well decomposition of > the PCN architecture. Suggest Nov. 2007. >=20 > >Jul 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information within a DiffServ Domain > > (Informational) >=20 > I'm OK. > > > >Nov 2007 Flow Admission and Termination within a DiffServ > > Domain (Informational) >=20 > Suggest that "Flow Admission and Termination within a DiffServ Domain" > be moved to Mar 2008. One meeting after the architecture. >=20 > >Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > > (Proposed Standard) > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from within a DiffServ Domain to the Egress > > (Proposed Standard) >=20 > The (Pre-)Congestion Detection within a DiffServ Domain and Encoding and > Transport of (Pre-)Congestion Information from within a DiffServ Domain > to the Egress should be combined into on document. >=20 > Mar 2008 (Pre-)Congestion Detection and Encoding within a DiffServ > Domain > (Proposed Standard) >=20 > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from the Domain Egress to the Ingress > > (Proposed Standard) >=20 > To reflect the charter "If this WG requires extensions or modifications > to protocols that are products of other WGs, it may motivate their need > and describe requirements in informational documents; design of such > extensions and modifications will take place in the appropriate WGs." > The above deliverable should be change to: >=20 > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) >=20 >=20 > >Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms > > (Informational) >=20 > I believe that for interoperability, the WG will need to define and > agree on standardized behavior for ingress and egress nodes for reaction > to PCN information. Specific mechanisms should only be document as > examples. The above deliverable should be changed to: >=20 > Mar 2008 Behavioral definition for Ingress and Egress Nodes > for Flow Admission and Termination within a > DiffServ Domain > (Proposed Standard) >=20 >=20 > Regards, Joe > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: February 2, 2007 3:25 AM > To: pcn@ietf.org > Subject: [PCN] 3rd charter text update >=20 > Hi, >=20 > attached is another charter text update. I think this is > significantly more clear that previous iterations and can be > submitted to the IESG and IAB for informal discussion. >=20 > Lars >=20 > --- >=20 > Congestion and Pre-Congestion Notification (PCN) >=20 > Chair(s): > tbd >=20 > Transport Area Director(s): > Magnus Westerlund > Lars Eggert >=20 > Transport Area Advisor: > Lars Eggert >=20 > Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html >=20 >=20 > Description of Working Group: >=20 > The Congestion and Pre-Congestion Notification (PCN) working group > develops mechanisms to protect the quality-of-service of established > flows within a DiffServ domain when congestion is imminent or > existing. These mechanisms operate at the domain boundary, based on > aggregated congestion and pre-congestion information from within the > domain. The focus of the WG is on developing standards for the > marking behavior of the interior nodes and the encoding transport of > the congestion information. Reaction mechanisms at the boundary > consist of flow admission and flow termination. Although designed to > work together, flow admission and flow termination are independent > mechanisms, and the use of one does not require or prevent the use of > the other. In consultation with the AD, the WG may produce a small > number of informational documents that describe how specific quality- > of-service policies for a domain can be implemented using these two > mechanisms. >=20 > The PCN WG will specify the following components to protect the > quality-of-service of flows within a DiffServ domain: >=20 > (1) a general architecture for flow admission and termination based > on aggregated (pre-)congestion information >=20 > (2) a specification of conditions under which interior nodes > generate > (pre-)congestion information >=20 > (3) encoding and transport of (pre-)congestion information > between the interior, egress and ingress nodes of the domain >=20 > (4) ingress node control mechanisms for flow admission or > termination, > based on aggregated (pre-)congestion information >=20 > The WG focuses on the overall architecture, and specifically on the > marking behavior and encoding and transport mechanisms needed to > realize it. Standards-track protocols and mechanisms are only > developed where necessary for interoperability. For other components > of the architecture, the WG may document examples or provide > recommended solutions in informational documents. The architecture > document will be comprehensive, and include security, manageability > and operational considerations. If this WG requires extensions or > modifications to protocols that are products of other WGs, it may > motivate their need and describe requirements in informational > documents; design of such extensions and modifications will take > place in the appropriate WGs. >=20 >=20 > The initial scope of the PCN WG is restricted by the following > assumptions: >=20 > (A) these components are deployed in a single DiffServ domain, > where all boundary and interior nodes are PCN-enabled > and mutually trust each other >=20 > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping >=20 > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective >=20 > (D) flows may have different precedence, but the applicability > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, etc.) > is out of scope >=20 > After completion of the initial phase, the PCN WG may re-charter to > develop solutions for scenarios where some of these restrictions are > not in place. It may also re-charter to consider applying the PCN > mechanisms to additional deployment scenarios (operation over > concatenated DiffServ domains, PCN-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion information. One example > could be flow-rate adaptation (rather than flow admission/ > termination) during times of congestion. The details of these work > items are outside the scope of the initial phase; but the WG may > consider their requirements to design components that are > sufficiently general to support such extensions in the future. >=20 >=20 > Goals and Milestones: >=20 > Jul 2007 Flow Admission and Termination Architecture > (Informational) >=20 > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Information within a DiffServ Domain > (Informational) >=20 > Nov 2007 Flow Admission and Termination within a DiffServ > Domain (Informational) >=20 > Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > (Proposed Standard) >=20 > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from within a DiffServ Domain to the Egress > (Proposed Standard) >=20 > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from the Domain Egress to the Ingress > (Proposed Standard) >=20 > Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms > (Informational) >=20 >=20 >=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 Mon Feb 05 08:14:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3gR-0001IE-0Y; Mon, 05 Feb 2007 08:14:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3gP-0001I9-V8 for pcn@ietf.org; Mon, 05 Feb 2007 08:14:57 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE3gP-0001ex-CE for pcn@ietf.org; Mon, 05 Feb 2007 08:14:57 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l15DEG1A029200; Mon, 5 Feb 2007 14:14:34 +0100 (MET) From: "Georgios Karagiannis" To: "'Jozef Babiarz'" , "'Lars Eggert'" , References: <9671A92C3C8B5744BC97F855F7CB64650E755617@zcarhxm1.corp.nortel.com> Subject: RE: [PCN] 3rd charter Goals and Milestones Date: Mon, 5 Feb 2007 14:14:33 +0100 Message-ID: <003d01c74927$9c6a41b0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdGo7yOAULbnaeoTQKbK6Cu0sum4wB+ZCFwACKGpkA= In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E755617@zcarhxm1.corp.nortel.com> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Feb 2007 14:14:35 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b 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 all I agree with Joe's proposal except the last deliverable, that in my opinion should remain as is: > >Mar 2008 Suggested Flow Admission and Termination Boundary > Mechanisms > > (Informational) Best Regards, Georgios > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: zondag 4 februari 2007 21:52 > To: Lars Eggert; pcn@ietf.org > Subject: RE: [PCN] 3rd charter Goals and Milestones > > I think the charter wording is good. One suggestion is that > we add to the first sentence "inelastic" ... established > inelastic flows within DiffServ ... so that it's clear PCN > will not be used with elastic flows. > > However, I think we need additional discussion on Goals and > Milestones: > > >Goals and Milestones: > > > >Jul 2007 Flow Admission and Termination Architecture > > (Informational) > > Would like to suggest that we allow more time for the > completion of the above document as it is to be > comprehensive, and include security, manageability and > operational considerations as well decomposition of the PCN > architecture. Suggest Nov. 2007. > > >Jul 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information within a DiffServ Domain > > (Informational) > > I'm OK. > > > >Nov 2007 Flow Admission and Termination within a DiffServ > > Domain (Informational) > > Suggest that "Flow Admission and Termination within a DiffServ Domain" > be moved to Mar 2008. One meeting after the architecture. > > >Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > > (Proposed Standard) > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from within a DiffServ Domain to the Egress > > (Proposed Standard) > > The (Pre-)Congestion Detection within a DiffServ Domain and > Encoding and Transport of (Pre-)Congestion Information from > within a DiffServ Domain to the Egress should be combined > into on document. > > Mar 2008 (Pre-)Congestion Detection and Encoding within a DiffServ > Domain > (Proposed Standard) > > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from the Domain Egress to the Ingress > > (Proposed Standard) > > To reflect the charter "If this WG requires extensions or > modifications to protocols that are products of other WGs, it > may motivate their need and describe requirements in > informational documents; design of such extensions and > modifications will take place in the appropriate WGs." > The above deliverable should be change to: > > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) > > > >Mar 2008 Suggested Flow Admission and Termination Boundary > Mechanisms > > (Informational) > > I believe that for interoperability, the WG will need to > define and agree on standardized behavior for ingress and > egress nodes for reaction to PCN information. Specific > mechanisms should only be document as examples. The above > deliverable should be changed to: > > Mar 2008 Behavioral definition for Ingress and Egress Nodes > for Flow Admission and Termination within a > DiffServ Domain > (Proposed Standard) > > > Regards, Joe > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: February 2, 2007 3:25 AM > To: pcn@ietf.org > Subject: [PCN] 3rd charter text update > > Hi, > > attached is another charter text update. I think this is > significantly more clear that previous iterations and can be > submitted to the IESG and IAB for informal discussion. > > Lars > > --- > > Congestion and Pre-Congestion Notification (PCN) > > Chair(s): > tbd > > Transport Area Director(s): > Magnus Westerlund > Lars Eggert > > Transport Area Advisor: > Lars Eggert > > Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > Description of Working Group: > > The Congestion and Pre-Congestion Notification (PCN) working > group develops mechanisms to protect the quality-of-service > of established flows within a DiffServ domain when congestion > is imminent or existing. These mechanisms operate at the > domain boundary, based on aggregated congestion and > pre-congestion information from within the domain. The focus > of the WG is on developing standards for the marking behavior > of the interior nodes and the encoding transport of the > congestion information. Reaction mechanisms at the boundary > consist of flow admission and flow termination. Although > designed to work together, flow admission and flow > termination are independent mechanisms, and the use of one > does not require or prevent the use of the other. In > consultation with the AD, the WG may produce a small number > of informational documents that describe how specific > quality- of-service policies for a domain can be implemented > using these two mechanisms. > > The PCN WG will specify the following components to protect > the quality-of-service of flows within a DiffServ domain: > > (1) a general architecture for flow admission and > termination based > on aggregated (pre-)congestion information > > (2) a specification of conditions under which interior > nodes generate > (pre-)congestion information > > (3) encoding and transport of (pre-)congestion information > between the interior, egress and ingress nodes of the domain > > (4) ingress node control mechanisms for flow admission or > termination, > based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture, and specifically > on the marking behavior and encoding and transport mechanisms > needed to realize it. Standards-track protocols and > mechanisms are only developed where necessary for > interoperability. For other components of the architecture, > the WG may document examples or provide recommended solutions > in informational documents. The architecture document will be > comprehensive, and include security, manageability and > operational considerations. If this WG requires extensions or > modifications to protocols that are products of other WGs, it > may motivate their need and describe requirements in > informational documents; design of such extensions and > modifications will take place in the appropriate WGs. > > > The initial scope of the PCN WG is restricted by the following > assumptions: > > (A) these components are deployed in a single DiffServ domain, > where all boundary and interior nodes are PCN-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing > or shaping > > (C) the number of flows across any potential aggregation > bottleneck > is sufficiently large for stateless, statistical > mechanisms to be > effective > > (D) flows may have different precedence, but the applicability > of the PCN mechanisms for emergency use (911, GETS, > WPS, MLPP, etc.) > is out of scope > > After completion of the initial phase, the PCN WG may > re-charter to develop solutions for scenarios where some of > these restrictions are not in place. It may also re-charter > to consider applying the PCN mechanisms to additional > deployment scenarios (operation over concatenated DiffServ > domains, PCN-aware application mechanisms, etc.). The WG may > also consider to investigate additional response mechanisms > that act on (pre-)congestion information. One example could > be flow-rate adaptation (rather than flow admission/ > termination) during times of congestion. The details of these > work items are outside the scope of the initial phase; but > the WG may consider their requirements to design components > that are sufficiently general to support such extensions in > the future. > > > Goals and Milestones: > > Jul 2007 Flow Admission and Termination Architecture > (Informational) > > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Information within a DiffServ Domain > (Informational) > > Nov 2007 Flow Admission and Termination within a DiffServ > Domain (Informational) > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from within a DiffServ Domain to the Egress > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from the Domain Egress to the Ingress > (Proposed Standard) > > Mar 2008 Suggested Flow Admission and Termination Boundary > Mechanisms > (Informational) > > > > _______________________________________________ > 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 Feb 05 09:07:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4Ua-000532-Ng; Mon, 05 Feb 2007 09:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4UZ-00052w-AL for pcn@ietf.org; Mon, 05 Feb 2007 09:06:47 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE4UY-0001tp-JC for pcn@ietf.org; Mon, 05 Feb 2007 09:06:47 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 5 Feb 2007 15:06:45 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 15:06:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: FW: [PCN] 3rd charter Goals and Milestones Date: Mon, 5 Feb 2007 15:06:44 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB06@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones Thread-Index: AcdGo7yOAULbnaeoTQKbK6Cu0sum4wB+ZCFwAB8ZU8AABPyHUA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 05 Feb 2007 14:06:44.0889 (UTC) FILETIME=[DE381890:01C7492E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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 As Phil, I agree with Joe's suggested wording & Goals changes. But I=20 prefer Joe's suggested timing.=20 And I support Phil's proposal to foresee signaling between boundary=20 nodes. Regards, Ruediger Phil Eardley wrote: The charter looks good. I agree with joe's suggested wording & Goals changes. On the issue of the timing of the milestones, I prefer the original timescales to joe's changes but either are OK with me. Where joe suggests > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) Note that there will probably be signalling mods also in the direction ingress to egress. Suggest changing "from Egress to Ingress Nodes" to "between boundary nodes" Thanks phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 04 February 2007 20:52 > To: Lars Eggert; pcn@ietf.org > Subject: RE: [PCN] 3rd charter Goals and Milestones >=20 > I think the charter wording is good. One suggestion is that we add to > the first sentence "inelastic" ... established inelastic flows within > DiffServ ... so that it's clear PCN will not be used with elastic flows. >=20 > However, I think we need additional discussion on Goals and Milestones: >=20 > >Goals and Milestones: > > > >Jul 2007 Flow Admission and Termination Architecture > > (Informational) >=20 > Would like to suggest that we allow more time for the completion of the > above document as it is to be comprehensive, and include security, > manageability and operational considerations as well decomposition of > the PCN architecture. Suggest Nov. 2007. >=20 > >Jul 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information within a DiffServ Domain > > (Informational) >=20 > I'm OK. > > > >Nov 2007 Flow Admission and Termination within a DiffServ > > Domain (Informational) >=20 > Suggest that "Flow Admission and Termination within a DiffServ Domain" > be moved to Mar 2008. One meeting after the architecture. >=20 > >Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > > (Proposed Standard) > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from within a DiffServ Domain to the Egress > > (Proposed Standard) >=20 > The (Pre-)Congestion Detection within a DiffServ Domain and Encoding and > Transport of (Pre-)Congestion Information from within a DiffServ Domain > to the Egress should be combined into on document. >=20 > Mar 2008 (Pre-)Congestion Detection and Encoding within a DiffServ > Domain > (Proposed Standard) >=20 > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from the Domain Egress to the Ingress > > (Proposed Standard) >=20 > To reflect the charter "If this WG requires extensions or modifications > to protocols that are products of other WGs, it may motivate their need > and describe requirements in informational documents; design of such > extensions and modifications will take place in the appropriate WGs." > The above deliverable should be change to: >=20 > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) >=20 >=20 > >Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms > > (Informational) >=20 > I believe that for interoperability, the WG will need to define and > agree on standardized behavior for ingress and egress nodes for reaction > to PCN information. Specific mechanisms should only be document as > examples. The above deliverable should be changed to: >=20 > Mar 2008 Behavioral definition for Ingress and Egress Nodes > for Flow Admission and Termination within a > DiffServ Domain > (Proposed Standard) >=20 >=20 > Regards, Joe > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: February 2, 2007 3:25 AM > To: pcn@ietf.org > Subject: [PCN] 3rd charter text update >=20 > Hi, >=20 > attached is another charter text update. I think this is > significantly more clear that previous iterations and can be > submitted to the IESG and IAB for informal discussion. >=20 > Lars >=20 > --- >=20 > Congestion and Pre-Congestion Notification (PCN) >=20 > Chair(s): > tbd >=20 > Transport Area Director(s): > Magnus Westerlund > Lars Eggert >=20 > Transport Area Advisor: > Lars Eggert >=20 > Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html >=20 >=20 > Description of Working Group: >=20 > The Congestion and Pre-Congestion Notification (PCN) working group > develops mechanisms to protect the quality-of-service of established > flows within a DiffServ domain when congestion is imminent or > existing. These mechanisms operate at the domain boundary, based on > aggregated congestion and pre-congestion information from within the > domain. The focus of the WG is on developing standards for the > marking behavior of the interior nodes and the encoding transport of > the congestion information. Reaction mechanisms at the boundary > consist of flow admission and flow termination. Although designed to > work together, flow admission and flow termination are independent > mechanisms, and the use of one does not require or prevent the use of > the other. In consultation with the AD, the WG may produce a small > number of informational documents that describe how specific quality- > of-service policies for a domain can be implemented using these two > mechanisms. >=20 > The PCN WG will specify the following components to protect the > quality-of-service of flows within a DiffServ domain: >=20 > (1) a general architecture for flow admission and termination based > on aggregated (pre-)congestion information >=20 > (2) a specification of conditions under which interior nodes > generate > (pre-)congestion information >=20 > (3) encoding and transport of (pre-)congestion information > between the interior, egress and ingress nodes of the domain >=20 > (4) ingress node control mechanisms for flow admission or > termination, > based on aggregated (pre-)congestion information >=20 > The WG focuses on the overall architecture, and specifically on the > marking behavior and encoding and transport mechanisms needed to > realize it. Standards-track protocols and mechanisms are only > developed where necessary for interoperability. For other components > of the architecture, the WG may document examples or provide > recommended solutions in informational documents. The architecture > document will be comprehensive, and include security, manageability > and operational considerations. If this WG requires extensions or > modifications to protocols that are products of other WGs, it may > motivate their need and describe requirements in informational > documents; design of such extensions and modifications will take > place in the appropriate WGs. >=20 >=20 > The initial scope of the PCN WG is restricted by the following > assumptions: >=20 > (A) these components are deployed in a single DiffServ domain, > where all boundary and interior nodes are PCN-enabled > and mutually trust each other >=20 > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping >=20 > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective >=20 > (D) flows may have different precedence, but the applicability > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, etc.) > is out of scope >=20 > After completion of the initial phase, the PCN WG may re-charter to > develop solutions for scenarios where some of these restrictions are > not in place. It may also re-charter to consider applying the PCN > mechanisms to additional deployment scenarios (operation over > concatenated DiffServ domains, PCN-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion information. One example > could be flow-rate adaptation (rather than flow admission/ > termination) during times of congestion. The details of these work > items are outside the scope of the initial phase; but the WG may > consider their requirements to design components that are > sufficiently general to support such extensions in the future. >=20 >=20 > Goals and Milestones: >=20 > Jul 2007 Flow Admission and Termination Architecture > (Informational) >=20 > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Information within a DiffServ Domain > (Informational) >=20 > Nov 2007 Flow Admission and Termination within a DiffServ > Domain (Informational) >=20 > Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > (Proposed Standard) >=20 > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from within a DiffServ Domain to the Egress > (Proposed Standard) >=20 > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > from the Domain Egress to the Ingress > (Proposed Standard) >=20 > Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms > (Informational) >=20 >=20 >=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 Feb 05 09:31:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4sI-0000Bw-9A; Mon, 05 Feb 2007 09:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4sH-0000Br-J3 for pcn@ietf.org; Mon, 05 Feb 2007 09:31:17 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE4sE-0006Dc-Rr for pcn@ietf.org; Mon, 05 Feb 2007 09:31:17 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2007 06:31:14 -0800 X-IronPort-AV: i="4.13,284,1167638400"; d="scan'208"; a="109096192:sNHT600162552" 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/8.12.11) with ESMTP id l15EVDps021610; Mon, 5 Feb 2007 06:31:13 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l15EUlnj010159; Mon, 5 Feb 2007 06:31:11 -0800 (PST) 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); Mon, 5 Feb 2007 09:31:03 -0500 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] 3rd charter Goals and Milestones Date: Mon, 5 Feb 2007 09:31:01 -0500 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBED4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones Thread-Index: AcdGo7yOAULbnaeoTQKbK6Cu0sum4wB+ZCFwAB8ZU8AABgfSEA== From: "Anna Charny \(acharny\)" To: , , , X-OriginalArrivalTime: 05 Feb 2007 14:31:03.0426 (UTC) FILETIME=[43932E20:01C74932] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11471; t=1170685873; x=1171549873; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=203rd=20charter=20Goals=20and=20Milestones |Sender:=20; bh=OcE9hlbTbLzWASTCxuPviJXBTKykWzq9YTSi5oGDiKE=; b=CKrZPsGNJXneaBpixYSMWU0xzXkSMhDSf7T0J2INL5sDJSKbtlWWtiDgpZ7TXECPaN8xE0cQ QvUpETUj0a8qrT8J9RnYP/RKUQJdRhqNcWrwWRzqE6vaSEQnzODxeTlz; Authentication-Results: sj-dkim-6; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e 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 I agree with Phil's suggestion for the last deliverable. I am happy with Joe's proposals for the milestones, although I am also OK with the current ones. Anna=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: Monday, February 05, 2007 6:41 AM > To: babiarz@nortel.com; lars.eggert@nokia.com; pcn@ietf.org > Subject: RE: [PCN] 3rd charter Goals and Milestones >=20 > The charter looks good. > I agree with joe's suggested wording & Goals changes. On the=20 > issue of the timing of the milestones, I prefer the original=20 > timescales to joe's changes but either are OK with me. >=20 > Where joe suggests > > Mar 2008 Requirements for Signalling of (Pre-)Congestion=20 > information > > from Egress to Ingress Nodes in a DiffServ Domain > > (Informational) > Note that there will probably be signalling mods also in the=20 > direction ingress to egress. Suggest changing "from Egress to=20 > Ingress Nodes" to "between boundary nodes" >=20 > Thanks > phil >=20 > > -----Original Message----- > > From: Jozef Babiarz [mailto:babiarz@nortel.com] > > Sent: 04 February 2007 20:52 > > To: Lars Eggert; pcn@ietf.org > > Subject: RE: [PCN] 3rd charter Goals and Milestones > >=20 > > I think the charter wording is good. One suggestion is that=20 > we add to=20 > > the first sentence "inelastic" ... established inelastic=20 > flows within=20 > > DiffServ ... so that it's clear PCN will not be used with elastic > flows. > >=20 > > However, I think we need additional discussion on Goals and > Milestones: > >=20 > > >Goals and Milestones: > > > > > >Jul 2007 Flow Admission and Termination Architecture > > > (Informational) > >=20 > > Would like to suggest that we allow more time for the completion of > the > > above document as it is to be comprehensive, and include security,=20 > > manageability and operational considerations as well=20 > decomposition of=20 > > the PCN architecture. Suggest Nov. 2007. > >=20 > > >Jul 2007 Survey of Encoding and Transport Choices of > > > (Pre-)Congestion Information within a DiffServ Domain > > > (Informational) > >=20 > > I'm OK. > > > > > >Nov 2007 Flow Admission and Termination within a DiffServ > > > Domain (Informational) > >=20 > > Suggest that "Flow Admission and Termination within a=20 > DiffServ Domain" > > be moved to Mar 2008. One meeting after the architecture. > >=20 > > >Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > > > (Proposed Standard) > > > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > > from within a DiffServ Domain to the Egress > > > (Proposed Standard) > >=20 > > The (Pre-)Congestion Detection within a DiffServ Domain and Encoding > and > > Transport of (Pre-)Congestion Information from within a DiffServ > Domain > > to the Egress should be combined into on document. > >=20 > > Mar 2008 (Pre-)Congestion Detection and Encoding within=20 > a DiffServ > > Domain > > (Proposed Standard) > >=20 > > > > > >Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > > from the Domain Egress to the Ingress > > > (Proposed Standard) > >=20 > > To reflect the charter "If this WG requires extensions or > modifications > > to protocols that are products of other WGs, it may motivate their > need > > and describe requirements in informational documents;=20 > design of such=20 > > extensions and modifications will take place in the=20 > appropriate WGs." > > The above deliverable should be change to: > >=20 > > Mar 2008 Requirements for Signalling of (Pre-)Congestion=20 > information > > from Egress to Ingress Nodes in a DiffServ Domain > > (Informational) > >=20 > >=20 > > >Mar 2008 Suggested Flow Admission and Termination Boundary > Mechanisms > > > (Informational) > >=20 > > I believe that for interoperability, the WG will need to define and=20 > > agree on standardized behavior for ingress and egress nodes for > reaction > > to PCN information. Specific mechanisms should only be document as=20 > > examples. The above deliverable should be changed to: > >=20 > > Mar 2008 Behavioral definition for Ingress and Egress Nodes > > for Flow Admission and Termination within a > > DiffServ Domain > > (Proposed Standard) > >=20 > >=20 > > Regards, Joe > > Telephone: 613-763-6098 (ESN 393-6098) > > Email: babiarz@nortel.com > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: February 2, 2007 3:25 AM > > To: pcn@ietf.org > > Subject: [PCN] 3rd charter text update > >=20 > > Hi, > >=20 > > attached is another charter text update. I think this is=20 > significantly=20 > > more clear that previous iterations and can be submitted to=20 > the IESG=20 > > and IAB for informal discussion. > >=20 > > Lars > >=20 > > --- > >=20 > > Congestion and Pre-Congestion Notification (PCN) > >=20 > > Chair(s): > > tbd > >=20 > > Transport Area Director(s): > > Magnus Westerlund > > Lars Eggert > >=20 > > Transport Area Advisor: > > Lars Eggert > >=20 > > Mailing Lists: > > General Discussion: pcn@ietf.org > > To Subscribe: pcn-request@ietf.org > > In Body: (un)subscribe > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > >=20 > >=20 > > Description of Working Group: > >=20 > > The Congestion and Pre-Congestion Notification (PCN) working group=20 > > develops mechanisms to protect the quality-of-service of=20 > established=20 > > flows within a DiffServ domain when congestion is imminent or=20 > > existing. These mechanisms operate at the domain boundary, based on=20 > > aggregated congestion and pre-congestion information from=20 > within the=20 > > domain. The focus of the WG is on developing standards for=20 > the marking=20 > > behavior of the interior nodes and the encoding transport of the=20 > > congestion information. Reaction mechanisms at the boundary=20 > consist of=20 > > flow admission and flow termination. Although designed to work=20 > > together, flow admission and flow termination are independent=20 > > mechanisms, and the use of one does not require or prevent=20 > the use of=20 > > the other. In consultation with the AD, the WG may produce a small=20 > > number of informational documents that describe how=20 > specific quality-=20 > > of-service policies for a domain can be implemented using these two=20 > > mechanisms. > >=20 > > The PCN WG will specify the following components to protect the=20 > > quality-of-service of flows within a DiffServ domain: > >=20 > > (1) a general architecture for flow admission and termination > based > > on aggregated (pre-)congestion information > >=20 > > (2) a specification of conditions under which interior nodes=20 > > generate > > (pre-)congestion information > >=20 > > (3) encoding and transport of (pre-)congestion information > > between the interior, egress and ingress nodes of the domain > >=20 > > (4) ingress node control mechanisms for flow admission or=20 > > termination, > > based on aggregated (pre-)congestion information > >=20 > > The WG focuses on the overall architecture, and specifically on the=20 > > marking behavior and encoding and transport mechanisms needed to=20 > > realize it. Standards-track protocols and mechanisms are only=20 > > developed where necessary for interoperability. For other=20 > components=20 > > of the architecture, the WG may document examples or provide=20 > > recommended solutions in informational documents. The architecture=20 > > document will be comprehensive, and include security, manageability=20 > > and operational considerations. If this WG requires extensions or=20 > > modifications to protocols that are products of other WGs, it may=20 > > motivate their need and describe requirements in informational=20 > > documents; design of such extensions and modifications will=20 > take place=20 > > in the appropriate WGs. > >=20 > >=20 > > The initial scope of the PCN WG is restricted by the following > > assumptions: > >=20 > > (A) these components are deployed in a single DiffServ domain, > > where all boundary and interior nodes are PCN-enabled > > and mutually trust each other > >=20 > > (B) all flows handled by these mechanisms are inelastic and > > constrained to a known maximum rate through policing or > shaping > >=20 > > (C) the number of flows across any potential aggregation > bottleneck > > is sufficiently large for stateless, statistical=20 > mechanisms to=20 > > be > > effective > >=20 > > (D) flows may have different precedence, but the applicability > > of the PCN mechanisms for emergency use (911, GETS,=20 > WPS, MLPP,=20 > > etc.) > > is out of scope > >=20 > > After completion of the initial phase, the PCN WG may re-charter to=20 > > develop solutions for scenarios where some of these=20 > restrictions are=20 > > not in place. It may also re-charter to consider applying the PCN=20 > > mechanisms to additional deployment scenarios (operation over=20 > > concatenated DiffServ domains, PCN-aware application mechanisms,=20 > > etc.). The WG may also consider to investigate additional response=20 > > mechanisms that act on (pre-)congestion information. One=20 > example could=20 > > be flow-rate adaptation (rather than flow admission/ > > termination) during times of congestion. The details of these work=20 > > items are outside the scope of the initial phase; but the WG may=20 > > consider their requirements to design components that are=20 > sufficiently=20 > > general to support such extensions in the future. > >=20 > >=20 > > Goals and Milestones: > >=20 > > Jul 2007 Flow Admission and Termination Architecture > > (Informational) > >=20 > > Jul 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information within a DiffServ Domain > > (Informational) > >=20 > > Nov 2007 Flow Admission and Termination within a DiffServ > > Domain (Informational) > >=20 > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain > > (Proposed Standard) > >=20 > > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from within a DiffServ Domain to the Egress > > (Proposed Standard) > >=20 > > Mar 2008 Encoding and Transport of (Pre-)Congestion Information > > from the Domain Egress to the Ingress > > (Proposed Standard) > >=20 > > Mar 2008 Suggested Flow Admission and Termination Boundary > Mechanisms > > (Informational) > >=20 > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 05 10:30:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5o2-0006Tl-N6; Mon, 05 Feb 2007 10:30:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5o0-0006Tf-Qo for pcn@ietf.org; Mon, 05 Feb 2007 10:30:56 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE5no-0001iG-1v for pcn@ietf.org; Mon, 05 Feb 2007 10:30:56 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CB50820926; Mon, 5 Feb 2007 16:30:38 +0100 (CET) X-AuditID: c1b4fb3c-b1fccbb0000007de-2c-45c74d9e44bc Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B1B8D203CD; Mon, 5 Feb 2007 16:30:38 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 16:30:38 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 16:30:38 +0100 Message-ID: <45C74D9E.5000101@ericsson.com> Date: Mon, 05 Feb 2007 16:30:38 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] 3rd charter Goals and Milestones References: <9671A92C3C8B5744BC97F855F7CB64650E755617@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E755617@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 15:30:38.0366 (UTC) FILETIME=[9667BBE0:01C7493A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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, I think it is reasonable to push out the dates a bit. Jozef Babiarz skrev: > >> Nov 2007 (Pre-)Congestion Detection within a DiffServ Domain >> (Proposed Standard) >> >> Mar 2008 Encoding and Transport of (Pre-)Congestion Information >> from within a DiffServ Domain to the Egress >> (Proposed Standard) > > The (Pre-)Congestion Detection within a DiffServ Domain and Encoding and > Transport of (Pre-)Congestion Information from within a DiffServ Domain > to the Egress should be combined into on document. > > Mar 2008 (Pre-)Congestion Detection and Encoding within a DiffServ > Domain > (Proposed Standard) > This I don't agree with. The reasons to separate them is to allow for a reasonable decomposition. By keeping the separated in two milestones we can better ensure that the extensibility for future usages of PCN will be available. >> Mar 2008 Encoding and Transport of (Pre-)Congestion Information >> from the Domain Egress to the Ingress >> (Proposed Standard) > > To reflect the charter "If this WG requires extensions or modifications > to protocols that are products of other WGs, it may motivate their need > and describe requirements in informational documents; design of such > extensions and modifications will take place in the appropriate WGs." > The above deliverable should be change to: > > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) > So you are assuming that PCN are going to require extensions in the protocols. You might be right. However I still think there will be need for a proposed standard document in this WG on how one uses that extension. > >> Mar 2008 Suggested Flow Admission and Termination Boundary Mechanisms >> (Informational) > > I believe that for interoperability, the WG will need to define and > agree on standardized behavior for ingress and egress nodes for reaction > to PCN information. Specific mechanisms should only be document as > examples. The above deliverable should be changed to: > > Mar 2008 Behavioral definition for Ingress and Egress Nodes > for Flow Admission and Termination within a > DiffServ Domain > (Proposed Standard) > > This is not obvious. As the adaptation between how one accomplish a particular act as the result of the received information may be local in a node. And in addition it may not be unclear on how to act on that information. But this points to a possible weakness of the current charter that it doesn't talk about which QoS model we are talking about doing flow admission with in the first shot. We probably should clarify this. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Feb 05 10:32:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5py-00081O-G9; Mon, 05 Feb 2007 10:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5px-00081H-RV for pcn@ietf.org; Mon, 05 Feb 2007 10:32:57 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE5pq-0002Ef-1k for pcn@ietf.org; Mon, 05 Feb 2007 10:32:57 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71657206EB for ; Mon, 5 Feb 2007 16:32:47 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-fc-45c74e1fb79a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 57D8B2019A for ; Mon, 5 Feb 2007 16:32:47 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 16:32:47 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 16:32:47 +0100 Message-ID: <45C74E1E.2050807@ericsson.com> Date: Mon, 05 Feb 2007 16:32:46 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 15:32:47.0085 (UTC) FILETIME=[E320B1D0:01C7493A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [PCN] PCN Charter proposal version 4 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, Below is the 4th version of the PCN charter. It contains some modifications in the beginning to try to be more explicit about the decomposition. Then I also incorporated some of Jozef's comments. Cheers Magnus ---- Congestion and Pre-Congestion Notification (PCN) Chair(s): tbd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding transport of the congestion information. The transport and encoding of the congestion information is decompositioned into several components. The forward flow path to the domain boundary, the metering of the congestion situation at the boundary, and the transport of the data to the controlling peer. This decomposition is done to allow for future extensibility by defining additional variants of the components (with the exception of the first one). Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. In consultation with the AD, the WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and the egress node of the domain (4) Metering of the (pre-)congestion information at the egress node of the domain. (5) encoding and transport of (pre-)congestion information between the egress node and the ingress node of the domain (when necessary). (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the overall architecture, and specifically on the marking behavior and encoding and transport mechanisms needed to realize it. Standards-track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. If this WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Nov 2007 Flow Admission and Termination Architecture (Informational) Nov 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain (Informational) Mar 2007 Flow Admission and Termination within a DiffServ Domain (Informational) Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain (Proposed Standard) Mar 2008 Requirements for Signalling of (Pre-)Congestion information from Egress to Ingress Nodes in a DiffServ Domain (Informational) Jul 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Nov 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) Jul 2008 Suggested Flow Admission and Termination Boundary Mechanisms (Informational) -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Feb 05 13:33:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8el-0000W7-Uz; Mon, 05 Feb 2007 13:33:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8ek-0000W2-Gl for pcn@ietf.org; Mon, 05 Feb 2007 13:33:34 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8ei-00021p-NE for pcn@ietf.org; Mon, 05 Feb 2007 13:33:34 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l15IXTeL007187 for ; Mon, 5 Feb 2007 13:33:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] "Network Admission Control" (NAC) Date: Mon, 5 Feb 2007 13:33:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdG1+Oq5BAEU2cCQwSSlmwnnD98qQAAqC7AAAEjOmAAhtEygAAUn7FA References: <6439282641581441A36F7F6F83ED2ED2CBFAFE@S4DE8PSAAFQ.mitte.t-com.de> From: "Rodrig, Benny \(Benny\)" To: "Geib, Ruediger" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b 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, To me the charter doesn't seem to imply the expansion of scope that you're concerned about. Unlike many other terms "flow admission" doesn't seem to have misleading connotations. But I could be ok with "network flow admission".=20 If it is important that the charter be more explicit about this point, then perhaps a sentence should be added with some explicit description e.g. that the flow admission behavior at the boundary includes policing and/or interaction with per-flow mechanisms that are out of scope of PCN.=20 Benny =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: Monday, February 05, 2007 3:01 AM To: Rodrig, Benny (Benny) Cc: pcn@ietf.org Subject: RE: [PCN] "Network Admission Control" (NAC) I'm not sure whether "flow admission" is the correct description.=20 Wouldn' or couldn't that mean that PCN includes work on the per flow admission control functionality. PCN then is chartered to work on RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with Network- or Aggregate- or Per Domain Behaviour- Admission Control, then the chartered PCN work could be limited to provide an interface (API?) to the per flow signaling protocol. Isn't the latter sufficient for the initial charter? Regards, Ruediger |-----Original Message----- |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |Sent: Friday, February 02, 2007 5:09 PM |To: Moore, Sean (Sean); Tina TSOU; menth@informatik.uni-wuerzburg.de; |Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] "Network Admission Control" (NAC) | | |I think the 'flow admission' wording in the charter is fine and we=20 |don't need to choose a more precise term. The charter text explaining=20 |that this flow admission happens at the domain boundary in reaction to=20 |pre-congestion info from within the domain, etc. seems to describe it=20 |sufficiently. | |Benny | |-----Original Message----- |From: Moore, Sean (Sean) |Sent: Friday, February 02, 2007 9:59 AM |To: Tina TSOU; Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |Cc: pcn@ietf.org; Geib, Ruediger |Subject: RE: [PCN] "Network Admission Control" (NAC) | |Probably shouldn't use "Resource Admission Control" as this term (RAC)=20 |is used in IMS and it is not the same as what we are discussing |- Sean | |-----Original Message----- |From: Tina TSOU [mailto:tena@huawei.com] |Sent: Friday, February 02, 2007 9:25 AM |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |Cc: pcn@ietf.org; Geib, Ruediger |Subject: Re: [PCN] "Network Admission Control" (NAC) | |Hi, |How about Resource Admission Control or Network Resource Admission=20 |Control? |I don't have strong opinion on that, just some terms popped up in my |mind:) | |B. R. |Tina | |----- Original Message ----- |From: "Michael Menth" |To: "Rodrig, Benny (Benny)" |Cc: ; "Geib, Ruediger" |Sent: Friday, February 02, 2007 12:16 PM |Subject: [PCN] "Network Admission Control" (NAC) | | |> Hi, |> |> I've got a comment on the term "Network Admission Control" (NAC). |> |> Wikipedia |http://en.wikipedia.org/wiki/Network_Admission_Control only |> knows NAC in the context of restricting access to the |network based on | |> identity or security posture (it's essentially a Cisco product).=20 |> However, most important is the aspect that access is denied |to a whole | |> network, subnetwork, domain, region, etc. NAC is in contrast to AC=20 |> algorithms deciding whether a new flow can be admitted to be=20 |> transported over a single link which has been studied in |depth in the |> 1990s in the context of ATM systems. Three years ago, I have |reviewed |> and studied different approaches for NAC (based on resource |management |issues) in my PhD thesis: |>=20 |http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04 |> .pdf The terms connection or flow admission control are less |specific |> than NAC as they do not tell the scope of the AC. |> |> Best regards, |> |> Michael |> |> Rodrig, Benny (Benny) wrote: |>> What I think you mean, and the admission control that PCN |deals with, | |>> better not be described as "network admission control" since that=20 |>> term often (e.g. see |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |>> refers to admission based on the identity of the sender, which is=20 |>> probably out of scope for PCN. The flow admission control in PCN=20 |>> scope is based on considerations related to network status i.e. |>> pre-congestion. |>> The PCN flow admission control can be part of a call admission=20 |>> control solution, if it interacts with other mechanisms such as for=20 |>> example with Int-Serv outside the PCN domain and/or with SIP QoS=20 |>> pre-conditions. Such interactions, or assumptions about |them, may not |be in the scope of PCN. |>> |>> |>> Benny |>> -----Original Message----- |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent:=20 |>> Thursday, February 01, 2007 4:44 AM |>> To: Romascanu, Dan (Dan) |>> Cc: pcn@ietf.org |>> Subject: RE: [PCN] charter, addition to scope |>> |>> Hi Dan, |>> |>> your proposal seems sound to me. My impression is the |discussion may |>> have approached consensus on the following issues to get chartered |>> initially: |>> |>> - PCN is limited to a single DiffServ domain. |>> - PCN aware nodes must be "on path". |>> - PCN only standardises PCN related IP layer |>> functionalities including RSVP or NSIS signaling |>> between edge nodes. |>> - PCN only works on "network admission control". |>> |>> If "Edge node" requires further definition to exclude |things to close | |>> to an "end system", we should add it at appropriate places. |>> "PCN related" would exclude dealing with middleboxes doing anything=20 |>> else with packets than PCN DiffServ forwarding. |>> |>> Another question is, what the reaction of an ingress edge |node should | |>> be in case of an indicated network congestion. My |impression is, that | |>> with the initial charter we should just define a desired |behaviour in | |>> terms of an aggregate traffic reduction (e.g. "stop admission new=20 |>> flows demanding CL forwarding or bandwidth increases of admitted=20 |>> ones" or "reduce CL traffic by x percent"). |>> Future work items may be added when the WG is re-chartered after=20 |>> having reached first aims. It may indeed be useful to think about=20 |>> some requirements for future PCN use already now. As I didn't think=20 |>> about particular topics in detail, I don't try to summarise which=20 |>> requirements that could be by this mail. |>> |>> Regards, |>> |>> Ruediger |>> |>> |>> |-----Original Message----- |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |>> |Sent: Thursday, February 01, 2007 9:45 AM |>> |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl |>> |Cc: pcn@ietf.org |>> |Subject: RE: [PCN] charter, addition to scope |>> | |>> | |>> |Maybe we should stop for a moment and consider what layer |should PCN | |>> |deal with. It looks to me that we are mixing network admission=20 |>> |control and call admission control in this discussion. |This problem |>> |is quite complex, and there are many scenarios that need |to be taken | |>> |into consideration. Sometimes flow =3D call, sometimes call |=3DNOT flow |>> |and sometimes there is a mix on the same path. In some cases media=20 |>> |gateways |>> |>> |are collocated with the edge nodes in some other cases not. Even=20 |>> |when flow =3D call there are two admission control layers |(network and | |>> |call) that are in dependency but not identical and separate=20 |>> |protocols run at transport and session. I am not sure how much of=20 |>> |all this falls under what PCN should do. |>> | |>> |Dan |>> | |>> | |>> | |>> | |>> | | | |>> |> -----Original Message----- |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |>> |> Cc: pcn@ietf.org |>> |> Subject: RE: [PCN] charter, addition to scope |>> |> |> To all, |>> |> I agree that there must be a prioritization of flows from the |> |>> aggregation devices However, it's not just the media |gateway that |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") |as well - |>> |>> |> it is the signaling proxy at the edge that reserves the media=20 |>> |> path. |> |>> The reservation protocol request to the network from the VoIP |>=20 |>> proxy/gateway must reserve resources to the destination in the |>=20 |>> network. |>> |> The resource reservation request to the network by the edge |> |>> proxy/media gateway, must at the very minimum, meet the following |> |>> conditions: |>> |> 1. it needs to specify the resources required for the IP & ports |>> |> |> |>> (RTP/RTCP & bandwidth) |>> |> for example, G.711 and G.729 voice and various MPEG-4 video=20 |>> |> codecs |>> |>> |> all have very different requirements 2. it must be mapped to the |>> |> |> |>> signaling request |>> |> for SIP, it must map the SDP for media with the reservation=20 |>> |> flow - |>> |>> |> for example something along the lines of RFC 3524 |>> |> while not the answer, the mapping of the media flows is a |> |>> necessary component |>> |> It should be noted that the edge proxies/media gateways may=20 |>> |> have a |>> |>> |> large number of flows (and ports for each |>> |> RTP/RTCP flow) from the same source IP. The request |is made for | |>> |> |> |>> each flow or conversation 3. it must be honored by the edge network |>> |> device. |>> |> The trust boundary must be extended to the edge proxy/media |> |>> gateway for each new flow. |>> |> This brings up the issue of security authentication |of the edge | |>> |> |> |>> proxy/media gateway to the network |>> |> Does this happen in EAP, NAC, or just interoperability and |> |>> certification among vendors |>> |> If the resources are not available, then the signaling=20 |>> |> indicates |> |>> the session is not completed. For example a SIP |>> |> CANCEL from the edge proxy |>> |> |> In addition, the network device must have priority queuing=20 |>> |> |> enabled |>> |> for input queues from the edge device. |>> |> The media flows must not be subject to input buffers |being filled |>> |> |> |>> prior to classification |>> |> |> Thanks, |>> |> Richard Lee |>> |> Fidelity Investments |>> |> Enterprise Technology and Architecture |>> |> 617-563-3278 |>> |> |> |> -----Original Message----- |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |>> |> To: karagian@cs.utwente.nl |>> |> Cc: pcn@ietf.org |>> |> Subject: RE: [PCN] charter, addition to scope |>> |> |> |> Georgios wrote: |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |>> |> > > > In the first phase of PCN work to reduce the list of |>> |> issues it was |>> |> |> > > > proposed that the WG focus on network |deployment scenario |>> where |>> |> all |>> |> > > > nodes can be trusted and delay work on deployment |>> |> scenarios where |>> |> some |>> |> > > > of the nodes are not trusted. |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I |>> agree. If |>> |> "nodes" |> > > include end systems, proxies or other entities,=20 |>> |> then I |>> don't |> > > agree we had agreement on that. |>> |> > |> > Georgios: This imposes an additional restriction on the=20 |>> |> > |> > scope |>> of |> > the charter, which has been not discussed yet. |>> |> > >From what I remember before, during and after the PCN BOF |>> |> > there was no objection on using the term edge node, that could=20 |>> |> > mean something different than a edge |>> |> router. |>> |> > Please note that this is something different than a |>> |scenario covered |>> |> by |>> |> > an application based deployment model. |>> |> |> It's certainly not a new restriction based on the |discussion in | |>> |> |> the |>> |> BOF engendered about whether a SIP telephone (used on some of the |>> |> slides) was a good example. I believe the BOF |conclusion was that | |>> |> a SIP telephone was a bad example. |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |>> |proposed work: |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) The first set=20 |>> |> of issues has already been discussed extensively - my=20 |>> |> understanding is that the SIP scenario is currently out |of scope, |>> |> and |>> |>> |> I don't care to reopen that discussion. |>> |> |> The "telephone" issues come up in two ways: |>> |> (2a) Small number of flows may make relatively fine-grained |>> |adjustment |>> |> on the link to the phone impossible. The PCN work prior to the=20 |>> |> BOF relied on the ability to make such adjustments. |>> |> (2b) While other sorts of phones may be trusted, a SIP phone=20 |>> |> (which may be software-only) is definitely not trustable in |general. |>> |> |> I would observe that Lars Westerberg's suggestion of a Media |>> Gateway: |>> |> |> > I am referring telecom scenario where MGWs are connected to=20 |>> |> |> > an |>> |> IP-backbone. |>> |> > In these scenarios, the admission control function is |a part of |>> |> > the |>> |> MGW |>> |> > and not the routers. The IP-backbone is provisioned by |a network | |>> |> > |> |>> > management system. |>> |> |> could avoid all of these issues: |>> |> (1) The media gateway could speak RSVP to the network management |>> |> |> |>> system, |>> |> avoiding any need to deal with SIP here. |>> |> (2a) A media gateway is likely to handle enough flows to be |>> |consistent |>> |> with the fine-grained adjustment assumed by the work done to |>> date. |>> |> (2b) One can plausibly assume/require that media gateways be=20 |>> |> trusted with respect to the IP network. |>> |> To the extent that one can vest "edge" functionality in |a trusted |>> |> |> |>> media gateway, I see no reason to exclude that scenario. |>> |> |> Thanks, |>> |> --David |>> |> ---------------------------------------------------- |>> |> David L. Black, Senior Technologist EMC Corporation, 176 South=20 |>> |> St., Hopkinton, MA 01748 |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |>> |> ---------------------------------------------------- |>> |> |> _______________________________________________ |>> |> 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,=20 |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, |Germany, |> room B206 |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 |> 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 Mon Feb 05 13:56:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE90T-0003wY-S5; Mon, 05 Feb 2007 13:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE90T-0003wT-GG for pcn@ietf.org; Mon, 05 Feb 2007 13:56:01 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE90R-0007G7-Vn for pcn@ietf.org; Mon, 05 Feb 2007 13:56:01 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l15Itw4U031318 for ; Mon, 5 Feb 2007 13:55:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] PCN Charter proposal version 4 Date: Mon, 5 Feb 2007 13:55:58 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjw References: <45C74E1E.2050807@ericsson.com> From: "Rodrig, Benny \(Benny\)" To: "Magnus Westerlund" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 I think it was good to add to the milestones the 'Requirements for Signaling of (Pre-)Congestion information from Egress to Ingress Nodes in a DiffServ Domain (Informational)' per Joe's suggestion.=20 Now isn't there something puzzling in keeping 'Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress' as a Proposed Standard? Proposed Standard seems to suggest that the PCN WG will be defining protocol mechanisms for this, which is not obviously the case. What if this relies on other protocols that may be running between the boundary nodes in different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in SIP)? In that case such a document, if at all needed, would probably have to be just a BCP. Benny -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, February 05, 2007 10:33 AM To: pcn@ietf.org Subject: [PCN] PCN Charter proposal version 4 Hi, Below is the 4th version of the PCN charter. It contains some modifications in the beginning to try to be more explicit about the decomposition. Then I also incorporated some of Jozef's comments. Cheers Magnus ---- Congestion and Pre-Congestion Notification (PCN) Chair(s): tbd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established flows within a DiffServ domain when congestion is imminent or existing.=20 These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding transport of the congestion information. The transport and encoding of the congestion information is decompositioned into several components. The forward flow path to the domain boundary, the metering of the congestion situation at the boundary, and the transport of the data to the controlling peer. This decomposition is done to allow for future extensibility by defining additional variants of the components (with the exception of the first one). Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. In consultation with the AD, the WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and the egress node of the domain (4) Metering of the (pre-)congestion information at the egress node of the domain. (5) encoding and transport of (pre-)congestion information between the egress node and the ingress node of the domain (when necessary). (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the overall architecture, and specifically on the marking behavior and encoding and transport mechanisms needed to realize it. Standards-track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. If this WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Nov 2007 Flow Admission and Termination Architecture (Informational) Nov 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain (Informational) Mar 2007 Flow Admission and Termination within a DiffServ Domain (Informational) Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain (Proposed Standard) Mar 2008 Requirements for Signalling of (Pre-)Congestion information from Egress to Ingress Nodes in a DiffServ Domain (Informational) Jul 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Nov 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) Jul 2008 Suggested Flow Admission and Termination Boundary Mechanisms (Informational) --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Feb 05 14:39:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9gm-0003vk-N3; Mon, 05 Feb 2007 14:39:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9gm-0003vf-7Y for pcn@ietf.org; Mon, 05 Feb 2007 14:39:44 -0500 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 1HE9gj-00084X-Ki for pcn@ietf.org; Mon, 05 Feb 2007 14:39:44 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 985864283; Mon, 5 Feb 2007 20:39:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8A2895315; Mon, 5 Feb 2007 20:39:34 +0100 (CET) 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 0D9494059; Mon, 5 Feb 2007 20:39:34 +0100 (CET) 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 l15JdXs23826; Mon, 5 Feb 2007 20:39:33 +0100 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 108886F58E; Mon, 5 Feb 2007 20:36:20 +0100 (CET) Message-ID: <45C78759.2020208@informatik.uni-wuerzburg.de> Date: Mon, 05 Feb 2007 20:36:57 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Rodrig, Benny (Benny)" Subject: Re: [PCN] "Network Admission Control" (NAC) References: <6439282641581441A36F7F6F83ED2ED2CBFAFE@S4DE8PSAAFQ.mitte.t-com.de> 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: a50b6fe619b8c4df89c7095cedd22e37 Cc: pcn@ietf.org, "Geib, Ruediger" 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, the word NAC itself means that access is possibly denied to a network which can be due to security or resource reasons. NAC in the security context has become a quite popular expression as it is the name of a Cisco product. The name NAC sounds good (to me) as it is very catchy and easy to understand also for non-experts. I don't see a large problem when the term NAC exists in different contexts. If people need to distinguish both approaches, security-related NAC and resource-related NAC can be used. However, people working in both areas might see this differently. As the new version of the PCN charter talks about domains, domain admission control (DAC) would be a natural substitute for NAC. DAC has no misleading connotations, but it doesn't sound nice (to me). Better sounds maybe per-domain AC (PDAC) and concisely states what it is. In analogy to routing, intradomain admission control is another option, but it also implies the existence of interdomain admission control. I'm not sure whether we want this right now. If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN charter, we can leave this issue open until we have a clearer opinion. Michael Rodrig, Benny (Benny) wrote: > Ruediger, > > To me the charter doesn't seem to imply the expansion of scope that > you're concerned about. Unlike many other terms "flow admission" doesn't > seem to have misleading connotations. But I could be ok with "network > flow admission". > > If it is important that the charter be more explicit about this point, > then perhaps a sentence should be added with some explicit description > e.g. that the flow admission behavior at the boundary includes policing > and/or interaction with per-flow mechanisms that are out of scope of > PCN. > > Benny > > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Monday, February 05, 2007 3:01 AM > To: Rodrig, Benny (Benny) > Cc: pcn@ietf.org > Subject: RE: [PCN] "Network Admission Control" (NAC) > > I'm not sure whether "flow admission" is the correct description. > Wouldn' or couldn't that mean that PCN includes work on the per flow > admission control functionality. PCN then is chartered to work on > RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with Network- or > Aggregate- or Per Domain Behaviour- Admission Control, then the > chartered PCN work could be limited to provide an interface (API?) to > the per flow signaling protocol. Isn't the latter sufficient for the > initial charter? > > Regards, > > Ruediger > > |-----Original Message----- > |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > |Sent: Friday, February 02, 2007 5:09 PM > |To: Moore, Sean (Sean); Tina TSOU; menth@informatik.uni-wuerzburg.de; > |Geib, Rudiger > |Cc: pcn@ietf.org > |Subject: RE: [PCN] "Network Admission Control" (NAC) > | > | > |I think the 'flow admission' wording in the charter is fine and we > |don't need to choose a more precise term. The charter text explaining > |that this flow admission happens at the domain boundary in reaction to > |pre-congestion info from within the domain, etc. seems to describe it > |sufficiently. > | > |Benny > | > |-----Original Message----- > |From: Moore, Sean (Sean) > |Sent: Friday, February 02, 2007 9:59 AM > |To: Tina TSOU; Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de > |Cc: pcn@ietf.org; Geib, Ruediger > |Subject: RE: [PCN] "Network Admission Control" (NAC) > | > |Probably shouldn't use "Resource Admission Control" as this term (RAC) > |is used in IMS and it is not the same as what we are discussing > |- Sean > | > |-----Original Message----- > |From: Tina TSOU [mailto:tena@huawei.com] > |Sent: Friday, February 02, 2007 9:25 AM > |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de > |Cc: pcn@ietf.org; Geib, Ruediger > |Subject: Re: [PCN] "Network Admission Control" (NAC) > | > |Hi, > |How about Resource Admission Control or Network Resource Admission > |Control? > |I don't have strong opinion on that, just some terms popped up in my > |mind:) > | > |B. R. > |Tina > | > |----- Original Message ----- > |From: "Michael Menth" > |To: "Rodrig, Benny (Benny)" > |Cc: ; "Geib, Ruediger" > |Sent: Friday, February 02, 2007 12:16 PM > |Subject: [PCN] "Network Admission Control" (NAC) > | > | > |> Hi, > |> > |> I've got a comment on the term "Network Admission Control" (NAC). > |> > |> Wikipedia > |http://en.wikipedia.org/wiki/Network_Admission_Control only > |> knows NAC in the context of restricting access to the > |network based on > | > |> identity or security posture (it's essentially a Cisco product). > |> However, most important is the aspect that access is denied > |to a whole > | > |> network, subnetwork, domain, region, etc. NAC is in contrast to AC > |> algorithms deciding whether a new flow can be admitted to be > |> transported over a single link which has been studied in > |depth in the > |> 1990s in the context of ATM systems. Three years ago, I have > |reviewed > |> and studied different approaches for NAC (based on resource > |management > |issues) in my PhD thesis: > |> > |http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04 > |> .pdf The terms connection or flow admission control are less > |specific > |> than NAC as they do not tell the scope of the AC. > |> > |> Best regards, > |> > |> Michael > |> > |> Rodrig, Benny (Benny) wrote: > |>> What I think you mean, and the admission control that PCN > |deals with, > | > |>> better not be described as "network admission control" since that > |>> term often (e.g. see > |>> http://en.wikipedia.org/wiki/Network_Admission_Control) > |>> refers to admission based on the identity of the sender, which is > |>> probably out of scope for PCN. The flow admission control in PCN > |>> scope is based on considerations related to network status i.e. > |>> pre-congestion. > |>> The PCN flow admission control can be part of a call admission > |>> control solution, if it interacts with other mechanisms such as for > |>> example with Int-Serv outside the PCN domain and/or with SIP QoS > |>> pre-conditions. Such interactions, or assumptions about > |them, may not > |be in the scope of PCN. > |>> > |>> > |>> Benny > |>> -----Original Message----- > |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: > |>> Thursday, February 01, 2007 4:44 AM > |>> To: Romascanu, Dan (Dan) > |>> Cc: pcn@ietf.org > |>> Subject: RE: [PCN] charter, addition to scope > |>> > |>> Hi Dan, > |>> > |>> your proposal seems sound to me. My impression is the > |discussion may > |>> have approached consensus on the following issues to get chartered > |>> initially: > |>> > |>> - PCN is limited to a single DiffServ domain. > |>> - PCN aware nodes must be "on path". > |>> - PCN only standardises PCN related IP layer > |>> functionalities including RSVP or NSIS signaling > |>> between edge nodes. > |>> - PCN only works on "network admission control". > |>> > |>> If "Edge node" requires further definition to exclude > |things to close > | > |>> to an "end system", we should add it at appropriate places. > |>> "PCN related" would exclude dealing with middleboxes doing anything > |>> else with packets than PCN DiffServ forwarding. > |>> > |>> Another question is, what the reaction of an ingress edge > |node should > | > |>> be in case of an indicated network congestion. My > |impression is, that > | > |>> with the initial charter we should just define a desired > |behaviour in > | > |>> terms of an aggregate traffic reduction (e.g. "stop admission new > |>> flows demanding CL forwarding or bandwidth increases of admitted > |>> ones" or "reduce CL traffic by x percent"). > |>> Future work items may be added when the WG is re-chartered after > |>> having reached first aims. It may indeed be useful to think about > |>> some requirements for future PCN use already now. As I didn't think > |>> about particular topics in detail, I don't try to summarise which > |>> requirements that could be by this mail. > |>> > |>> Regards, > |>> > |>> Ruediger > |>> > |>> > |>> |-----Original Message----- > |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > |>> |Sent: Thursday, February 01, 2007 9:45 AM > |>> |To: Lee, Richard FTC; Black_David@emc.com; karagian@cs.utwente.nl > |>> |Cc: pcn@ietf.org > |>> |Subject: RE: [PCN] charter, addition to scope > |>> | > |>> | > |>> |Maybe we should stop for a moment and consider what layer > |should PCN > | > |>> |deal with. It looks to me that we are mixing network admission > |>> |control and call admission control in this discussion. > |This problem > |>> |is quite complex, and there are many scenarios that need > |to be taken > | > |>> |into consideration. Sometimes flow = call, sometimes call > |=NOT flow > |>> |and sometimes there is a mix on the same path. In some cases media > |>> |gateways > |>> > |>> |are collocated with the edge nodes in some other cases not. Even > |>> |when flow = call there are two admission control layers > |(network and > | > |>> |call) that are in dependency but not identical and separate > |>> |protocols run at transport and session. I am not sure how much of > |>> |all this falls under what PCN should do. > |>> | > |>> |Dan > |>> | > |>> | > |>> | > |>> | > |>> | | | > |>> |> -----Original Message----- > |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > |>> |> Sent: Wednesday, January 31, 2007 11:28 PM > |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl > |>> |> Cc: pcn@ietf.org > |>> |> Subject: RE: [PCN] charter, addition to scope > |>> |> |> To all, > |>> |> I agree that there must be a prioritization of flows from the |> > |>> aggregation devices However, it's not just the media > |gateway that |> > |>> should speak RSVP, but the edge proxy (or firewall "proxy") > |as well - > |>> > |>> |> it is the signaling proxy at the edge that reserves the media > |>> |> path. |> > |>> The reservation protocol request to the network from the VoIP |> > |>> proxy/gateway must reserve resources to the destination in the |> > |>> network. > |>> |> The resource reservation request to the network by the edge |> > |>> proxy/media gateway, must at the very minimum, meet the following |> > |>> conditions: > |>> |> 1. it needs to specify the resources required for the IP & ports > |>> |> |> > |>> (RTP/RTCP & bandwidth) > |>> |> for example, G.711 and G.729 voice and various MPEG-4 video > |>> |> codecs > |>> > |>> |> all have very different requirements 2. it must be mapped to the > |>> |> |> > |>> signaling request > |>> |> for SIP, it must map the SDP for media with the reservation > |>> |> flow - > |>> > |>> |> for example something along the lines of RFC 3524 > |>> |> while not the answer, the mapping of the media flows is a |> > |>> necessary component > |>> |> It should be noted that the edge proxies/media gateways may > |>> |> have a > |>> > |>> |> large number of flows (and ports for each > |>> |> RTP/RTCP flow) from the same source IP. The request > |is made for > | > |>> |> |> > |>> each flow or conversation 3. it must be honored by the edge network > |>> |> device. > |>> |> The trust boundary must be extended to the edge proxy/media |> > |>> gateway for each new flow. > |>> |> This brings up the issue of security authentication > |of the edge > | > |>> |> |> > |>> proxy/media gateway to the network > |>> |> Does this happen in EAP, NAC, or just interoperability and |> > |>> certification among vendors > |>> |> If the resources are not available, then the signaling > |>> |> indicates |> > |>> the session is not completed. For example a SIP > |>> |> CANCEL from the edge proxy > |>> |> |> In addition, the network device must have priority queuing > |>> |> |> enabled > |>> |> for input queues from the edge device. > |>> |> The media flows must not be subject to input buffers > |being filled > |>> |> |> > |>> prior to classification > |>> |> |> Thanks, > |>> |> Richard Lee > |>> |> Fidelity Investments > |>> |> Enterprise Technology and Architecture > |>> |> 617-563-3278 > |>> |> |> |> -----Original Message----- > |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] > |>> |> Sent: Wednesday, January 31, 2007 2:30 PM > |>> |> To: karagian@cs.utwente.nl > |>> |> Cc: pcn@ietf.org > |>> |> Subject: RE: [PCN] charter, addition to scope > |>> |> |> |> Georgios wrote: > |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > |>> |> > > > In the first phase of PCN work to reduce the list of > |>> |> issues it was > |>> |> |> > > > proposed that the WG focus on network > |deployment scenario > |>> where > |>> |> all > |>> |> > > > nodes can be trusted and delay work on deployment > |>> |> scenarios where > |>> |> some > |>> |> > > > of the nodes are not trusted. > |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, then yes, I > |>> agree. If > |>> |> "nodes" |> > > include end systems, proxies or other entities, > |>> |> then I > |>> don't |> > > agree we had agreement on that. > |>> |> > |> > Georgios: This imposes an additional restriction on the > |>> |> > |> > scope > |>> of |> > the charter, which has been not discussed yet. > |>> |> > >From what I remember before, during and after the PCN BOF > |>> |> > there was no objection on using the term edge node, that could > |>> |> > mean something different than a edge > |>> |> router. > |>> |> > Please note that this is something different than a > |>> |scenario covered > |>> |> by > |>> |> > an application based deployment model. > |>> |> |> It's certainly not a new restriction based on the > |discussion in > | > |>> |> |> the > |>> |> BOF engendered about whether a SIP telephone (used on some of the > |>> |> slides) was a good example. I believe the BOF > |conclusion was that > | > |>> |> a SIP telephone was a bad example. > |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the > |>> |proposed work: > |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) The first set > |>> |> of issues has already been discussed extensively - my > |>> |> understanding is that the SIP scenario is currently out > |of scope, > |>> |> and > |>> > |>> |> I don't care to reopen that discussion. > |>> |> |> The "telephone" issues come up in two ways: > |>> |> (2a) Small number of flows may make relatively fine-grained > |>> |adjustment > |>> |> on the link to the phone impossible. The PCN work prior to the > |>> |> BOF relied on the ability to make such adjustments. > |>> |> (2b) While other sorts of phones may be trusted, a SIP phone > |>> |> (which may be software-only) is definitely not trustable in > |general. > |>> |> |> I would observe that Lars Westerberg's suggestion of a Media > |>> Gateway: > |>> |> |> > I am referring telecom scenario where MGWs are connected to > |>> |> |> > an > |>> |> IP-backbone. > |>> |> > In these scenarios, the admission control function is > |a part of > |>> |> > the > |>> |> MGW > |>> |> > and not the routers. The IP-backbone is provisioned by > |a network > | > |>> |> > |> > |>> > management system. > |>> |> |> could avoid all of these issues: > |>> |> (1) The media gateway could speak RSVP to the network management > |>> |> |> > |>> system, > |>> |> avoiding any need to deal with SIP here. > |>> |> (2a) A media gateway is likely to handle enough flows to be > |>> |consistent > |>> |> with the fine-grained adjustment assumed by the work done to > |>> date. > |>> |> (2b) One can plausibly assume/require that media gateways be > |>> |> trusted with respect to the IP network. > |>> |> To the extent that one can vest "edge" functionality in > |a trusted > |>> |> |> > |>> media gateway, I see no reason to exclude that scenario. > |>> |> |> Thanks, > |>> |> --David > |>> |> ---------------------------------------------------- > |>> |> David L. Black, Senior Technologist EMC Corporation, 176 South > |>> |> St., Hopkinton, MA 01748 > |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 > |>> |> ---------------------------------------------------- > |>> |> |> _______________________________________________ > |>> |> 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 > | > | > | > > > _______________________________________________ > 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 Tue Feb 06 03:18:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELWw-0001Nq-Tb; Tue, 06 Feb 2007 03:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELWv-0001NY-KZ for pcn@ietf.org; Tue, 06 Feb 2007 03:18:21 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HELWr-0006Vb-Hq for pcn@ietf.org; Tue, 06 Feb 2007 03:18:21 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 6 Feb 2007 09:18:14 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 09:18:13 +0100 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: RE: [PCN] "Network Admission Control" (NAC) Date: Tue, 6 Feb 2007 09:18:12 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB0C@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <45C78759.2020208@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdJXWB62tBAVOtAQq6PRkrVU6CYlgAaPllQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 06 Feb 2007 08:18:13.0451 (UTC) FILETIME=[5871A1B0:01C749C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab 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 Benny, I prefer Michaels proposal, NAC or DAC is allright with me if we=20 provide a definition for our terminology. The same would hold=20 if "flow admission" is used, which I feel to be to close to=20 "per flow". A side note on the abbreviation NAC: it is also described as=20 Network Access Control by Wikipedia. I've checked that because=20 within my company what is described by Wiki as Network=20 "Admission Control" is called Network Access Control. Regards, Ruediger |-----Original Message----- |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |Sent: Monday, February 05, 2007 8:37 PM |To: Rodrig, Benny (Benny) |Cc: Geib, R=FCdiger; pcn@ietf.org |Subject: Re: [PCN] "Network Admission Control" (NAC) | | |Hi, | |the word NAC itself means that access is possibly denied to a network=20 |which can be due to security or resource reasons. NAC in the security=20 |context has become a quite popular expression as it is the name of a=20 |Cisco product. The name NAC sounds good (to me) as it is very catchy = and=20 |easy to understand also for non-experts. I don't see a large problem=20 |when the term NAC exists in different contexts. If people need to=20 |distinguish both approaches, security-related NAC and resource-related=20 |NAC can be used. However, people working in both areas might see this=20 |differently. | |As the new version of the PCN charter talks about domains, domain=20 |admission control (DAC) would be a natural substitute for NAC. DAC has=20 |no misleading connotations, but it doesn't sound nice (to me). Better=20 |sounds maybe per-domain AC (PDAC) and concisely states what it is. In=20 |analogy to routing, intradomain admission control is another option, = but=20 |it also implies the existence of interdomain admission control. I'm not = |sure whether we want this right now. |=20 |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN=20 |charter, we can leave this issue open until we have a clearer opinion. | | Michael | |Rodrig, Benny (Benny) wrote: |> Ruediger, |> |> To me the charter doesn't seem to imply the expansion of scope that |> you're concerned about. Unlike many other terms "flow admission" = doesn't |> seem to have misleading connotations. But I could be ok with "network |> flow admission".=20 |> |> If it is important that the charter be more explicit about this = point, |> then perhaps a sentence should be added with some explicit = description |> e.g. that the flow admission behavior at the boundary includes = policing |> and/or interaction with per-flow mechanisms that are out of scope of |> PCN.=20 |> |> Benny |> =20 |> |> -----Original Message----- |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |> Sent: Monday, February 05, 2007 3:01 AM |> To: Rodrig, Benny (Benny) |> Cc: pcn@ietf.org |> Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> I'm not sure whether "flow admission" is the correct description.=20 |> Wouldn' or couldn't that mean that PCN includes work on the per flow |> admission control functionality. PCN then is chartered to work on |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with=20 |Network- or |> Aggregate- or Per Domain Behaviour- Admission Control, then the |> chartered PCN work could be limited to provide an interface (API?) to |> the per flow signaling protocol. Isn't the latter sufficient for the |> initial charter? |> |> Regards, |> |> Ruediger |> |> |-----Original Message----- |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |> |Sent: Friday, February 02, 2007 5:09 PM |> |To: Moore, Sean (Sean); Tina TSOU;=20 |menth@informatik.uni-wuerzburg.de; |> |Geib, Rudiger |> |Cc: pcn@ietf.org |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> | |> | |> |I think the 'flow admission' wording in the charter is fine and we=20 |> |don't need to choose a more precise term. The charter text=20 |explaining=20 |> |that this flow admission happens at the domain boundary in=20 |reaction to=20 |> |pre-congestion info from within the domain, etc. seems to=20 |describe it=20 |> |sufficiently. |> | |> |Benny |> | |> |-----Original Message----- |> |From: Moore, Sean (Sean) |> |Sent: Friday, February 02, 2007 9:59 AM |> |To: Tina TSOU; Rodrig, Benny (Benny);=20 |menth@informatik.uni-wuerzburg.de |> |Cc: pcn@ietf.org; Geib, Ruediger |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> | |> |Probably shouldn't use "Resource Admission Control" as this=20 |term (RAC)=20 |> |is used in IMS and it is not the same as what we are discussing |> |- Sean |> | |> |-----Original Message----- |> |From: Tina TSOU [mailto:tena@huawei.com] |> |Sent: Friday, February 02, 2007 9:25 AM |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |> |Cc: pcn@ietf.org; Geib, Ruediger |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> | |> |Hi, |> |How about Resource Admission Control or Network Resource Admission=20 |> |Control? |> |I don't have strong opinion on that, just some terms popped up in my |> |mind:) |> | |> |B. R. |> |Tina |> | |> |----- Original Message ----- |> |From: "Michael Menth" |> |To: "Rodrig, Benny (Benny)" |> |Cc: ; "Geib, Ruediger" |> |Sent: Friday, February 02, 2007 12:16 PM |> |Subject: [PCN] "Network Admission Control" (NAC) |> | |> | |> |> Hi, |> |> |> |> I've got a comment on the term "Network Admission Control" (NAC). |> |> |> |> Wikipedia |> |http://en.wikipedia.org/wiki/Network_Admission_Control only |> |> knows NAC in the context of restricting access to the |> |network based on |> | |> |> identity or security posture (it's essentially a Cisco product).=20 |> |> However, most important is the aspect that access is denied |> |to a whole |> | |> |> network, subnetwork, domain, region, etc. NAC is in=20 |contrast to AC=20 |> |> algorithms deciding whether a new flow can be admitted to be=20 |> |> transported over a single link which has been studied in |> |depth in the |> |> 1990s in the context of ATM systems. Three years ago, I have |> |reviewed |> |> and studied different approaches for NAC (based on resource |> |management |> |issues) in my PhD thesis: |> |>=20 |>=20 ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04 |> |> .pdf The terms connection or flow admission control are less |> |specific |> |> than NAC as they do not tell the scope of the AC. |> |> |> |> Best regards, |> |> |> |> Michael |> |> |> |> Rodrig, Benny (Benny) wrote: |> |>> What I think you mean, and the admission control that PCN |> |deals with, |> | |> |>> better not be described as "network admission control"=20 |since that=20 |> |>> term often (e.g. see |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |> |>> refers to admission based on the identity of the sender,=20 |which is=20 |> |>> probably out of scope for PCN. The flow admission control in PCN=20 |> |>> scope is based on considerations related to network status i.e. |> |>> pre-congestion. |> |>> The PCN flow admission control can be part of a call admission=20 |> |>> control solution, if it interacts with other mechanisms=20 |such as for=20 |> |>> example with Int-Serv outside the PCN domain and/or with SIP QoS=20 |> |>> pre-conditions. Such interactions, or assumptions about |> |them, may not |> |be in the scope of PCN. |> |>> |> |>> |> |>> Benny |> |>> -----Original Message----- |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent:=20 |> |>> Thursday, February 01, 2007 4:44 AM |> |>> To: Romascanu, Dan (Dan) |> |>> Cc: pcn@ietf.org |> |>> Subject: RE: [PCN] charter, addition to scope |> |>> |> |>> Hi Dan, |> |>> |> |>> your proposal seems sound to me. My impression is the |> |discussion may |> |>> have approached consensus on the following issues to get=20 |chartered |> |>> initially: |> |>> |> |>> - PCN is limited to a single DiffServ domain. |> |>> - PCN aware nodes must be "on path". |> |>> - PCN only standardises PCN related IP layer |> |>> functionalities including RSVP or NSIS signaling |> |>> between edge nodes. |> |>> - PCN only works on "network admission control". |> |>> |> |>> If "Edge node" requires further definition to exclude |> |things to close |> | |> |>> to an "end system", we should add it at appropriate places. |> |>> "PCN related" would exclude dealing with middleboxes=20 |doing anything=20 |> |>> else with packets than PCN DiffServ forwarding. |> |>> |> |>> Another question is, what the reaction of an ingress edge |> |node should |> | |> |>> be in case of an indicated network congestion. My |> |impression is, that |> | |> |>> with the initial charter we should just define a desired |> |behaviour in |> | |> |>> terms of an aggregate traffic reduction (e.g. "stop=20 |admission new=20 |> |>> flows demanding CL forwarding or bandwidth increases of admitted=20 |> |>> ones" or "reduce CL traffic by x percent"). |> |>> Future work items may be added when the WG is re-chartered after=20 |> |>> having reached first aims. It may indeed be useful to=20 |think about=20 |> |>> some requirements for future PCN use already now. As I=20 |didn't think=20 |> |>> about particular topics in detail, I don't try to=20 |summarise which=20 |> |>> requirements that could be by this mail. |> |>> |> |>> Regards, |> |>> |> |>> Ruediger |> |>> |> |>> |> |>> |-----Original Message----- |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |> |>> |Sent: Thursday, February 01, 2007 9:45 AM |> |>> |To: Lee, Richard FTC; Black_David@emc.com;=20 |karagian@cs.utwente.nl |> |>> |Cc: pcn@ietf.org |> |>> |Subject: RE: [PCN] charter, addition to scope |> |>> | |> |>> | |> |>> |Maybe we should stop for a moment and consider what layer |> |should PCN |> | |> |>> |deal with. It looks to me that we are mixing network admission=20 |> |>> |control and call admission control in this discussion. |> |This problem |> |>> |is quite complex, and there are many scenarios that need |> |to be taken |> | |> |>> |into consideration. Sometimes flow =3D call, sometimes call |> |=3DNOT flow |> |>> |and sometimes there is a mix on the same path. In some=20 |cases media=20 |> |>> |gateways |> |>> |> |>> |are collocated with the edge nodes in some other cases=20 |not. Even=20 |> |>> |when flow =3D call there are two admission control layers |> |(network and |> | |> |>> |call) that are in dependency but not identical and separate=20 |> |>> |protocols run at transport and session. I am not sure=20 |how much of=20 |> |>> |all this falls under what PCN should do. |> |>> | |> |>> |Dan |> |>> | |> |>> | |> |>> | |> |>> | |> |>> | | | |> |>> |> -----Original Message----- |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |> |>> |> Cc: pcn@ietf.org |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |>> |> |> To all, |> |>> |> I agree that there must be a prioritization of flows=20 |from the |> |> |>> aggregation devices However, it's not just the media |> |gateway that |> |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") |> |as well - |> |>> |> |>> |> it is the signaling proxy at the edge that reserves the media=20 |> |>> |> path. |> |> |>> The reservation protocol request to the network from the VoIP |>=20 |> |>> proxy/gateway must reserve resources to the destination=20 |in the |>=20 |> |>> network. |> |>> |> The resource reservation request to the network by the edge |> |> |>> proxy/media gateway, must at the very minimum, meet the=20 |following |> |> |>> conditions: |> |>> |> 1. it needs to specify the resources required for the=20 |IP & ports |> |>> |> |> |> |>> (RTP/RTCP & bandwidth) |> |>> |> for example, G.711 and G.729 voice and various=20 |MPEG-4 video=20 |> |>> |> codecs |> |>> |> |>> |> all have very different requirements 2. it must be=20 |mapped to the |> |>> |> |> |> |>> signaling request |> |>> |> for SIP, it must map the SDP for media with the=20 |reservation=20 |> |>> |> flow - |> |>> |> |>> |> for example something along the lines of RFC 3524 |> |>> |> while not the answer, the mapping of the media=20 |flows is a |> |> |>> necessary component |> |>> |> It should be noted that the edge proxies/media=20 |gateways may=20 |> |>> |> have a |> |>> |> |>> |> large number of flows (and ports for each |> |>> |> RTP/RTCP flow) from the same source IP. The request |> |is made for |> | |> |>> |> |> |> |>> each flow or conversation 3. it must be honored by the=20 |edge network |> |>> |> device. |> |>> |> The trust boundary must be extended to the edge=20 |proxy/media |> |> |>> gateway for each new flow. |> |>> |> This brings up the issue of security authentication |> |of the edge |> | |> |>> |> |> |> |>> proxy/media gateway to the network |> |>> |> Does this happen in EAP, NAC, or just interoperability and |> |> |>> certification among vendors |> |>> |> If the resources are not available, then the signaling=20 |> |>> |> indicates |> |> |>> the session is not completed. For example a SIP |> |>> |> CANCEL from the edge proxy |> |>> |> |> In addition, the network device must have priority queuing=20 |> |>> |> |> enabled |> |>> |> for input queues from the edge device. |> |>> |> The media flows must not be subject to input buffers |> |being filled |> |>> |> |> |> |>> prior to classification |> |>> |> |> Thanks, |> |>> |> Richard Lee |> |>> |> Fidelity Investments |> |>> |> Enterprise Technology and Architecture |> |>> |> 617-563-3278 |> |>> |> |> |> -----Original Message----- |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |> |>> |> To: karagian@cs.utwente.nl |> |>> |> Cc: pcn@ietf.org |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |>> |> |> |> Georgios wrote: |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> |>> |> > > > In the first phase of PCN work to reduce the list of |> |>> |> issues it was |> |>> |> |> > > > proposed that the WG focus on network |> |deployment scenario |> |>> where |> |>> |> all |> |>> |> > > > nodes can be trusted and delay work on deployment |> |>> |> scenarios where |> |>> |> some |> |>> |> > > > of the nodes are not trusted. |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers,=20 |then yes, I |> |>> agree. If |> |>> |> "nodes" |> > > include end systems, proxies or other=20 |entities,=20 |> |>> |> then I |> |>> don't |> > > agree we had agreement on that. |> |>> |> > |> > Georgios: This imposes an additional=20 |restriction on the=20 |> |>> |> > |> > scope |> |>> of |> > the charter, which has been not discussed yet. |> |>> |> > >From what I remember before, during and after the PCN BOF |> |>> |> > there was no objection on using the term edge node,=20 |that could=20 |> |>> |> > mean something different than a edge |> |>> |> router. |> |>> |> > Please note that this is something different than a |> |>> |scenario covered |> |>> |> by |> |>> |> > an application based deployment model. |> |>> |> |> It's certainly not a new restriction based on the |> |discussion in |> | |> |>> |> |> the |> |>> |> BOF engendered about whether a SIP telephone (used on=20 |some of the |> |>> |> slides) was a good example. I believe the BOF |> |conclusion was that |> | |> |>> |> a SIP telephone was a bad example. |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |> |>> |proposed work: |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-)=20 |The first set=20 |> |>> |> of issues has already been discussed extensively - my=20 |> |>> |> understanding is that the SIP scenario is currently out |> |of scope, |> |>> |> and |> |>> |> |>> |> I don't care to reopen that discussion. |> |>> |> |> The "telephone" issues come up in two ways: |> |>> |> (2a) Small number of flows may make relatively fine-grained |> |>> |adjustment |> |>> |> on the link to the phone impossible. The PCN work=20 |prior to the=20 |> |>> |> BOF relied on the ability to make such adjustments. |> |>> |> (2b) While other sorts of phones may be trusted, a SIP phone=20 |> |>> |> (which may be software-only) is definitely not trustable in |> |general. |> |>> |> |> I would observe that Lars Westerberg's suggestion=20 |of a Media |> |>> Gateway: |> |>> |> |> > I am referring telecom scenario where MGWs are=20 |connected to=20 |> |>> |> |> > an |> |>> |> IP-backbone. |> |>> |> > In these scenarios, the admission control function is |> |a part of |> |>> |> > the |> |>> |> MGW |> |>> |> > and not the routers. The IP-backbone is provisioned by |> |a network |> | |> |>> |> > |> |> |>> > management system. |> |>> |> |> could avoid all of these issues: |> |>> |> (1) The media gateway could speak RSVP to the network=20 |management |> |>> |> |> |> |>> system, |> |>> |> avoiding any need to deal with SIP here. |> |>> |> (2a) A media gateway is likely to handle enough flows to be |> |>> |consistent |> |>> |> with the fine-grained adjustment assumed by the work done to |> |>> date. |> |>> |> (2b) One can plausibly assume/require that media gateways be=20 |> |>> |> trusted with respect to the IP network. |> |>> |> To the extent that one can vest "edge" functionality in |> |a trusted |> |>> |> |> |> |>> media gateway, I see no reason to exclude that scenario. |> |>> |> |> Thanks, |> |>> |> --David |> |>> |> ---------------------------------------------------- |> |>> |> David L. Black, Senior Technologist EMC Corporation,=20 |176 South=20 |> |>> |> St., Hopkinton, MA 01748 |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |> |>> |> ---------------------------------------------------- |> |>> |> |> _______________________________________________ |> |>> |> 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,=20 |> |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, |> |Germany, |> |> room B206 |> |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 |> |> 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 |> =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 Tue Feb 06 03:33:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELlA-00085x-09; Tue, 06 Feb 2007 03:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELl8-00084D-Pm for pcn@ietf.org; Tue, 06 Feb 2007 03:33:02 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HELl4-0001bf-FT for pcn@ietf.org; Tue, 06 Feb 2007 03:33:02 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD100A9G91RZS@szxga01-in.huawei.com> for pcn@ietf.org; Tue, 06 Feb 2007 16:32:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD1008K191O00@szxga01-in.huawei.com> for pcn@ietf.org; Tue, 06 Feb 2007 16:32:15 +0800 (CST) Received: from z24109a ([10.70.40.156]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD100LXM91O3W@szxml04-in.huawei.com> for pcn@ietf.org; Tue, 06 Feb 2007 16:32:12 +0800 (CST) Date: Tue, 06 Feb 2007 16:32:12 +0800 From: Tina TSOU Subject: Re: [PCN] "Network Admission Control" (NAC) To: brodrig@avaya.com, "Geib, Ruediger" Message-id: <009901c749c9$4c88b3f0$9c28460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <6439282641581441A36F7F6F83ED2ED2CBFB0C@S4DE8PSAAFQ.mitte.t-com.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 87e958510a39f65fbeb5ae8b5e360e3b 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 Ruediger, Do we also consider Network Access Control in PCN? B. R. Tina ----- Original Message -----=20 =46rom: "Geib, Ruediger" To: Cc: Sent: Tuesday, February 06, 2007 4:18 PM Subject: RE: [PCN] "Network Admission Control" (NAC) Benny, I prefer Michaels proposal, NAC or DAC is allright with me if we provide a definition for our terminology. The same would hold if "flow admission" is used, which I feel to be to close to "per flow". A side note on the abbreviation NAC: it is also described as Network Access Control by Wikipedia. I've checked that because within my company what is described by Wiki as Network "Admission Control" is called Network Access Control. Regards, Ruediger |-----Original Message----- |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |Sent: Monday, February 05, 2007 8:37 PM |To: Rodrig, Benny (Benny) |Cc: Geib, R=FCdiger; pcn@ietf.org |Subject: Re: [PCN] "Network Admission Control" (NAC) | | |Hi, | |the word NAC itself means that access is possibly denied to a networ= k |which can be due to security or resource reasons. NAC in the securit= y |context has become a quite popular expression as it is the name of a |Cisco product. The name NAC sounds good (to me) as it is very catchy= and |easy to understand also for non-experts. I don't see a large problem |when the term NAC exists in different contexts. If people need to |distinguish both approaches, security-related NAC and resource-relat= ed |NAC can be used. However, people working in both areas might see thi= s |differently. | |As the new version of the PCN charter talks about domains, domain |admission control (DAC) would be a natural substitute for NAC. DAC h= as |no misleading connotations, but it doesn't sound nice (to me). Bette= r |sounds maybe per-domain AC (PDAC) and concisely states what it is. I= n |analogy to routing, intradomain admission control is another option,= but |it also implies the existence of interdomain admission control. I'm = not |sure whether we want this right now. | |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN |charter, we can leave this issue open until we have a clearer opinio= n. | | Michael | |Rodrig, Benny (Benny) wrote: |> Ruediger, |> |> To me the charter doesn't seem to imply the expansion of scope tha= t |> you're concerned about. Unlike many other terms "flow admission" d= oesn't |> seem to have misleading connotations. But I could be ok with "netw= ork |> flow admission". |> |> If it is important that the charter be more explicit about this po= int, |> then perhaps a sentence should be added with some explicit descrip= tion |> e.g. that the flow admission behavior at the boundary includes pol= icing |> and/or interaction with per-flow mechanisms that are out of scope = of |> PCN. |> |> Benny |> |> |> -----Original Message----- |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> Sent: Monday, February 05, 2007 3:01 AM |> To: Rodrig, Benny (Benny) |> Cc: pcn@ietf.org |> Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> I'm not sure whether "flow admission" is the correct description. |> Wouldn' or couldn't that mean that PCN includes work on the per fl= ow |> admission control functionality. PCN then is chartered to work on |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with |Network- or |> Aggregate- or Per Domain Behaviour- Admission Control, then the |> chartered PCN work could be limited to provide an interface (API?)= to |> the per flow signaling protocol. Isn't the latter sufficient for t= he |> initial charter? |> |> Regards, |> |> Ruediger |> |> |-----Original Message----- |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |> |Sent: Friday, February 02, 2007 5:09 PM |> |To: Moore, Sean (Sean); Tina TSOU; |menth@informatik.uni-wuerzburg.de; |> |Geib, Rudiger |> |Cc: pcn@ietf.org |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> | |> | |> |I think the 'flow admission' wording in the charter is fine and w= e |> |don't need to choose a more precise term. The charter text |explaining |> |that this flow admission happens at the domain boundary in |reaction to |> |pre-congestion info from within the domain, etc. seems to |describe it |> |sufficiently. |> | |> |Benny |> | |> |-----Original Message----- |> |From: Moore, Sean (Sean) |> |Sent: Friday, February 02, 2007 9:59 AM |> |To: Tina TSOU; Rodrig, Benny (Benny); |menth@informatik.uni-wuerzburg.de |> |Cc: pcn@ietf.org; Geib, Ruediger |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> | |> |Probably shouldn't use "Resource Admission Control" as this |term (RAC) |> |is used in IMS and it is not the same as what we are discussing |> |- Sean |> | |> |-----Original Message----- |> |From: Tina TSOU [mailto:tena@huawei.com] |> |Sent: Friday, February 02, 2007 9:25 AM |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |> |Cc: pcn@ietf.org; Geib, Ruediger |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> | |> |Hi, |> |How about Resource Admission Control or Network Resource Admissio= n |> |Control? |> |I don't have strong opinion on that, just some terms popped up in= my |> |mind:) |> | |> |B. R. |> |Tina |> | |> |----- Original Message ----- |> |From: "Michael Menth" |> |To: "Rodrig, Benny (Benny)" |> |Cc: ; "Geib, Ruediger" |> |Sent: Friday, February 02, 2007 12:16 PM |> |Subject: [PCN] "Network Admission Control" (NAC) |> | |> | |> |> Hi, |> |> |> |> I've got a comment on the term "Network Admission Control" (NAC= ). |> |> |> |> Wikipedia |> |http://en.wikipedia.org/wiki/Network_Admission_Control only |> |> knows NAC in the context of restricting access to the |> |network based on |> | |> |> identity or security posture (it's essentially a Cisco product)= . |> |> However, most important is the aspect that access is denied |> |to a whole |> | |> |> network, subnetwork, domain, region, etc. NAC is in |contrast to AC |> |> algorithms deciding whether a new flow can be admitted to be |> |> transported over a single link which has been studied in |> |depth in the |> |> 1990s in the context of ATM systems. Three years ago, I have |> |reviewed |> |> and studied different approaches for NAC (based on resource |> |management |> |issues) in my PhD thesis: |> |> |> ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Ment= h04 |> |> .pdf The terms connection or flow admission control are less |> |specific |> |> than NAC as they do not tell the scope of the AC. |> |> |> |> Best regards, |> |> |> |> Michael |> |> |> |> Rodrig, Benny (Benny) wrote: |> |>> What I think you mean, and the admission control that PCN |> |deals with, |> | |> |>> better not be described as "network admission control" |since that |> |>> term often (e.g. see |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |> |>> refers to admission based on the identity of the sender, |which is |> |>> probably out of scope for PCN. The flow admission control in P= CN |> |>> scope is based on considerations related to network status i.e= . |> |>> pre-congestion. |> |>> The PCN flow admission control can be part of a call admission |> |>> control solution, if it interacts with other mechanisms |such as for |> |>> example with Int-Serv outside the PCN domain and/or with SIP Q= oS |> |>> pre-conditions. Such interactions, or assumptions about |> |them, may not |> |be in the scope of PCN. |> |>> |> |>> |> |>> Benny |> |>> -----Original Message----- |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent= : |> |>> Thursday, February 01, 2007 4:44 AM |> |>> To: Romascanu, Dan (Dan) |> |>> Cc: pcn@ietf.org |> |>> Subject: RE: [PCN] charter, addition to scope |> |>> |> |>> Hi Dan, |> |>> |> |>> your proposal seems sound to me. My impression is the |> |discussion may |> |>> have approached consensus on the following issues to get |chartered |> |>> initially: |> |>> |> |>> - PCN is limited to a single DiffServ domain. |> |>> - PCN aware nodes must be "on path". |> |>> - PCN only standardises PCN related IP layer |> |>> functionalities including RSVP or NSIS signaling |> |>> between edge nodes. |> |>> - PCN only works on "network admission control". |> |>> |> |>> If "Edge node" requires further definition to exclude |> |things to close |> | |> |>> to an "end system", we should add it at appropriate places. |> |>> "PCN related" would exclude dealing with middleboxes |doing anything |> |>> else with packets than PCN DiffServ forwarding. |> |>> |> |>> Another question is, what the reaction of an ingress edge |> |node should |> | |> |>> be in case of an indicated network congestion. My |> |impression is, that |> | |> |>> with the initial charter we should just define a desired |> |behaviour in |> | |> |>> terms of an aggregate traffic reduction (e.g. "stop |admission new |> |>> flows demanding CL forwarding or bandwidth increases of admitt= ed |> |>> ones" or "reduce CL traffic by x percent"). |> |>> Future work items may be added when the WG is re-chartered aft= er |> |>> having reached first aims. It may indeed be useful to |think about |> |>> some requirements for future PCN use already now. As I |didn't think |> |>> about particular topics in detail, I don't try to |summarise which |> |>> requirements that could be by this mail. |> |>> |> |>> Regards, |> |>> |> |>> Ruediger |> |>> |> |>> |> |>> |-----Original Message----- |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |> |>> |Sent: Thursday, February 01, 2007 9:45 AM |> |>> |To: Lee, Richard FTC; Black_David@emc.com; |karagian@cs.utwente.nl |> |>> |Cc: pcn@ietf.org |> |>> |Subject: RE: [PCN] charter, addition to scope |> |>> | |> |>> | |> |>> |Maybe we should stop for a moment and consider what layer |> |should PCN |> | |> |>> |deal with. It looks to me that we are mixing network admissio= n |> |>> |control and call admission control in this discussion. |> |This problem |> |>> |is quite complex, and there are many scenarios that need |> |to be taken |> | |> |>> |into consideration. Sometimes flow =3D call, sometimes call |> |=3DNOT flow |> |>> |and sometimes there is a mix on the same path. In some |cases media |> |>> |gateways |> |>> |> |>> |are collocated with the edge nodes in some other cases |not. Even |> |>> |when flow =3D call there are two admission control layers |> |(network and |> | |> |>> |call) that are in dependency but not identical and separate |> |>> |protocols run at transport and session. I am not sure |how much of |> |>> |all this falls under what PCN should do. |> |>> | |> |>> |Dan |> |>> | |> |>> | |> |>> | |> |>> | |> |>> | | | |> |>> |> -----Original Message----- |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |> |>> |> Cc: pcn@ietf.org |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |>> |> |> To all, |> |>> |> I agree that there must be a prioritization of flows |from the |> |> |>> aggregation devices However, it's not just the media |> |gateway that |> |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") |> |as well - |> |>> |> |>> |> it is the signaling proxy at the edge that reserves the med= ia |> |>> |> path. |> |> |>> The reservation protocol request to the network from the VoIP = |> |> |>> proxy/gateway must reserve resources to the destination |in the |> |> |>> network. |> |>> |> The resource reservation request to the network by the edge= |> |> |>> proxy/media gateway, must at the very minimum, meet the |following |> |> |>> conditions: |> |>> |> 1. it needs to specify the resources required for the |IP & ports |> |>> |> |> |> |>> (RTP/RTCP & bandwidth) |> |>> |> for example, G.711 and G.729 voice and various |MPEG-4 video |> |>> |> codecs |> |>> |> |>> |> all have very different requirements 2. it must be |mapped to the |> |>> |> |> |> |>> signaling request |> |>> |> for SIP, it must map the SDP for media with the |reservation |> |>> |> flow - |> |>> |> |>> |> for example something along the lines of RFC 3524 |> |>> |> while not the answer, the mapping of the media |flows is a |> |> |>> necessary component |> |>> |> It should be noted that the edge proxies/media |gateways may |> |>> |> have a |> |>> |> |>> |> large number of flows (and ports for each |> |>> |> RTP/RTCP flow) from the same source IP. The request |> |is made for |> | |> |>> |> |> |> |>> each flow or conversation 3. it must be honored by the |edge network |> |>> |> device. |> |>> |> The trust boundary must be extended to the edge |proxy/media |> |> |>> gateway for each new flow. |> |>> |> This brings up the issue of security authentication |> |of the edge |> | |> |>> |> |> |> |>> proxy/media gateway to the network |> |>> |> Does this happen in EAP, NAC, or just interoperability and = |> |> |>> certification among vendors |> |>> |> If the resources are not available, then the signaling |> |>> |> indicates |> |> |>> the session is not completed. For example a SIP |> |>> |> CANCEL from the edge proxy |> |>> |> |> In addition, the network device must have priority queui= ng |> |>> |> |> enabled |> |>> |> for input queues from the edge device. |> |>> |> The media flows must not be subject to input buffers |> |being filled |> |>> |> |> |> |>> prior to classification |> |>> |> |> Thanks, |> |>> |> Richard Lee |> |>> |> Fidelity Investments |> |>> |> Enterprise Technology and Architecture |> |>> |> 617-563-3278 |> |>> |> |> |> -----Original Message----- |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |> |>> |> To: karagian@cs.utwente.nl |> |>> |> Cc: pcn@ietf.org |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |>> |> |> |> Georgios wrote: |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> |>> |> > > > In the first phase of PCN work to reduce the list of |> |>> |> issues it was |> |>> |> |> > > > proposed that the WG focus on network |> |deployment scenario |> |>> where |> |>> |> all |> |>> |> > > > nodes can be trusted and delay work on deployment |> |>> |> scenarios where |> |>> |> some |> |>> |> > > > of the nodes are not trusted. |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, |then yes, I |> |>> agree. If |> |>> |> "nodes" |> > > include end systems, proxies or other |entities, |> |>> |> then I |> |>> don't |> > > agree we had agreement on that. |> |>> |> > |> > Georgios: This imposes an additional |restriction on the |> |>> |> > |> > scope |> |>> of |> > the charter, which has been not discussed yet. |> |>> |> > >From what I remember before, during and after the PCN BO= F |> |>> |> > there was no objection on using the term edge node, |that could |> |>> |> > mean something different than a edge |> |>> |> router. |> |>> |> > Please note that this is something different than a |> |>> |scenario covered |> |>> |> by |> |>> |> > an application based deployment model. |> |>> |> |> It's certainly not a new restriction based on the |> |discussion in |> | |> |>> |> |> the |> |>> |> BOF engendered about whether a SIP telephone (used on |some of the |> |>> |> slides) was a good example. I believe the BOF |> |conclusion was that |> | |> |>> |> a SIP telephone was a bad example. |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |> |>> |proposed work: |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) |The first set |> |>> |> of issues has already been discussed extensively - my |> |>> |> understanding is that the SIP scenario is currently out |> |of scope, |> |>> |> and |> |>> |> |>> |> I don't care to reopen that discussion. |> |>> |> |> The "telephone" issues come up in two ways: |> |>> |> (2a) Small number of flows may make relatively fine-grained |> |>> |adjustment |> |>> |> on the link to the phone impossible. The PCN work |prior to the |> |>> |> BOF relied on the ability to make such adjustments. |> |>> |> (2b) While other sorts of phones may be trusted, a SIP phon= e |> |>> |> (which may be software-only) is definitely not trustable in |> |general. |> |>> |> |> I would observe that Lars Westerberg's suggestion |of a Media |> |>> Gateway: |> |>> |> |> > I am referring telecom scenario where MGWs are |connected to |> |>> |> |> > an |> |>> |> IP-backbone. |> |>> |> > In these scenarios, the admission control function is |> |a part of |> |>> |> > the |> |>> |> MGW |> |>> |> > and not the routers. The IP-backbone is provisioned by |> |a network |> | |> |>> |> > |> |> |>> > management system. |> |>> |> |> could avoid all of these issues: |> |>> |> (1) The media gateway could speak RSVP to the network |management |> |>> |> |> |> |>> system, |> |>> |> avoiding any need to deal with SIP here. |> |>> |> (2a) A media gateway is likely to handle enough flows to be |> |>> |consistent |> |>> |> with the fine-grained adjustment assumed by the work done t= o |> |>> date. |> |>> |> (2b) One can plausibly assume/require that media gateways b= e |> |>> |> trusted with respect to the IP network. |> |>> |> To the extent that one can vest "edge" functionality in |> |a trusted |> |>> |> |> |> |>> media gateway, I see no reason to exclude that scenario. |> |>> |> |> Thanks, |> |>> |> --David |> |>> |> ---------------------------------------------------- |> |>> |> David L. Black, Senior Technologist EMC Corporation, |176 South |> |>> |> St., Hopkinton, MA 01748 |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |> |>> |> ---------------------------------------------------- |> |>> |> |> _______________________________________________ |> |>> |> 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 |> | |> | |> | |> |> |> _______________________________________________ |> 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=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 06 04:24:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMYV-0007Ut-MG; Tue, 06 Feb 2007 04:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMYT-0007Un-SQ for pcn@ietf.org; Tue, 06 Feb 2007 04:24:01 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEMYR-0005R7-OM for pcn@ietf.org; Tue, 06 Feb 2007 04:24:01 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 6 Feb 2007 10:23:57 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 10:23:57 +0100 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: RE: [PCN] "Network Admission Control" (NAC) Date: Tue, 6 Feb 2007 10:23:56 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB0D@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <009901c749c9$4c88b3f0$9c28460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdJyXnZp3lPv0OjSQ6wHzvqc+JT9QABqY+w From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 06 Feb 2007 09:23:57.0389 (UTC) FILETIME=[8736CFD0:01C749D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ce9c9805f9fd7f2a8e6eb8268c6b0fc 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 Tina, |Do we also consider Network Access Control in PCN? No, that's out of scope. Regards, Ruediger | |B. R. |Tina |----- Original Message -----=20 |From: "Geib, Ruediger" |To: |Cc: |Sent: Tuesday, February 06, 2007 4:18 PM |Subject: RE: [PCN] "Network Admission Control" (NAC) | | |Benny, | |I prefer Michaels proposal, NAC or DAC is allright with me if we |provide a definition for our terminology. The same would hold |if "flow admission" is used, which I feel to be to close to |"per flow". | |A side note on the abbreviation NAC: it is also described as |Network Access Control by Wikipedia. I've checked that because |within my company what is described by Wiki as Network |"Admission Control" is called Network Access Control. | |Regards, | |Ruediger | ||-----Original Message----- ||From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] ||Sent: Monday, February 05, 2007 8:37 PM ||To: Rodrig, Benny (Benny) ||Cc: Geib, R=FCdiger; pcn@ietf.org ||Subject: Re: [PCN] "Network Admission Control" (NAC) || || ||Hi, || ||the word NAC itself means that access is possibly denied to a network ||which can be due to security or resource reasons. NAC in the security ||context has become a quite popular expression as it is the name of a ||Cisco product. The name NAC sounds good (to me) as it is very=20 |catchy and ||easy to understand also for non-experts. I don't see a large problem ||when the term NAC exists in different contexts. If people need to ||distinguish both approaches, security-related NAC and resource-related ||NAC can be used. However, people working in both areas might see this ||differently. || ||As the new version of the PCN charter talks about domains, domain ||admission control (DAC) would be a natural substitute for NAC. DAC has ||no misleading connotations, but it doesn't sound nice (to me). Better ||sounds maybe per-domain AC (PDAC) and concisely states what it is. In ||analogy to routing, intradomain admission control is another=20 |option, but ||it also implies the existence of interdomain admission=20 |control. I'm not ||sure whether we want this right now. || ||If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN ||charter, we can leave this issue open until we have a clearer opinion. || || Michael || ||Rodrig, Benny (Benny) wrote: ||> Ruediger, ||> ||> To me the charter doesn't seem to imply the expansion of scope that ||> you're concerned about. Unlike many other terms "flow=20 |admission" doesn't ||> seem to have misleading connotations. But I could be ok=20 |with "network ||> flow admission". ||> ||> If it is important that the charter be more explicit about=20 |this point, ||> then perhaps a sentence should be added with some explicit=20 |description ||> e.g. that the flow admission behavior at the boundary=20 |includes policing ||> and/or interaction with per-flow mechanisms that are out of scope of ||> PCN. ||> ||> Benny ||> ||> ||> -----Original Message----- ||> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] ||> Sent: Monday, February 05, 2007 3:01 AM ||> To: Rodrig, Benny (Benny) ||> Cc: pcn@ietf.org ||> Subject: RE: [PCN] "Network Admission Control" (NAC) ||> ||> I'm not sure whether "flow admission" is the correct description. ||> Wouldn' or couldn't that mean that PCN includes work on the per flow ||> admission control functionality. PCN then is chartered to work on ||> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with ||Network- or ||> Aggregate- or Per Domain Behaviour- Admission Control, then the ||> chartered PCN work could be limited to provide an interface=20 |(API?) to ||> the per flow signaling protocol. Isn't the latter sufficient for the ||> initial charter? ||> ||> Regards, ||> ||> Ruediger ||> ||> |-----Original Message----- ||> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] ||> |Sent: Friday, February 02, 2007 5:09 PM ||> |To: Moore, Sean (Sean); Tina TSOU; ||menth@informatik.uni-wuerzburg.de; ||> |Geib, Rudiger ||> |Cc: pcn@ietf.org ||> |Subject: RE: [PCN] "Network Admission Control" (NAC) ||> | ||> | ||> |I think the 'flow admission' wording in the charter is fine and we ||> |don't need to choose a more precise term. The charter text ||explaining ||> |that this flow admission happens at the domain boundary in ||reaction to ||> |pre-congestion info from within the domain, etc. seems to ||describe it ||> |sufficiently. ||> | ||> |Benny ||> | ||> |-----Original Message----- ||> |From: Moore, Sean (Sean) ||> |Sent: Friday, February 02, 2007 9:59 AM ||> |To: Tina TSOU; Rodrig, Benny (Benny); ||menth@informatik.uni-wuerzburg.de ||> |Cc: pcn@ietf.org; Geib, Ruediger ||> |Subject: RE: [PCN] "Network Admission Control" (NAC) ||> | ||> |Probably shouldn't use "Resource Admission Control" as this ||term (RAC) ||> |is used in IMS and it is not the same as what we are discussing ||> |- Sean ||> | ||> |-----Original Message----- ||> |From: Tina TSOU [mailto:tena@huawei.com] ||> |Sent: Friday, February 02, 2007 9:25 AM ||> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de ||> |Cc: pcn@ietf.org; Geib, Ruediger ||> |Subject: Re: [PCN] "Network Admission Control" (NAC) ||> | ||> |Hi, ||> |How about Resource Admission Control or Network Resource Admission ||> |Control? ||> |I don't have strong opinion on that, just some terms=20 |popped up in my ||> |mind:) ||> | ||> |B. R. ||> |Tina ||> | ||> |----- Original Message ----- ||> |From: "Michael Menth" ||> |To: "Rodrig, Benny (Benny)" ||> |Cc: ; "Geib, Ruediger" ||> |Sent: Friday, February 02, 2007 12:16 PM ||> |Subject: [PCN] "Network Admission Control" (NAC) ||> | ||> | ||> |> Hi, ||> |> ||> |> I've got a comment on the term "Network Admission Control" (NAC). ||> |> ||> |> Wikipedia ||> |http://en.wikipedia.org/wiki/Network_Admission_Control only ||> |> knows NAC in the context of restricting access to the ||> |network based on ||> | ||> |> identity or security posture (it's essentially a Cisco product). ||> |> However, most important is the aspect that access is denied ||> |to a whole ||> | ||> |> network, subnetwork, domain, region, etc. NAC is in ||contrast to AC ||> |> algorithms deciding whether a new flow can be admitted to be ||> |> transported over a single link which has been studied in ||> |depth in the ||> |> 1990s in the context of ATM systems. Three years ago, I have ||> |reviewed ||> |> and studied different approaches for NAC (based on resource ||> |management ||> |issues) in my PhD thesis: ||> |> ||> |||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pd |f/Menth04 ||> |> .pdf The terms connection or flow admission control are less ||> |specific ||> |> than NAC as they do not tell the scope of the AC. ||> |> ||> |> Best regards, ||> |> ||> |> Michael ||> |> ||> |> Rodrig, Benny (Benny) wrote: ||> |>> What I think you mean, and the admission control that PCN ||> |deals with, ||> | ||> |>> better not be described as "network admission control" ||since that ||> |>> term often (e.g. see ||> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) ||> |>> refers to admission based on the identity of the sender, ||which is ||> |>> probably out of scope for PCN. The flow admission control in PCN ||> |>> scope is based on considerations related to network status i.e. ||> |>> pre-congestion. ||> |>> The PCN flow admission control can be part of a call admission ||> |>> control solution, if it interacts with other mechanisms ||such as for ||> |>> example with Int-Serv outside the PCN domain and/or with SIP QoS ||> |>> pre-conditions. Such interactions, or assumptions about ||> |them, may not ||> |be in the scope of PCN. ||> |>> ||> |>> ||> |>> Benny ||> |>> -----Original Message----- ||> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: ||> |>> Thursday, February 01, 2007 4:44 AM ||> |>> To: Romascanu, Dan (Dan) ||> |>> Cc: pcn@ietf.org ||> |>> Subject: RE: [PCN] charter, addition to scope ||> |>> ||> |>> Hi Dan, ||> |>> ||> |>> your proposal seems sound to me. My impression is the ||> |discussion may ||> |>> have approached consensus on the following issues to get ||chartered ||> |>> initially: ||> |>> ||> |>> - PCN is limited to a single DiffServ domain. ||> |>> - PCN aware nodes must be "on path". ||> |>> - PCN only standardises PCN related IP layer ||> |>> functionalities including RSVP or NSIS signaling ||> |>> between edge nodes. ||> |>> - PCN only works on "network admission control". ||> |>> ||> |>> If "Edge node" requires further definition to exclude ||> |things to close ||> | ||> |>> to an "end system", we should add it at appropriate places. ||> |>> "PCN related" would exclude dealing with middleboxes ||doing anything ||> |>> else with packets than PCN DiffServ forwarding. ||> |>> ||> |>> Another question is, what the reaction of an ingress edge ||> |node should ||> | ||> |>> be in case of an indicated network congestion. My ||> |impression is, that ||> | ||> |>> with the initial charter we should just define a desired ||> |behaviour in ||> | ||> |>> terms of an aggregate traffic reduction (e.g. "stop ||admission new ||> |>> flows demanding CL forwarding or bandwidth increases of admitted ||> |>> ones" or "reduce CL traffic by x percent"). ||> |>> Future work items may be added when the WG is re-chartered after ||> |>> having reached first aims. It may indeed be useful to ||think about ||> |>> some requirements for future PCN use already now. As I ||didn't think ||> |>> about particular topics in detail, I don't try to ||summarise which ||> |>> requirements that could be by this mail. ||> |>> ||> |>> Regards, ||> |>> ||> |>> Ruediger ||> |>> ||> |>> ||> |>> |-----Original Message----- ||> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] ||> |>> |Sent: Thursday, February 01, 2007 9:45 AM ||> |>> |To: Lee, Richard FTC; Black_David@emc.com; ||karagian@cs.utwente.nl ||> |>> |Cc: pcn@ietf.org ||> |>> |Subject: RE: [PCN] charter, addition to scope ||> |>> | ||> |>> | ||> |>> |Maybe we should stop for a moment and consider what layer ||> |should PCN ||> | ||> |>> |deal with. It looks to me that we are mixing network admission ||> |>> |control and call admission control in this discussion. ||> |This problem ||> |>> |is quite complex, and there are many scenarios that need ||> |to be taken ||> | ||> |>> |into consideration. Sometimes flow =3D call, sometimes call ||> |=3DNOT flow ||> |>> |and sometimes there is a mix on the same path. In some ||cases media ||> |>> |gateways ||> |>> ||> |>> |are collocated with the edge nodes in some other cases ||not. Even ||> |>> |when flow =3D call there are two admission control layers ||> |(network and ||> | ||> |>> |call) that are in dependency but not identical and separate ||> |>> |protocols run at transport and session. I am not sure ||how much of ||> |>> |all this falls under what PCN should do. ||> |>> | ||> |>> |Dan ||> |>> | ||> |>> | ||> |>> | ||> |>> | ||> |>> | | | ||> |>> |> -----Original Message----- ||> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] ||> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM ||> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl ||> |>> |> Cc: pcn@ietf.org ||> |>> |> Subject: RE: [PCN] charter, addition to scope ||> |>> |> |> To all, ||> |>> |> I agree that there must be a prioritization of flows ||from the |> ||> |>> aggregation devices However, it's not just the media ||> |gateway that |> ||> |>> should speak RSVP, but the edge proxy (or firewall "proxy") ||> |as well - ||> |>> ||> |>> |> it is the signaling proxy at the edge that reserves the media ||> |>> |> path. |> ||> |>> The reservation protocol request to the network from the VoIP |> ||> |>> proxy/gateway must reserve resources to the destination ||in the |> ||> |>> network. ||> |>> |> The resource reservation request to the network by=20 |the edge |> ||> |>> proxy/media gateway, must at the very minimum, meet the ||following |> ||> |>> conditions: ||> |>> |> 1. it needs to specify the resources required for the ||IP & ports ||> |>> |> |> ||> |>> (RTP/RTCP & bandwidth) ||> |>> |> for example, G.711 and G.729 voice and various ||MPEG-4 video ||> |>> |> codecs ||> |>> ||> |>> |> all have very different requirements 2. it must be ||mapped to the ||> |>> |> |> ||> |>> signaling request ||> |>> |> for SIP, it must map the SDP for media with the ||reservation ||> |>> |> flow - ||> |>> ||> |>> |> for example something along the lines of RFC 3524 ||> |>> |> while not the answer, the mapping of the media ||flows is a |> ||> |>> necessary component ||> |>> |> It should be noted that the edge proxies/media ||gateways may ||> |>> |> have a ||> |>> ||> |>> |> large number of flows (and ports for each ||> |>> |> RTP/RTCP flow) from the same source IP. The request ||> |is made for ||> | ||> |>> |> |> ||> |>> each flow or conversation 3. it must be honored by the ||edge network ||> |>> |> device. ||> |>> |> The trust boundary must be extended to the edge ||proxy/media |> ||> |>> gateway for each new flow. ||> |>> |> This brings up the issue of security authentication ||> |of the edge ||> | ||> |>> |> |> ||> |>> proxy/media gateway to the network ||> |>> |> Does this happen in EAP, NAC, or just interoperability and |> ||> |>> certification among vendors ||> |>> |> If the resources are not available, then the signaling ||> |>> |> indicates |> ||> |>> the session is not completed. For example a SIP ||> |>> |> CANCEL from the edge proxy ||> |>> |> |> In addition, the network device must have priority queuing ||> |>> |> |> enabled ||> |>> |> for input queues from the edge device. ||> |>> |> The media flows must not be subject to input buffers ||> |being filled ||> |>> |> |> ||> |>> prior to classification ||> |>> |> |> Thanks, ||> |>> |> Richard Lee ||> |>> |> Fidelity Investments ||> |>> |> Enterprise Technology and Architecture ||> |>> |> 617-563-3278 ||> |>> |> |> |> -----Original Message----- ||> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] ||> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM ||> |>> |> To: karagian@cs.utwente.nl ||> |>> |> Cc: pcn@ietf.org ||> |>> |> Subject: RE: [PCN] charter, addition to scope ||> |>> |> |> |> Georgios wrote: ||> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: ||> |>> |> > > > In the first phase of PCN work to reduce the list of ||> |>> |> issues it was ||> |>> |> |> > > > proposed that the WG focus on network ||> |deployment scenario ||> |>> where ||> |>> |> all ||> |>> |> > > > nodes can be trusted and delay work on deployment ||> |>> |> scenarios where ||> |>> |> some ||> |>> |> > > > of the nodes are not trusted. ||> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, ||then yes, I ||> |>> agree. If ||> |>> |> "nodes" |> > > include end systems, proxies or other ||entities, ||> |>> |> then I ||> |>> don't |> > > agree we had agreement on that. ||> |>> |> > |> > Georgios: This imposes an additional ||restriction on the ||> |>> |> > |> > scope ||> |>> of |> > the charter, which has been not discussed yet. ||> |>> |> > >From what I remember before, during and after the PCN BOF ||> |>> |> > there was no objection on using the term edge node, ||that could ||> |>> |> > mean something different than a edge ||> |>> |> router. ||> |>> |> > Please note that this is something different than a ||> |>> |scenario covered ||> |>> |> by ||> |>> |> > an application based deployment model. ||> |>> |> |> It's certainly not a new restriction based on the ||> |discussion in ||> | ||> |>> |> |> the ||> |>> |> BOF engendered about whether a SIP telephone (used on ||some of the ||> |>> |> slides) was a good example. I believe the BOF ||> |conclusion was that ||> | ||> |>> |> a SIP telephone was a bad example. ||> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the ||> |>> |proposed work: ||> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) ||The first set ||> |>> |> of issues has already been discussed extensively - my ||> |>> |> understanding is that the SIP scenario is currently out ||> |of scope, ||> |>> |> and ||> |>> ||> |>> |> I don't care to reopen that discussion. ||> |>> |> |> The "telephone" issues come up in two ways: ||> |>> |> (2a) Small number of flows may make relatively fine-grained ||> |>> |adjustment ||> |>> |> on the link to the phone impossible. The PCN work ||prior to the ||> |>> |> BOF relied on the ability to make such adjustments. ||> |>> |> (2b) While other sorts of phones may be trusted, a SIP phone ||> |>> |> (which may be software-only) is definitely not trustable in ||> |general. ||> |>> |> |> I would observe that Lars Westerberg's suggestion ||of a Media ||> |>> Gateway: ||> |>> |> |> > I am referring telecom scenario where MGWs are ||connected to ||> |>> |> |> > an ||> |>> |> IP-backbone. ||> |>> |> > In these scenarios, the admission control function is ||> |a part of ||> |>> |> > the ||> |>> |> MGW ||> |>> |> > and not the routers. The IP-backbone is provisioned by ||> |a network ||> | ||> |>> |> > |> ||> |>> > management system. ||> |>> |> |> could avoid all of these issues: ||> |>> |> (1) The media gateway could speak RSVP to the network ||management ||> |>> |> |> ||> |>> system, ||> |>> |> avoiding any need to deal with SIP here. ||> |>> |> (2a) A media gateway is likely to handle enough flows to be ||> |>> |consistent ||> |>> |> with the fine-grained adjustment assumed by the work done to ||> |>> date. ||> |>> |> (2b) One can plausibly assume/require that media gateways be ||> |>> |> trusted with respect to the IP network. ||> |>> |> To the extent that one can vest "edge" functionality in ||> |a trusted ||> |>> |> |> ||> |>> media gateway, I see no reason to exclude that scenario. ||> |>> |> |> Thanks, ||> |>> |> --David ||> |>> |> ---------------------------------------------------- ||> |>> |> David L. Black, Senior Technologist EMC Corporation, ||176 South ||> |>> |> St., Hopkinton, MA 01748 ||> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 ||> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 ||> |>> |> ---------------------------------------------------- ||> |>> |> |> _______________________________________________ ||> |>> |> 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 ||> | ||> | ||> | ||> ||> ||> _______________________________________________ ||> 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=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 Tue Feb 06 04:55:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEN2U-0003mT-5H; Tue, 06 Feb 2007 04:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEN2T-0003lY-CV for pcn@ietf.org; Tue, 06 Feb 2007 04:55:01 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEN2R-0003lh-St for pcn@ietf.org; Tue, 06 Feb 2007 04:55:01 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 6 Feb 2007 10:54:56 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 10:54:53 +0100 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: [PCN] 3rd charter Goals and Milestones - QoS model Date: Tue, 6 Feb 2007 10:54:53 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB0E@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <45C74D9E.5000101@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones Thread-Index: AcdJOr+eJIBaR33kS+Sl2/bBXWxmBQAlniYg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 06 Feb 2007 09:54:53.0826 (UTC) FILETIME=[D9BC9E20:01C749D4] 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 Magnus, then what's a good way to proceed? The current drafts=20 propose the CL QoS model. The PCN mechanism defined so=20 far is designed to avoid packet loss. I like both, CL=20 and the idea to react before packet loss occurs, at=20 least with regard to admitted traffic. Should PCN select one QoS model as an example and define=20 how to standardise application of PCN for other QoS=20 models? What to do if we can't reach consesus on one? As an alternative, mechanisms for several QoS=20 models could be standardised immediately. That doesn't=20 sound tempting to me. On the other side, it would=20 preferable if the signaling between boundary nodes is=20 able to support different QoS models for which PCN=20 is applied. A discussion on "signaling" supporting=20 different "QoS models" is delaying progress of the NSIS=20 WG since a couple of months now. We should make sure=20 that PCN isn't running into similar problems.=20 Regards, Ruediger |>> Mar 2008 Suggested Flow Admission and Termination Boundary = Mechanisms |>> (Informational) |>=20 |> I believe that for interoperability, the WG will need to define and |> agree on standardized behavior for ingress and egress nodes for = reaction |> to PCN information. Specific mechanisms should only be document as |> examples. The above deliverable should be changed to: =20 |>=20 |> Mar 2008 Behavioral definition for Ingress and Egress Nodes |> for Flow Admission and Termination within a |> DiffServ Domain=20 |> (Proposed Standard) |>=20 |>=20 | |This is not obvious. As the adaptation between how one accomplish a=20 |particular act as the result of the received information may=20 |be local in a node. And in addition it may not be unclear on how to act = on that=20 |information. | |But this points to a possible weakness of the current charter that it=20 |doesn't talk about which QoS model we are talking about doing flow=20 |admission with in the first shot. We probably should clarify this. | |Cheers | |Magnus Westerlund | |IETF Transport Area Director & TSVWG Chair |---------------------------------------------------------------------- |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 Tue Feb 06 05:01:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEN8M-0007fm-Jw; Tue, 06 Feb 2007 05:01:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEN8L-0007fh-K6 for pcn@ietf.org; Tue, 06 Feb 2007 05:01:05 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEN8K-0004zd-7t for pcn@ietf.org; Tue, 06 Feb 2007 05:01:05 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 6 Feb 2007 11:01:03 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 11:00:58 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] PCN Charter proposal version 4 - editorials Date: Tue, 6 Feb 2007 11:00:58 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB0F@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <45C74E1E.2050807@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOviFMYS1ejNiQ2iNhbaq6S6pqgAmd51A From: "Geib, Ruediger" To: X-OriginalArrivalTime: 06 Feb 2007 10:00:58.0865 (UTC) FILETIME=[B3512610:01C749D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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="===============1692016120==" Errors-To: pcn-bounces@ietf.org --===============1692016120== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBhIGZldyBlZGl0b3JpYWwgY29tbWVudHMgKG1hcmtlZCBeXikuDQoNClJlZ2FyZHMsIFJ1 ZWRpZ2VyDQoNCltzbmlwXQ0KDQp8VGhlIENvbmdlc3Rpb24gYW5kIFByZS1Db25nZXN0aW9uIE5v dGlmaWNhdGlvbiAoUENOKSB3b3JraW5nIGdyb3VwIA0KfGRldmVsb3BzIG1lY2hhbmlzbXMgdG8g cHJvdGVjdCB0aGUgcXVhbGl0eS1vZi1zZXJ2aWNlIG9mIGVzdGFibGlzaGVkIA0KfGZsb3dzIHdp dGhpbiBhIERpZmZTZXJ2IGRvbWFpbiB3aGVuIGNvbmdlc3Rpb24gaXMgaW1taW5lbnQgb3IgDQp8 ZXhpc3RpbmcuIA0KfFRoZXNlIG1lY2hhbmlzbXMgb3BlcmF0ZSBhdCB0aGUgZG9tYWluIGJvdW5k YXJ5LCBiYXNlZCBvbiBhZ2dyZWdhdGVkIA0KfGNvbmdlc3Rpb24gYW5kIHByZS1jb25nZXN0aW9u IGluZm9ybWF0aW9uIGZyb20gd2l0aGluIHRoZSBkb21haW4uIFRoZSANCnxmb2N1cyBvZiB0aGUg V0cgaXMgb24gZGV2ZWxvcGluZyBzdGFuZGFyZHMgZm9yIHRoZSBtYXJraW5nIGJlaGF2aW9yIG9m IA0KfHRoZSBpbnRlcmlvciBub2RlcyBhbmQgdGhlIGVuY29kaW5nIGFuZCB0cmFuc3BvcnQgb2Yg dGhlIGNvbmdlc3Rpb24gDQp8aW5mb3JtYXRpb24uICAgICAgICAgICAgICAgICAgICAgICAgXl5e DQoNCltzbmlwXQ0KDQoNCnxNYXIgMjAwOCAgIEZsb3cgQWRtaXNzaW9uIGFuZCBUZXJtaW5hdGlv biB3aXRoaW4gYSBEaWZmU2Vydg0KfCAgICAgICBeICAgRG9tYWluIChJbmZvcm1hdGlvbmFsKQ0K fA0KfE1hciAyMDA4ICAgKFByZS0pQ29uZ2VzdGlvbiBEZXRlY3Rpb24gd2l0aGluIGEgRGlmZlNl cnYgRG9tYWluDQp8ICAgICAgIF4gICAgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KfA0KDQoNCg== --===============1692016120== 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 --===============1692016120==-- From pcn-bounces@ietf.org Tue Feb 06 05:03:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HENAd-0008Ru-S1; Tue, 06 Feb 2007 05:03:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HENAc-0008Ri-Aw for pcn@ietf.org; Tue, 06 Feb 2007 05:03:26 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HENAY-0005RR-OI for pcn@ietf.org; Tue, 06 Feb 2007 05:03:26 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16A2mem012099; Tue, 6 Feb 2007 11:02:52 +0100 (MET) From: "Georgios Karagiannis" To: "'Rodrig, Benny \(Benny\)'" , "'Magnus Westerlund'" , References: <45C74E1E.2050807@ericsson.com> Subject: RE: [PCN] PCN Charter proposal version 4 Date: Tue, 6 Feb 2007 11:03:05 +0100 Message-ID: <000f01c749d6$01b92b90$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8A= In-Reply-To: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 11:02:53 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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 I agree with Benny's suggestion that we should not make the 'Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress' as a Proposed Standard. BCP is okay with me! Best Regards, Georgios > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: maandag 5 februari 2007 19:56 > To: Magnus Westerlund; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 > > I think it was good to add to the milestones the > 'Requirements for Signaling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational)' per Joe's suggestion. > > Now isn't there something puzzling in keeping 'Encoding and > Transport of (Pre-)Congestion Information from the Domain > Egress to the Ingress' as a Proposed Standard? Proposed > Standard seems to suggest that the PCN WG will be defining > protocol mechanisms for this, which is not obviously the > case. What if this relies on other protocols that may be > running between the boundary nodes in different scenarios > (e.g. NSIS QoS NSLP, RSVP, SDP in SIP)? In that case such a > document, if at all needed, would probably have to be just a BCP. > > Benny > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, February 05, 2007 10:33 AM > To: pcn@ietf.org > Subject: [PCN] PCN Charter proposal version 4 > > Hi, > > Below is the 4th version of the PCN charter. It contains some > modifications in the beginning to try to be more explicit > about the decomposition. Then I also incorporated some of > Jozef's comments. > > Cheers > > Magnus > > ---- > > Congestion and Pre-Congestion Notification (PCN) > > Chair(s): > tbd > > Transport Area Director(s): > Magnus Westerlund > Lars Eggert > > Transport Area Advisor: > Lars Eggert > > Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > Description of Working Group: > > The Congestion and Pre-Congestion Notification (PCN) working > group develops mechanisms to protect the quality-of-service > of established flows within a DiffServ domain when congestion > is imminent or existing. > These mechanisms operate at the domain boundary, based on > aggregated congestion and pre-congestion information from > within the domain. The focus of the WG is on developing > standards for the marking behavior of the interior nodes and > the encoding transport of the congestion information. The > transport and encoding of the congestion information is > decompositioned into several components. The forward flow > path to the domain boundary, the metering of the congestion > situation at the boundary, and the transport of the data to > the controlling peer. This decomposition is done to allow for > future extensibility by defining additional variants of the > components (with the exception of the first one). Reaction > mechanisms at the boundary consist of flow admission and flow > termination. Although designed to work together, flow > admission and flow termination are independent mechanisms, > and the use of one does not require or prevent the use of the > other. In consultation with the AD, the WG may produce a > small number of informational documents that describe how > specific quality-of-service policies for a domain can be > implemented using these two mechanisms. > > The PCN WG will specify the following components to protect > the quality-of-service of flows within a DiffServ domain: > > (1) a general architecture for flow admission and > termination based > on aggregated (pre-)congestion information > > (2) a specification of conditions under which interior > nodes generate > (pre-)congestion information > > (3) encoding and transport of (pre-)congestion information > between the interior and the egress node of the domain > > (4) Metering of the (pre-)congestion information at the egress > node of the domain. > > (5) encoding and transport of (pre-)congestion information > between the egress node and the ingress node of the domain > (when necessary). > > (6) ingress node control mechanisms for flow admission or > termination, > based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture, and specifically > on the marking behavior and encoding and transport mechanisms > needed to realize it. Standards-track protocols and > mechanisms are only developed where necessary for > interoperability. For other components of the architecture, > the WG may document examples or provide recommended solutions > in informational documents. The architecture document will be > comprehensive, and include security, manageability and > operational considerations. If this WG requires extensions or > modifications to protocols that are products of other WGs, it > may motivate their need and describe requirements in > informational documents; design of such extensions and > modifications will take place in the appropriate WGs. > > > The initial scope of the PCN WG is restricted by the following > assumptions: > > (A) these components are deployed in a single DiffServ domain, > where all boundary and interior nodes are PCN-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing > or shaping > > (C) the number of flows across any potential aggregation > bottleneck > is sufficiently large for stateless, statistical > mechanisms to be > effective > > (D) flows may have different precedence, but the applicability > of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, > etc.) > is out of scope > > After completion of the initial phase, the PCN WG may > re-charter to develop solutions for scenarios where some of > these restrictions are not in place. It may also re-charter > to consider applying the PCN mechanisms to additional > deployment scenarios (operation over concatenated DiffServ > domains, PCN-aware application mechanisms, etc.). The WG may > also consider to investigate additional response mechanisms > that act on (pre-)congestion information. One example could > be flow-rate adaptation (rather than flow > admission/termination) during times of congestion. The > details of these work items are outside the scope of the > initial phase; but the WG may consider their requirements to > design components that are sufficiently general to support > such extensions in the future. > > > Goals and Milestones: > > Nov 2007 Flow Admission and Termination Architecture > (Informational) > > Nov 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Information within a DiffServ Domain > (Informational) > > Mar 2007 Flow Admission and Termination within a DiffServ > Domain (Informational) > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > (Proposed Standard) > > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > from Egress to Ingress Nodes in a DiffServ Domain > (Informational) > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > from within a DiffServ Domain to the Egress > (Proposed Standard) > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > from the Domain Egress to the Ingress > (Proposed Standard) > > Jul 2008 Suggested Flow Admission and Termination Boundary > Mechanisms > (Informational) > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 06 08:09:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQ4p-00074z-QI; Tue, 06 Feb 2007 08:09:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQ4o-00074l-Ir for pcn@ietf.org; Tue, 06 Feb 2007 08:09:38 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQ4i-0001vr-QO for pcn@ietf.org; Tue, 06 Feb 2007 08:09:38 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 12:54:32 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Feb 2007 12:54:31 +0000 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 Charter proposal version 4 Date: Tue, 6 Feb 2007 12:54:31 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEE4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000f01c749d6$01b92b90$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUA== From: To: , , , X-OriginalArrivalTime: 06 Feb 2007 12:54:31.0963 (UTC) FILETIME=[F201CEB0:01C749ED] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e 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 The encoding has to be STD, I believe=20 The transport protocol - have given my views earlier > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 06 February 2007 10:03 > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 >=20 > Hi >=20 > I agree with Benny's suggestion that we should not make the > 'Encoding and Transport of (Pre-)Congestion Information from the Domain > Egress to the Ingress' as a Proposed Standard. > BCP is okay with me! >=20 > Best Regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > Sent: maandag 5 februari 2007 19:56 > > To: Magnus Westerlund; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > I think it was good to add to the milestones the > > 'Requirements for Signaling of (Pre-)Congestion information > > from Egress to Ingress Nodes in a DiffServ Domain > > (Informational)' per Joe's suggestion. > > > > Now isn't there something puzzling in keeping 'Encoding and > > Transport of (Pre-)Congestion Information from the Domain > > Egress to the Ingress' as a Proposed Standard? Proposed > > Standard seems to suggest that the PCN WG will be defining > > protocol mechanisms for this, which is not obviously the > > case. What if this relies on other protocols that may be > > running between the boundary nodes in different scenarios > > (e.g. NSIS QoS NSLP, RSVP, SDP in SIP)? In that case such a > > document, if at all needed, would probably have to be just a BCP. > > > > Benny > > > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Monday, February 05, 2007 10:33 AM > > To: pcn@ietf.org > > Subject: [PCN] PCN Charter proposal version 4 > > > > Hi, > > > > Below is the 4th version of the PCN charter. It contains some > > modifications in the beginning to try to be more explicit > > about the decomposition. Then I also incorporated some of > > Jozef's comments. > > > > Cheers > > > > Magnus > > > > ---- > > > > Congestion and Pre-Congestion Notification (PCN) > > > > Chair(s): > > tbd > > > > Transport Area Director(s): > > Magnus Westerlund > > Lars Eggert > > > > Transport Area Advisor: > > Lars Eggert > > > > Mailing Lists: > > General Discussion: pcn@ietf.org > > To Subscribe: pcn-request@ietf.org > > In Body: (un)subscribe > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > Description of Working Group: > > > > The Congestion and Pre-Congestion Notification (PCN) working > > group develops mechanisms to protect the quality-of-service > > of established flows within a DiffServ domain when congestion > > is imminent or existing. > > These mechanisms operate at the domain boundary, based on > > aggregated congestion and pre-congestion information from > > within the domain. The focus of the WG is on developing > > standards for the marking behavior of the interior nodes and > > the encoding transport of the congestion information. The > > transport and encoding of the congestion information is > > decompositioned into several components. The forward flow > > path to the domain boundary, the metering of the congestion > > situation at the boundary, and the transport of the data to > > the controlling peer. This decomposition is done to allow for > > future extensibility by defining additional variants of the > > components (with the exception of the first one). Reaction > > mechanisms at the boundary consist of flow admission and flow > > termination. Although designed to work together, flow > > admission and flow termination are independent mechanisms, > > and the use of one does not require or prevent the use of the > > other. In consultation with the AD, the WG may produce a > > small number of informational documents that describe how > > specific quality-of-service policies for a domain can be > > implemented using these two mechanisms. > > > > The PCN WG will specify the following components to protect > > the quality-of-service of flows within a DiffServ domain: > > > > (1) a general architecture for flow admission and > > termination based > > on aggregated (pre-)congestion information > > > > (2) a specification of conditions under which interior > > nodes generate > > (pre-)congestion information > > > > (3) encoding and transport of (pre-)congestion information > > between the interior and the egress node of the domain > > > > (4) Metering of the (pre-)congestion information at the egress > > node of the domain. > > > > (5) encoding and transport of (pre-)congestion information > > between the egress node and the ingress node of the domain > > (when necessary). > > > > (6) ingress node control mechanisms for flow admission or > > termination, > > based on aggregated (pre-)congestion information > > > > The WG focuses on the overall architecture, and specifically > > on the marking behavior and encoding and transport mechanisms > > needed to realize it. Standards-track protocols and > > mechanisms are only developed where necessary for > > interoperability. For other components of the architecture, > > the WG may document examples or provide recommended solutions > > in informational documents. The architecture document will be > > comprehensive, and include security, manageability and > > operational considerations. If this WG requires extensions or > > modifications to protocols that are products of other WGs, it > > may motivate their need and describe requirements in > > informational documents; design of such extensions and > > modifications will take place in the appropriate WGs. > > > > > > The initial scope of the PCN WG is restricted by the following > > assumptions: > > > > (A) these components are deployed in a single DiffServ domain, > > where all boundary and interior nodes are PCN-enabled > > and mutually trust each other > > > > (B) all flows handled by these mechanisms are inelastic and > > constrained to a known maximum rate through policing > > or shaping > > > > (C) the number of flows across any potential aggregation > > bottleneck > > is sufficiently large for stateless, statistical > > mechanisms to be > > effective > > > > (D) flows may have different precedence, but the applicability > > of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, > > etc.) > > is out of scope > > > > After completion of the initial phase, the PCN WG may > > re-charter to develop solutions for scenarios where some of > > these restrictions are not in place. It may also re-charter > > to consider applying the PCN mechanisms to additional > > deployment scenarios (operation over concatenated DiffServ > > domains, PCN-aware application mechanisms, etc.). The WG may > > also consider to investigate additional response mechanisms > > that act on (pre-)congestion information. One example could > > be flow-rate adaptation (rather than flow > > admission/termination) during times of congestion. The > > details of these work items are outside the scope of the > > initial phase; but the WG may consider their requirements to > > design components that are sufficiently general to support > > such extensions in the future. > > > > > > Goals and Milestones: > > > > Nov 2007 Flow Admission and Termination Architecture > > (Informational) > > > > Nov 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information within a DiffServ Domain > > (Informational) > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > Domain (Informational) > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > (Proposed Standard) > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > > from Egress to Ingress Nodes in a DiffServ Domain > > (Informational) > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > from within a DiffServ Domain to the Egress > > (Proposed Standard) > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > from the Domain Egress to the Ingress > > (Proposed Standard) > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > Mechanisms > > (Informational) > > > > -- > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > ---------------------------------------------------------------------- > > 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 > > >=20 >=20 >=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 Tue Feb 06 08:29:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQNm-000080-95; Tue, 06 Feb 2007 08:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQNk-00007v-I6 for pcn@ietf.org; Tue, 06 Feb 2007 08:29:12 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQNj-0002AV-F6 for pcn@ietf.org; Tue, 06 Feb 2007 08:29:12 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l16DSmqC015367; Tue, 6 Feb 2007 13:28:49 GMT 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 Charter proposal version 4 Date: Tue, 6 Feb 2007 13:28:45 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUAAAsJlA References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEE4@E03MVZ1-UKDY.domain1.systemhost.net> From: "Hancock, Robert" To: , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 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,=20 > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 >=20 > The encoding has to be STD, I believe > The transport protocol - have given my views earlier Now I'm very confused. If we are talking about the communication between edge/boundary nodes (e.g. in the current proposal this is mainly egress --> ingress notifications IIRC), then I can't=20 see why the encoding would have one status and the transport=20 another. Furthermore, since we are talking about protocols between nodes (albeit within the same domain - but then the interior-->edge is also intra-domain) then this would seem to be an interoperability issue for which the standards track is in principle appropriate. However, the charter also contains the text > > > If this WG requires extensions or=20 > > > modifications to protocols that are products of other WGs, it may=20 > > > motivate their need and describe requirements in informational=20 > > > documents; design of such extensions and modifications will take=20 > > > place in the appropriate WGs. which seems exactly correct. In other words, if it turns out that rsvp/nsis/sip/whatever extensions are needed, those extensions should not be PCN products; an appropriate PCN product would be an informational which stated what functionality an extension would need. Only if PCN developed a *new* protocol for edge-edge communication (e.g. egress-ingress notifications) would a standards track document for the Nov 2008 milestone be appropriate, but that would seem a surprising state of affairs. ? robert h. >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 06 February 2007 10:03 > > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > >=20 > > Hi > >=20 > > I agree with Benny's suggestion that we should not make the=20 > 'Encoding=20 > > and Transport of (Pre-)Congestion Information from the > Domain > > Egress to the Ingress' as a Proposed Standard. > > BCP is okay with me! > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > > > -----Original Message----- > > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > > Sent: maandag 5 februari 2007 19:56 > > > To: Magnus Westerlund; pcn@ietf.org > > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > > > I think it was good to add to the milestones the=20 > 'Requirements for=20 > > > Signaling of (Pre-)Congestion information from Egress to Ingress=20 > > > Nodes in a DiffServ Domain (Informational)' per Joe's suggestion. > > > > > > Now isn't there something puzzling in keeping 'Encoding and=20 > > > Transport of (Pre-)Congestion Information from the Domain=20 > Egress to=20 > > > the Ingress' as a Proposed Standard? Proposed Standard seems to=20 > > > suggest that the PCN WG will be defining protocol mechanisms for=20 > > > this, which is not obviously the case. What if this=20 > relies on other=20 > > > protocols that may be running between the boundary nodes in=20 > > > different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in=20 > SIP)? In that=20 > > > case such a document, if at all needed, would probably have to be=20 > > > just a BCP. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Monday, February 05, 2007 10:33 AM > > > To: pcn@ietf.org > > > Subject: [PCN] PCN Charter proposal version 4 > > > > > > Hi, > > > > > > Below is the 4th version of the PCN charter. It contains some=20 > > > modifications in the beginning to try to be more explicit=20 > about the=20 > > > decomposition. Then I also incorporated some of Jozef's comments. > > > > > > Cheers > > > > > > Magnus > > > > > > ---- > > > > > > Congestion and Pre-Congestion Notification (PCN) > > > > > > Chair(s): > > > tbd > > > > > > Transport Area Director(s): > > > Magnus Westerlund > > > Lars Eggert > > > > > > Transport Area Advisor: > > > Lars Eggert > > > > > > Mailing Lists: > > > General Discussion: pcn@ietf.org > > > To Subscribe: pcn-request@ietf.org > > > In Body: (un)subscribe > > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > > > > Description of Working Group: > > > > > > The Congestion and Pre-Congestion Notification (PCN)=20 > working group=20 > > > develops mechanisms to protect the quality-of-service of=20 > established=20 > > > flows within a DiffServ domain when congestion is imminent or=20 > > > existing. > > > These mechanisms operate at the domain boundary, based on=20 > aggregated=20 > > > congestion and pre-congestion information from within the domain.=20 > > > The focus of the WG is on developing standards for the marking=20 > > > behavior of the interior nodes and the encoding transport of the=20 > > > congestion information. The transport and encoding of the=20 > congestion=20 > > > information is decompositioned into several components.=20 > The forward=20 > > > flow path to the domain boundary, the metering of the congestion=20 > > > situation at the boundary, and the transport of the data to the=20 > > > controlling peer. This decomposition is done to allow for future=20 > > > extensibility by defining additional variants of the components=20 > > > (with the exception of the first one). Reaction mechanisms at the=20 > > > boundary consist of flow admission and flow termination. Although=20 > > > designed to work together, flow admission and flow=20 > termination are=20 > > > independent mechanisms, and the use of one does not require or=20 > > > prevent the use of the other. In consultation with the AD, the WG=20 > > > may produce a small number of informational documents=20 > that describe=20 > > > how specific quality-of-service policies for a domain can be=20 > > > implemented using these two mechanisms. > > > > > > The PCN WG will specify the following components to protect the=20 > > > quality-of-service of flows within a DiffServ domain: > > > > > > (1) a general architecture for flow admission and termination=20 > > > based > > > on aggregated (pre-)congestion information > > > > > > (2) a specification of conditions under which interior nodes=20 > > > generate > > > (pre-)congestion information > > > > > > (3) encoding and transport of (pre-)congestion information > > > between the interior and the egress node of the domain > > > > > > (4) Metering of the (pre-)congestion information at the egress > > > node of the domain. > > > > > > (5) encoding and transport of (pre-)congestion information > > > between the egress node and the ingress node of the domain > > > (when necessary). > > > > > > (6) ingress node control mechanisms for flow admission or=20 > > > termination, > > > based on aggregated (pre-)congestion information > > > > > > The WG focuses on the overall architecture, and=20 > specifically on the=20 > > > marking behavior and encoding and transport mechanisms needed to=20 > > > realize it. Standards-track protocols and mechanisms are only=20 > > > developed where necessary for interoperability. For other=20 > components=20 > > > of the architecture, the WG may document examples or provide=20 > > > recommended solutions in informational documents. The=20 > architecture=20 > > > document will be comprehensive, and include security,=20 > manageability=20 > > > and operational considerations. If this WG requires extensions or=20 > > > modifications to protocols that are products of other WGs, it may=20 > > > motivate their need and describe requirements in informational=20 > > > documents; design of such extensions and modifications will take=20 > > > place in the appropriate WGs. > > > > > > > > > The initial scope of the PCN WG is restricted by the following > > > assumptions: > > > > > > (A) these components are deployed in a single DiffServ domain, > > > where all boundary and interior nodes are PCN-enabled > > > and mutually trust each other > > > > > > (B) all flows handled by these mechanisms are inelastic and > > > constrained to a known maximum rate through policing or=20 > > > shaping > > > > > > (C) the number of flows across any potential aggregation=20 > > > bottleneck > > > is sufficiently large for stateless, statistical=20 > mechanisms=20 > > > to be > > > effective > > > > > > (D) flows may have different precedence, but the applicability > > > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, > > > etc.) > > > is out of scope > > > > > > After completion of the initial phase, the PCN WG may=20 > re-charter to=20 > > > develop solutions for scenarios where some of these=20 > restrictions are=20 > > > not in place. It may also re-charter to consider applying the PCN=20 > > > mechanisms to additional deployment scenarios (operation over=20 > > > concatenated DiffServ domains, PCN-aware application mechanisms,=20 > > > etc.). The WG may also consider to investigate additional=20 > response=20 > > > mechanisms that act on (pre-)congestion information. One example=20 > > > could be flow-rate adaptation (rather than flow > > > admission/termination) during times of congestion. The details of=20 > > > these work items are outside the scope of the initial=20 > phase; but the=20 > > > WG may consider their requirements to design components that are=20 > > > sufficiently general to support such extensions in the future. > > > > > > > > > Goals and Milestones: > > > > > > Nov 2007 Flow Admission and Termination Architecture > > > (Informational) > > > > > > Nov 2007 Survey of Encoding and Transport Choices of > > > (Pre-)Congestion Information within a DiffServ Domain > > > (Informational) > > > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > > Domain (Informational) > > > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > > (Proposed Standard) > > > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion > information > > > from Egress to Ingress Nodes in a DiffServ Domain > > > (Informational) > > > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > > from within a DiffServ Domain to the Egress > > > (Proposed Standard) > > > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > > from the Domain Egress to the Ingress > > > (Proposed Standard) > > > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > > Mechanisms > > > (Informational) > > > > > > -- > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > > ---------------------------------------------------------------------- > > > 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:=20 > 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 > > > > >=20 > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 06 09:31:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERLm-0005IA-Qf; Tue, 06 Feb 2007 09:31:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERLl-0005I4-FX for pcn@ietf.org; Tue, 06 Feb 2007 09:31:13 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERLk-00054O-NA for pcn@ietf.org; Tue, 06 Feb 2007 09:31:13 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l16EVBKQ008309 for ; Tue, 6 Feb 2007 09:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [PCN] PCN Charter proposal version 4 Date: Tue, 6 Feb 2007 09:31:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUAAAsJlAAAIh9wA= References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEE4@E03MVZ1-UKDY.domain1.systemhost.net> From: "Rodrig, Benny \(Benny\)" To: "Hancock, Robert" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 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 Indeed encoding & transport between domain boundary nodes will be STD but likely by other WGs. If the Nov 2008 milestone stays in the PCN charter in addition to the respective informational requirements doc, then it will probably describe how to use those mechanisms specified by the other WGs. Perhaps the wording 'encoding and transport' better be replaced with the same language as in the requirements doc milestone, hence: - Nov 2008 Signalling of (Pre-)Congestion information from Egress to Ingress Nodes in a DiffServ Domain (BCP) Benny -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 Sent: Tuesday, February 06, 2007 8:29 AM To: philip.eardley@bt.com; pcn@ietf.org Subject: RE: [PCN] PCN Charter proposal version 4 hi,=20 > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >=20 > The encoding has to be STD, I believe > The transport protocol - have given my views earlier Now I'm very confused. If we are talking about the communication between edge/boundary nodes (e.g. in the current proposal this is mainly egress --> ingress notifications IIRC), then I can't see why the encoding would have one status and the transport another. Furthermore, since we are talking about protocols between nodes (albeit within the same domain - but then the interior-->edge is also intra-domain) then this would seem to be an interoperability issue for which the standards track is in principle appropriate. However, the charter also contains the text > > > If this WG requires extensions or modifications to protocols that=20 > > > are products of other WGs, it may motivate their need and describe > > > requirements in informational documents; design of such extensions > > > and modifications will take place in the appropriate WGs. which seems exactly correct. In other words, if it turns out that rsvp/nsis/sip/whatever extensions are needed, those extensions should not be PCN products; an appropriate PCN product would be an informational which stated what functionality an extension would need. Only if PCN developed a *new* protocol for edge-edge communication (e.g. egress-ingress notifications) would a standards track document for the Nov 2008 milestone be appropriate, but that would seem a surprising state of affairs. ? robert h. >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 06 February 2007 10:03 > > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > >=20 > > Hi > >=20 > > I agree with Benny's suggestion that we should not make the > 'Encoding > > and Transport of (Pre-)Congestion Information from the > Domain > > Egress to the Ingress' as a Proposed Standard. > > BCP is okay with me! > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > > > -----Original Message----- > > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > > Sent: maandag 5 februari 2007 19:56 > > > To: Magnus Westerlund; pcn@ietf.org > > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > > > I think it was good to add to the milestones the > 'Requirements for > > > Signaling of (Pre-)Congestion information from Egress to Ingress=20 > > > Nodes in a DiffServ Domain (Informational)' per Joe's suggestion. > > > > > > Now isn't there something puzzling in keeping 'Encoding and=20 > > > Transport of (Pre-)Congestion Information from the Domain > Egress to > > > the Ingress' as a Proposed Standard? Proposed Standard seems to=20 > > > suggest that the PCN WG will be defining protocol mechanisms for=20 > > > this, which is not obviously the case. What if this > relies on other > > > protocols that may be running between the boundary nodes in=20 > > > different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in > SIP)? In that > > > case such a document, if at all needed, would probably have to be=20 > > > just a BCP. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Monday, February 05, 2007 10:33 AM > > > To: pcn@ietf.org > > > Subject: [PCN] PCN Charter proposal version 4 > > > > > > Hi, > > > > > > Below is the 4th version of the PCN charter. It contains some=20 > > > modifications in the beginning to try to be more explicit > about the > > > decomposition. Then I also incorporated some of Jozef's comments. > > > > > > Cheers > > > > > > Magnus > > > > > > ---- > > > > > > Congestion and Pre-Congestion Notification (PCN) > > > > > > Chair(s): > > > tbd > > > > > > Transport Area Director(s): > > > Magnus Westerlund > > > Lars Eggert > > > > > > Transport Area Advisor: > > > Lars Eggert > > > > > > Mailing Lists: > > > General Discussion: pcn@ietf.org > > > To Subscribe: pcn-request@ietf.org > > > In Body: (un)subscribe > > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > > > > Description of Working Group: > > > > > > The Congestion and Pre-Congestion Notification (PCN) > working group > > > develops mechanisms to protect the quality-of-service of > established > > > flows within a DiffServ domain when congestion is imminent or=20 > > > existing. > > > These mechanisms operate at the domain boundary, based on > aggregated > > > congestion and pre-congestion information from within the domain.=20 > > > The focus of the WG is on developing standards for the marking=20 > > > behavior of the interior nodes and the encoding transport of the=20 > > > congestion information. The transport and encoding of the > congestion > > > information is decompositioned into several components.=20 > The forward > > > flow path to the domain boundary, the metering of the congestion=20 > > > situation at the boundary, and the transport of the data to the=20 > > > controlling peer. This decomposition is done to allow for future=20 > > > extensibility by defining additional variants of the components=20 > > > (with the exception of the first one). Reaction mechanisms at the=20 > > > boundary consist of flow admission and flow termination. Although=20 > > > designed to work together, flow admission and flow > termination are > > > independent mechanisms, and the use of one does not require or=20 > > > prevent the use of the other. In consultation with the AD, the WG=20 > > > may produce a small number of informational documents > that describe > > > how specific quality-of-service policies for a domain can be=20 > > > implemented using these two mechanisms. > > > > > > The PCN WG will specify the following components to protect the=20 > > > quality-of-service of flows within a DiffServ domain: > > > > > > (1) a general architecture for flow admission and termination=20 > > > based > > > on aggregated (pre-)congestion information > > > > > > (2) a specification of conditions under which interior nodes=20 > > > generate > > > (pre-)congestion information > > > > > > (3) encoding and transport of (pre-)congestion information > > > between the interior and the egress node of the domain > > > > > > (4) Metering of the (pre-)congestion information at the egress > > > node of the domain. > > > > > > (5) encoding and transport of (pre-)congestion information > > > between the egress node and the ingress node of the domain > > > (when necessary). > > > > > > (6) ingress node control mechanisms for flow admission or=20 > > > termination, > > > based on aggregated (pre-)congestion information > > > > > > The WG focuses on the overall architecture, and > specifically on the > > > marking behavior and encoding and transport mechanisms needed to=20 > > > realize it. Standards-track protocols and mechanisms are only=20 > > > developed where necessary for interoperability. For other > components > > > of the architecture, the WG may document examples or provide=20 > > > recommended solutions in informational documents. The > architecture > > > document will be comprehensive, and include security, > manageability > > > and operational considerations. If this WG requires extensions or=20 > > > modifications to protocols that are products of other WGs, it may=20 > > > motivate their need and describe requirements in informational=20 > > > documents; design of such extensions and modifications will take=20 > > > place in the appropriate WGs. > > > > > > > > > The initial scope of the PCN WG is restricted by the following > > > assumptions: > > > > > > (A) these components are deployed in a single DiffServ domain, > > > where all boundary and interior nodes are PCN-enabled > > > and mutually trust each other > > > > > > (B) all flows handled by these mechanisms are inelastic and > > > constrained to a known maximum rate through policing or=20 > > > shaping > > > > > > (C) the number of flows across any potential aggregation=20 > > > bottleneck > > > is sufficiently large for stateless, statistical > mechanisms > > > to be > > > effective > > > > > > (D) flows may have different precedence, but the applicability > > > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, > > > etc.) > > > is out of scope > > > > > > After completion of the initial phase, the PCN WG may > re-charter to > > > develop solutions for scenarios where some of these > restrictions are > > > not in place. It may also re-charter to consider applying the PCN=20 > > > mechanisms to additional deployment scenarios (operation over=20 > > > concatenated DiffServ domains, PCN-aware application mechanisms,=20 > > > etc.). The WG may also consider to investigate additional > response > > > mechanisms that act on (pre-)congestion information. One example=20 > > > could be flow-rate adaptation (rather than flow > > > admission/termination) during times of congestion. The details of=20 > > > these work items are outside the scope of the initial > phase; but the > > > WG may consider their requirements to design components that are=20 > > > sufficiently general to support such extensions in the future. > > > > > > > > > Goals and Milestones: > > > > > > Nov 2007 Flow Admission and Termination Architecture > > > (Informational) > > > > > > Nov 2007 Survey of Encoding and Transport Choices of > > > (Pre-)Congestion Information within a DiffServ Domain > > > (Informational) > > > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > > Domain (Informational) > > > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > > (Proposed Standard) > > > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion > information > > > from Egress to Ingress Nodes in a DiffServ Domain > > > (Informational) > > > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > > from within a DiffServ Domain to the Egress > > > (Proposed Standard) > > > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > > from the Domain Egress to the Ingress > > > (Proposed Standard) > > > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > > Mechanisms > > > (Informational) > > > > > > -- > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > > ---------------------------------------------------------------------- > > > 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:=20 > 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 > > > > >=20 > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=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 Tue Feb 06 09:41:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERVu-0000hc-Rw; Tue, 06 Feb 2007 09:41:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERVt-0000hV-VG for pcn@ietf.org; Tue, 06 Feb 2007 09:41:41 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERVr-0007rd-Sp for pcn@ietf.org; Tue, 06 Feb 2007 09:41:41 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l16Efceb018700 for ; Tue, 6 Feb 2007 09:41:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] "Network Admission Control" (NAC) Date: Tue, 6 Feb 2007 09:41:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdJXWB62tBAVOtAQq6PRkrVU6CYlgAaPllQAA1FTvA= References: <6439282641581441A36F7F6F83ED2ED2CBFB0C@S4DE8PSAAFQ.mitte.t-com.de> From: "Rodrig, Benny \(Benny\)" To: "Geib, Ruediger" X-Scanner: InterScan AntiVirus for Sendmail 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 List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger, Michael, I don't feel strongly about this either way. Terminology debates are = often significant when they indicate differences in views and = assumptions about scope and focus. But my impression is that this is not = the case here and that we're talking about the same thing. Benny=20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: Tuesday, February 06, 2007 3:18 AM To: Rodrig, Benny (Benny) Cc: pcn@ietf.org; menth@informatik.uni-wuerzburg.de Subject: RE: [PCN] "Network Admission Control" (NAC) Benny, I prefer Michaels proposal, NAC or DAC is allright with me if we provide = a definition for our terminology. The same would hold if "flow = admission" is used, which I feel to be to close to "per flow". A side note on the abbreviation NAC: it is also described as Network = Access Control by Wikipedia. I've checked that because within my company = what is described by Wiki as Network "Admission Control" is called = Network Access Control. Regards, Ruediger |-----Original Message----- |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |Sent: Monday, February 05, 2007 8:37 PM |To: Rodrig, Benny (Benny) |Cc: Geib, R=FCdiger; pcn@ietf.org |Subject: Re: [PCN] "Network Admission Control" (NAC) | | |Hi, | |the word NAC itself means that access is possibly denied to a network=20 |which can be due to security or resource reasons. NAC in the security=20 |context has become a quite popular expression as it is the name of a=20 |Cisco product. The name NAC sounds good (to me) as it is very catchy=20 |and easy to understand also for non-experts. I don't see a large=20 |problem when the term NAC exists in different contexts. If people need=20 |to distinguish both approaches, security-related NAC and=20 |resource-related NAC can be used. However, people working in both areas = |might see this differently. | |As the new version of the PCN charter talks about domains, domain=20 |admission control (DAC) would be a natural substitute for NAC. DAC has=20 |no misleading connotations, but it doesn't sound nice (to me). Better=20 |sounds maybe per-domain AC (PDAC) and concisely states what it is. In=20 |analogy to routing, intradomain admission control is another option,=20 |but it also implies the existence of interdomain admission control. I'm = |not sure whether we want this right now. |=20 |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN=20 |charter, we can leave this issue open until we have a clearer opinion. | | Michael | |Rodrig, Benny (Benny) wrote: |> Ruediger, |> |> To me the charter doesn't seem to imply the expansion of scope that=20 |> you're concerned about. Unlike many other terms "flow admission"=20 |> doesn't seem to have misleading connotations. But I could be ok with=20 |> "network flow admission". |> |> If it is important that the charter be more explicit about this=20 |> point, then perhaps a sentence should be added with some explicit=20 |> description e.g. that the flow admission behavior at the boundary=20 |> includes policing and/or interaction with per-flow mechanisms that=20 |> are out of scope of PCN. |> |> Benny |> =20 |> |> -----Original Message----- |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> Sent: Monday, February 05, 2007 3:01 AM |> To: Rodrig, Benny (Benny) |> Cc: pcn@ietf.org |> Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> I'm not sure whether "flow admission" is the correct description.=20 |> Wouldn' or couldn't that mean that PCN includes work on the per flow=20 |> admission control functionality. PCN then is chartered to work on |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with |Network- or |> Aggregate- or Per Domain Behaviour- Admission Control, then the=20 |> chartered PCN work could be limited to provide an interface (API?) to = |> the per flow signaling protocol. Isn't the latter sufficient for the=20 |> initial charter? |> |> Regards, |> |> Ruediger |> |> |-----Original Message----- |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |> |Sent: Friday, February 02, 2007 5:09 PM |> |To: Moore, Sean (Sean); Tina TSOU; |menth@informatik.uni-wuerzburg.de; |> |Geib, Rudiger |> |Cc: pcn@ietf.org |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> | |> | |> |I think the 'flow admission' wording in the charter is fine and we=20 |> |don't need to choose a more precise term. The charter text |explaining |> |that this flow admission happens at the domain boundary in |reaction to |> |pre-congestion info from within the domain, etc. seems to |describe it |> |sufficiently. |> | |> |Benny |> | |> |-----Original Message----- |> |From: Moore, Sean (Sean) |> |Sent: Friday, February 02, 2007 9:59 AM |> |To: Tina TSOU; Rodrig, Benny (Benny); |menth@informatik.uni-wuerzburg.de |> |Cc: pcn@ietf.org; Geib, Ruediger |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> | |> |Probably shouldn't use "Resource Admission Control" as this |term (RAC) |> |is used in IMS and it is not the same as what we are discussing |> |- Sean |> | |> |-----Original Message----- |> |From: Tina TSOU [mailto:tena@huawei.com] |> |Sent: Friday, February 02, 2007 9:25 AM |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |> |Cc: pcn@ietf.org; Geib, Ruediger |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> | |> |Hi, |> |How about Resource Admission Control or Network Resource Admission=20 |> |Control? |> |I don't have strong opinion on that, just some terms popped up in my |> |mind:) |> | |> |B. R. |> |Tina |> | |> |----- Original Message ----- |> |From: "Michael Menth" |> |To: "Rodrig, Benny (Benny)" |> |Cc: ; "Geib, Ruediger" |> |Sent: Friday, February 02, 2007 12:16 PM |> |Subject: [PCN] "Network Admission Control" (NAC) |> | |> | |> |> Hi, |> |> |> |> I've got a comment on the term "Network Admission Control" (NAC). |> |> |> |> Wikipedia |> |http://en.wikipedia.org/wiki/Network_Admission_Control only |> |> knows NAC in the context of restricting access to the |> |network based on |> | |> |> identity or security posture (it's essentially a Cisco product).=20 |> |> However, most important is the aspect that access is denied |> |to a whole |> | |> |> network, subnetwork, domain, region, etc. NAC is in |contrast to AC |> |> algorithms deciding whether a new flow can be admitted to be=20 |> |> transported over a single link which has been studied in |> |depth in the |> |> 1990s in the context of ATM systems. Three years ago, I have |> |reviewed |> |> and studied different approaches for NAC (based on resource |> |management |> |issues) in my PhD thesis: |> |>=20 |>=20 ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04 |> |> .pdf The terms connection or flow admission control are less |> |specific |> |> than NAC as they do not tell the scope of the AC. |> |> |> |> Best regards, |> |> |> |> Michael |> |> |> |> Rodrig, Benny (Benny) wrote: |> |>> What I think you mean, and the admission control that PCN |> |deals with, |> | |> |>> better not be described as "network admission control"=20 |since that |> |>> term often (e.g. see |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |> |>> refers to admission based on the identity of the sender, |which is |> |>> probably out of scope for PCN. The flow admission control in PCN=20 |> |>> scope is based on considerations related to network status i.e. |> |>> pre-congestion. |> |>> The PCN flow admission control can be part of a call admission=20 |> |>> control solution, if it interacts with other mechanisms |such as for |> |>> example with Int-Serv outside the PCN domain and/or with SIP QoS=20 |> |>> pre-conditions. Such interactions, or assumptions about |> |them, may not |> |be in the scope of PCN. |> |>> |> |>> |> |>> Benny |> |>> -----Original Message----- |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent:=20 |> |>> Thursday, February 01, 2007 4:44 AM |> |>> To: Romascanu, Dan (Dan) |> |>> Cc: pcn@ietf.org |> |>> Subject: RE: [PCN] charter, addition to scope |> |>> |> |>> Hi Dan, |> |>> |> |>> your proposal seems sound to me. My impression is the |> |discussion may |> |>> have approached consensus on the following issues to get |chartered |> |>> initially: |> |>> |> |>> - PCN is limited to a single DiffServ domain. |> |>> - PCN aware nodes must be "on path". |> |>> - PCN only standardises PCN related IP layer |> |>> functionalities including RSVP or NSIS signaling |> |>> between edge nodes. |> |>> - PCN only works on "network admission control". |> |>> |> |>> If "Edge node" requires further definition to exclude |> |things to close |> | |> |>> to an "end system", we should add it at appropriate places. |> |>> "PCN related" would exclude dealing with middleboxes |doing anything |> |>> else with packets than PCN DiffServ forwarding. |> |>> |> |>> Another question is, what the reaction of an ingress edge |> |node should |> | |> |>> be in case of an indicated network congestion. My |> |impression is, that |> | |> |>> with the initial charter we should just define a desired |> |behaviour in |> | |> |>> terms of an aggregate traffic reduction (e.g. "stop |admission new |> |>> flows demanding CL forwarding or bandwidth increases of admitted=20 |> |>> ones" or "reduce CL traffic by x percent"). |> |>> Future work items may be added when the WG is re-chartered after=20 |> |>> having reached first aims. It may indeed be useful to |think about |> |>> some requirements for future PCN use already now. As I |didn't think |> |>> about particular topics in detail, I don't try to |summarise which |> |>> requirements that could be by this mail. |> |>> |> |>> Regards, |> |>> |> |>> Ruediger |> |>> |> |>> |> |>> |-----Original Message----- |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |> |>> |Sent: Thursday, February 01, 2007 9:45 AM |> |>> |To: Lee, Richard FTC; Black_David@emc.com; |karagian@cs.utwente.nl |> |>> |Cc: pcn@ietf.org |> |>> |Subject: RE: [PCN] charter, addition to scope |> |>> | |> |>> | |> |>> |Maybe we should stop for a moment and consider what layer |> |should PCN |> | |> |>> |deal with. It looks to me that we are mixing network admission=20 |> |>> |control and call admission control in this discussion. |> |This problem |> |>> |is quite complex, and there are many scenarios that need |> |to be taken |> | |> |>> |into consideration. Sometimes flow =3D call, sometimes call |> |=3DNOT flow |> |>> |and sometimes there is a mix on the same path. In some |cases media |> |>> |gateways |> |>> |> |>> |are collocated with the edge nodes in some other cases |not. Even |> |>> |when flow =3D call there are two admission control layers |> |(network and |> | |> |>> |call) that are in dependency but not identical and separate=20 |> |>> |protocols run at transport and session. I am not sure |how much of |> |>> |all this falls under what PCN should do. |> |>> | |> |>> |Dan |> |>> | |> |>> | |> |>> | |> |>> | |> |>> | | | |> |>> |> -----Original Message----- |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |> |>> |> Cc: pcn@ietf.org |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |>> |> |> To all, |> |>> |> I agree that there must be a prioritization of flows |from the |> |> |>> aggregation devices However, it's not just the media |> |gateway that |> |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") |> |as well - |> |>> |> |>> |> it is the signaling proxy at the edge that reserves the media=20 |> |>> |> path. |> |> |>> The reservation protocol request to the network from the VoIP |>=20 |> |>> proxy/gateway must reserve resources to the destination |in the |> |> |>> network. |> |>> |> The resource reservation request to the network by the edge |> |> |>> proxy/media gateway, must at the very minimum, meet the |following |> |> |>> conditions: |> |>> |> 1. it needs to specify the resources required for the |IP & ports |> |>> |> |> |> |>> (RTP/RTCP & bandwidth) |> |>> |> for example, G.711 and G.729 voice and various |MPEG-4 video |> |>> |> codecs |> |>> |> |>> |> all have very different requirements 2. it must be |mapped to the |> |>> |> |> |> |>> signaling request |> |>> |> for SIP, it must map the SDP for media with the |reservation |> |>> |> flow - |> |>> |> |>> |> for example something along the lines of RFC 3524 |> |>> |> while not the answer, the mapping of the media |flows is a |> |> |>> necessary component |> |>> |> It should be noted that the edge proxies/media |gateways may |> |>> |> have a |> |>> |> |>> |> large number of flows (and ports for each |> |>> |> RTP/RTCP flow) from the same source IP. The request |> |is made for |> | |> |>> |> |> |> |>> each flow or conversation 3. it must be honored by the |edge network |> |>> |> device. |> |>> |> The trust boundary must be extended to the edge |proxy/media |> |> |>> gateway for each new flow. |> |>> |> This brings up the issue of security authentication |> |of the edge |> | |> |>> |> |> |> |>> proxy/media gateway to the network |> |>> |> Does this happen in EAP, NAC, or just interoperability and |> |> |>> certification among vendors |> |>> |> If the resources are not available, then the signaling=20 |> |>> |> indicates |> |> |>> the session is not completed. For example a SIP |> |>> |> CANCEL from the edge proxy |> |>> |> |> In addition, the network device must have priority queuing=20 |> |>> |> |> enabled |> |>> |> for input queues from the edge device. |> |>> |> The media flows must not be subject to input buffers |> |being filled |> |>> |> |> |> |>> prior to classification |> |>> |> |> Thanks, |> |>> |> Richard Lee |> |>> |> Fidelity Investments |> |>> |> Enterprise Technology and Architecture |> |>> |> 617-563-3278 |> |>> |> |> |> -----Original Message----- |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |> |>> |> To: karagian@cs.utwente.nl |> |>> |> Cc: pcn@ietf.org |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |>> |> |> |> Georgios wrote: |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> |>> |> > > > In the first phase of PCN work to reduce the list of |> |>> |> issues it was |> |>> |> |> > > > proposed that the WG focus on network |> |deployment scenario |> |>> where |> |>> |> all |> |>> |> > > > nodes can be trusted and delay work on deployment |> |>> |> scenarios where |> |>> |> some |> |>> |> > > > of the nodes are not trusted. |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, |then yes, I |> |>> agree. If |> |>> |> "nodes" |> > > include end systems, proxies or other |entities, |> |>> |> then I |> |>> don't |> > > agree we had agreement on that. |> |>> |> > |> > Georgios: This imposes an additional |restriction on the |> |>> |> > |> > scope |> |>> of |> > the charter, which has been not discussed yet. |> |>> |> > >From what I remember before, during and after the PCN BOF |> |>> |> > there was no objection on using the term edge node, |that could |> |>> |> > mean something different than a edge |> |>> |> router. |> |>> |> > Please note that this is something different than a |> |>> |scenario covered |> |>> |> by |> |>> |> > an application based deployment model. |> |>> |> |> It's certainly not a new restriction based on the |> |discussion in |> | |> |>> |> |> the |> |>> |> BOF engendered about whether a SIP telephone (used on |some of the |> |>> |> slides) was a good example. I believe the BOF |> |conclusion was that |> | |> |>> |> a SIP telephone was a bad example. |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |> |>> |proposed work: |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) |The first set |> |>> |> of issues has already been discussed extensively - my=20 |> |>> |> understanding is that the SIP scenario is currently out |> |of scope, |> |>> |> and |> |>> |> |>> |> I don't care to reopen that discussion. |> |>> |> |> The "telephone" issues come up in two ways: |> |>> |> (2a) Small number of flows may make relatively fine-grained |> |>> |adjustment |> |>> |> on the link to the phone impossible. The PCN work |prior to the |> |>> |> BOF relied on the ability to make such adjustments. |> |>> |> (2b) While other sorts of phones may be trusted, a SIP phone=20 |> |>> |> (which may be software-only) is definitely not trustable in |> |general. |> |>> |> |> I would observe that Lars Westerberg's suggestion |of a Media |> |>> Gateway: |> |>> |> |> > I am referring telecom scenario where MGWs are |connected to |> |>> |> |> > an |> |>> |> IP-backbone. |> |>> |> > In these scenarios, the admission control function is |> |a part of |> |>> |> > the |> |>> |> MGW |> |>> |> > and not the routers. The IP-backbone is provisioned by |> |a network |> | |> |>> |> > |> |> |>> > management system. |> |>> |> |> could avoid all of these issues: |> |>> |> (1) The media gateway could speak RSVP to the network |management |> |>> |> |> |> |>> system, |> |>> |> avoiding any need to deal with SIP here. |> |>> |> (2a) A media gateway is likely to handle enough flows to be |> |>> |consistent |> |>> |> with the fine-grained adjustment assumed by the work done to |> |>> date. |> |>> |> (2b) One can plausibly assume/require that media gateways be=20 |> |>> |> trusted with respect to the IP network. |> |>> |> To the extent that one can vest "edge" functionality in |> |a trusted |> |>> |> |> |> |>> media gateway, I see no reason to exclude that scenario. |> |>> |> |> Thanks, |> |>> |> --David |> |>> |> ---------------------------------------------------- |> |>> |> David L. Black, Senior Technologist EMC Corporation, |176 South |> |>> |> St., Hopkinton, MA 01748 |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |> |>> |> ---------------------------------------------------- |> |>> |> |> _______________________________________________ |> |>> |> 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,=20 |> |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, |> |Germany, |> |> room B206 |> |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 |> |> 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 |> =20 | |-- |Dr. Michael Menth, Assistant Professor |University of Wuerzburg, Institute of Computer Science Am Hubland,=20 |D-97074 Wuerzburg, Germany, room B206 |phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 |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 Feb 06 10:32:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESJ2-0008Ho-Uz; Tue, 06 Feb 2007 10:32:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESJ1-0008Hj-SY for pcn@ietf.org; Tue, 06 Feb 2007 10:32:27 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HESIw-0000G0-Ly for pcn@ietf.org; Tue, 06 Feb 2007 10:32:27 -0500 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 l16FVw510365; Tue, 6 Feb 2007 10:31:59 -0500 (EST) 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 Charter proposal version 4 Date: Tue, 6 Feb 2007 10:31:14 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E842F31@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEE4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUAAE63xw From: "Jozef Babiarz" To: , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 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 I believe that the encoding of PCN information in the IP header that interior nodes will perform needs to be standardized.=20 The signaling or transport of PCN information from egress to ingress nodes should be written as requirements (informational) so that signaling protocols such as RSVP, NSIS and possibly others can be extended to convey PCN information between boarder nodes. PCN WG will not work on any extensions to signaling protocols. =20 Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: February 6, 2007 7:55 AM To: karagian@cs.utwente.nl; brodrig@avaya.com; magnus.westerlund@ericsson.com; pcn@ietf.org Subject: RE: [PCN] PCN Charter proposal version 4 The encoding has to be STD, I believe=20 The transport protocol - have given my views earlier > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 06 February 2007 10:03 > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 >=20 > Hi >=20 > I agree with Benny's suggestion that we should not make the > 'Encoding and Transport of (Pre-)Congestion Information from the Domain > Egress to the Ingress' as a Proposed Standard. > BCP is okay with me! >=20 > Best Regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > Sent: maandag 5 februari 2007 19:56 > > To: Magnus Westerlund; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > I think it was good to add to the milestones the > > 'Requirements for Signaling of (Pre-)Congestion information > > from Egress to Ingress Nodes in a DiffServ Domain > > (Informational)' per Joe's suggestion. > > > > Now isn't there something puzzling in keeping 'Encoding and > > Transport of (Pre-)Congestion Information from the Domain > > Egress to the Ingress' as a Proposed Standard? Proposed > > Standard seems to suggest that the PCN WG will be defining > > protocol mechanisms for this, which is not obviously the > > case. What if this relies on other protocols that may be > > running between the boundary nodes in different scenarios > > (e.g. NSIS QoS NSLP, RSVP, SDP in SIP)? In that case such a > > document, if at all needed, would probably have to be just a BCP. > > > > Benny > > > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Monday, February 05, 2007 10:33 AM > > To: pcn@ietf.org > > Subject: [PCN] PCN Charter proposal version 4 > > > > Hi, > > > > Below is the 4th version of the PCN charter. It contains some > > modifications in the beginning to try to be more explicit > > about the decomposition. Then I also incorporated some of > > Jozef's comments. > > > > Cheers > > > > Magnus > > > > ---- > > > > Congestion and Pre-Congestion Notification (PCN) > > > > Chair(s): > > tbd > > > > Transport Area Director(s): > > Magnus Westerlund > > Lars Eggert > > > > Transport Area Advisor: > > Lars Eggert > > > > Mailing Lists: > > General Discussion: pcn@ietf.org > > To Subscribe: pcn-request@ietf.org > > In Body: (un)subscribe > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > Description of Working Group: > > > > The Congestion and Pre-Congestion Notification (PCN) working > > group develops mechanisms to protect the quality-of-service > > of established flows within a DiffServ domain when congestion > > is imminent or existing. > > These mechanisms operate at the domain boundary, based on > > aggregated congestion and pre-congestion information from > > within the domain. The focus of the WG is on developing > > standards for the marking behavior of the interior nodes and > > the encoding transport of the congestion information. The > > transport and encoding of the congestion information is > > decompositioned into several components. The forward flow > > path to the domain boundary, the metering of the congestion > > situation at the boundary, and the transport of the data to > > the controlling peer. This decomposition is done to allow for > > future extensibility by defining additional variants of the > > components (with the exception of the first one). Reaction > > mechanisms at the boundary consist of flow admission and flow > > termination. Although designed to work together, flow > > admission and flow termination are independent mechanisms, > > and the use of one does not require or prevent the use of the > > other. In consultation with the AD, the WG may produce a > > small number of informational documents that describe how > > specific quality-of-service policies for a domain can be > > implemented using these two mechanisms. > > > > The PCN WG will specify the following components to protect > > the quality-of-service of flows within a DiffServ domain: > > > > (1) a general architecture for flow admission and > > termination based > > on aggregated (pre-)congestion information > > > > (2) a specification of conditions under which interior > > nodes generate > > (pre-)congestion information > > > > (3) encoding and transport of (pre-)congestion information > > between the interior and the egress node of the domain > > > > (4) Metering of the (pre-)congestion information at the egress > > node of the domain. > > > > (5) encoding and transport of (pre-)congestion information > > between the egress node and the ingress node of the domain > > (when necessary). > > > > (6) ingress node control mechanisms for flow admission or > > termination, > > based on aggregated (pre-)congestion information > > > > The WG focuses on the overall architecture, and specifically > > on the marking behavior and encoding and transport mechanisms > > needed to realize it. Standards-track protocols and > > mechanisms are only developed where necessary for > > interoperability. For other components of the architecture, > > the WG may document examples or provide recommended solutions > > in informational documents. The architecture document will be > > comprehensive, and include security, manageability and > > operational considerations. If this WG requires extensions or > > modifications to protocols that are products of other WGs, it > > may motivate their need and describe requirements in > > informational documents; design of such extensions and > > modifications will take place in the appropriate WGs. > > > > > > The initial scope of the PCN WG is restricted by the following > > assumptions: > > > > (A) these components are deployed in a single DiffServ domain, > > where all boundary and interior nodes are PCN-enabled > > and mutually trust each other > > > > (B) all flows handled by these mechanisms are inelastic and > > constrained to a known maximum rate through policing > > or shaping > > > > (C) the number of flows across any potential aggregation > > bottleneck > > is sufficiently large for stateless, statistical > > mechanisms to be > > effective > > > > (D) flows may have different precedence, but the applicability > > of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, > > etc.) > > is out of scope > > > > After completion of the initial phase, the PCN WG may > > re-charter to develop solutions for scenarios where some of > > these restrictions are not in place. It may also re-charter > > to consider applying the PCN mechanisms to additional > > deployment scenarios (operation over concatenated DiffServ > > domains, PCN-aware application mechanisms, etc.). The WG may > > also consider to investigate additional response mechanisms > > that act on (pre-)congestion information. One example could > > be flow-rate adaptation (rather than flow > > admission/termination) during times of congestion. The > > details of these work items are outside the scope of the > > initial phase; but the WG may consider their requirements to > > design components that are sufficiently general to support > > such extensions in the future. > > > > > > Goals and Milestones: > > > > Nov 2007 Flow Admission and Termination Architecture > > (Informational) > > > > Nov 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information within a DiffServ Domain > > (Informational) > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > Domain (Informational) > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > (Proposed Standard) > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion information > > from Egress to Ingress Nodes in a DiffServ Domain > > (Informational) > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > from within a DiffServ Domain to the Egress > > (Proposed Standard) > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > from the Domain Egress to the Ingress > > (Proposed Standard) > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > Mechanisms > > (Informational) > > > > -- > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > ---------------------------------------------------------------------- > > 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 > > >=20 >=20 >=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 Tue Feb 06 10:37:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESO0-0003pa-VF; Tue, 06 Feb 2007 10:37:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESO0-0003nk-0H for pcn@ietf.org; Tue, 06 Feb 2007 10:37:36 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HESNx-0001VR-8h for pcn@ietf.org; Tue, 06 Feb 2007 10:37:35 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16FZr4t027319; Tue, 6 Feb 2007 16:35:58 +0100 (MET) From: "Georgios Karagiannis" To: "'Jozef Babiarz'" , , , , References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEE4@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB64650E842F31@zcarhxm1.corp.nortel.com> Subject: RE: [PCN] PCN Charter proposal version 4 Date: Tue, 6 Feb 2007 16:36:11 +0100 Message-ID: <004b01c74a04$8a3ebb00$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUAAE63xwAACvNPA= In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E842F31@zcarhxm1.corp.nortel.com> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 16:35:59 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c 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 Joe Okay, then we actually agree! Informational for the PCN information from egress to ingress nodes is okay for me! Best regards, Georgios > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: dinsdag 6 februari 2007 16:31 > To: philip.eardley@bt.com; karagian@cs.utwente.nl; > brodrig@avaya.com; magnus.westerlund@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 > > I believe that the encoding of PCN information in the IP > header that interior nodes will perform needs to be standardized. > > The signaling or transport of PCN information from egress to > ingress nodes should be written as requirements > (informational) so that signaling protocols such as RSVP, > NSIS and possibly others can be extended to convey PCN > information between boarder nodes. PCN WG will not work on > any extensions to signaling protocols. > > > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: February 6, 2007 7:55 AM > To: karagian@cs.utwente.nl; brodrig@avaya.com; > magnus.westerlund@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 > > The encoding has to be STD, I believe > The transport protocol - have given my views earlier > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 06 February 2007 10:03 > > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > Hi > > > > I agree with Benny's suggestion that we should not make the > 'Encoding > > and Transport of (Pre-)Congestion Information from the > Domain > > Egress to the Ingress' as a Proposed Standard. > > BCP is okay with me! > > > > Best Regards, > > Georgios > > > > > > > -----Original Message----- > > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > > Sent: maandag 5 februari 2007 19:56 > > > To: Magnus Westerlund; pcn@ietf.org > > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > > > I think it was good to add to the milestones the > 'Requirements for > > > Signaling of (Pre-)Congestion information from Egress to Ingress > > > Nodes in a DiffServ Domain (Informational)' per Joe's suggestion. > > > > > > Now isn't there something puzzling in keeping 'Encoding and > > > Transport of (Pre-)Congestion Information from the Domain > Egress to > > > the Ingress' as a Proposed Standard? Proposed Standard seems to > > > suggest that the PCN WG will be defining protocol mechanisms for > > > this, which is not obviously the case. What if this > relies on other > > > protocols that may be running between the boundary nodes in > > > different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in > SIP)? In that > > > case such a document, if at all needed, would probably have to be > > > just a BCP. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Monday, February 05, 2007 10:33 AM > > > To: pcn@ietf.org > > > Subject: [PCN] PCN Charter proposal version 4 > > > > > > Hi, > > > > > > Below is the 4th version of the PCN charter. It contains some > > > modifications in the beginning to try to be more explicit > about the > > > decomposition. Then I also incorporated some of Jozef's comments. > > > > > > Cheers > > > > > > Magnus > > > > > > ---- > > > > > > Congestion and Pre-Congestion Notification (PCN) > > > > > > Chair(s): > > > tbd > > > > > > Transport Area Director(s): > > > Magnus Westerlund > > > Lars Eggert > > > > > > Transport Area Advisor: > > > Lars Eggert > > > > > > Mailing Lists: > > > General Discussion: pcn@ietf.org > > > To Subscribe: pcn-request@ietf.org > > > In Body: (un)subscribe > > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > > > > Description of Working Group: > > > > > > The Congestion and Pre-Congestion Notification (PCN) > working group > > > develops mechanisms to protect the quality-of-service of > established > > > flows within a DiffServ domain when congestion is imminent or > > > existing. > > > These mechanisms operate at the domain boundary, based on > aggregated > > > congestion and pre-congestion information from within the domain. > > > The focus of the WG is on developing standards for the marking > > > behavior of the interior nodes and the encoding transport of the > > > congestion information. The transport and encoding of the > congestion > > > information is decompositioned into several components. > The forward > > > flow path to the domain boundary, the metering of the congestion > > > situation at the boundary, and the transport of the data to the > > > controlling peer. This decomposition is done to allow for future > > > extensibility by defining additional variants of the components > > > (with the exception of the first one). Reaction mechanisms at the > > > boundary consist of flow admission and flow termination. Although > > > designed to work together, flow admission and flow > termination are > > > independent mechanisms, and the use of one does not require or > > > prevent the use of the other. In consultation with the AD, the WG > > > may produce a small number of informational documents > that describe > > > how specific quality-of-service policies for a domain can be > > > implemented using these two mechanisms. > > > > > > The PCN WG will specify the following components to protect the > > > quality-of-service of flows within a DiffServ domain: > > > > > > (1) a general architecture for flow admission and termination > > > based > > > on aggregated (pre-)congestion information > > > > > > (2) a specification of conditions under which interior nodes > > > generate > > > (pre-)congestion information > > > > > > (3) encoding and transport of (pre-)congestion information > > > between the interior and the egress node of the domain > > > > > > (4) Metering of the (pre-)congestion information at the egress > > > node of the domain. > > > > > > (5) encoding and transport of (pre-)congestion information > > > between the egress node and the ingress node of the domain > > > (when necessary). > > > > > > (6) ingress node control mechanisms for flow admission or > > > termination, > > > based on aggregated (pre-)congestion information > > > > > > The WG focuses on the overall architecture, and > specifically on the > > > marking behavior and encoding and transport mechanisms needed to > > > realize it. Standards-track protocols and mechanisms are only > > > developed where necessary for interoperability. For other > components > > > of the architecture, the WG may document examples or provide > > > recommended solutions in informational documents. The > architecture > > > document will be comprehensive, and include security, > manageability > > > and operational considerations. If this WG requires extensions or > > > modifications to protocols that are products of other WGs, it may > > > motivate their need and describe requirements in informational > > > documents; design of such extensions and modifications will take > > > place in the appropriate WGs. > > > > > > > > > The initial scope of the PCN WG is restricted by the following > > > assumptions: > > > > > > (A) these components are deployed in a single DiffServ domain, > > > where all boundary and interior nodes are PCN-enabled > > > and mutually trust each other > > > > > > (B) all flows handled by these mechanisms are inelastic and > > > constrained to a known maximum rate through policing or > > > shaping > > > > > > (C) the number of flows across any potential aggregation > > > bottleneck > > > is sufficiently large for stateless, statistical > mechanisms > > > to be > > > effective > > > > > > (D) flows may have different precedence, but the applicability > > > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, > > > etc.) > > > is out of scope > > > > > > After completion of the initial phase, the PCN WG may > re-charter to > > > develop solutions for scenarios where some of these > restrictions are > > > not in place. It may also re-charter to consider applying the PCN > > > mechanisms to additional deployment scenarios (operation over > > > concatenated DiffServ domains, PCN-aware application mechanisms, > > > etc.). The WG may also consider to investigate additional > response > > > mechanisms that act on (pre-)congestion information. One example > > > could be flow-rate adaptation (rather than flow > > > admission/termination) during times of congestion. The details of > > > these work items are outside the scope of the initial > phase; but the > > > WG may consider their requirements to design components that are > > > sufficiently general to support such extensions in the future. > > > > > > > > > Goals and Milestones: > > > > > > Nov 2007 Flow Admission and Termination Architecture > > > (Informational) > > > > > > Nov 2007 Survey of Encoding and Transport Choices of > > > (Pre-)Congestion Information within a DiffServ Domain > > > (Informational) > > > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > > Domain (Informational) > > > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > > (Proposed Standard) > > > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion > information > > > from Egress to Ingress Nodes in a DiffServ Domain > > > (Informational) > > > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > > from within a DiffServ Domain to the Egress > > > (Proposed Standard) > > > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > > from the Domain Egress to the Ingress > > > (Proposed Standard) > > > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > > Mechanisms > > > (Informational) > > > > > > -- > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > > ---------------------------------------------------------------------- > > > 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 > > > > > > > > > > > _______________________________________________ > > 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 Feb 06 10:39:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESPP-00045p-KI; Tue, 06 Feb 2007 10:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESPO-00044n-TO for pcn@ietf.org; Tue, 06 Feb 2007 10:39:02 -0500 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 1HESPM-0001h1-5g for pcn@ietf.org; Tue, 06 Feb 2007 10:39:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2007 07:39:00 -0800 X-IronPort-AV: i="4.13,291,1167638400"; d="scan'208"; a="761866769:sNHT66350514" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l16FcwNa000773; Tue, 6 Feb 2007 07:38:58 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l16FcfEI024432; Tue, 6 Feb 2007 07:38:53 -0800 (PST) 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); Tue, 6 Feb 2007 10:38:50 -0500 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 Charter proposal version 4 Date: Tue, 6 Feb 2007 10:38:48 -0500 Message-ID: In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E842F31@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUAAE63xwAAC13OA= From: "Anna Charny \(acharny\)" To: "Jozef Babiarz" , , , , , X-OriginalArrivalTime: 06 Feb 2007 15:38:50.0514 (UTC) FILETIME=[E6294F20:01C74A04] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12414; t=1170776338; x=1171640338; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20Charter=20proposal=20version=204 |Sender:=20; bh=sdbJJiaMr2QdxXvelwcYirmJif2oOWXCAA00on8JZic=; b=BMPp7s6beg5IMTiM8K8laona6OIDreADzmQRlgYcKbxIXU/VGmCjO0yAtduXEeIRtAT7MmYp f6V78yYB8TLwpllCbknKU+mF0wU3ULiLK9xqd+c0l6pAubxernk5A0WY; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 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 Joe, That is my understanding as well. It is my understanding also that the PCN WG might explicitly send a liason to relevant WGs to request development of appropriate signaling extensions.=20 Anna=20 > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 > Sent: Tuesday, February 06, 2007 10:31 AM > To: philip.eardley@bt.com; karagian@cs.utwente.nl;=20 > brodrig@avaya.com; magnus.westerlund@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 >=20 > I believe that the encoding of PCN information in the IP=20 > header that interior nodes will perform needs to be standardized.=20 >=20 > The signaling or transport of PCN information from egress to=20 > ingress nodes should be written as requirements=20 > (informational) so that signaling protocols such as RSVP,=20 > NSIS and possibly others can be extended to convey PCN=20 > information between boarder nodes. PCN WG will not work on=20 > any extensions to signaling protocols. >=20 > =20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: February 6, 2007 7:55 AM > To: karagian@cs.utwente.nl; brodrig@avaya.com;=20 > magnus.westerlund@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 >=20 > The encoding has to be STD, I believe > The transport protocol - have given my views earlier >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 06 February 2007 10:03 > > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > >=20 > > Hi > >=20 > > I agree with Benny's suggestion that we should not make the=20 > 'Encoding=20 > > and Transport of (Pre-)Congestion Information from the > Domain > > Egress to the Ingress' as a Proposed Standard. > > BCP is okay with me! > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > > > -----Original Message----- > > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > > Sent: maandag 5 februari 2007 19:56 > > > To: Magnus Westerlund; pcn@ietf.org > > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > > > I think it was good to add to the milestones the=20 > 'Requirements for=20 > > > Signaling of (Pre-)Congestion information from Egress to Ingress=20 > > > Nodes in a DiffServ Domain (Informational)' per Joe's suggestion. > > > > > > Now isn't there something puzzling in keeping 'Encoding and=20 > > > Transport of (Pre-)Congestion Information from the Domain=20 > Egress to=20 > > > the Ingress' as a Proposed Standard? Proposed Standard seems to=20 > > > suggest that the PCN WG will be defining protocol mechanisms for=20 > > > this, which is not obviously the case. What if this=20 > relies on other=20 > > > protocols that may be running between the boundary nodes in=20 > > > different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in=20 > SIP)? In that=20 > > > case such a document, if at all needed, would probably have to be=20 > > > just a BCP. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Monday, February 05, 2007 10:33 AM > > > To: pcn@ietf.org > > > Subject: [PCN] PCN Charter proposal version 4 > > > > > > Hi, > > > > > > Below is the 4th version of the PCN charter. It contains some=20 > > > modifications in the beginning to try to be more explicit=20 > about the=20 > > > decomposition. Then I also incorporated some of Jozef's comments. > > > > > > Cheers > > > > > > Magnus > > > > > > ---- > > > > > > Congestion and Pre-Congestion Notification (PCN) > > > > > > Chair(s): > > > tbd > > > > > > Transport Area Director(s): > > > Magnus Westerlund > > > Lars Eggert > > > > > > Transport Area Advisor: > > > Lars Eggert > > > > > > Mailing Lists: > > > General Discussion: pcn@ietf.org > > > To Subscribe: pcn-request@ietf.org > > > In Body: (un)subscribe > > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > > > > Description of Working Group: > > > > > > The Congestion and Pre-Congestion Notification (PCN)=20 > working group=20 > > > develops mechanisms to protect the quality-of-service of=20 > established=20 > > > flows within a DiffServ domain when congestion is imminent or=20 > > > existing. > > > These mechanisms operate at the domain boundary, based on=20 > aggregated=20 > > > congestion and pre-congestion information from within the domain.=20 > > > The focus of the WG is on developing standards for the marking=20 > > > behavior of the interior nodes and the encoding transport of the=20 > > > congestion information. The transport and encoding of the=20 > congestion=20 > > > information is decompositioned into several components.=20 > The forward=20 > > > flow path to the domain boundary, the metering of the congestion=20 > > > situation at the boundary, and the transport of the data to the=20 > > > controlling peer. This decomposition is done to allow for future=20 > > > extensibility by defining additional variants of the components=20 > > > (with the exception of the first one). Reaction mechanisms at the=20 > > > boundary consist of flow admission and flow termination. Although=20 > > > designed to work together, flow admission and flow=20 > termination are=20 > > > independent mechanisms, and the use of one does not require or=20 > > > prevent the use of the other. In consultation with the AD, the WG=20 > > > may produce a small number of informational documents=20 > that describe=20 > > > how specific quality-of-service policies for a domain can be=20 > > > implemented using these two mechanisms. > > > > > > The PCN WG will specify the following components to protect the=20 > > > quality-of-service of flows within a DiffServ domain: > > > > > > (1) a general architecture for flow admission and termination=20 > > > based > > > on aggregated (pre-)congestion information > > > > > > (2) a specification of conditions under which interior nodes=20 > > > generate > > > (pre-)congestion information > > > > > > (3) encoding and transport of (pre-)congestion information > > > between the interior and the egress node of the domain > > > > > > (4) Metering of the (pre-)congestion information at the egress > > > node of the domain. > > > > > > (5) encoding and transport of (pre-)congestion information > > > between the egress node and the ingress node of the domain > > > (when necessary). > > > > > > (6) ingress node control mechanisms for flow admission or=20 > > > termination, > > > based on aggregated (pre-)congestion information > > > > > > The WG focuses on the overall architecture, and=20 > specifically on the=20 > > > marking behavior and encoding and transport mechanisms needed to=20 > > > realize it. Standards-track protocols and mechanisms are only=20 > > > developed where necessary for interoperability. For other=20 > components=20 > > > of the architecture, the WG may document examples or provide=20 > > > recommended solutions in informational documents. The=20 > architecture=20 > > > document will be comprehensive, and include security,=20 > manageability=20 > > > and operational considerations. If this WG requires extensions or=20 > > > modifications to protocols that are products of other WGs, it may=20 > > > motivate their need and describe requirements in informational=20 > > > documents; design of such extensions and modifications will take=20 > > > place in the appropriate WGs. > > > > > > > > > The initial scope of the PCN WG is restricted by the following > > > assumptions: > > > > > > (A) these components are deployed in a single DiffServ domain, > > > where all boundary and interior nodes are PCN-enabled > > > and mutually trust each other > > > > > > (B) all flows handled by these mechanisms are inelastic and > > > constrained to a known maximum rate through policing or=20 > > > shaping > > > > > > (C) the number of flows across any potential aggregation=20 > > > bottleneck > > > is sufficiently large for stateless, statistical=20 > mechanisms=20 > > > to be > > > effective > > > > > > (D) flows may have different precedence, but the applicability > > > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, > > > etc.) > > > is out of scope > > > > > > After completion of the initial phase, the PCN WG may=20 > re-charter to=20 > > > develop solutions for scenarios where some of these=20 > restrictions are=20 > > > not in place. It may also re-charter to consider applying the PCN=20 > > > mechanisms to additional deployment scenarios (operation over=20 > > > concatenated DiffServ domains, PCN-aware application mechanisms,=20 > > > etc.). The WG may also consider to investigate additional=20 > response=20 > > > mechanisms that act on (pre-)congestion information. One example=20 > > > could be flow-rate adaptation (rather than flow > > > admission/termination) during times of congestion. The details of=20 > > > these work items are outside the scope of the initial=20 > phase; but the=20 > > > WG may consider their requirements to design components that are=20 > > > sufficiently general to support such extensions in the future. > > > > > > > > > Goals and Milestones: > > > > > > Nov 2007 Flow Admission and Termination Architecture > > > (Informational) > > > > > > Nov 2007 Survey of Encoding and Transport Choices of > > > (Pre-)Congestion Information within a DiffServ Domain > > > (Informational) > > > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > > Domain (Informational) > > > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > > (Proposed Standard) > > > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion > information > > > from Egress to Ingress Nodes in a DiffServ Domain > > > (Informational) > > > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > > from within a DiffServ Domain to the Egress > > > (Proposed Standard) > > > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > > from the Domain Egress to the Ingress > > > (Proposed Standard) > > > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > > Mechanisms > > > (Informational) > > > > > > -- > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > > ---------------------------------------------------------------------- > > > 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:=20 > 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 > > > > >=20 > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 06 10:47:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESY2-0000Mb-DV; Tue, 06 Feb 2007 10:47:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESY2-0000MW-3Y for pcn@ietf.org; Tue, 06 Feb 2007 10:47:58 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HESY1-0003nE-JP for pcn@ietf.org; Tue, 06 Feb 2007 10:47:58 -0500 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 l16Flcg09957; Tue, 6 Feb 2007 10:47:38 -0500 (EST) 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 Charter proposal version 4 Date: Tue, 6 Feb 2007 10:47:36 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E842FBB@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdJOw3FkidZe7gQToyuEHC8Qb1qQQAGUpjwACBXN8AABgdIUAAE63xwAAC13OAAAGhDwA== From: "Jozef Babiarz" To: "Anna Charny \(acharny\)" , , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf 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 Anna, I would support that. Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: February 6, 2007 10:39 AM To: Babiarz, Jozef (CAR:0S03); philip.eardley@bt.com; karagian@cs.utwente.nl; brodrig@avaya.com; magnus.westerlund@ericsson.com; pcn@ietf.org Subject: RE: [PCN] PCN Charter proposal version 4 Hi Joe, That is my understanding as well. It is my understanding also that the PCN WG might explicitly send a liason to relevant WGs to request development of appropriate signaling extensions.=20 Anna=20 > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 > Sent: Tuesday, February 06, 2007 10:31 AM > To: philip.eardley@bt.com; karagian@cs.utwente.nl;=20 > brodrig@avaya.com; magnus.westerlund@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 >=20 > I believe that the encoding of PCN information in the IP=20 > header that interior nodes will perform needs to be standardized.=20 >=20 > The signaling or transport of PCN information from egress to=20 > ingress nodes should be written as requirements=20 > (informational) so that signaling protocols such as RSVP,=20 > NSIS and possibly others can be extended to convey PCN=20 > information between boarder nodes. PCN WG will not work on=20 > any extensions to signaling protocols. >=20 > =20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: February 6, 2007 7:55 AM > To: karagian@cs.utwente.nl; brodrig@avaya.com;=20 > magnus.westerlund@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] PCN Charter proposal version 4 >=20 > The encoding has to be STD, I believe > The transport protocol - have given my views earlier >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 06 February 2007 10:03 > > To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; pcn@ietf.org > > Subject: RE: [PCN] PCN Charter proposal version 4 > >=20 > > Hi > >=20 > > I agree with Benny's suggestion that we should not make the=20 > 'Encoding=20 > > and Transport of (Pre-)Congestion Information from the > Domain > > Egress to the Ingress' as a Proposed Standard. > > BCP is okay with me! > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > > > -----Original Message----- > > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > > Sent: maandag 5 februari 2007 19:56 > > > To: Magnus Westerlund; pcn@ietf.org > > > Subject: RE: [PCN] PCN Charter proposal version 4 > > > > > > I think it was good to add to the milestones the=20 > 'Requirements for=20 > > > Signaling of (Pre-)Congestion information from Egress to Ingress=20 > > > Nodes in a DiffServ Domain (Informational)' per Joe's suggestion. > > > > > > Now isn't there something puzzling in keeping 'Encoding and=20 > > > Transport of (Pre-)Congestion Information from the Domain=20 > Egress to=20 > > > the Ingress' as a Proposed Standard? Proposed Standard seems to=20 > > > suggest that the PCN WG will be defining protocol mechanisms for=20 > > > this, which is not obviously the case. What if this=20 > relies on other=20 > > > protocols that may be running between the boundary nodes in=20 > > > different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in=20 > SIP)? In that=20 > > > case such a document, if at all needed, would probably have to be=20 > > > just a BCP. > > > > > > Benny > > > > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Monday, February 05, 2007 10:33 AM > > > To: pcn@ietf.org > > > Subject: [PCN] PCN Charter proposal version 4 > > > > > > Hi, > > > > > > Below is the 4th version of the PCN charter. It contains some=20 > > > modifications in the beginning to try to be more explicit=20 > about the=20 > > > decomposition. Then I also incorporated some of Jozef's comments. > > > > > > Cheers > > > > > > Magnus > > > > > > ---- > > > > > > Congestion and Pre-Congestion Notification (PCN) > > > > > > Chair(s): > > > tbd > > > > > > Transport Area Director(s): > > > Magnus Westerlund > > > Lars Eggert > > > > > > Transport Area Advisor: > > > Lars Eggert > > > > > > Mailing Lists: > > > General Discussion: pcn@ietf.org > > > To Subscribe: pcn-request@ietf.org > > > In Body: (un)subscribe > > > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > > > > > > > > Description of Working Group: > > > > > > The Congestion and Pre-Congestion Notification (PCN)=20 > working group=20 > > > develops mechanisms to protect the quality-of-service of=20 > established=20 > > > flows within a DiffServ domain when congestion is imminent or=20 > > > existing. > > > These mechanisms operate at the domain boundary, based on=20 > aggregated=20 > > > congestion and pre-congestion information from within the domain.=20 > > > The focus of the WG is on developing standards for the marking=20 > > > behavior of the interior nodes and the encoding transport of the=20 > > > congestion information. The transport and encoding of the=20 > congestion=20 > > > information is decompositioned into several components.=20 > The forward=20 > > > flow path to the domain boundary, the metering of the congestion=20 > > > situation at the boundary, and the transport of the data to the=20 > > > controlling peer. This decomposition is done to allow for future=20 > > > extensibility by defining additional variants of the components=20 > > > (with the exception of the first one). Reaction mechanisms at the=20 > > > boundary consist of flow admission and flow termination. Although=20 > > > designed to work together, flow admission and flow=20 > termination are=20 > > > independent mechanisms, and the use of one does not require or=20 > > > prevent the use of the other. In consultation with the AD, the WG=20 > > > may produce a small number of informational documents=20 > that describe=20 > > > how specific quality-of-service policies for a domain can be=20 > > > implemented using these two mechanisms. > > > > > > The PCN WG will specify the following components to protect the=20 > > > quality-of-service of flows within a DiffServ domain: > > > > > > (1) a general architecture for flow admission and termination=20 > > > based > > > on aggregated (pre-)congestion information > > > > > > (2) a specification of conditions under which interior nodes=20 > > > generate > > > (pre-)congestion information > > > > > > (3) encoding and transport of (pre-)congestion information > > > between the interior and the egress node of the domain > > > > > > (4) Metering of the (pre-)congestion information at the egress > > > node of the domain. > > > > > > (5) encoding and transport of (pre-)congestion information > > > between the egress node and the ingress node of the domain > > > (when necessary). > > > > > > (6) ingress node control mechanisms for flow admission or=20 > > > termination, > > > based on aggregated (pre-)congestion information > > > > > > The WG focuses on the overall architecture, and=20 > specifically on the=20 > > > marking behavior and encoding and transport mechanisms needed to=20 > > > realize it. Standards-track protocols and mechanisms are only=20 > > > developed where necessary for interoperability. For other=20 > components=20 > > > of the architecture, the WG may document examples or provide=20 > > > recommended solutions in informational documents. The=20 > architecture=20 > > > document will be comprehensive, and include security,=20 > manageability=20 > > > and operational considerations. If this WG requires extensions or=20 > > > modifications to protocols that are products of other WGs, it may=20 > > > motivate their need and describe requirements in informational=20 > > > documents; design of such extensions and modifications will take=20 > > > place in the appropriate WGs. > > > > > > > > > The initial scope of the PCN WG is restricted by the following > > > assumptions: > > > > > > (A) these components are deployed in a single DiffServ domain, > > > where all boundary and interior nodes are PCN-enabled > > > and mutually trust each other > > > > > > (B) all flows handled by these mechanisms are inelastic and > > > constrained to a known maximum rate through policing or=20 > > > shaping > > > > > > (C) the number of flows across any potential aggregation=20 > > > bottleneck > > > is sufficiently large for stateless, statistical=20 > mechanisms=20 > > > to be > > > effective > > > > > > (D) flows may have different precedence, but the applicability > > > of the PCN mechanisms for emergency use (911, GETS, WPS, > MLPP, > > > etc.) > > > is out of scope > > > > > > After completion of the initial phase, the PCN WG may=20 > re-charter to=20 > > > develop solutions for scenarios where some of these=20 > restrictions are=20 > > > not in place. It may also re-charter to consider applying the PCN=20 > > > mechanisms to additional deployment scenarios (operation over=20 > > > concatenated DiffServ domains, PCN-aware application mechanisms,=20 > > > etc.). The WG may also consider to investigate additional=20 > response=20 > > > mechanisms that act on (pre-)congestion information. One example=20 > > > could be flow-rate adaptation (rather than flow > > > admission/termination) during times of congestion. The details of=20 > > > these work items are outside the scope of the initial=20 > phase; but the=20 > > > WG may consider their requirements to design components that are=20 > > > sufficiently general to support such extensions in the future. > > > > > > > > > Goals and Milestones: > > > > > > Nov 2007 Flow Admission and Termination Architecture > > > (Informational) > > > > > > Nov 2007 Survey of Encoding and Transport Choices of > > > (Pre-)Congestion Information within a DiffServ Domain > > > (Informational) > > > > > > Mar 2007 Flow Admission and Termination within a DiffServ > > > Domain (Informational) > > > > > > Mar 2007 (Pre-)Congestion Detection within a DiffServ Domain > > > (Proposed Standard) > > > > > > Mar 2008 Requirements for Signalling of (Pre-)Congestion > information > > > from Egress to Ingress Nodes in a DiffServ Domain > > > (Informational) > > > > > > Jul 2008 Encoding and Transport of (Pre-)Congestion Information > > > from within a DiffServ Domain to the Egress > > > (Proposed Standard) > > > > > > Nov 2008 Encoding and Transport of (Pre-)Congestion Information > > > from the Domain Egress to the Ingress > > > (Proposed Standard) > > > > > > Jul 2008 Suggested Flow Admission and Termination Boundary > > > Mechanisms > > > (Informational) > > > > > > -- > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > > ---------------------------------------------------------------------- > > > 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:=20 > 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 > > > > >=20 > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 07 16:45:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEubu-0001vE-0O; Wed, 07 Feb 2007 16:45:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuDy-0002rk-Ea for pcn@ietf.org; Wed, 07 Feb 2007 16:21:06 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEtyG-0006bC-FO for pcn@ietf.org; Wed, 07 Feb 2007 16:05:45 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE758205E4; Wed, 7 Feb 2007 22:04:50 +0100 (CET) X-AuditID: c1b4fb3c-b1fccbb0000007de-5f-45ca3ef25bbd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C85BB203C8; Wed, 7 Feb 2007 22:04:50 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 22:04:17 +0100 Received: from [138.85.13.128] ([138.85.13.128]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 22:04:16 +0100 Message-ID: <45CA3ECD.4000100@ericsson.com> Date: Wed, 07 Feb 2007 22:04:13 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] PCN Charter proposal version 4 References: <9671A92C3C8B5744BC97F855F7CB64650E842F31@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E842F31@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2007 21:04:17.0186 (UTC) FILETIME=[8760C020:01C74AFB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Jozef Babiarz skrev: > I believe that the encoding of PCN information in the IP header that > interior nodes will perform needs to be standardized. > > The signaling or transport of PCN information from egress to ingress > nodes should be written as requirements (informational) so that > signaling protocols such as RSVP, NSIS and possibly others can be > extended to convey PCN information between boarder nodes. PCN WG will > not work on any extensions to signaling protocols. > Yes, this is a good summary. However, there will still be need for a standard tracks document that says which pieces that goes together in which way. Thus Informational or BCP does not seem appropriate. Thus, me and Lars intends to keep this milestone for the moment to be a standard track document. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Wed Feb 07 17:57:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEvjU-0007gC-Pl; Wed, 07 Feb 2007 17:57:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEvjT-0007bq-6s for pcn@ietf.org; Wed, 07 Feb 2007 17:57:43 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEvjR-0006yk-V3 for pcn@ietf.org; Wed, 07 Feb 2007 17:57:43 -0500 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 l17MvL428784; Wed, 7 Feb 2007 17:57:21 -0500 (EST) 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 Charter proposal version 4 Date: Wed, 7 Feb 2007 17:57:20 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E8A2B4C@zcarhxm1.corp.nortel.com> In-Reply-To: <45CA3ECD.4000100@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Charter proposal version 4 Thread-Index: AcdK+52zjUR2SNlOQYqD3JRy1PF5mAABeImA From: "Jozef Babiarz" To: "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Magnus Westerlund skrev: >Yes, this is a good summary. However, there will still be need for a=20 >standard tracks document that says which pieces that goes together in=20 >which way. Thus Informational or BCP does not seem appropriate. Thus, me=20 >and Lars intends to keep this milestone for the moment to be a standard >track document. My thinking was that we only standardized the minimum staff that is needed in the interor nodes and boundary edge nodes for interoperability. In my view the PCN WG would not standardize how PCN will be used in different deployment models. How the pieces go together and how they would be used in different deployment models would be done as Informational RFCs. I was thinking of following the DiffServ WG approach of only standardizing mechnisims or protocols and leave it to informational documents for different ways they can be used. =20 Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: February 7, 2007 4:04 PM To: Babiarz, Jozef (CAR:0S03) Cc: philip.eardley@bt.com; karagian@cs.utwente.nl; brodrig@avaya.com; pcn@ietf.org Subject: Re: [PCN] PCN Charter proposal version 4 Jozef Babiarz skrev: > I believe that the encoding of PCN information in the IP header that > interior nodes will perform needs to be standardized.=20 >=20 > The signaling or transport of PCN information from egress to ingress > nodes should be written as requirements (informational) so that > signaling protocols such as RSVP, NSIS and possibly others can be > extended to convey PCN information between boarder nodes. PCN WG will > not work on any extensions to signaling protocols. >=20 Yes, this is a good summary. However, there will still be need for a=20 standard tracks document that says which pieces that goes together in=20 which way. Thus Informational or BCP does not seem appropriate. Thus, me and Lars intends to keep this milestone for the moment to be a standard=20 track document. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Thu Feb 08 11:07:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBo9-00015I-Et; Thu, 08 Feb 2007 11:07:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBo8-00011s-5D for pcn@ietf.org; Thu, 08 Feb 2007 11:07:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFBo5-0006mM-8F for pcn@ietf.org; Thu, 08 Feb 2007 11:07:36 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2007 11:07:33 -0500 X-IronPort-AV: i="4.13,302,1167627600"; d="scan'208"; a="113408811:sNHT82426198" 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/8.12.11) with ESMTP id l18G7Wa4005805; Thu, 8 Feb 2007 11:07:32 -0500 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 l18G7WOA029445; Thu, 8 Feb 2007 11:07:32 -0500 (EST) 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, 8 Feb 2007 11:07:32 -0500 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: [PCN] "Network Admission Control" (NAC) Date: Thu, 8 Feb 2007 11:07:30 -0500 Message-ID: In-Reply-To: <009901c749c9$4c88b3f0$9c28460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdJyXnmU+3K4rG0RROL42854Ty6AgB0YAww From: "Anna Charny \(acharny\)" To: "Tina TSOU" , , "Geib, Ruediger" X-OriginalArrivalTime: 08 Feb 2007 16:07:32.0331 (UTC) FILETIME=[3D453BB0:01C74B9B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=22328; t=1170950853; x=1171814853; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20=22Network=20Admission=20Control=22=20(NAC) |Sender:=20 |To:=20=22Tina=20TSOU=22=20, =20, =0A=2 0=20=20=20=20=20=20=20=22Geib, =20Ruediger=22=20; bh=AbUiKDkVHyi5HUedXR8HwhkHXo7Y5pvwR5pNn+xSfA4=; b=Voikpi7ChQZ7P2V5Z+HSqxB4hpfVawc8IMThbY3ANQCJNA2UoxqHSCXwJJ5JH5jqYW7sGoxR y4knBsNUiT4N2e7c5OWZcY3+gbFPYptF7eMldjdPT6oN4ebz5nK9zV3t; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e 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, Just a thought that there will be a number of terminology issues to = address once the WG is formed. I wonder if this discussion can become = part of the work on the terminology that would eventually find its way = into (I think) the architecture draft? Anna=20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com]=20 > Sent: Tuesday, February 06, 2007 3:32 AM > To: brodrig@avaya.com; Geib, Ruediger > Cc: pcn@ietf.org > Subject: Re: [PCN] "Network Admission Control" (NAC) >=20 > Hi Ruediger, > Do we also consider Network Access Control in PCN? >=20 > B. R. > Tina > ----- Original Message ----- > From: "Geib, Ruediger" > To: > Cc: > Sent: Tuesday, February 06, 2007 4:18 PM > Subject: RE: [PCN] "Network Admission Control" (NAC) >=20 >=20 > Benny, >=20 > I prefer Michaels proposal, NAC or DAC is allright with me if we > provide a definition for our terminology. The same would hold > if "flow admission" is used, which I feel to be to close to > "per flow". >=20 > A side note on the abbreviation NAC: it is also described as > Network Access Control by Wikipedia. I've checked that because > within my company what is described by Wiki as Network > "Admission Control" is called Network Access Control. >=20 > Regards, >=20 > Ruediger >=20 > |-----Original Message----- > |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > |Sent: Monday, February 05, 2007 8:37 PM > |To: Rodrig, Benny (Benny) > |Cc: Geib, R=FCdiger; pcn@ietf.org > |Subject: Re: [PCN] "Network Admission Control" (NAC) > | > | > |Hi, > | > |the word NAC itself means that access is possibly denied to a network > |which can be due to security or resource reasons. NAC in the security > |context has become a quite popular expression as it is the name of a > |Cisco product. The name NAC sounds good (to me) as it is=20 > very catchy and > |easy to understand also for non-experts. I don't see a large problem > |when the term NAC exists in different contexts. If people need to > |distinguish both approaches, security-related NAC and=20 > resource-related > |NAC can be used. However, people working in both areas might see this > |differently. > | > |As the new version of the PCN charter talks about domains, domain > |admission control (DAC) would be a natural substitute for=20 > NAC. DAC has > |no misleading connotations, but it doesn't sound nice (to me). Better > |sounds maybe per-domain AC (PDAC) and concisely states what it is. In > |analogy to routing, intradomain admission control is another=20 > option, but > |it also implies the existence of interdomain admission=20 > control. I'm not > |sure whether we want this right now. > | > |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN > |charter, we can leave this issue open until we have a=20 > clearer opinion. > | > | Michael > | > |Rodrig, Benny (Benny) wrote: > |> Ruediger, > |> > |> To me the charter doesn't seem to imply the expansion of scope that > |> you're concerned about. Unlike many other terms "flow=20 > admission" doesn't > |> seem to have misleading connotations. But I could be ok=20 > with "network > |> flow admission". > |> > |> If it is important that the charter be more explicit about=20 > this point, > |> then perhaps a sentence should be added with some explicit=20 > description > |> e.g. that the flow admission behavior at the boundary=20 > includes policing > |> and/or interaction with per-flow mechanisms that are out=20 > of scope of > |> PCN. > |> > |> Benny > |> > |> > |> -----Original Message----- > |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |> Sent: Monday, February 05, 2007 3:01 AM > |> To: Rodrig, Benny (Benny) > |> Cc: pcn@ietf.org > |> Subject: RE: [PCN] "Network Admission Control" (NAC) > |> > |> I'm not sure whether "flow admission" is the correct description. > |> Wouldn' or couldn't that mean that PCN includes work on=20 > the per flow > |> admission control functionality. PCN then is chartered to work on > |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with > |Network- or > |> Aggregate- or Per Domain Behaviour- Admission Control, then the > |> chartered PCN work could be limited to provide an=20 > interface (API?) to > |> the per flow signaling protocol. Isn't the latter=20 > sufficient for the > |> initial charter? > |> > |> Regards, > |> > |> Ruediger > |> > |> |-----Original Message----- > |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > |> |Sent: Friday, February 02, 2007 5:09 PM > |> |To: Moore, Sean (Sean); Tina TSOU; > |menth@informatik.uni-wuerzburg.de; > |> |Geib, Rudiger > |> |Cc: pcn@ietf.org > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > |> | > |> | > |> |I think the 'flow admission' wording in the charter is fine and we > |> |don't need to choose a more precise term. The charter text > |explaining > |> |that this flow admission happens at the domain boundary in > |reaction to > |> |pre-congestion info from within the domain, etc. seems to > |describe it > |> |sufficiently. > |> | > |> |Benny > |> | > |> |-----Original Message----- > |> |From: Moore, Sean (Sean) > |> |Sent: Friday, February 02, 2007 9:59 AM > |> |To: Tina TSOU; Rodrig, Benny (Benny); > |menth@informatik.uni-wuerzburg.de > |> |Cc: pcn@ietf.org; Geib, Ruediger > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > |> | > |> |Probably shouldn't use "Resource Admission Control" as this > |term (RAC) > |> |is used in IMS and it is not the same as what we are discussing > |> |- Sean > |> | > |> |-----Original Message----- > |> |From: Tina TSOU [mailto:tena@huawei.com] > |> |Sent: Friday, February 02, 2007 9:25 AM > |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de > |> |Cc: pcn@ietf.org; Geib, Ruediger > |> |Subject: Re: [PCN] "Network Admission Control" (NAC) > |> | > |> |Hi, > |> |How about Resource Admission Control or Network Resource Admission > |> |Control? > |> |I don't have strong opinion on that, just some terms=20 > popped up in my > |> |mind:) > |> | > |> |B. R. > |> |Tina > |> | > |> |----- Original Message ----- > |> |From: "Michael Menth" > |> |To: "Rodrig, Benny (Benny)" > |> |Cc: ; "Geib, Ruediger" > |> |Sent: Friday, February 02, 2007 12:16 PM > |> |Subject: [PCN] "Network Admission Control" (NAC) > |> | > |> | > |> |> Hi, > |> |> > |> |> I've got a comment on the term "Network Admission=20 > Control" (NAC). > |> |> > |> |> Wikipedia > |> |http://en.wikipedia.org/wiki/Network_Admission_Control only > |> |> knows NAC in the context of restricting access to the > |> |network based on > |> | > |> |> identity or security posture (it's essentially a Cisco product). > |> |> However, most important is the aspect that access is denied > |> |to a whole > |> | > |> |> network, subnetwork, domain, region, etc. NAC is in > |contrast to AC > |> |> algorithms deciding whether a new flow can be admitted to be > |> |> transported over a single link which has been studied in > |> |depth in the > |> |> 1990s in the context of ATM systems. Three years ago, I have > |> |reviewed > |> |> and studied different approaches for NAC (based on resource > |> |management > |> |issues) in my PhD thesis: > |> |> > |> > ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p df/Menth04 > |> |> .pdf The terms connection or flow admission control are less > |> |specific > |> |> than NAC as they do not tell the scope of the AC. > |> |> > |> |> Best regards, > |> |> > |> |> Michael > |> |> > |> |> Rodrig, Benny (Benny) wrote: > |> |>> What I think you mean, and the admission control that PCN > |> |deals with, > |> | > |> |>> better not be described as "network admission control" > |since that > |> |>> term often (e.g. see > |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) > |> |>> refers to admission based on the identity of the sender, > |which is > |> |>> probably out of scope for PCN. The flow admission=20 > control in PCN > |> |>> scope is based on considerations related to network status i.e. > |> |>> pre-congestion. > |> |>> The PCN flow admission control can be part of a call admission > |> |>> control solution, if it interacts with other mechanisms > |such as for > |> |>> example with Int-Serv outside the PCN domain and/or=20 > with SIP QoS > |> |>> pre-conditions. Such interactions, or assumptions about > |> |them, may not > |> |be in the scope of PCN. > |> |>> > |> |>> > |> |>> Benny > |> |>> -----Original Message----- > |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: > |> |>> Thursday, February 01, 2007 4:44 AM > |> |>> To: Romascanu, Dan (Dan) > |> |>> Cc: pcn@ietf.org > |> |>> Subject: RE: [PCN] charter, addition to scope > |> |>> > |> |>> Hi Dan, > |> |>> > |> |>> your proposal seems sound to me. My impression is the > |> |discussion may > |> |>> have approached consensus on the following issues to get > |chartered > |> |>> initially: > |> |>> > |> |>> - PCN is limited to a single DiffServ domain. > |> |>> - PCN aware nodes must be "on path". > |> |>> - PCN only standardises PCN related IP layer > |> |>> functionalities including RSVP or NSIS signaling > |> |>> between edge nodes. > |> |>> - PCN only works on "network admission control". > |> |>> > |> |>> If "Edge node" requires further definition to exclude > |> |things to close > |> | > |> |>> to an "end system", we should add it at appropriate places. > |> |>> "PCN related" would exclude dealing with middleboxes > |doing anything > |> |>> else with packets than PCN DiffServ forwarding. > |> |>> > |> |>> Another question is, what the reaction of an ingress edge > |> |node should > |> | > |> |>> be in case of an indicated network congestion. My > |> |impression is, that > |> | > |> |>> with the initial charter we should just define a desired > |> |behaviour in > |> | > |> |>> terms of an aggregate traffic reduction (e.g. "stop > |admission new > |> |>> flows demanding CL forwarding or bandwidth increases=20 > of admitted > |> |>> ones" or "reduce CL traffic by x percent"). > |> |>> Future work items may be added when the WG is=20 > re-chartered after > |> |>> having reached first aims. It may indeed be useful to > |think about > |> |>> some requirements for future PCN use already now. As I > |didn't think > |> |>> about particular topics in detail, I don't try to > |summarise which > |> |>> requirements that could be by this mail. > |> |>> > |> |>> Regards, > |> |>> > |> |>> Ruediger > |> |>> > |> |>> > |> |>> |-----Original Message----- > |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > |> |>> |Sent: Thursday, February 01, 2007 9:45 AM > |> |>> |To: Lee, Richard FTC; Black_David@emc.com; > |karagian@cs.utwente.nl > |> |>> |Cc: pcn@ietf.org > |> |>> |Subject: RE: [PCN] charter, addition to scope > |> |>> | > |> |>> | > |> |>> |Maybe we should stop for a moment and consider what layer > |> |should PCN > |> | > |> |>> |deal with. It looks to me that we are mixing network admission > |> |>> |control and call admission control in this discussion. > |> |This problem > |> |>> |is quite complex, and there are many scenarios that need > |> |to be taken > |> | > |> |>> |into consideration. Sometimes flow =3D call, sometimes call > |> |=3DNOT flow > |> |>> |and sometimes there is a mix on the same path. In some > |cases media > |> |>> |gateways > |> |>> > |> |>> |are collocated with the edge nodes in some other cases > |not. Even > |> |>> |when flow =3D call there are two admission control layers > |> |(network and > |> | > |> |>> |call) that are in dependency but not identical and separate > |> |>> |protocols run at transport and session. I am not sure > |how much of > |> |>> |all this falls under what PCN should do. > |> |>> | > |> |>> |Dan > |> |>> | > |> |>> | > |> |>> | > |> |>> | > |> |>> | | | > |> |>> |> -----Original Message----- > |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM > |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl > |> |>> |> Cc: pcn@ietf.org > |> |>> |> Subject: RE: [PCN] charter, addition to scope > |> |>> |> |> To all, > |> |>> |> I agree that there must be a prioritization of flows > |from the |> > |> |>> aggregation devices However, it's not just the media > |> |gateway that |> > |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") > |> |as well - > |> |>> > |> |>> |> it is the signaling proxy at the edge that reserves=20 > the media > |> |>> |> path. |> > |> |>> The reservation protocol request to the network from=20 > the VoIP |> > |> |>> proxy/gateway must reserve resources to the destination > |in the |> > |> |>> network. > |> |>> |> The resource reservation request to the network by=20 > the edge |> > |> |>> proxy/media gateway, must at the very minimum, meet the > |following |> > |> |>> conditions: > |> |>> |> 1. it needs to specify the resources required for the > |IP & ports > |> |>> |> |> > |> |>> (RTP/RTCP & bandwidth) > |> |>> |> for example, G.711 and G.729 voice and various > |MPEG-4 video > |> |>> |> codecs > |> |>> > |> |>> |> all have very different requirements 2. it must be > |mapped to the > |> |>> |> |> > |> |>> signaling request > |> |>> |> for SIP, it must map the SDP for media with the > |reservation > |> |>> |> flow - > |> |>> > |> |>> |> for example something along the lines of RFC 3524 > |> |>> |> while not the answer, the mapping of the media > |flows is a |> > |> |>> necessary component > |> |>> |> It should be noted that the edge proxies/media > |gateways may > |> |>> |> have a > |> |>> > |> |>> |> large number of flows (and ports for each > |> |>> |> RTP/RTCP flow) from the same source IP. The request > |> |is made for > |> | > |> |>> |> |> > |> |>> each flow or conversation 3. it must be honored by the > |edge network > |> |>> |> device. > |> |>> |> The trust boundary must be extended to the edge > |proxy/media |> > |> |>> gateway for each new flow. > |> |>> |> This brings up the issue of security authentication > |> |of the edge > |> | > |> |>> |> |> > |> |>> proxy/media gateway to the network > |> |>> |> Does this happen in EAP, NAC, or just=20 > interoperability and |> > |> |>> certification among vendors > |> |>> |> If the resources are not available, then the signaling > |> |>> |> indicates |> > |> |>> the session is not completed. For example a SIP > |> |>> |> CANCEL from the edge proxy > |> |>> |> |> In addition, the network device must have=20 > priority queuing > |> |>> |> |> enabled > |> |>> |> for input queues from the edge device. > |> |>> |> The media flows must not be subject to input buffers > |> |being filled > |> |>> |> |> > |> |>> prior to classification > |> |>> |> |> Thanks, > |> |>> |> Richard Lee > |> |>> |> Fidelity Investments > |> |>> |> Enterprise Technology and Architecture > |> |>> |> 617-563-3278 > |> |>> |> |> |> -----Original Message----- > |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] > |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM > |> |>> |> To: karagian@cs.utwente.nl > |> |>> |> Cc: pcn@ietf.org > |> |>> |> Subject: RE: [PCN] charter, addition to scope > |> |>> |> |> |> Georgios wrote: > |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > |> |>> |> > > > In the first phase of PCN work to reduce the list of > |> |>> |> issues it was > |> |>> |> |> > > > proposed that the WG focus on network > |> |deployment scenario > |> |>> where > |> |>> |> all > |> |>> |> > > > nodes can be trusted and delay work on deployment > |> |>> |> scenarios where > |> |>> |> some > |> |>> |> > > > of the nodes are not trusted. > |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, > |then yes, I > |> |>> agree. If > |> |>> |> "nodes" |> > > include end systems, proxies or other > |entities, > |> |>> |> then I > |> |>> don't |> > > agree we had agreement on that. > |> |>> |> > |> > Georgios: This imposes an additional > |restriction on the > |> |>> |> > |> > scope > |> |>> of |> > the charter, which has been not discussed yet. > |> |>> |> > >From what I remember before, during and after the PCN BOF > |> |>> |> > there was no objection on using the term edge node, > |that could > |> |>> |> > mean something different than a edge > |> |>> |> router. > |> |>> |> > Please note that this is something different than a > |> |>> |scenario covered > |> |>> |> by > |> |>> |> > an application based deployment model. > |> |>> |> |> It's certainly not a new restriction based on the > |> |discussion in > |> | > |> |>> |> |> the > |> |>> |> BOF engendered about whether a SIP telephone (used on > |some of the > |> |>> |> slides) was a good example. I believe the BOF > |> |conclusion was that > |> | > |> |>> |> a SIP telephone was a bad example. > |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the > |> |>> |proposed work: > |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) > |The first set > |> |>> |> of issues has already been discussed extensively - my > |> |>> |> understanding is that the SIP scenario is currently out > |> |of scope, > |> |>> |> and > |> |>> > |> |>> |> I don't care to reopen that discussion. > |> |>> |> |> The "telephone" issues come up in two ways: > |> |>> |> (2a) Small number of flows may make relatively fine-grained > |> |>> |adjustment > |> |>> |> on the link to the phone impossible. The PCN work > |prior to the > |> |>> |> BOF relied on the ability to make such adjustments. > |> |>> |> (2b) While other sorts of phones may be trusted, a SIP phone > |> |>> |> (which may be software-only) is definitely not trustable in > |> |general. > |> |>> |> |> I would observe that Lars Westerberg's suggestion > |of a Media > |> |>> Gateway: > |> |>> |> |> > I am referring telecom scenario where MGWs are > |connected to > |> |>> |> |> > an > |> |>> |> IP-backbone. > |> |>> |> > In these scenarios, the admission control function is > |> |a part of > |> |>> |> > the > |> |>> |> MGW > |> |>> |> > and not the routers. The IP-backbone is provisioned by > |> |a network > |> | > |> |>> |> > |> > |> |>> > management system. > |> |>> |> |> could avoid all of these issues: > |> |>> |> (1) The media gateway could speak RSVP to the network > |management > |> |>> |> |> > |> |>> system, > |> |>> |> avoiding any need to deal with SIP here. > |> |>> |> (2a) A media gateway is likely to handle enough flows to be > |> |>> |consistent > |> |>> |> with the fine-grained adjustment assumed by the work done to > |> |>> date. > |> |>> |> (2b) One can plausibly assume/require that media gateways be > |> |>> |> trusted with respect to the IP network. > |> |>> |> To the extent that one can vest "edge" functionality in > |> |a trusted > |> |>> |> |> > |> |>> media gateway, I see no reason to exclude that scenario. > |> |>> |> |> Thanks, > |> |>> |> --David > |> |>> |> ---------------------------------------------------- > |> |>> |> David L. Black, Senior Technologist EMC Corporation, > |176 South > |> |>> |> St., Hopkinton, MA 01748 > |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 > |> |>> |> ---------------------------------------------------- > |> |>> |> |> _______________________________________________ > |> |>> |> 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 > |> | > |> | > |> | > |> > |> > |> _______________________________________________ > |> 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 > | > | >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 08 20:33:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKds-0005sT-Pa; Thu, 08 Feb 2007 20:33:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKdr-0005lI-Er for pcn@ietf.org; Thu, 08 Feb 2007 20:33:35 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFKdo-0001U2-5n for pcn@ietf.org; Thu, 08 Feb 2007 20:33:35 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD6007XM9L80V@szxga04-in.huawei.com> for pcn@ietf.org; Fri, 09 Feb 2007 09:31:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD6005GF9L50G@szxga04-in.huawei.com> for pcn@ietf.org; Fri, 09 Feb 2007 09:31:56 +0800 (CST) Received: from z24109a ([10.70.40.156]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD6008039L52D@szxml03-in.huawei.com> for pcn@ietf.org; Fri, 09 Feb 2007 09:31:53 +0800 (CST) Date: Fri, 09 Feb 2007 09:31:54 +0800 From: Tina TSOU Subject: Re: [PCN] "Network Admission Control" (NAC) To: "Geib, Ruediger" , brodrig@avaya.com, "Anna Charny (acharny)" Message-id: <002801c74bea$14f1cd50$9c28460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c2c13da073bbdd073b64ce7ea2347217 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, I agree with you. Probably we need the terminology in the session of = the=20 architecture draft, or a small informal draft. B. R. Tina ----- Original Message -----=20 =46rom: "Anna Charny (acharny)" To: "Tina TSOU" ; ; "Geib, Ruedig= er"=20 Cc: Sent: Friday, February 09, 2007 12:07 AM Subject: RE: [PCN] "Network Admission Control" (NAC) Hi, Just a thought that there will be a number of terminology issues to a= ddress=20 once the WG is formed. I wonder if this discussion can become part of= the=20 work on the terminology that would eventually find its way into (I th= ink)=20 the architecture draft? Anna > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Tuesday, February 06, 2007 3:32 AM > To: brodrig@avaya.com; Geib, Ruediger > Cc: pcn@ietf.org > Subject: Re: [PCN] "Network Admission Control" (NAC) > > Hi Ruediger, > Do we also consider Network Access Control in PCN? > > B. R. > Tina > ----- Original Message ----- > From: "Geib, Ruediger" > To: > Cc: > Sent: Tuesday, February 06, 2007 4:18 PM > Subject: RE: [PCN] "Network Admission Control" (NAC) > > > Benny, > > I prefer Michaels proposal, NAC or DAC is allright with me if we > provide a definition for our terminology. The same would hold > if "flow admission" is used, which I feel to be to close to > "per flow". > > A side note on the abbreviation NAC: it is also described as > Network Access Control by Wikipedia. I've checked that because > within my company what is described by Wiki as Network > "Admission Control" is called Network Access Control. > > Regards, > > Ruediger > > |-----Original Message----- > |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > |Sent: Monday, February 05, 2007 8:37 PM > |To: Rodrig, Benny (Benny) > |Cc: Geib, R=FCdiger; pcn@ietf.org > |Subject: Re: [PCN] "Network Admission Control" (NAC) > | > | > |Hi, > | > |the word NAC itself means that access is possibly denied to a netw= ork > |which can be due to security or resource reasons. NAC in the secur= ity > |context has become a quite popular expression as it is the name of= a > |Cisco product. The name NAC sounds good (to me) as it is > very catchy and > |easy to understand also for non-experts. I don't see a large probl= em > |when the term NAC exists in different contexts. If people need to > |distinguish both approaches, security-related NAC and > resource-related > |NAC can be used. However, people working in both areas might see t= his > |differently. > | > |As the new version of the PCN charter talks about domains, domain > |admission control (DAC) would be a natural substitute for > NAC. DAC has > |no misleading connotations, but it doesn't sound nice (to me). Bet= ter > |sounds maybe per-domain AC (PDAC) and concisely states what it is.= In > |analogy to routing, intradomain admission control is another > option, but > |it also implies the existence of interdomain admission > control. I'm not > |sure whether we want this right now. > | > |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN > |charter, we can leave this issue open until we have a > clearer opinion. > | > | Michael > | > |Rodrig, Benny (Benny) wrote: > |> Ruediger, > |> > |> To me the charter doesn't seem to imply the expansion of scope t= hat > |> you're concerned about. Unlike many other terms "flow > admission" doesn't > |> seem to have misleading connotations. But I could be ok > with "network > |> flow admission". > |> > |> If it is important that the charter be more explicit about > this point, > |> then perhaps a sentence should be added with some explicit > description > |> e.g. that the flow admission behavior at the boundary > includes policing > |> and/or interaction with per-flow mechanisms that are out > of scope of > |> PCN. > |> > |> Benny > |> > |> > |> -----Original Message----- > |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |> Sent: Monday, February 05, 2007 3:01 AM > |> To: Rodrig, Benny (Benny) > |> Cc: pcn@ietf.org > |> Subject: RE: [PCN] "Network Admission Control" (NAC) > |> > |> I'm not sure whether "flow admission" is the correct description= . > |> Wouldn' or couldn't that mean that PCN includes work on > the per flow > |> admission control functionality. PCN then is chartered to work o= n > |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with > |Network- or > |> Aggregate- or Per Domain Behaviour- Admission Control, then the > |> chartered PCN work could be limited to provide an > interface (API?) to > |> the per flow signaling protocol. Isn't the latter > sufficient for the > |> initial charter? > |> > |> Regards, > |> > |> Ruediger > |> > |> |-----Original Message----- > |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > |> |Sent: Friday, February 02, 2007 5:09 PM > |> |To: Moore, Sean (Sean); Tina TSOU; > |menth@informatik.uni-wuerzburg.de; > |> |Geib, Rudiger > |> |Cc: pcn@ietf.org > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > |> | > |> | > |> |I think the 'flow admission' wording in the charter is fine and= we > |> |don't need to choose a more precise term. The charter text > |explaining > |> |that this flow admission happens at the domain boundary in > |reaction to > |> |pre-congestion info from within the domain, etc. seems to > |describe it > |> |sufficiently. > |> | > |> |Benny > |> | > |> |-----Original Message----- > |> |From: Moore, Sean (Sean) > |> |Sent: Friday, February 02, 2007 9:59 AM > |> |To: Tina TSOU; Rodrig, Benny (Benny); > |menth@informatik.uni-wuerzburg.de > |> |Cc: pcn@ietf.org; Geib, Ruediger > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > |> | > |> |Probably shouldn't use "Resource Admission Control" as this > |term (RAC) > |> |is used in IMS and it is not the same as what we are discussing > |> |- Sean > |> | > |> |-----Original Message----- > |> |From: Tina TSOU [mailto:tena@huawei.com] > |> |Sent: Friday, February 02, 2007 9:25 AM > |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de > |> |Cc: pcn@ietf.org; Geib, Ruediger > |> |Subject: Re: [PCN] "Network Admission Control" (NAC) > |> | > |> |Hi, > |> |How about Resource Admission Control or Network Resource Admiss= ion > |> |Control? > |> |I don't have strong opinion on that, just some terms > popped up in my > |> |mind:) > |> | > |> |B. R. > |> |Tina > |> | > |> |----- Original Message ----- > |> |From: "Michael Menth" > |> |To: "Rodrig, Benny (Benny)" > |> |Cc: ; "Geib, Ruediger" > |> |Sent: Friday, February 02, 2007 12:16 PM > |> |Subject: [PCN] "Network Admission Control" (NAC) > |> | > |> | > |> |> Hi, > |> |> > |> |> I've got a comment on the term "Network Admission > Control" (NAC). > |> |> > |> |> Wikipedia > |> |http://en.wikipedia.org/wiki/Network_Admission_Control only > |> |> knows NAC in the context of restricting access to the > |> |network based on > |> | > |> |> identity or security posture (it's essentially a Cisco produc= t). > |> |> However, most important is the aspect that access is denied > |> |to a whole > |> | > |> |> network, subnetwork, domain, region, etc. NAC is in > |contrast to AC > |> |> algorithms deciding whether a new flow can be admitted to be > |> |> transported over a single link which has been studied in > |> |depth in the > |> |> 1990s in the context of ATM systems. Three years ago, I have > |> |reviewed > |> |> and studied different approaches for NAC (based on resource > |> |management > |> |issues) in my PhD thesis: > |> |> > |> > ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p df/Menth04 > |> |> .pdf The terms connection or flow admission control are less > |> |specific > |> |> than NAC as they do not tell the scope of the AC. > |> |> > |> |> Best regards, > |> |> > |> |> Michael > |> |> > |> |> Rodrig, Benny (Benny) wrote: > |> |>> What I think you mean, and the admission control that PCN > |> |deals with, > |> | > |> |>> better not be described as "network admission control" > |since that > |> |>> term often (e.g. see > |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) > |> |>> refers to admission based on the identity of the sender, > |which is > |> |>> probably out of scope for PCN. The flow admission > control in PCN > |> |>> scope is based on considerations related to network status i= .e. > |> |>> pre-congestion. > |> |>> The PCN flow admission control can be part of a call admissi= on > |> |>> control solution, if it interacts with other mechanisms > |such as for > |> |>> example with Int-Serv outside the PCN domain and/or > with SIP QoS > |> |>> pre-conditions. Such interactions, or assumptions about > |> |them, may not > |> |be in the scope of PCN. > |> |>> > |> |>> > |> |>> Benny > |> |>> -----Original Message----- > |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Se= nt: > |> |>> Thursday, February 01, 2007 4:44 AM > |> |>> To: Romascanu, Dan (Dan) > |> |>> Cc: pcn@ietf.org > |> |>> Subject: RE: [PCN] charter, addition to scope > |> |>> > |> |>> Hi Dan, > |> |>> > |> |>> your proposal seems sound to me. My impression is the > |> |discussion may > |> |>> have approached consensus on the following issues to get > |chartered > |> |>> initially: > |> |>> > |> |>> - PCN is limited to a single DiffServ domain. > |> |>> - PCN aware nodes must be "on path". > |> |>> - PCN only standardises PCN related IP layer > |> |>> functionalities including RSVP or NSIS signaling > |> |>> between edge nodes. > |> |>> - PCN only works on "network admission control". > |> |>> > |> |>> If "Edge node" requires further definition to exclude > |> |things to close > |> | > |> |>> to an "end system", we should add it at appropriate places. > |> |>> "PCN related" would exclude dealing with middleboxes > |doing anything > |> |>> else with packets than PCN DiffServ forwarding. > |> |>> > |> |>> Another question is, what the reaction of an ingress edge > |> |node should > |> | > |> |>> be in case of an indicated network congestion. My > |> |impression is, that > |> | > |> |>> with the initial charter we should just define a desired > |> |behaviour in > |> | > |> |>> terms of an aggregate traffic reduction (e.g. "stop > |admission new > |> |>> flows demanding CL forwarding or bandwidth increases > of admitted > |> |>> ones" or "reduce CL traffic by x percent"). > |> |>> Future work items may be added when the WG is > re-chartered after > |> |>> having reached first aims. It may indeed be useful to > |think about > |> |>> some requirements for future PCN use already now. As I > |didn't think > |> |>> about particular topics in detail, I don't try to > |summarise which > |> |>> requirements that could be by this mail. > |> |>> > |> |>> Regards, > |> |>> > |> |>> Ruediger > |> |>> > |> |>> > |> |>> |-----Original Message----- > |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > |> |>> |Sent: Thursday, February 01, 2007 9:45 AM > |> |>> |To: Lee, Richard FTC; Black_David@emc.com; > |karagian@cs.utwente.nl > |> |>> |Cc: pcn@ietf.org > |> |>> |Subject: RE: [PCN] charter, addition to scope > |> |>> | > |> |>> | > |> |>> |Maybe we should stop for a moment and consider what layer > |> |should PCN > |> | > |> |>> |deal with. It looks to me that we are mixing network admiss= ion > |> |>> |control and call admission control in this discussion. > |> |This problem > |> |>> |is quite complex, and there are many scenarios that need > |> |to be taken > |> | > |> |>> |into consideration. Sometimes flow =3D call, sometimes call > |> |=3DNOT flow > |> |>> |and sometimes there is a mix on the same path. In some > |cases media > |> |>> |gateways > |> |>> > |> |>> |are collocated with the edge nodes in some other cases > |not. Even > |> |>> |when flow =3D call there are two admission control layers > |> |(network and > |> | > |> |>> |call) that are in dependency but not identical and separate > |> |>> |protocols run at transport and session. I am not sure > |how much of > |> |>> |all this falls under what PCN should do. > |> |>> | > |> |>> |Dan > |> |>> | > |> |>> | > |> |>> | > |> |>> | > |> |>> | | | > |> |>> |> -----Original Message----- > |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM > |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl > |> |>> |> Cc: pcn@ietf.org > |> |>> |> Subject: RE: [PCN] charter, addition to scope > |> |>> |> |> To all, > |> |>> |> I agree that there must be a prioritization of flows > |from the |> > |> |>> aggregation devices However, it's not just the media > |> |gateway that |> > |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") > |> |as well - > |> |>> > |> |>> |> it is the signaling proxy at the edge that reserves > the media > |> |>> |> path. |> > |> |>> The reservation protocol request to the network from > the VoIP |> > |> |>> proxy/gateway must reserve resources to the destination > |in the |> > |> |>> network. > |> |>> |> The resource reservation request to the network by > the edge |> > |> |>> proxy/media gateway, must at the very minimum, meet the > |following |> > |> |>> conditions: > |> |>> |> 1. it needs to specify the resources required for the > |IP & ports > |> |>> |> |> > |> |>> (RTP/RTCP & bandwidth) > |> |>> |> for example, G.711 and G.729 voice and various > |MPEG-4 video > |> |>> |> codecs > |> |>> > |> |>> |> all have very different requirements 2. it must be > |mapped to the > |> |>> |> |> > |> |>> signaling request > |> |>> |> for SIP, it must map the SDP for media with the > |reservation > |> |>> |> flow - > |> |>> > |> |>> |> for example something along the lines of RFC 3524 > |> |>> |> while not the answer, the mapping of the media > |flows is a |> > |> |>> necessary component > |> |>> |> It should be noted that the edge proxies/media > |gateways may > |> |>> |> have a > |> |>> > |> |>> |> large number of flows (and ports for each > |> |>> |> RTP/RTCP flow) from the same source IP. The request > |> |is made for > |> | > |> |>> |> |> > |> |>> each flow or conversation 3. it must be honored by the > |edge network > |> |>> |> device. > |> |>> |> The trust boundary must be extended to the edge > |proxy/media |> > |> |>> gateway for each new flow. > |> |>> |> This brings up the issue of security authentication > |> |of the edge > |> | > |> |>> |> |> > |> |>> proxy/media gateway to the network > |> |>> |> Does this happen in EAP, NAC, or just > interoperability and |> > |> |>> certification among vendors > |> |>> |> If the resources are not available, then the signaling > |> |>> |> indicates |> > |> |>> the session is not completed. For example a SIP > |> |>> |> CANCEL from the edge proxy > |> |>> |> |> In addition, the network device must have > priority queuing > |> |>> |> |> enabled > |> |>> |> for input queues from the edge device. > |> |>> |> The media flows must not be subject to input buffers > |> |being filled > |> |>> |> |> > |> |>> prior to classification > |> |>> |> |> Thanks, > |> |>> |> Richard Lee > |> |>> |> Fidelity Investments > |> |>> |> Enterprise Technology and Architecture > |> |>> |> 617-563-3278 > |> |>> |> |> |> -----Original Message----- > |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] > |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM > |> |>> |> To: karagian@cs.utwente.nl > |> |>> |> Cc: pcn@ietf.org > |> |>> |> Subject: RE: [PCN] charter, addition to scope > |> |>> |> |> |> Georgios wrote: > |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > |> |>> |> > > > In the first phase of PCN work to reduce the list o= f > |> |>> |> issues it was > |> |>> |> |> > > > proposed that the WG focus on network > |> |deployment scenario > |> |>> where > |> |>> |> all > |> |>> |> > > > nodes can be trusted and delay work on deployment > |> |>> |> scenarios where > |> |>> |> some > |> |>> |> > > > of the nodes are not trusted. > |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, > |then yes, I > |> |>> agree. If > |> |>> |> "nodes" |> > > include end systems, proxies or other > |entities, > |> |>> |> then I > |> |>> don't |> > > agree we had agreement on that. > |> |>> |> > |> > Georgios: This imposes an additional > |restriction on the > |> |>> |> > |> > scope > |> |>> of |> > the charter, which has been not discussed yet. > |> |>> |> > >From what I remember before, during and after the PCN = BOF > |> |>> |> > there was no objection on using the term edge node, > |that could > |> |>> |> > mean something different than a edge > |> |>> |> router. > |> |>> |> > Please note that this is something different than a > |> |>> |scenario covered > |> |>> |> by > |> |>> |> > an application based deployment model. > |> |>> |> |> It's certainly not a new restriction based on the > |> |discussion in > |> | > |> |>> |> |> the > |> |>> |> BOF engendered about whether a SIP telephone (used on > |some of the > |> |>> |> slides) was a good example. I believe the BOF > |> |conclusion was that > |> | > |> |>> |> a SIP telephone was a bad example. > |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt th= e > |> |>> |proposed work: > |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) > |The first set > |> |>> |> of issues has already been discussed extensively - my > |> |>> |> understanding is that the SIP scenario is currently out > |> |of scope, > |> |>> |> and > |> |>> > |> |>> |> I don't care to reopen that discussion. > |> |>> |> |> The "telephone" issues come up in two ways: > |> |>> |> (2a) Small number of flows may make relatively fine-grain= ed > |> |>> |adjustment > |> |>> |> on the link to the phone impossible. The PCN work > |prior to the > |> |>> |> BOF relied on the ability to make such adjustments. > |> |>> |> (2b) While other sorts of phones may be trusted, a SIP ph= one > |> |>> |> (which may be software-only) is definitely not trustable = in > |> |general. > |> |>> |> |> I would observe that Lars Westerberg's suggestion > |of a Media > |> |>> Gateway: > |> |>> |> |> > I am referring telecom scenario where MGWs are > |connected to > |> |>> |> |> > an > |> |>> |> IP-backbone. > |> |>> |> > In these scenarios, the admission control function is > |> |a part of > |> |>> |> > the > |> |>> |> MGW > |> |>> |> > and not the routers. The IP-backbone is provisioned by > |> |a network > |> | > |> |>> |> > |> > |> |>> > management system. > |> |>> |> |> could avoid all of these issues: > |> |>> |> (1) The media gateway could speak RSVP to the network > |management > |> |>> |> |> > |> |>> system, > |> |>> |> avoiding any need to deal with SIP here. > |> |>> |> (2a) A media gateway is likely to handle enough flows to = be > |> |>> |consistent > |> |>> |> with the fine-grained adjustment assumed by the work done= to > |> |>> date. > |> |>> |> (2b) One can plausibly assume/require that media gateways= be > |> |>> |> trusted with respect to the IP network. > |> |>> |> To the extent that one can vest "edge" functionality in > |> |a trusted > |> |>> |> |> > |> |>> media gateway, I see no reason to exclude that scenario. > |> |>> |> |> Thanks, > |> |>> |> --David > |> |>> |> ---------------------------------------------------- > |> |>> |> David L. Black, Senior Technologist EMC Corporation, > |176 South > |> |>> |> St., Hopkinton, MA 01748 > |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 > |> |>> |> ---------------------------------------------------- > |> |>> |> |> _______________________________________________ > |> |>> |> 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 Wuerzbur= g, > |> |> 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 > |> > | > |--=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 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 09 01:53:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFPdt-0004vX-3x; Fri, 09 Feb 2007 01:53:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFPd9-0004kk-3M for pcn@ietf.org; Fri, 09 Feb 2007 01:53:11 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFPZ6-0003Je-Dx for pcn@ietf.org; Fri, 09 Feb 2007 01:49:13 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B448320757; Fri, 9 Feb 2007 07:48:51 +0100 (CET) X-AuditID: c1b4fb3c-b0fcabb0000007de-97-45cc1953fc08 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 911D820714; Fri, 9 Feb 2007 07:48:51 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 07:48:51 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 07:48:51 +0100 Message-ID: <45CC1953.9040804@ericsson.com> Date: Fri, 09 Feb 2007 07:48:51 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tina TSOU Subject: Re: [PCN] "Network Admission Control" (NAC) References: <002801c74bea$14f1cd50$9c28460a@china.huawei.com> In-Reply-To: <002801c74bea$14f1cd50$9c28460a@china.huawei.com> X-OriginalArrivalTime: 09 Feb 2007 06:48:51.0028 (UTC) FILETIME=[5B6E1140:01C74C16] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 2278abf12cc2008bf368ff74d7126599 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: , Content-Type: multipart/mixed; boundary="===============0587413657==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0587413657== Content-Type: multipart/alternative; boundary="------------020105010904050001010106" This is a multi-part message in MIME format. --------------020105010904050001010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable good suggestion. I agrre, the terminology for admision control is a good=20 topic for the framework draft. regards Lasse Tina TSOU wrote: > Hi Anna, > I agree with you. Probably we need the terminology in the session of th= e > architecture draft, or a small informal draft. > > B. R. > Tina > > ----- Original Message ----- > From: "Anna Charny (acharny)" > To: "Tina TSOU" ; ; "Geib, Ruediger= " > > Cc: > Sent: Friday, February 09, 2007 12:07 AM > Subject: RE: [PCN] "Network Admission Control" (NAC) > > > Hi, > > Just a thought that there will be a number of terminology issues to=20 > address > once the WG is formed. I wonder if this discussion can become part of t= he > work on the terminology that would eventually find its way into (I thin= k) > the architecture draft? > > Anna > > > > -----Original Message----- > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: Tuesday, February 06, 2007 3:32 AM > > To: brodrig@avaya.com; Geib, Ruediger > > Cc: pcn@ietf.org > > Subject: Re: [PCN] "Network Admission Control" (NAC) > > > > Hi Ruediger, > > Do we also consider Network Access Control in PCN? > > > > B. R. > > Tina > > ----- Original Message ----- > > From: "Geib, Ruediger" > > To: > > Cc: > > Sent: Tuesday, February 06, 2007 4:18 PM > > Subject: RE: [PCN] "Network Admission Control" (NAC) > > > > > > Benny, > > > > I prefer Michaels proposal, NAC or DAC is allright with me if we > > provide a definition for our terminology. The same would hold > > if "flow admission" is used, which I feel to be to close to > > "per flow". > > > > A side note on the abbreviation NAC: it is also described as > > Network Access Control by Wikipedia. I've checked that because > > within my company what is described by Wiki as Network > > "Admission Control" is called Network Access Control. > > > > Regards, > > > > Ruediger > > > > |-----Original Message----- > > |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > |Sent: Monday, February 05, 2007 8:37 PM > > |To: Rodrig, Benny (Benny) > > |Cc: Geib, R=FCdiger; pcn@ietf.org > > |Subject: Re: [PCN] "Network Admission Control" (NAC) > > | > > | > > |Hi, > > | > > |the word NAC itself means that access is possibly denied to a networ= k > > |which can be due to security or resource reasons. NAC in the securit= y > > |context has become a quite popular expression as it is the name of a > > |Cisco product. The name NAC sounds good (to me) as it is > > very catchy and > > |easy to understand also for non-experts. I don't see a large problem > > |when the term NAC exists in different contexts. If people need to > > |distinguish both approaches, security-related NAC and > > resource-related > > |NAC can be used. However, people working in both areas might see thi= s > > |differently. > > | > > |As the new version of the PCN charter talks about domains, domain > > |admission control (DAC) would be a natural substitute for > > NAC. DAC has > > |no misleading connotations, but it doesn't sound nice (to me). Bette= r > > |sounds maybe per-domain AC (PDAC) and concisely states what it is. I= n > > |analogy to routing, intradomain admission control is another > > option, but > > |it also implies the existence of interdomain admission > > control. I'm not > > |sure whether we want this right now. > > | > > |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN > > |charter, we can leave this issue open until we have a > > clearer opinion. > > | > > | Michael > > | > > |Rodrig, Benny (Benny) wrote: > > |> Ruediger, > > |> > > |> To me the charter doesn't seem to imply the expansion of scope tha= t > > |> you're concerned about. Unlike many other terms "flow > > admission" doesn't > > |> seem to have misleading connotations. But I could be ok > > with "network > > |> flow admission". > > |> > > |> If it is important that the charter be more explicit about > > this point, > > |> then perhaps a sentence should be added with some explicit > > description > > |> e.g. that the flow admission behavior at the boundary > > includes policing > > |> and/or interaction with per-flow mechanisms that are out > > of scope of > > |> PCN. > > |> > > |> Benny > > |> > > |> > > |> -----Original Message----- > > |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > |> Sent: Monday, February 05, 2007 3:01 AM > > |> To: Rodrig, Benny (Benny) > > |> Cc: pcn@ietf.org > > |> Subject: RE: [PCN] "Network Admission Control" (NAC) > > |> > > |> I'm not sure whether "flow admission" is the correct description. > > |> Wouldn' or couldn't that mean that PCN includes work on > > the per flow > > |> admission control functionality. PCN then is chartered to work on > > |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with > > |Network- or > > |> Aggregate- or Per Domain Behaviour- Admission Control, then the > > |> chartered PCN work could be limited to provide an > > interface (API?) to > > |> the per flow signaling protocol. Isn't the latter > > sufficient for the > > |> initial charter? > > |> > > |> Regards, > > |> > > |> Ruediger > > |> > > |> |-----Original Message----- > > |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > |> |Sent: Friday, February 02, 2007 5:09 PM > > |> |To: Moore, Sean (Sean); Tina TSOU; > > |menth@informatik.uni-wuerzburg.de; > > |> |Geib, Rudiger > > |> |Cc: pcn@ietf.org > > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > > |> | > > |> | > > |> |I think the 'flow admission' wording in the charter is fine and w= e > > |> |don't need to choose a more precise term. The charter text > > |explaining > > |> |that this flow admission happens at the domain boundary in > > |reaction to > > |> |pre-congestion info from within the domain, etc. seems to > > |describe it > > |> |sufficiently. > > |> | > > |> |Benny > > |> | > > |> |-----Original Message----- > > |> |From: Moore, Sean (Sean) > > |> |Sent: Friday, February 02, 2007 9:59 AM > > |> |To: Tina TSOU; Rodrig, Benny (Benny); > > |menth@informatik.uni-wuerzburg.de > > |> |Cc: pcn@ietf.org; Geib, Ruediger > > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > > |> | > > |> |Probably shouldn't use "Resource Admission Control" as this > > |term (RAC) > > |> |is used in IMS and it is not the same as what we are discussing > > |> |- Sean > > |> | > > |> |-----Original Message----- > > |> |From: Tina TSOU [mailto:tena@huawei.com] > > |> |Sent: Friday, February 02, 2007 9:25 AM > > |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de > > |> |Cc: pcn@ietf.org; Geib, Ruediger > > |> |Subject: Re: [PCN] "Network Admission Control" (NAC) > > |> | > > |> |Hi, > > |> |How about Resource Admission Control or Network Resource Admissio= n > > |> |Control? > > |> |I don't have strong opinion on that, just some terms > > popped up in my > > |> |mind:) > > |> | > > |> |B. R. > > |> |Tina > > |> | > > |> |----- Original Message ----- > > |> |From: "Michael Menth" > > |> |To: "Rodrig, Benny (Benny)" > > |> |Cc: ; "Geib, Ruediger" > > |> |Sent: Friday, February 02, 2007 12:16 PM > > |> |Subject: [PCN] "Network Admission Control" (NAC) > > |> | > > |> | > > |> |> Hi, > > |> |> > > |> |> I've got a comment on the term "Network Admission > > Control" (NAC). > > |> |> > > |> |> Wikipedia > > |> |http://en.wikipedia.org/wiki/Network_Admission_Control only > > |> |> knows NAC in the context of restricting access to the > > |> |network based on > > |> | > > |> |> identity or security posture (it's essentially a Cisco product)= . > > |> |> However, most important is the aspect that access is denied > > |> |to a whole > > |> | > > |> |> network, subnetwork, domain, region, etc. NAC is in > > |contrast to AC > > |> |> algorithms deciding whether a new flow can be admitted to be > > |> |> transported over a single link which has been studied in > > |> |depth in the > > |> |> 1990s in the context of ATM systems. Three years ago, I have > > |> |reviewed > > |> |> and studied different approaches for NAC (based on resource > > |> |management > > |> |issues) in my PhD thesis: > > |> |> > > |> > > ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p > df/Menth04 > > |> |> .pdf The terms connection or flow admission control are less > > |> |specific > > |> |> than NAC as they do not tell the scope of the AC. > > |> |> > > |> |> Best regards, > > |> |> > > |> |> Michael > > |> |> > > |> |> Rodrig, Benny (Benny) wrote: > > |> |>> What I think you mean, and the admission control that PCN > > |> |deals with, > > |> | > > |> |>> better not be described as "network admission control" > > |since that > > |> |>> term often (e.g. see > > |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) > > |> |>> refers to admission based on the identity of the sender, > > |which is > > |> |>> probably out of scope for PCN. The flow admission > > control in PCN > > |> |>> scope is based on considerations related to network status i.e= . > > |> |>> pre-congestion. > > |> |>> The PCN flow admission control can be part of a call admission > > |> |>> control solution, if it interacts with other mechanisms > > |such as for > > |> |>> example with Int-Serv outside the PCN domain and/or > > with SIP QoS > > |> |>> pre-conditions. Such interactions, or assumptions about > > |> |them, may not > > |> |be in the scope of PCN. > > |> |>> > > |> |>> > > |> |>> Benny > > |> |>> -----Original Message----- > > |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent= : > > |> |>> Thursday, February 01, 2007 4:44 AM > > |> |>> To: Romascanu, Dan (Dan) > > |> |>> Cc: pcn@ietf.org > > |> |>> Subject: RE: [PCN] charter, addition to scope > > |> |>> > > |> |>> Hi Dan, > > |> |>> > > |> |>> your proposal seems sound to me. My impression is the > > |> |discussion may > > |> |>> have approached consensus on the following issues to get > > |chartered > > |> |>> initially: > > |> |>> > > |> |>> - PCN is limited to a single DiffServ domain. > > |> |>> - PCN aware nodes must be "on path". > > |> |>> - PCN only standardises PCN related IP layer > > |> |>> functionalities including RSVP or NSIS signaling > > |> |>> between edge nodes. > > |> |>> - PCN only works on "network admission control". > > |> |>> > > |> |>> If "Edge node" requires further definition to exclude > > |> |things to close > > |> | > > |> |>> to an "end system", we should add it at appropriate places. > > |> |>> "PCN related" would exclude dealing with middleboxes > > |doing anything > > |> |>> else with packets than PCN DiffServ forwarding. > > |> |>> > > |> |>> Another question is, what the reaction of an ingress edge > > |> |node should > > |> | > > |> |>> be in case of an indicated network congestion. My > > |> |impression is, that > > |> | > > |> |>> with the initial charter we should just define a desired > > |> |behaviour in > > |> | > > |> |>> terms of an aggregate traffic reduction (e.g. "stop > > |admission new > > |> |>> flows demanding CL forwarding or bandwidth increases > > of admitted > > |> |>> ones" or "reduce CL traffic by x percent"). > > |> |>> Future work items may be added when the WG is > > re-chartered after > > |> |>> having reached first aims. It may indeed be useful to > > |think about > > |> |>> some requirements for future PCN use already now. As I > > |didn't think > > |> |>> about particular topics in detail, I don't try to > > |summarise which > > |> |>> requirements that could be by this mail. > > |> |>> > > |> |>> Regards, > > |> |>> > > |> |>> Ruediger > > |> |>> > > |> |>> > > |> |>> |-----Original Message----- > > |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > |> |>> |Sent: Thursday, February 01, 2007 9:45 AM > > |> |>> |To: Lee, Richard FTC; Black_David@emc.com; > > |karagian@cs.utwente.nl > > |> |>> |Cc: pcn@ietf.org > > |> |>> |Subject: RE: [PCN] charter, addition to scope > > |> |>> | > > |> |>> | > > |> |>> |Maybe we should stop for a moment and consider what layer > > |> |should PCN > > |> | > > |> |>> |deal with. It looks to me that we are mixing network admissio= n > > |> |>> |control and call admission control in this discussion. > > |> |This problem > > |> |>> |is quite complex, and there are many scenarios that need > > |> |to be taken > > |> | > > |> |>> |into consideration. Sometimes flow =3D call, sometimes call > > |> |=3DNOT flow > > |> |>> |and sometimes there is a mix on the same path. In some > > |cases media > > |> |>> |gateways > > |> |>> > > |> |>> |are collocated with the edge nodes in some other cases > > |not. Even > > |> |>> |when flow =3D call there are two admission control layers > > |> |(network and > > |> | > > |> |>> |call) that are in dependency but not identical and separate > > |> |>> |protocols run at transport and session. I am not sure > > |how much of > > |> |>> |all this falls under what PCN should do. > > |> |>> | > > |> |>> |Dan > > |> |>> | > > |> |>> | > > |> |>> | > > |> |>> | > > |> |>> | | | > > |> |>> |> -----Original Message----- > > |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > > |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM > > |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl > > |> |>> |> Cc: pcn@ietf.org > > |> |>> |> Subject: RE: [PCN] charter, addition to scope > > |> |>> |> |> To all, > > |> |>> |> I agree that there must be a prioritization of flows > > |from the |> > > |> |>> aggregation devices However, it's not just the media > > |> |gateway that |> > > |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") > > |> |as well - > > |> |>> > > |> |>> |> it is the signaling proxy at the edge that reserves > > the media > > |> |>> |> path. |> > > |> |>> The reservation protocol request to the network from > > the VoIP |> > > |> |>> proxy/gateway must reserve resources to the destination > > |in the |> > > |> |>> network. > > |> |>> |> The resource reservation request to the network by > > the edge |> > > |> |>> proxy/media gateway, must at the very minimum, meet the > > |following |> > > |> |>> conditions: > > |> |>> |> 1. it needs to specify the resources required for the > > |IP & ports > > |> |>> |> |> > > |> |>> (RTP/RTCP & bandwidth) > > |> |>> |> for example, G.711 and G.729 voice and various > > |MPEG-4 video > > |> |>> |> codecs > > |> |>> > > |> |>> |> all have very different requirements 2. it must be > > |mapped to the > > |> |>> |> |> > > |> |>> signaling request > > |> |>> |> for SIP, it must map the SDP for media with the > > |reservation > > |> |>> |> flow - > > |> |>> > > |> |>> |> for example something along the lines of RFC 3524 > > |> |>> |> while not the answer, the mapping of the media > > |flows is a |> > > |> |>> necessary component > > |> |>> |> It should be noted that the edge proxies/media > > |gateways may > > |> |>> |> have a > > |> |>> > > |> |>> |> large number of flows (and ports for each > > |> |>> |> RTP/RTCP flow) from the same source IP. The request > > |> |is made for > > |> | > > |> |>> |> |> > > |> |>> each flow or conversation 3. it must be honored by the > > |edge network > > |> |>> |> device. > > |> |>> |> The trust boundary must be extended to the edge > > |proxy/media |> > > |> |>> gateway for each new flow. > > |> |>> |> This brings up the issue of security authentication > > |> |of the edge > > |> | > > |> |>> |> |> > > |> |>> proxy/media gateway to the network > > |> |>> |> Does this happen in EAP, NAC, or just > > interoperability and |> > > |> |>> certification among vendors > > |> |>> |> If the resources are not available, then the signaling > > |> |>> |> indicates |> > > |> |>> the session is not completed. For example a SIP > > |> |>> |> CANCEL from the edge proxy > > |> |>> |> |> In addition, the network device must have > > priority queuing > > |> |>> |> |> enabled > > |> |>> |> for input queues from the edge device. > > |> |>> |> The media flows must not be subject to input buffers > > |> |being filled > > |> |>> |> |> > > |> |>> prior to classification > > |> |>> |> |> Thanks, > > |> |>> |> Richard Lee > > |> |>> |> Fidelity Investments > > |> |>> |> Enterprise Technology and Architecture > > |> |>> |> 617-563-3278 > > |> |>> |> |> |> -----Original Message----- > > |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] > > |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM > > |> |>> |> To: karagian@cs.utwente.nl > > |> |>> |> Cc: pcn@ietf.org > > |> |>> |> Subject: RE: [PCN] charter, addition to scope > > |> |>> |> |> |> Georgios wrote: > > |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > |> |>> |> > > > In the first phase of PCN work to reduce the list of > > |> |>> |> issues it was > > |> |>> |> |> > > > proposed that the WG focus on network > > |> |deployment scenario > > |> |>> where > > |> |>> |> all > > |> |>> |> > > > nodes can be trusted and delay work on deployment > > |> |>> |> scenarios where > > |> |>> |> some > > |> |>> |> > > > of the nodes are not trusted. > > |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, > > |then yes, I > > |> |>> agree. If > > |> |>> |> "nodes" |> > > include end systems, proxies or other > > |entities, > > |> |>> |> then I > > |> |>> don't |> > > agree we had agreement on that. > > |> |>> |> > |> > Georgios: This imposes an additional > > |restriction on the > > |> |>> |> > |> > scope > > |> |>> of |> > the charter, which has been not discussed yet. > > |> |>> |> > >From what I remember before, during and after the PCN BO= F > > |> |>> |> > there was no objection on using the term edge node, > > |that could > > |> |>> |> > mean something different than a edge > > |> |>> |> router. > > |> |>> |> > Please note that this is something different than a > > |> |>> |scenario covered > > |> |>> |> by > > |> |>> |> > an application based deployment model. > > |> |>> |> |> It's certainly not a new restriction based on the > > |> |discussion in > > |> | > > |> |>> |> |> the > > |> |>> |> BOF engendered about whether a SIP telephone (used on > > |some of the > > |> |>> |> slides) was a good example. I believe the BOF > > |> |conclusion was that > > |> | > > |> |>> |> a SIP telephone was a bad example. > > |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the > > |> |>> |proposed work: > > |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) > > |The first set > > |> |>> |> of issues has already been discussed extensively - my > > |> |>> |> understanding is that the SIP scenario is currently out > > |> |of scope, > > |> |>> |> and > > |> |>> > > |> |>> |> I don't care to reopen that discussion. > > |> |>> |> |> The "telephone" issues come up in two ways: > > |> |>> |> (2a) Small number of flows may make relatively fine-grained > > |> |>> |adjustment > > |> |>> |> on the link to the phone impossible. The PCN work > > |prior to the > > |> |>> |> BOF relied on the ability to make such adjustments. > > |> |>> |> (2b) While other sorts of phones may be trusted, a SIP phon= e > > |> |>> |> (which may be software-only) is definitely not trustable in > > |> |general. > > |> |>> |> |> I would observe that Lars Westerberg's suggestion > > |of a Media > > |> |>> Gateway: > > |> |>> |> |> > I am referring telecom scenario where MGWs are > > |connected to > > |> |>> |> |> > an > > |> |>> |> IP-backbone. > > |> |>> |> > In these scenarios, the admission control function is > > |> |a part of > > |> |>> |> > the > > |> |>> |> MGW > > |> |>> |> > and not the routers. The IP-backbone is provisioned by > > |> |a network > > |> | > > |> |>> |> > |> > > |> |>> > management system. > > |> |>> |> |> could avoid all of these issues: > > |> |>> |> (1) The media gateway could speak RSVP to the network > > |management > > |> |>> |> |> > > |> |>> system, > > |> |>> |> avoiding any need to deal with SIP here. > > |> |>> |> (2a) A media gateway is likely to handle enough flows to be > > |> |>> |consistent > > |> |>> |> with the fine-grained adjustment assumed by the work done t= o > > |> |>> date. > > |> |>> |> (2b) One can plausibly assume/require that media gateways b= e > > |> |>> |> trusted with respect to the IP network. > > |> |>> |> To the extent that one can vest "edge" functionality in > > |> |a trusted > > |> |>> |> |> > > |> |>> media gateway, I see no reason to exclude that scenario. > > |> |>> |> |> Thanks, > > |> |>> |> --David > > |> |>> |> ---------------------------------------------------- > > |> |>> |> David L. Black, Senior Technologist EMC Corporation, > > |176 South > > |> |>> |> St., Hopkinton, MA 01748 > > |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 > > |> |>> |> ---------------------------------------------------- > > |> |>> |> |> _______________________________________________ > > |> |>> |> 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 > > |> | > > |> | > > |> | > > |> > > |> > > |> _______________________________________________ > > |> 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 > > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > --------------020105010904050001010106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit good suggestion. I agrre, the terminology for admision control is a good topic for the framework draft.

regards Lasse


Tina TSOU wrote:
Re: [PCN] "Network Admission Control" (NAC)

Hi Anna,
I agree with you. Probably we need the terminology in the session of the
architecture draft, or a small informal draft.

B. R.
Tina

----- Original Message -----
From: "Anna Charny (acharny)" <acharny@cisco.com>
To: "Tina TSOU" <tena@huawei.com>; <brodrig@avaya.com>; "Geib, Ruediger"
<Ruediger.Geib@t-systems.com>
Cc: <pcn@ietf.org>
Sent: Friday, February 09, 2007 12:07 AM
Subject: RE: [PCN] "Network Admission Control" (NAC)


Hi,

Just a thought that there will be a number of terminology issues to address
once the WG is formed. I wonder if this discussion can become part of the
work on the terminology that would eventually find its way into (I think)
the architecture draft?

Anna


> -----Original Message-----
> From: Tina TSOU [mailto:tena@huawei.com]
> Sent: Tuesday, February 06, 2007 3:32 AM
> To: brodrig@avaya.com; Geib, Ruediger
> Cc: pcn@ietf.org
> Subject: Re: [PCN] "Network Admission Control" (NAC)
>
> Hi Ruediger,
> Do we also consider Network Access Control in PCN?
>
> B. R.
> Tina
> ----- Original Message -----
> From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
> To: <brodrig@avaya.com>
> Cc: <pcn@ietf.org>
> Sent: Tuesday, February 06, 2007 4:18 PM
> Subject: RE: [PCN] "Network Admission Control" (NAC)
>
>
> Benny,
>
> I prefer Michaels proposal, NAC or DAC is allright with me if we
> provide a definition for our terminology. The same would hold
> if "flow admission" is used, which I feel to be to close to
> "per flow".
>
> A side note on the abbreviation NAC: it is also described as
> Network Access Control by Wikipedia. I've checked that because
> within my company what is described by Wiki as Network
> "Admission Control" is called Network Access Control.
>
> Regards,
>
> Ruediger
>
> |-----Original Message-----
> |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
> |Sent: Monday, February 05, 2007 8:37 PM
> |To: Rodrig, Benny (Benny)
> |Cc: Geib, Rüdiger; pcn@ietf.org
> |Subject: Re: [PCN] "Network Admission Control" (NAC)
> |
> |
> |Hi,
> |
> |the word NAC itself means that access is possibly denied to a network
> |which can be due to security or resource reasons. NAC in the security
> |context has become a quite popular expression as it is the name of a
> |Cisco product. The name NAC sounds good (to me) as it is
> very catchy and
> |easy to understand also for non-experts. I don't see a large problem
> |when the term NAC exists in different contexts. If people need to
> |distinguish both approaches, security-related NAC and
> resource-related
> |NAC can be used. However, people working in both areas might see this
> |differently.
> |
> |As the new version of the PCN charter talks about domains, domain
> |admission control (DAC) would be a natural substitute for
> NAC. DAC has
> |no misleading connotations, but it doesn't sound nice (to me). Better
> |sounds maybe per-domain AC (PDAC) and concisely states what it is. In
> |analogy to routing, intradomain admission control is another
> option, but
> |it also implies the existence of interdomain admission
> control. I'm not
> |sure whether we want this right now.
> |
> |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN
> |charter, we can leave this issue open until we have a
> clearer opinion.
> |
> |    Michael
> |
> |Rodrig, Benny (Benny) wrote:
> |> Ruediger,
> |>
> |> To me the charter doesn't seem to imply the expansion of scope that
> |> you're concerned about. Unlike many other terms "flow
> admission" doesn't
> |> seem to have misleading connotations. But I could be ok
> with "network
> |> flow admission".
> |>
> |> If it is important that the charter be more explicit about
> this point,
> |> then perhaps a sentence should be added with some explicit
> description
> |> e.g. that the flow admission behavior at the boundary
> includes policing
> |> and/or interaction with per-flow mechanisms that are out
> of scope of
> |> PCN.
> |>
> |> Benny
> |>
> |>
> |> -----Original Message-----
> |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> |> Sent: Monday, February 05, 2007 3:01 AM
> |> To: Rodrig, Benny (Benny)
> |> Cc: pcn@ietf.org
> |> Subject: RE: [PCN] "Network Admission Control" (NAC)
> |>
> |> I'm not sure whether "flow admission" is the correct description.
> |> Wouldn' or couldn't that mean that PCN includes work on
> the per flow
> |> admission control functionality. PCN then is chartered to work on
> |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with
> |Network- or
> |> Aggregate- or Per Domain Behaviour- Admission Control, then the
> |> chartered PCN work could be limited to provide an
> interface (API?) to
> |> the per flow signaling protocol. Isn't the latter
> sufficient for the
> |> initial charter?
> |>
> |> Regards,
> |>
> |> Ruediger
> |>
> |> |-----Original Message-----
> |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com]
> |> |Sent: Friday, February 02, 2007 5:09 PM
> |> |To: Moore, Sean (Sean); Tina TSOU;
> |menth@informatik.uni-wuerzburg.de;
> |> |Geib, Rudiger
> |> |Cc: pcn@ietf.org
> |> |Subject: RE: [PCN] "Network Admission Control" (NAC)
> |> |
> |> |
> |> |I think the 'flow admission' wording in the charter is fine and we
> |> |don't need to choose a more precise term. The charter text
> |explaining
> |> |that this flow admission happens at the domain boundary in
> |reaction to
> |> |pre-congestion info from within the domain, etc. seems to
> |describe it
> |> |sufficiently.
> |> |
> |> |Benny
> |> |
> |> |-----Original Message-----
> |> |From: Moore, Sean (Sean)
> |> |Sent: Friday, February 02, 2007 9:59 AM
> |> |To: Tina TSOU; Rodrig, Benny (Benny);
> |menth@informatik.uni-wuerzburg.de
> |> |Cc: pcn@ietf.org; Geib, Ruediger
> |> |Subject: RE: [PCN] "Network Admission Control" (NAC)
> |> |
> |> |Probably shouldn't use "Resource Admission Control" as this
> |term (RAC)
> |> |is used in IMS and it is not the same as what we are discussing
> |> |- Sean
> |> |
> |> |-----Original Message-----
> |> |From: Tina TSOU [mailto:tena@huawei.com]
> |> |Sent: Friday, February 02, 2007 9:25 AM
> |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de
> |> |Cc: pcn@ietf.org; Geib, Ruediger
> |> |Subject: Re: [PCN] "Network Admission Control" (NAC)
> |> |
> |> |Hi,
> |> |How about Resource Admission Control or Network Resource Admission
> |> |Control?
> |> |I don't have strong opinion on that, just some terms
> popped up in my
> |> |mind:)
> |> |
> |> |B. R.
> |> |Tina
> |> |
> |> |----- Original Message -----
> |> |From: "Michael Menth" <menth@informatik.uni-wuerzburg.de>
> |> |To: "Rodrig, Benny (Benny)" <brodrig@avaya.com>
> |> |Cc: <pcn@ietf.org>; "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
> |> |Sent: Friday, February 02, 2007 12:16 PM
> |> |Subject: [PCN] "Network Admission Control" (NAC)
> |> |
> |> |
> |> |> Hi,
> |> |>
> |> |> I've got a comment on the term "Network Admission
> Control" (NAC).
> |> |>
> |> |> Wikipedia
> |> |http://en.wikipedia.org/wiki/Network_Admission_Control only
> |> |> knows NAC in the context of restricting access to the
> |> |network based on
> |> |
> |> |> identity or security posture (it's essentially a Cisco product).
> |> |> However, most important is the aspect that access is denied
> |> |to a whole
> |> |
> |> |> network, subnetwork, domain, region, etc. NAC is in
> |contrast to AC
> |> |> algorithms deciding whether a new flow can be admitted to be
> |> |> transported over a single link which has been studied in
> |> |depth in the
> |> |> 1990s in the context of ATM systems. Three years ago, I have
> |> |reviewed
> |> |> and studied different approaches for NAC (based on resource
> |> |management
> |> |issues) in my PhD thesis:
> |> |>
> |>
> ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p
df/Menth04
> |> |> .pdf The terms connection or flow admission control are less
> |> |specific
> |> |> than NAC as they do not tell the scope of the AC.
> |> |>
> |> |> Best regards,
> |> |>
> |> |>    Michael
> |> |>
> |> |> Rodrig, Benny (Benny) wrote:
> |> |>> What I think you mean, and the admission control that PCN
> |> |deals with,
> |> |
> |> |>> better not be described as "network admission control"
> |since that
> |> |>> term often (e.g. see
> |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control)
> |> |>> refers to admission based on the identity of the sender,
> |which is
> |> |>> probably out of scope for PCN. The flow admission
> control in PCN
> |> |>> scope is based on considerations related to network status i.e.
> |> |>> pre-congestion.
> |> |>> The PCN flow admission control can be part of a call admission
> |> |>> control solution, if it interacts with other mechanisms
> |such as for
> |> |>> example with Int-Serv outside the PCN domain and/or
> with SIP QoS
> |> |>> pre-conditions. Such interactions, or assumptions about
> |> |them, may not
> |> |be in the scope of PCN.
> |> |>>
> |> |>>
> |> |>> Benny
> |> |>> -----Original Message-----
> |> |>> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent:
> |> |>> Thursday, February 01, 2007 4:44 AM
> |> |>> To: Romascanu, Dan (Dan)
> |> |>> Cc: pcn@ietf.org
> |> |>> Subject: RE: [PCN] charter, addition to scope
> |> |>>
> |> |>> Hi Dan,
> |> |>>
> |> |>> your proposal seems sound to me. My impression is the
> |> |discussion may
> |> |>> have approached consensus on the following issues to get
> |chartered
> |> |>> initially:
> |> |>>
> |> |>> - PCN is limited to a single DiffServ domain.
> |> |>> - PCN aware nodes must be "on path".
> |> |>> - PCN only standardises PCN related IP layer
> |> |>>   functionalities including RSVP or NSIS signaling
> |> |>>   between edge nodes.
> |> |>> - PCN only works on "network admission control".
> |> |>>
> |> |>> If "Edge node" requires further definition to exclude
> |> |things to close
> |> |
> |> |>> to an "end system", we should add it at appropriate places.
> |> |>> "PCN related" would exclude dealing with middleboxes
> |doing anything
> |> |>> else with packets than PCN DiffServ forwarding.
> |> |>>
> |> |>> Another question is, what the reaction of an ingress edge
> |> |node should
> |> |
> |> |>> be in case of an indicated network congestion. My
> |> |impression is, that
> |> |
> |> |>> with the initial charter we should just define a desired
> |> |behaviour in
> |> |
> |> |>> terms of an aggregate traffic reduction (e.g. "stop
> |admission new
> |> |>> flows demanding CL forwarding or bandwidth increases
> of admitted
> |> |>> ones" or "reduce CL traffic by x percent").
> |> |>> Future work items may be added when the WG is
> re-chartered after
> |> |>> having reached first aims. It may indeed be useful to
> |think about
> |> |>> some requirements for future PCN use already now. As I
> |didn't think
> |> |>> about particular topics in detail, I don't try to
> |summarise which
> |> |>> requirements that could be by this mail.
> |> |>>
> |> |>> Regards,
> |> |>>
> |> |>> Ruediger
> |> |>>
> |> |>>
> |> |>> |-----Original Message-----
> |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> |> |>> |Sent: Thursday, February 01, 2007 9:45 AM
> |> |>> |To: Lee, Richard FTC; Black_David@emc.com;
> |karagian@cs.utwente.nl
> |> |>> |Cc: pcn@ietf.org
> |> |>> |Subject: RE: [PCN] charter, addition to scope
> |> |>> |
> |> |>> |
> |> |>> |Maybe we should stop for a moment and consider what layer
> |> |should PCN
> |> |
> |> |>> |deal with. It looks to me that we are mixing network admission
> |> |>> |control and call admission control in this discussion.
> |> |This problem
> |> |>> |is quite complex, and there are many scenarios that need
> |> |to be taken
> |> |
> |> |>> |into consideration. Sometimes flow = call, sometimes call
> |> |=NOT flow
> |> |>> |and sometimes there is a mix on the same path. In some
> |cases media
> |> |>> |gateways
> |> |>>
> |> |>> |are collocated with the edge nodes in some other cases
> |not. Even
> |> |>> |when flow = call there are two admission control layers
> |> |(network and
> |> |
> |> |>> |call) that are in dependency but not identical and separate
> |> |>> |protocols run at transport and session. I am not sure
> |how much of
> |> |>> |all this falls under what PCN should do.
> |> |>> |
> |> |>> |Dan
> |> |>> |
> |> |>> |
> |> |>> |
> |> |>> |
> |> |>> | | |
> |> |>> |> -----Original Message-----
> |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM]
> |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM
> |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl
> |> |>> |> Cc: pcn@ietf.org
> |> |>> |> Subject: RE: [PCN] charter, addition to scope
> |> |>> |> |> To all,
> |> |>> |> I agree that there must be a prioritization of flows
> |from the |>
> |> |>> aggregation devices However, it's not just the media
> |> |gateway that |>
> |> |>> should speak RSVP, but the edge proxy (or firewall "proxy")
> |> |as well -
> |> |>>
> |> |>> |> it is the signaling proxy at the edge that reserves
> the media
> |> |>> |> path. |>
> |> |>> The reservation protocol request to the network from
> the VoIP |>
> |> |>> proxy/gateway must reserve resources to the destination
> |in the |>
> |> |>> network.
> |> |>> |> The resource reservation request to the network by
> the edge |>
> |> |>> proxy/media gateway, must at the very minimum, meet the
> |following |>
> |> |>> conditions:
> |> |>> |> 1. it needs to specify the resources required for the
> |IP & ports
> |> |>> |> |>
> |> |>> (RTP/RTCP & bandwidth)
> |> |>> |>    for example, G.711 and G.729 voice and various
> |MPEG-4 video
> |> |>> |> codecs
> |> |>>
> |> |>> |> all have very different requirements 2. it must be
> |mapped to the
> |> |>> |> |>
> |> |>> signaling request
> |> |>> |>    for SIP, it must map the SDP for media with the
> |reservation
> |> |>> |> flow -
> |> |>>
> |> |>> |> for example something along the lines of RFC 3524
> |> |>> |>    while not the answer, the mapping of the media
> |flows is a |>
> |> |>> necessary component
> |> |>> |>    It should be noted that the edge proxies/media
> |gateways may
> |> |>> |> have a
> |> |>>
> |> |>> |> large number of flows (and ports for each
> |> |>> |>    RTP/RTCP flow) from the same source IP. The request
> |> |is made for
> |> |
> |> |>> |> |>
> |> |>> each flow or conversation 3. it must be honored by the
> |edge network
> |> |>> |> device.
> |> |>> |>    The trust boundary must be extended to the edge
> |proxy/media |>
> |> |>> gateway for each new flow.
> |> |>> |>    This brings up the issue of security authentication
> |> |of the edge
> |> |
> |> |>> |> |>
> |> |>> proxy/media gateway to the network
> |> |>> |> Does this happen in EAP, NAC, or just
> interoperability and |>
> |> |>> certification among vendors
> |> |>> |>    If the resources are not available, then the signaling
> |> |>> |> indicates |>
> |> |>> the session is not completed. For example a SIP
> |> |>> |>    CANCEL from the edge proxy
> |> |>> |> |> In addition, the network device must have
> priority queuing
> |> |>> |> |> enabled
> |> |>> |> for input queues from the edge device.
> |> |>> |> The media flows must not be subject to input buffers
> |> |being filled
> |> |>> |> |>
> |> |>> prior to classification
> |> |>> |> |> Thanks,
> |> |>> |> Richard Lee
> |> |>> |> Fidelity Investments
> |> |>> |> Enterprise Technology and Architecture
> |> |>> |> 617-563-3278
> |> |>> |> |> |> -----Original Message-----
> |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com]
> |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM
> |> |>> |> To: karagian@cs.utwente.nl
> |> |>> |> Cc: pcn@ietf.org
> |> |>> |> Subject: RE: [PCN] charter, addition to scope
> |> |>> |> |> |> Georgios wrote:
> |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
> |> |>> |> > > > In the first phase of PCN work to reduce the list of
> |> |>> |> issues it was
> |> |>> |> |> > > > proposed that the WG focus on network
> |> |deployment scenario
> |> |>> where
> |> |>> |> all
> |> |>> |> > > > nodes can be trusted and delay work on deployment
> |> |>> |> scenarios where
> |> |>> |> some
> |> |>> |> > > > of the nodes are not trusted.
> |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers,
> |then yes, I
> |> |>> agree. If
> |> |>> |> "nodes" |> > > include end systems, proxies or other
> |entities,
> |> |>> |> then I
> |> |>> don't |> > > agree we had agreement on that.
> |> |>> |> > |> > Georgios: This imposes an additional
> |restriction on the
> |> |>> |> > |> > scope
> |> |>> of |> > the charter, which has been not discussed yet.
> |> |>> |> > >From what I remember before, during and after the PCN BOF
> |> |>> |> > there was no objection on using the term edge node,
> |that could
> |> |>> |> > mean something different than a edge
> |> |>> |> router.
> |> |>> |> > Please note that this is something different than a
> |> |>> |scenario covered
> |> |>> |> by
> |> |>> |> > an application based deployment model.
> |> |>> |> |> It's certainly not a new restriction based on the
> |> |discussion in
> |> |
> |> |>> |> |> the
> |> |>> |> BOF engendered about whether a SIP telephone (used on
> |some of the
> |> |>> |> slides) was a good example.  I believe the BOF
> |> |conclusion was that
> |> |
> |> |>> |> a SIP telephone was a bad example.
> |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the
> |> |>> |proposed work:
> |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-)
> |The first set
> |> |>> |> of issues  has already been discussed extensively - my
> |> |>> |> understanding is that the SIP scenario is currently out
> |> |of scope,
> |> |>> |> and
> |> |>>
> |> |>> |> I don't care to reopen that discussion.
> |> |>> |> |> The "telephone" issues come up in two ways:
> |> |>> |> (2a) Small number of flows may make relatively fine-grained
> |> |>> |adjustment
> |> |>> |> on the link to the phone impossible.  The PCN work
> |prior to the
> |> |>> |> BOF relied on the ability to make such adjustments.
> |> |>> |> (2b) While other sorts of phones may be trusted, a SIP phone
> |> |>> |> (which may be software-only) is definitely not trustable in
> |> |general.
> |> |>> |> |> I would observe that Lars Westerberg's suggestion
> |of a Media
> |> |>> Gateway:
> |> |>> |> |> > I am referring telecom scenario where MGWs are
> |connected to
> |> |>> |> |> > an
> |> |>> |> IP-backbone.
> |> |>> |> > In these scenarios, the admission control function is
> |> |a part of
> |> |>> |> > the
> |> |>> |> MGW
> |> |>> |> > and not the routers. The IP-backbone is provisioned by
> |> |a network
> |> |
> |> |>> |> > |>
> |> |>>  > management system.
> |> |>> |> |> could avoid all of these issues:
> |> |>> |> (1) The media gateway could speak RSVP to the network
> |management
> |> |>> |> |>
> |> |>> system,
> |> |>> |> avoiding any need to deal with SIP here.
> |> |>> |> (2a) A media gateway is likely to handle enough flows to be
> |> |>> |consistent
> |> |>> |> with the fine-grained adjustment assumed by the work done to
> |> |>> date.
> |> |>> |> (2b) One can plausibly assume/require that media gateways be
> |> |>> |> trusted with respect to the IP network.
> |> |>> |> To the extent that one can vest "edge" functionality in
> |> |a trusted
> |> |>> |> |>
> |> |>> media gateway, I see no reason to exclude that scenario.
> |> |>> |> |> Thanks,
> |> |>> |> --David
> |> |>> |> ----------------------------------------------------
> |> |>> |> David L. Black, Senior Technologist EMC Corporation,
> |176 South
> |> |>> |> St., Hopkinton, MA  01748
> |> |>> |> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> |> |>> |> black_david@emc.com        Mobile: +1 (978) 394-7754
> |> |>> |> ----------------------------------------------------
> |> |>> |> |> _______________________________________________
> |> |>> |> 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
> |> |
> |> |
> |> |
> |>
> |>
> |> _______________________________________________
> |> 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
>



_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn

--------------020105010904050001010106-- --===============0587413657== 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 --===============0587413657==-- From pcn-bounces@ietf.org Fri Feb 09 02:58:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFQdt-0001Fv-M7; Fri, 09 Feb 2007 02:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFQds-0001Fq-RL for pcn@ietf.org; Fri, 09 Feb 2007 02:58:00 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFQdp-0005vH-H9 for pcn@ietf.org; Fri, 09 Feb 2007 02:58:00 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 9 Feb 2007 08:57:51 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 08:57:51 +0100 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: RE: [PCN] "Network Admission Control" (NAC) Date: Fri, 9 Feb 2007 08:57:50 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB24@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdJyXnmU+3K4rG0RROL42854Ty6AgB0YAwwACEYsAA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 09 Feb 2007 07:57:51.0372 (UTC) FILETIME=[FF446CC0:01C74C1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cb592aae7f4601895f35714165597859 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, I'd appreciate that. I think that a fair part of the=20 discussions on different threads we had on this list was related to architecture and requirements, not=20 just to the charter. Regards, Ruediger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Thursday, February 08, 2007 5:08 PM |To: Tina TSOU; brodrig@avaya.com; Geib, R=FCdiger |Cc: pcn@ietf.org |Subject: RE: [PCN] "Network Admission Control" (NAC) | | |Hi, | |Just a thought that there will be a number of terminology=20 |issues to address once the WG is formed. I wonder if this=20 |discussion can become part of the work on the terminology that=20 |would eventually find its way into (I think) the architecture draft? | |Anna=20 | | |> -----Original Message----- |> From: Tina TSOU [mailto:tena@huawei.com]=20 |> Sent: Tuesday, February 06, 2007 3:32 AM |> To: brodrig@avaya.com; Geib, Ruediger |> Cc: pcn@ietf.org |> Subject: Re: [PCN] "Network Admission Control" (NAC) |>=20 |> Hi Ruediger, |> Do we also consider Network Access Control in PCN? |>=20 |> B. R. |> Tina |> ----- Original Message ----- |> From: "Geib, Ruediger" |> To: |> Cc: |> Sent: Tuesday, February 06, 2007 4:18 PM |> Subject: RE: [PCN] "Network Admission Control" (NAC) |>=20 |>=20 |> Benny, |>=20 |> I prefer Michaels proposal, NAC or DAC is allright with me if we |> provide a definition for our terminology. The same would hold |> if "flow admission" is used, which I feel to be to close to |> "per flow". |>=20 |> A side note on the abbreviation NAC: it is also described as |> Network Access Control by Wikipedia. I've checked that because |> within my company what is described by Wiki as Network |> "Admission Control" is called Network Access Control. |>=20 |> Regards, |>=20 |> Ruediger |>=20 |> |-----Original Message----- |> |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |> |Sent: Monday, February 05, 2007 8:37 PM |> |To: Rodrig, Benny (Benny) |> |Cc: Geib, R=FCdiger; pcn@ietf.org |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> | |> | |> |Hi, |> | |> |the word NAC itself means that access is possibly denied to=20 |a network |> |which can be due to security or resource reasons. NAC in=20 |the security |> |context has become a quite popular expression as it is the name of a |> |Cisco product. The name NAC sounds good (to me) as it is=20 |> very catchy and |> |easy to understand also for non-experts. I don't see a large problem |> |when the term NAC exists in different contexts. If people need to |> |distinguish both approaches, security-related NAC and=20 |> resource-related |> |NAC can be used. However, people working in both areas=20 |might see this |> |differently. |> | |> |As the new version of the PCN charter talks about domains, domain |> |admission control (DAC) would be a natural substitute for=20 |> NAC. DAC has |> |no misleading connotations, but it doesn't sound nice (to=20 |me). Better |> |sounds maybe per-domain AC (PDAC) and concisely states what=20 |it is. In |> |analogy to routing, intradomain admission control is another=20 |> option, but |> |it also implies the existence of interdomain admission=20 |> control. I'm not |> |sure whether we want this right now. |> | |> |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN |> |charter, we can leave this issue open until we have a=20 |> clearer opinion. |> | |> | Michael |> | |> |Rodrig, Benny (Benny) wrote: |> |> Ruediger, |> |> |> |> To me the charter doesn't seem to imply the expansion of=20 |scope that |> |> you're concerned about. Unlike many other terms "flow=20 |> admission" doesn't |> |> seem to have misleading connotations. But I could be ok=20 |> with "network |> |> flow admission". |> |> |> |> If it is important that the charter be more explicit about=20 |> this point, |> |> then perhaps a sentence should be added with some explicit=20 |> description |> |> e.g. that the flow admission behavior at the boundary=20 |> includes policing |> |> and/or interaction with per-flow mechanisms that are out=20 |> of scope of |> |> PCN. |> |> |> |> Benny |> |> |> |> |> |> -----Original Message----- |> |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> |> Sent: Monday, February 05, 2007 3:01 AM |> |> To: Rodrig, Benny (Benny) |> |> Cc: pcn@ietf.org |> |> Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> |> |> I'm not sure whether "flow admission" is the correct description. |> |> Wouldn' or couldn't that mean that PCN includes work on=20 |> the per flow |> |> admission control functionality. PCN then is chartered to work on |> |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with |> |Network- or |> |> Aggregate- or Per Domain Behaviour- Admission Control, then the |> |> chartered PCN work could be limited to provide an=20 |> interface (API?) to |> |> the per flow signaling protocol. Isn't the latter=20 |> sufficient for the |> |> initial charter? |> |> |> |> Regards, |> |> |> |> Ruediger |> |> |> |> |-----Original Message----- |> |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |> |> |Sent: Friday, February 02, 2007 5:09 PM |> |> |To: Moore, Sean (Sean); Tina TSOU; |> |menth@informatik.uni-wuerzburg.de; |> |> |Geib, Rudiger |> |> |Cc: pcn@ietf.org |> |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> | |> |> | |> |> |I think the 'flow admission' wording in the charter is=20 |fine and we |> |> |don't need to choose a more precise term. The charter text |> |explaining |> |> |that this flow admission happens at the domain boundary in |> |reaction to |> |> |pre-congestion info from within the domain, etc. seems to |> |describe it |> |> |sufficiently. |> |> | |> |> |Benny |> |> | |> |> |-----Original Message----- |> |> |From: Moore, Sean (Sean) |> |> |Sent: Friday, February 02, 2007 9:59 AM |> |> |To: Tina TSOU; Rodrig, Benny (Benny); |> |menth@informatik.uni-wuerzburg.de |> |> |Cc: pcn@ietf.org; Geib, Ruediger |> |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> | |> |> |Probably shouldn't use "Resource Admission Control" as this |> |term (RAC) |> |> |is used in IMS and it is not the same as what we are discussing |> |> |- Sean |> |> | |> |> |-----Original Message----- |> |> |From: Tina TSOU [mailto:tena@huawei.com] |> |> |Sent: Friday, February 02, 2007 9:25 AM |> |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |> |> |Cc: pcn@ietf.org; Geib, Ruediger |> |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> |> | |> |> |Hi, |> |> |How about Resource Admission Control or Network Resource=20 |Admission |> |> |Control? |> |> |I don't have strong opinion on that, just some terms=20 |> popped up in my |> |> |mind:) |> |> | |> |> |B. R. |> |> |Tina |> |> | |> |> |----- Original Message ----- |> |> |From: "Michael Menth" |> |> |To: "Rodrig, Benny (Benny)" |> |> |Cc: ; "Geib, Ruediger"=20 | |> |> |Sent: Friday, February 02, 2007 12:16 PM |> |> |Subject: [PCN] "Network Admission Control" (NAC) |> |> | |> |> | |> |> |> Hi, |> |> |> |> |> |> I've got a comment on the term "Network Admission=20 |> Control" (NAC). |> |> |> |> |> |> Wikipedia |> |> |http://en.wikipedia.org/wiki/Network_Admission_Control only |> |> |> knows NAC in the context of restricting access to the |> |> |network based on |> |> | |> |> |> identity or security posture (it's essentially a Cisco=20 |product). |> |> |> However, most important is the aspect that access is denied |> |> |to a whole |> |> | |> |> |> network, subnetwork, domain, region, etc. NAC is in |> |contrast to AC |> |> |> algorithms deciding whether a new flow can be admitted to be |> |> |> transported over a single link which has been studied in |> |> |depth in the |> |> |> 1990s in the context of ATM systems. Three years ago, I have |> |> |reviewed |> |> |> and studied different approaches for NAC (based on resource |> |> |management |> |> |issues) in my PhD thesis: |> |> |> |> |> |> ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p |df/Menth04 |> |> |> .pdf The terms connection or flow admission control are less |> |> |specific |> |> |> than NAC as they do not tell the scope of the AC. |> |> |> |> |> |> Best regards, |> |> |> |> |> |> Michael |> |> |> |> |> |> Rodrig, Benny (Benny) wrote: |> |> |>> What I think you mean, and the admission control that PCN |> |> |deals with, |> |> | |> |> |>> better not be described as "network admission control" |> |since that |> |> |>> term often (e.g. see |> |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |> |> |>> refers to admission based on the identity of the sender, |> |which is |> |> |>> probably out of scope for PCN. The flow admission=20 |> control in PCN |> |> |>> scope is based on considerations related to network=20 |status i.e. |> |> |>> pre-congestion. |> |> |>> The PCN flow admission control can be part of a call admission |> |> |>> control solution, if it interacts with other mechanisms |> |such as for |> |> |>> example with Int-Serv outside the PCN domain and/or=20 |> with SIP QoS |> |> |>> pre-conditions. Such interactions, or assumptions about |> |> |them, may not |> |> |be in the scope of PCN. |> |> |>> |> |> |>> |> |> |>> Benny |> |> |>> -----Original Message----- |> |> |>> From: Geib, Ruediger=20 |[mailto:Ruediger.Geib@t-systems.com] Sent: |> |> |>> Thursday, February 01, 2007 4:44 AM |> |> |>> To: Romascanu, Dan (Dan) |> |> |>> Cc: pcn@ietf.org |> |> |>> Subject: RE: [PCN] charter, addition to scope |> |> |>> |> |> |>> Hi Dan, |> |> |>> |> |> |>> your proposal seems sound to me. My impression is the |> |> |discussion may |> |> |>> have approached consensus on the following issues to get |> |chartered |> |> |>> initially: |> |> |>> |> |> |>> - PCN is limited to a single DiffServ domain. |> |> |>> - PCN aware nodes must be "on path". |> |> |>> - PCN only standardises PCN related IP layer |> |> |>> functionalities including RSVP or NSIS signaling |> |> |>> between edge nodes. |> |> |>> - PCN only works on "network admission control". |> |> |>> |> |> |>> If "Edge node" requires further definition to exclude |> |> |things to close |> |> | |> |> |>> to an "end system", we should add it at appropriate places. |> |> |>> "PCN related" would exclude dealing with middleboxes |> |doing anything |> |> |>> else with packets than PCN DiffServ forwarding. |> |> |>> |> |> |>> Another question is, what the reaction of an ingress edge |> |> |node should |> |> | |> |> |>> be in case of an indicated network congestion. My |> |> |impression is, that |> |> | |> |> |>> with the initial charter we should just define a desired |> |> |behaviour in |> |> | |> |> |>> terms of an aggregate traffic reduction (e.g. "stop |> |admission new |> |> |>> flows demanding CL forwarding or bandwidth increases=20 |> of admitted |> |> |>> ones" or "reduce CL traffic by x percent"). |> |> |>> Future work items may be added when the WG is=20 |> re-chartered after |> |> |>> having reached first aims. It may indeed be useful to |> |think about |> |> |>> some requirements for future PCN use already now. As I |> |didn't think |> |> |>> about particular topics in detail, I don't try to |> |summarise which |> |> |>> requirements that could be by this mail. |> |> |>> |> |> |>> Regards, |> |> |>> |> |> |>> Ruediger |> |> |>> |> |> |>> |> |> |>> |-----Original Message----- |> |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |> |> |>> |Sent: Thursday, February 01, 2007 9:45 AM |> |> |>> |To: Lee, Richard FTC; Black_David@emc.com; |> |karagian@cs.utwente.nl |> |> |>> |Cc: pcn@ietf.org |> |> |>> |Subject: RE: [PCN] charter, addition to scope |> |> |>> | |> |> |>> | |> |> |>> |Maybe we should stop for a moment and consider what layer |> |> |should PCN |> |> | |> |> |>> |deal with. It looks to me that we are mixing network=20 |admission |> |> |>> |control and call admission control in this discussion. |> |> |This problem |> |> |>> |is quite complex, and there are many scenarios that need |> |> |to be taken |> |> | |> |> |>> |into consideration. Sometimes flow =3D call, sometimes call |> |> |=3DNOT flow |> |> |>> |and sometimes there is a mix on the same path. In some |> |cases media |> |> |>> |gateways |> |> |>> |> |> |>> |are collocated with the edge nodes in some other cases |> |not. Even |> |> |>> |when flow =3D call there are two admission control layers |> |> |(network and |> |> | |> |> |>> |call) that are in dependency but not identical and separate |> |> |>> |protocols run at transport and session. I am not sure |> |how much of |> |> |>> |all this falls under what PCN should do. |> |> |>> | |> |> |>> |Dan |> |> |>> | |> |> |>> | |> |> |>> | |> |> |>> | |> |> |>> | | | |> |> |>> |> -----Original Message----- |> |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |> |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |> |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |> |> |>> |> Cc: pcn@ietf.org |> |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |> |>> |> |> To all, |> |> |>> |> I agree that there must be a prioritization of flows |> |from the |> |> |> |>> aggregation devices However, it's not just the media |> |> |gateway that |> |> |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") |> |> |as well - |> |> |>> |> |> |>> |> it is the signaling proxy at the edge that reserves=20 |> the media |> |> |>> |> path. |> |> |> |>> The reservation protocol request to the network from=20 |> the VoIP |> |> |> |>> proxy/gateway must reserve resources to the destination |> |in the |> |> |> |>> network. |> |> |>> |> The resource reservation request to the network by=20 |> the edge |> |> |> |>> proxy/media gateway, must at the very minimum, meet the |> |following |> |> |> |>> conditions: |> |> |>> |> 1. it needs to specify the resources required for the |> |IP & ports |> |> |>> |> |> |> |> |>> (RTP/RTCP & bandwidth) |> |> |>> |> for example, G.711 and G.729 voice and various |> |MPEG-4 video |> |> |>> |> codecs |> |> |>> |> |> |>> |> all have very different requirements 2. it must be |> |mapped to the |> |> |>> |> |> |> |> |>> signaling request |> |> |>> |> for SIP, it must map the SDP for media with the |> |reservation |> |> |>> |> flow - |> |> |>> |> |> |>> |> for example something along the lines of RFC 3524 |> |> |>> |> while not the answer, the mapping of the media |> |flows is a |> |> |> |>> necessary component |> |> |>> |> It should be noted that the edge proxies/media |> |gateways may |> |> |>> |> have a |> |> |>> |> |> |>> |> large number of flows (and ports for each |> |> |>> |> RTP/RTCP flow) from the same source IP. The request |> |> |is made for |> |> | |> |> |>> |> |> |> |> |>> each flow or conversation 3. it must be honored by the |> |edge network |> |> |>> |> device. |> |> |>> |> The trust boundary must be extended to the edge |> |proxy/media |> |> |> |>> gateway for each new flow. |> |> |>> |> This brings up the issue of security authentication |> |> |of the edge |> |> | |> |> |>> |> |> |> |> |>> proxy/media gateway to the network |> |> |>> |> Does this happen in EAP, NAC, or just=20 |> interoperability and |> |> |> |>> certification among vendors |> |> |>> |> If the resources are not available, then the signaling |> |> |>> |> indicates |> |> |> |>> the session is not completed. For example a SIP |> |> |>> |> CANCEL from the edge proxy |> |> |>> |> |> In addition, the network device must have=20 |> priority queuing |> |> |>> |> |> enabled |> |> |>> |> for input queues from the edge device. |> |> |>> |> The media flows must not be subject to input buffers |> |> |being filled |> |> |>> |> |> |> |> |>> prior to classification |> |> |>> |> |> Thanks, |> |> |>> |> Richard Lee |> |> |>> |> Fidelity Investments |> |> |>> |> Enterprise Technology and Architecture |> |> |>> |> 617-563-3278 |> |> |>> |> |> |> -----Original Message----- |> |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |> |> |>> |> To: karagian@cs.utwente.nl |> |> |>> |> Cc: pcn@ietf.org |> |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |> |>> |> |> |> Georgios wrote: |> |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> |> |>> |> > > > In the first phase of PCN work to reduce the list of |> |> |>> |> issues it was |> |> |>> |> |> > > > proposed that the WG focus on network |> |> |deployment scenario |> |> |>> where |> |> |>> |> all |> |> |>> |> > > > nodes can be trusted and delay work on deployment |> |> |>> |> scenarios where |> |> |>> |> some |> |> |>> |> > > > of the nodes are not trusted. |> |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, |> |then yes, I |> |> |>> agree. If |> |> |>> |> "nodes" |> > > include end systems, proxies or other |> |entities, |> |> |>> |> then I |> |> |>> don't |> > > agree we had agreement on that. |> |> |>> |> > |> > Georgios: This imposes an additional |> |restriction on the |> |> |>> |> > |> > scope |> |> |>> of |> > the charter, which has been not discussed yet. |> |> |>> |> > >From what I remember before, during and after=20 |the PCN BOF |> |> |>> |> > there was no objection on using the term edge node, |> |that could |> |> |>> |> > mean something different than a edge |> |> |>> |> router. |> |> |>> |> > Please note that this is something different than a |> |> |>> |scenario covered |> |> |>> |> by |> |> |>> |> > an application based deployment model. |> |> |>> |> |> It's certainly not a new restriction based on the |> |> |discussion in |> |> | |> |> |>> |> |> the |> |> |>> |> BOF engendered about whether a SIP telephone (used on |> |some of the |> |> |>> |> slides) was a good example. I believe the BOF |> |> |conclusion was that |> |> | |> |> |>> |> a SIP telephone was a bad example. |> |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |> |> |>> |proposed work: |> |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) |> |The first set |> |> |>> |> of issues has already been discussed extensively - my |> |> |>> |> understanding is that the SIP scenario is currently out |> |> |of scope, |> |> |>> |> and |> |> |>> |> |> |>> |> I don't care to reopen that discussion. |> |> |>> |> |> The "telephone" issues come up in two ways: |> |> |>> |> (2a) Small number of flows may make relatively fine-grained |> |> |>> |adjustment |> |> |>> |> on the link to the phone impossible. The PCN work |> |prior to the |> |> |>> |> BOF relied on the ability to make such adjustments. |> |> |>> |> (2b) While other sorts of phones may be trusted, a=20 |SIP phone |> |> |>> |> (which may be software-only) is definitely not trustable in |> |> |general. |> |> |>> |> |> I would observe that Lars Westerberg's suggestion |> |of a Media |> |> |>> Gateway: |> |> |>> |> |> > I am referring telecom scenario where MGWs are |> |connected to |> |> |>> |> |> > an |> |> |>> |> IP-backbone. |> |> |>> |> > In these scenarios, the admission control function is |> |> |a part of |> |> |>> |> > the |> |> |>> |> MGW |> |> |>> |> > and not the routers. The IP-backbone is provisioned by |> |> |a network |> |> | |> |> |>> |> > |> |> |> |>> > management system. |> |> |>> |> |> could avoid all of these issues: |> |> |>> |> (1) The media gateway could speak RSVP to the network |> |management |> |> |>> |> |> |> |> |>> system, |> |> |>> |> avoiding any need to deal with SIP here. |> |> |>> |> (2a) A media gateway is likely to handle enough flows to be |> |> |>> |consistent |> |> |>> |> with the fine-grained adjustment assumed by the=20 |work done to |> |> |>> date. |> |> |>> |> (2b) One can plausibly assume/require that media=20 |gateways be |> |> |>> |> trusted with respect to the IP network. |> |> |>> |> To the extent that one can vest "edge" functionality in |> |> |a trusted |> |> |>> |> |> |> |> |>> media gateway, I see no reason to exclude that scenario. |> |> |>> |> |> Thanks, |> |> |>> |> --David |> |> |>> |> ---------------------------------------------------- |> |> |>> |> David L. Black, Senior Technologist EMC Corporation, |> |176 South |> |> |>> |> St., Hopkinton, MA 01748 |> |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |> |> |>> |> ---------------------------------------------------- |> |> |>> |> |> _______________________________________________ |> |> |>> |> 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 |> |> | |> |> | |> |> | |> |> |> |> |> |> _______________________________________________ |> |> 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 |> | |> | |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn=20 |>=20 |>=20 |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=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 Fri Feb 09 04:05:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFRgt-0000PO-TX; Fri, 09 Feb 2007 04:05:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFRgt-0000PB-2A for pcn@ietf.org; Fri, 09 Feb 2007 04:05:11 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFRgo-00029d-VA for pcn@ietf.org; Fri, 09 Feb 2007 04:05:11 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l19948D0026597; Fri, 9 Feb 2007 10:04:12 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" References: <009901c749c9$4c88b3f0$9c28460a@china.huawei.com> Subject: RE: [PCN] "Network Admission Control" (NAC) Date: Fri, 9 Feb 2007 10:04:27 +0100 Message-ID: <000b01c74c29$4fe471d0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdJyXnmU+3K4rG0RROL42854Ty6AgB0YAwwACOICgA= X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 09 Feb 2007 10:04:14 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 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 I agree with you! This discussion should become=20 part of the work on terminology. Best Regards, Georgios =20 > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 > Sent: donderdag 8 februari 2007 17:08 > To: Tina TSOU; brodrig@avaya.com; Geib, Ruediger > Cc: pcn@ietf.org > Subject: RE: [PCN] "Network Admission Control" (NAC) >=20 > Hi, >=20 > Just a thought that there will be a number of terminology=20 > issues to address once the WG is formed. I wonder if this=20 > discussion can become part of the work on the terminology=20 > that would eventually find its way into (I think) the=20 > architecture draft? >=20 > Anna=20 >=20 >=20 > > -----Original Message----- > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: Tuesday, February 06, 2007 3:32 AM > > To: brodrig@avaya.com; Geib, Ruediger > > Cc: pcn@ietf.org > > Subject: Re: [PCN] "Network Admission Control" (NAC) > >=20 > > Hi Ruediger, > > Do we also consider Network Access Control in PCN? > >=20 > > B. R. > > Tina > > ----- Original Message ----- > > From: "Geib, Ruediger" > > To: > > Cc: > > Sent: Tuesday, February 06, 2007 4:18 PM > > Subject: RE: [PCN] "Network Admission Control" (NAC) > >=20 > >=20 > > Benny, > >=20 > > I prefer Michaels proposal, NAC or DAC is allright with me if we=20 > > provide a definition for our terminology. The same would=20 > hold if "flow=20 > > admission" is used, which I feel to be to close to "per flow". > >=20 > > A side note on the abbreviation NAC: it is also described=20 > as Network=20 > > Access Control by Wikipedia. I've checked that because within my=20 > > company what is described by Wiki as Network "Admission Control" is=20 > > called Network Access Control. > >=20 > > Regards, > >=20 > > Ruediger > >=20 > > |-----Original Message----- > > |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > |Sent: Monday, February 05, 2007 8:37 PM > > |To: Rodrig, Benny (Benny) > > |Cc: Geib, R=FCdiger; pcn@ietf.org > > |Subject: Re: [PCN] "Network Admission Control" (NAC) > > | > > | > > |Hi, > > | > > |the word NAC itself means that access is possibly denied=20 > to a network=20 > > |which can be due to security or resource reasons. NAC in=20 > the security=20 > > |context has become a quite popular expression as it is the=20 > name of a=20 > > |Cisco product. The name NAC sounds good (to me) as it is > > very catchy and > > |easy to understand also for non-experts. I don't see a=20 > large problem=20 > > |when the term NAC exists in different contexts. If people need to=20 > > |distinguish both approaches, security-related NAC and > > resource-related > > |NAC can be used. However, people working in both areas=20 > might see this=20 > > |differently. > > | > > |As the new version of the PCN charter talks about domains, domain=20 > > |admission control (DAC) would be a natural substitute for > > NAC. DAC has > > |no misleading connotations, but it doesn't sound nice (to=20 > me). Better=20 > > |sounds maybe per-domain AC (PDAC) and concisely states=20 > what it is. In=20 > > |analogy to routing, intradomain admission control is another > > option, but > > |it also implies the existence of interdomain admission > > control. I'm not > > |sure whether we want this right now. > > | > > |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN=20 > > |charter, we can leave this issue open until we have a > > clearer opinion. > > | > > | Michael > > | > > |Rodrig, Benny (Benny) wrote: > > |> Ruediger, > > |> > > |> To me the charter doesn't seem to imply the expansion of=20 > scope that=20 > > |> you're concerned about. Unlike many other terms "flow > > admission" doesn't > > |> seem to have misleading connotations. But I could be ok > > with "network > > |> flow admission". > > |> > > |> If it is important that the charter be more explicit about > > this point, > > |> then perhaps a sentence should be added with some explicit > > description > > |> e.g. that the flow admission behavior at the boundary > > includes policing > > |> and/or interaction with per-flow mechanisms that are out > > of scope of > > |> PCN. > > |> > > |> Benny > > |> > > |> > > |> -----Original Message----- > > |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > |> Sent: Monday, February 05, 2007 3:01 AM > > |> To: Rodrig, Benny (Benny) > > |> Cc: pcn@ietf.org > > |> Subject: RE: [PCN] "Network Admission Control" (NAC) > > |> > > |> I'm not sure whether "flow admission" is the correct description. > > |> Wouldn' or couldn't that mean that PCN includes work on > > the per flow > > |> admission control functionality. PCN then is chartered to work on > > |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with > > |Network- or > > |> Aggregate- or Per Domain Behaviour- Admission Control, then the=20 > > |> chartered PCN work could be limited to provide an > > interface (API?) to > > |> the per flow signaling protocol. Isn't the latter > > sufficient for the > > |> initial charter? > > |> > > |> Regards, > > |> > > |> Ruediger > > |> > > |> |-----Original Message----- > > |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > |> |Sent: Friday, February 02, 2007 5:09 PM > > |> |To: Moore, Sean (Sean); Tina TSOU; > > |menth@informatik.uni-wuerzburg.de; > > |> |Geib, Rudiger > > |> |Cc: pcn@ietf.org > > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > > |> | > > |> | > > |> |I think the 'flow admission' wording in the charter is=20 > fine and we=20 > > |> |don't need to choose a more precise term. The charter text > > |explaining > > |> |that this flow admission happens at the domain boundary in > > |reaction to > > |> |pre-congestion info from within the domain, etc. seems to > > |describe it > > |> |sufficiently. > > |> | > > |> |Benny > > |> | > > |> |-----Original Message----- > > |> |From: Moore, Sean (Sean) > > |> |Sent: Friday, February 02, 2007 9:59 AM > > |> |To: Tina TSOU; Rodrig, Benny (Benny); > > |menth@informatik.uni-wuerzburg.de > > |> |Cc: pcn@ietf.org; Geib, Ruediger > > |> |Subject: RE: [PCN] "Network Admission Control" (NAC) > > |> | > > |> |Probably shouldn't use "Resource Admission Control" as this > > |term (RAC) > > |> |is used in IMS and it is not the same as what we are discussing > > |> |- Sean > > |> | > > |> |-----Original Message----- > > |> |From: Tina TSOU [mailto:tena@huawei.com] > > |> |Sent: Friday, February 02, 2007 9:25 AM > > |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de > > |> |Cc: pcn@ietf.org; Geib, Ruediger > > |> |Subject: Re: [PCN] "Network Admission Control" (NAC) > > |> | > > |> |Hi, > > |> |How about Resource Admission Control or Network=20 > Resource Admission=20 > > |> |Control? > > |> |I don't have strong opinion on that, just some terms > > popped up in my > > |> |mind:) > > |> | > > |> |B. R. > > |> |Tina > > |> | > > |> |----- Original Message ----- > > |> |From: "Michael Menth" > > |> |To: "Rodrig, Benny (Benny)" > > |> |Cc: ; "Geib, Ruediger"=20 > > > |> |Sent: Friday, February 02, 2007 12:16 PM > > |> |Subject: [PCN] "Network Admission Control" (NAC) > > |> | > > |> | > > |> |> Hi, > > |> |> > > |> |> I've got a comment on the term "Network Admission > > Control" (NAC). > > |> |> > > |> |> Wikipedia > > |> |http://en.wikipedia.org/wiki/Network_Admission_Control only > > |> |> knows NAC in the context of restricting access to the > > |> |network based on > > |> | > > |> |> identity or security posture (it's essentially a=20 > Cisco product). > > |> |> However, most important is the aspect that access is denied > > |> |to a whole > > |> | > > |> |> network, subnetwork, domain, region, etc. NAC is in > > |contrast to AC > > |> |> algorithms deciding whether a new flow can be admitted to be=20 > > |> |> transported over a single link which has been studied in > > |> |depth in the > > |> |> 1990s in the context of ATM systems. Three years ago, I have > > |> |reviewed > > |> |> and studied different approaches for NAC (based on resource > > |> |management > > |> |issues) in my PhD thesis: > > |> |> > > |> > > ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p > df/Menth04 > > |> |> .pdf The terms connection or flow admission control are less > > |> |specific > > |> |> than NAC as they do not tell the scope of the AC. > > |> |> > > |> |> Best regards, > > |> |> > > |> |> Michael > > |> |> > > |> |> Rodrig, Benny (Benny) wrote: > > |> |>> What I think you mean, and the admission control that PCN > > |> |deals with, > > |> | > > |> |>> better not be described as "network admission control" > > |since that > > |> |>> term often (e.g. see > > |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) > > |> |>> refers to admission based on the identity of the sender, > > |which is > > |> |>> probably out of scope for PCN. The flow admission > > control in PCN > > |> |>> scope is based on considerations related to network=20 > status i.e. > > |> |>> pre-congestion. > > |> |>> The PCN flow admission control can be part of a call=20 > admission=20 > > |> |>> control solution, if it interacts with other mechanisms > > |such as for > > |> |>> example with Int-Serv outside the PCN domain and/or > > with SIP QoS > > |> |>> pre-conditions. Such interactions, or assumptions about > > |> |them, may not > > |> |be in the scope of PCN. > > |> |>> > > |> |>> > > |> |>> Benny > > |> |>> -----Original Message----- > > |> |>> From: Geib, Ruediger=20 > [mailto:Ruediger.Geib@t-systems.com] Sent: > > |> |>> Thursday, February 01, 2007 4:44 AM > > |> |>> To: Romascanu, Dan (Dan) > > |> |>> Cc: pcn@ietf.org > > |> |>> Subject: RE: [PCN] charter, addition to scope > > |> |>> > > |> |>> Hi Dan, > > |> |>> > > |> |>> your proposal seems sound to me. My impression is the > > |> |discussion may > > |> |>> have approached consensus on the following issues to get > > |chartered > > |> |>> initially: > > |> |>> > > |> |>> - PCN is limited to a single DiffServ domain. > > |> |>> - PCN aware nodes must be "on path". > > |> |>> - PCN only standardises PCN related IP layer > > |> |>> functionalities including RSVP or NSIS signaling > > |> |>> between edge nodes. > > |> |>> - PCN only works on "network admission control". > > |> |>> > > |> |>> If "Edge node" requires further definition to exclude > > |> |things to close > > |> | > > |> |>> to an "end system", we should add it at appropriate places. > > |> |>> "PCN related" would exclude dealing with middleboxes > > |doing anything > > |> |>> else with packets than PCN DiffServ forwarding. > > |> |>> > > |> |>> Another question is, what the reaction of an ingress edge > > |> |node should > > |> | > > |> |>> be in case of an indicated network congestion. My > > |> |impression is, that > > |> | > > |> |>> with the initial charter we should just define a desired > > |> |behaviour in > > |> | > > |> |>> terms of an aggregate traffic reduction (e.g. "stop > > |admission new > > |> |>> flows demanding CL forwarding or bandwidth increases > > of admitted > > |> |>> ones" or "reduce CL traffic by x percent"). > > |> |>> Future work items may be added when the WG is > > re-chartered after > > |> |>> having reached first aims. It may indeed be useful to > > |think about > > |> |>> some requirements for future PCN use already now. As I > > |didn't think > > |> |>> about particular topics in detail, I don't try to > > |summarise which > > |> |>> requirements that could be by this mail. > > |> |>> > > |> |>> Regards, > > |> |>> > > |> |>> Ruediger > > |> |>> > > |> |>> > > |> |>> |-----Original Message----- > > |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > |> |>> |Sent: Thursday, February 01, 2007 9:45 AM > > |> |>> |To: Lee, Richard FTC; Black_David@emc.com; > > |karagian@cs.utwente.nl > > |> |>> |Cc: pcn@ietf.org > > |> |>> |Subject: RE: [PCN] charter, addition to scope > > |> |>> | > > |> |>> | > > |> |>> |Maybe we should stop for a moment and consider what layer > > |> |should PCN > > |> | > > |> |>> |deal with. It looks to me that we are mixing=20 > network admission=20 > > |> |>> |control and call admission control in this discussion. > > |> |This problem > > |> |>> |is quite complex, and there are many scenarios that need > > |> |to be taken > > |> | > > |> |>> |into consideration. Sometimes flow =3D call, sometimes call > > |> |=3DNOT flow > > |> |>> |and sometimes there is a mix on the same path. In some > > |cases media > > |> |>> |gateways > > |> |>> > > |> |>> |are collocated with the edge nodes in some other cases > > |not. Even > > |> |>> |when flow =3D call there are two admission control layers > > |> |(network and > > |> | > > |> |>> |call) that are in dependency but not identical and separate=20 > > |> |>> |protocols run at transport and session. I am not sure > > |how much of > > |> |>> |all this falls under what PCN should do. > > |> |>> | > > |> |>> |Dan > > |> |>> | > > |> |>> | > > |> |>> | > > |> |>> | > > |> |>> | | | > > |> |>> |> -----Original Message----- > > |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] > > |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM > > |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl > > |> |>> |> Cc: pcn@ietf.org > > |> |>> |> Subject: RE: [PCN] charter, addition to scope > > |> |>> |> |> To all, > > |> |>> |> I agree that there must be a prioritization of flows > > |from the |> > > |> |>> aggregation devices However, it's not just the media > > |> |gateway that |> > > |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") > > |> |as well - > > |> |>> > > |> |>> |> it is the signaling proxy at the edge that reserves > > the media > > |> |>> |> path. |> > > |> |>> The reservation protocol request to the network from > > the VoIP |> > > |> |>> proxy/gateway must reserve resources to the destination > > |in the |> > > |> |>> network. > > |> |>> |> The resource reservation request to the network by > > the edge |> > > |> |>> proxy/media gateway, must at the very minimum, meet the > > |following |> > > |> |>> conditions: > > |> |>> |> 1. it needs to specify the resources required for the > > |IP & ports > > |> |>> |> |> > > |> |>> (RTP/RTCP & bandwidth) > > |> |>> |> for example, G.711 and G.729 voice and various > > |MPEG-4 video > > |> |>> |> codecs > > |> |>> > > |> |>> |> all have very different requirements 2. it must be > > |mapped to the > > |> |>> |> |> > > |> |>> signaling request > > |> |>> |> for SIP, it must map the SDP for media with the > > |reservation > > |> |>> |> flow - > > |> |>> > > |> |>> |> for example something along the lines of RFC 3524 > > |> |>> |> while not the answer, the mapping of the media > > |flows is a |> > > |> |>> necessary component > > |> |>> |> It should be noted that the edge proxies/media > > |gateways may > > |> |>> |> have a > > |> |>> > > |> |>> |> large number of flows (and ports for each > > |> |>> |> RTP/RTCP flow) from the same source IP. The request > > |> |is made for > > |> | > > |> |>> |> |> > > |> |>> each flow or conversation 3. it must be honored by the > > |edge network > > |> |>> |> device. > > |> |>> |> The trust boundary must be extended to the edge > > |proxy/media |> > > |> |>> gateway for each new flow. > > |> |>> |> This brings up the issue of security authentication > > |> |of the edge > > |> | > > |> |>> |> |> > > |> |>> proxy/media gateway to the network > > |> |>> |> Does this happen in EAP, NAC, or just > > interoperability and |> > > |> |>> certification among vendors > > |> |>> |> If the resources are not available, then the signaling=20 > > |> |>> |> indicates |> > > |> |>> the session is not completed. For example a SIP > > |> |>> |> CANCEL from the edge proxy > > |> |>> |> |> In addition, the network device must have > > priority queuing > > |> |>> |> |> enabled > > |> |>> |> for input queues from the edge device. > > |> |>> |> The media flows must not be subject to input buffers > > |> |being filled > > |> |>> |> |> > > |> |>> prior to classification > > |> |>> |> |> Thanks, > > |> |>> |> Richard Lee > > |> |>> |> Fidelity Investments > > |> |>> |> Enterprise Technology and Architecture > > |> |>> |> 617-563-3278 > > |> |>> |> |> |> -----Original Message----- > > |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] > > |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM > > |> |>> |> To: karagian@cs.utwente.nl > > |> |>> |> Cc: pcn@ietf.org > > |> |>> |> Subject: RE: [PCN] charter, addition to scope > > |> |>> |> |> |> Georgios wrote: > > |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > |> |>> |> > > > In the first phase of PCN work to reduce the list of > > |> |>> |> issues it was > > |> |>> |> |> > > > proposed that the WG focus on network > > |> |deployment scenario > > |> |>> where > > |> |>> |> all > > |> |>> |> > > > nodes can be trusted and delay work on deployment > > |> |>> |> scenarios where > > |> |>> |> some > > |> |>> |> > > > of the nodes are not trusted. > > |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, > > |then yes, I > > |> |>> agree. If > > |> |>> |> "nodes" |> > > include end systems, proxies or other > > |entities, > > |> |>> |> then I > > |> |>> don't |> > > agree we had agreement on that. > > |> |>> |> > |> > Georgios: This imposes an additional > > |restriction on the > > |> |>> |> > |> > scope > > |> |>> of |> > the charter, which has been not discussed yet. > > |> |>> |> > >From what I remember before, during and after=20 > the PCN BOF > > |> |>> |> > there was no objection on using the term edge node, > > |that could > > |> |>> |> > mean something different than a edge > > |> |>> |> router. > > |> |>> |> > Please note that this is something different than a > > |> |>> |scenario covered > > |> |>> |> by > > |> |>> |> > an application based deployment model. > > |> |>> |> |> It's certainly not a new restriction based on the > > |> |discussion in > > |> | > > |> |>> |> |> the > > |> |>> |> BOF engendered about whether a SIP telephone (used on > > |some of the > > |> |>> |> slides) was a good example. I believe the BOF > > |> |conclusion was that > > |> | > > |> |>> |> a SIP telephone was a bad example. > > |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the > > |> |>> |proposed work: > > |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) > > |The first set > > |> |>> |> of issues has already been discussed extensively - my=20 > > |> |>> |> understanding is that the SIP scenario is currently out > > |> |of scope, > > |> |>> |> and > > |> |>> > > |> |>> |> I don't care to reopen that discussion. > > |> |>> |> |> The "telephone" issues come up in two ways: > > |> |>> |> (2a) Small number of flows may make relatively=20 > fine-grained > > |> |>> |adjustment > > |> |>> |> on the link to the phone impossible. The PCN work > > |prior to the > > |> |>> |> BOF relied on the ability to make such adjustments. > > |> |>> |> (2b) While other sorts of phones may be trusted,=20 > a SIP phone=20 > > |> |>> |> (which may be software-only) is definitely not=20 > trustable in > > |> |general. > > |> |>> |> |> I would observe that Lars Westerberg's suggestion > > |of a Media > > |> |>> Gateway: > > |> |>> |> |> > I am referring telecom scenario where MGWs are > > |connected to > > |> |>> |> |> > an > > |> |>> |> IP-backbone. > > |> |>> |> > In these scenarios, the admission control function is > > |> |a part of > > |> |>> |> > the > > |> |>> |> MGW > > |> |>> |> > and not the routers. The IP-backbone is provisioned by > > |> |a network > > |> | > > |> |>> |> > |> > > |> |>> > management system. > > |> |>> |> |> could avoid all of these issues: > > |> |>> |> (1) The media gateway could speak RSVP to the network > > |management > > |> |>> |> |> > > |> |>> system, > > |> |>> |> avoiding any need to deal with SIP here. > > |> |>> |> (2a) A media gateway is likely to handle enough=20 > flows to be > > |> |>> |consistent > > |> |>> |> with the fine-grained adjustment assumed by the=20 > work done to > > |> |>> date. > > |> |>> |> (2b) One can plausibly assume/require that media=20 > gateways be=20 > > |> |>> |> trusted with respect to the IP network. > > |> |>> |> To the extent that one can vest "edge" functionality in > > |> |a trusted > > |> |>> |> |> > > |> |>> media gateway, I see no reason to exclude that scenario. > > |> |>> |> |> Thanks, > > |> |>> |> --David > > |> |>> |> ---------------------------------------------------- > > |> |>> |> David L. Black, Senior Technologist EMC Corporation, > > |176 South > > |> |>> |> St., Hopkinton, MA 01748 > > |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 > > |> |>> |> ---------------------------------------------------- > > |> |>> |> |> _______________________________________________ > > |> |>> |> 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=20 > Wuerzburg,=20 > > |> |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, > > |> |Germany, > > |> |> room B206 > > |> |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > > |> |> 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 > > |> > > | > > |-- > > |Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 > > |Institute of Computer Science Am Hubland, D-97074=20 > Wuerzburg, Germany,=20 > > |room B206 > > |phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > > |mailto:menth@informatik.uni-wuerzburg.de > > |http://www3.informatik.uni-wuerzburg.de/research/ngn > > | > > | > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > >=20 > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 09 09:21:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWct-00073T-SC; Fri, 09 Feb 2007 09:21:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWcs-00072O-50 for pcn@ietf.org; Fri, 09 Feb 2007 09:21:22 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFWcp-0000MS-Nv for pcn@ietf.org; Fri, 09 Feb 2007 09:21:22 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l19ELBTK030188 for ; Fri, 9 Feb 2007 09:21:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] "Network Admission Control" (NAC) Date: Fri, 9 Feb 2007 09:21:09 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] "Network Admission Control" (NAC) Thread-Index: AcdJyXnmU+3K4rG0RROL42854Ty6AgB0YAwwACEYsAAADSNLAA== References: <6439282641581441A36F7F6F83ED2ED2CBFB24@S4DE8PSAAFQ.mitte.t-com.de> From: "Rodrig, Benny \(Benny\)" To: "Geib, Ruediger" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 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 agree. It will be useful if these discussions, on terminology and = beyond, feed into the architecture draft.=20 Benny -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: Friday, February 09, 2007 2:58 AM To: acharny@cisco.com Cc: pcn@ietf.org Subject: RE: [PCN] "Network Admission Control" (NAC) Hi Anna, I'd appreciate that. I think that a fair part of the discussions on = different threads we had on this list was related to architecture and = requirements, not just to the charter. Regards, Ruediger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Thursday, February 08, 2007 5:08 PM |To: Tina TSOU; brodrig@avaya.com; Geib, R=FCdiger |Cc: pcn@ietf.org |Subject: RE: [PCN] "Network Admission Control" (NAC) | | |Hi, | |Just a thought that there will be a number of terminology issues to=20 |address once the WG is formed. I wonder if this discussion can become=20 |part of the work on the terminology that would eventually find its way=20 |into (I think) the architecture draft? | |Anna | | |> -----Original Message----- |> From: Tina TSOU [mailto:tena@huawei.com] |> Sent: Tuesday, February 06, 2007 3:32 AM |> To: brodrig@avaya.com; Geib, Ruediger |> Cc: pcn@ietf.org |> Subject: Re: [PCN] "Network Admission Control" (NAC) |>=20 |> Hi Ruediger, |> Do we also consider Network Access Control in PCN? |>=20 |> B. R. |> Tina |> ----- Original Message ----- |> From: "Geib, Ruediger" |> To: |> Cc: |> Sent: Tuesday, February 06, 2007 4:18 PM |> Subject: RE: [PCN] "Network Admission Control" (NAC) |>=20 |>=20 |> Benny, |>=20 |> I prefer Michaels proposal, NAC or DAC is allright with me if we=20 |> provide a definition for our terminology. The same would hold if=20 |> "flow admission" is used, which I feel to be to close to "per flow". |>=20 |> A side note on the abbreviation NAC: it is also described as Network=20 |> Access Control by Wikipedia. I've checked that because within my=20 |> company what is described by Wiki as Network "Admission Control" is=20 |> called Network Access Control. |>=20 |> Regards, |>=20 |> Ruediger |>=20 |> |-----Original Message----- |> |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |> |Sent: Monday, February 05, 2007 8:37 PM |> |To: Rodrig, Benny (Benny) |> |Cc: Geib, R=FCdiger; pcn@ietf.org |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> | |> | |> |Hi, |> | |> |the word NAC itself means that access is possibly denied to |a network |> |which can be due to security or resource reasons. NAC in |the security |> |context has become a quite popular expression as it is the name of a = |> |Cisco product. The name NAC sounds good (to me) as it is |> very catchy and |> |easy to understand also for non-experts. I don't see a large problem = |> |when the term NAC exists in different contexts. If people need to=20 |> |distinguish both approaches, security-related NAC and |> resource-related |> |NAC can be used. However, people working in both areas |might see this |> |differently. |> | |> |As the new version of the PCN charter talks about domains, domain=20 |> |admission control (DAC) would be a natural substitute for |> NAC. DAC has |> |no misleading connotations, but it doesn't sound nice (to |me). Better |> |sounds maybe per-domain AC (PDAC) and concisely states what |it is. In |> |analogy to routing, intradomain admission control is another |> option, but |> |it also implies the existence of interdomain admission |> control. I'm not |> |sure whether we want this right now. |> | |> |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN=20 |> |charter, we can leave this issue open until we have a |> clearer opinion. |> | |> | Michael |> | |> |Rodrig, Benny (Benny) wrote: |> |> Ruediger, |> |> |> |> To me the charter doesn't seem to imply the expansion of |scope that |> |> you're concerned about. Unlike many other terms "flow |> admission" doesn't |> |> seem to have misleading connotations. But I could be ok |> with "network |> |> flow admission". |> |> |> |> If it is important that the charter be more explicit about |> this point, |> |> then perhaps a sentence should be added with some explicit |> description |> |> e.g. that the flow admission behavior at the boundary |> includes policing |> |> and/or interaction with per-flow mechanisms that are out |> of scope of |> |> PCN. |> |> |> |> Benny |> |> |> |> |> |> -----Original Message----- |> |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> |> Sent: Monday, February 05, 2007 3:01 AM |> |> To: Rodrig, Benny (Benny) |> |> Cc: pcn@ietf.org |> |> Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> |> |> I'm not sure whether "flow admission" is the correct description. |> |> Wouldn' or couldn't that mean that PCN includes work on |> the per flow |> |> admission control functionality. PCN then is chartered to work on |> |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with |> |Network- or |> |> Aggregate- or Per Domain Behaviour- Admission Control, then the=20 |> |> chartered PCN work could be limited to provide an |> interface (API?) to |> |> the per flow signaling protocol. Isn't the latter |> sufficient for the |> |> initial charter? |> |> |> |> Regards, |> |> |> |> Ruediger |> |> |> |> |-----Original Message----- |> |> |From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] |> |> |Sent: Friday, February 02, 2007 5:09 PM |> |> |To: Moore, Sean (Sean); Tina TSOU; |> |menth@informatik.uni-wuerzburg.de; |> |> |Geib, Rudiger |> |> |Cc: pcn@ietf.org |> |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> | |> |> | |> |> |I think the 'flow admission' wording in the charter is |fine and we |> |> |don't need to choose a more precise term. The charter text |> |explaining |> |> |that this flow admission happens at the domain boundary in |> |reaction to |> |> |pre-congestion info from within the domain, etc. seems to |> |describe it |> |> |sufficiently. |> |> | |> |> |Benny |> |> | |> |> |-----Original Message----- |> |> |From: Moore, Sean (Sean) |> |> |Sent: Friday, February 02, 2007 9:59 AM |> |> |To: Tina TSOU; Rodrig, Benny (Benny); |> |menth@informatik.uni-wuerzburg.de |> |> |Cc: pcn@ietf.org; Geib, Ruediger |> |> |Subject: RE: [PCN] "Network Admission Control" (NAC) |> |> | |> |> |Probably shouldn't use "Resource Admission Control" as this |> |term (RAC) |> |> |is used in IMS and it is not the same as what we are discussing |> |> |- Sean |> |> | |> |> |-----Original Message----- |> |> |From: Tina TSOU [mailto:tena@huawei.com] |> |> |Sent: Friday, February 02, 2007 9:25 AM |> |> |To: Rodrig, Benny (Benny); menth@informatik.uni-wuerzburg.de |> |> |Cc: pcn@ietf.org; Geib, Ruediger |> |> |Subject: Re: [PCN] "Network Admission Control" (NAC) |> |> | |> |> |Hi, |> |> |How about Resource Admission Control or Network Resource |Admission |> |> |Control? |> |> |I don't have strong opinion on that, just some terms |> popped up in my |> |> |mind:) |> |> | |> |> |B. R. |> |> |Tina |> |> | |> |> |----- Original Message ----- |> |> |From: "Michael Menth" |> |> |To: "Rodrig, Benny (Benny)" |> |> |Cc: ; "Geib, Ruediger"=20 | |> |> |Sent: Friday, February 02, 2007 12:16 PM |> |> |Subject: [PCN] "Network Admission Control" (NAC) |> |> | |> |> | |> |> |> Hi, |> |> |> |> |> |> I've got a comment on the term "Network Admission |> Control" (NAC). |> |> |> |> |> |> Wikipedia |> |> |http://en.wikipedia.org/wiki/Network_Admission_Control only |> |> |> knows NAC in the context of restricting access to the |> |> |network based on |> |> | |> |> |> identity or security posture (it's essentially a Cisco |product). |> |> |> However, most important is the aspect that access is denied |> |> |to a whole |> |> | |> |> |> network, subnetwork, domain, region, etc. NAC is in |> |contrast to AC |> |> |> algorithms deciding whether a new flow can be admitted to be=20 |> |> |> transported over a single link which has been studied in |> |> |depth in the |> |> |> 1990s in the context of ATM systems. Three years ago, I have |> |> |reviewed |> |> |> and studied different approaches for NAC (based on resource |> |> |management |> |> |issues) in my PhD thesis: |> |> |> |> |> |> ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p |df/Menth04 |> |> |> .pdf The terms connection or flow admission control are less |> |> |specific |> |> |> than NAC as they do not tell the scope of the AC. |> |> |> |> |> |> Best regards, |> |> |> |> |> |> Michael |> |> |> |> |> |> Rodrig, Benny (Benny) wrote: |> |> |>> What I think you mean, and the admission control that PCN |> |> |deals with, |> |> | |> |> |>> better not be described as "network admission control" |> |since that |> |> |>> term often (e.g. see |> |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control) |> |> |>> refers to admission based on the identity of the sender, |> |which is |> |> |>> probably out of scope for PCN. The flow admission |> control in PCN |> |> |>> scope is based on considerations related to network |status i.e. |> |> |>> pre-congestion. |> |> |>> The PCN flow admission control can be part of a call admission = |> |> |>> control solution, if it interacts with other mechanisms |> |such as for |> |> |>> example with Int-Serv outside the PCN domain and/or |> with SIP QoS |> |> |>> pre-conditions. Such interactions, or assumptions about |> |> |them, may not |> |> |be in the scope of PCN. |> |> |>> |> |> |>> |> |> |>> Benny |> |> |>> -----Original Message----- |> |> |>> From: Geib, Ruediger |[mailto:Ruediger.Geib@t-systems.com] Sent: |> |> |>> Thursday, February 01, 2007 4:44 AM |> |> |>> To: Romascanu, Dan (Dan) |> |> |>> Cc: pcn@ietf.org |> |> |>> Subject: RE: [PCN] charter, addition to scope |> |> |>> |> |> |>> Hi Dan, |> |> |>> |> |> |>> your proposal seems sound to me. My impression is the |> |> |discussion may |> |> |>> have approached consensus on the following issues to get |> |chartered |> |> |>> initially: |> |> |>> |> |> |>> - PCN is limited to a single DiffServ domain. |> |> |>> - PCN aware nodes must be "on path". |> |> |>> - PCN only standardises PCN related IP layer |> |> |>> functionalities including RSVP or NSIS signaling |> |> |>> between edge nodes. |> |> |>> - PCN only works on "network admission control". |> |> |>> |> |> |>> If "Edge node" requires further definition to exclude |> |> |things to close |> |> | |> |> |>> to an "end system", we should add it at appropriate places. |> |> |>> "PCN related" would exclude dealing with middleboxes |> |doing anything |> |> |>> else with packets than PCN DiffServ forwarding. |> |> |>> |> |> |>> Another question is, what the reaction of an ingress edge |> |> |node should |> |> | |> |> |>> be in case of an indicated network congestion. My |> |> |impression is, that |> |> | |> |> |>> with the initial charter we should just define a desired |> |> |behaviour in |> |> | |> |> |>> terms of an aggregate traffic reduction (e.g. "stop |> |admission new |> |> |>> flows demanding CL forwarding or bandwidth increases |> of admitted |> |> |>> ones" or "reduce CL traffic by x percent"). |> |> |>> Future work items may be added when the WG is |> re-chartered after |> |> |>> having reached first aims. It may indeed be useful to |> |think about |> |> |>> some requirements for future PCN use already now. As I |> |didn't think |> |> |>> about particular topics in detail, I don't try to |> |summarise which |> |> |>> requirements that could be by this mail. |> |> |>> |> |> |>> Regards, |> |> |>> |> |> |>> Ruediger |> |> |>> |> |> |>> |> |> |>> |-----Original Message----- |> |> |>> |From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] |> |> |>> |Sent: Thursday, February 01, 2007 9:45 AM |> |> |>> |To: Lee, Richard FTC; Black_David@emc.com; |> |karagian@cs.utwente.nl |> |> |>> |Cc: pcn@ietf.org |> |> |>> |Subject: RE: [PCN] charter, addition to scope |> |> |>> | |> |> |>> | |> |> |>> |Maybe we should stop for a moment and consider what layer |> |> |should PCN |> |> | |> |> |>> |deal with. It looks to me that we are mixing network |admission |> |> |>> |control and call admission control in this discussion. |> |> |This problem |> |> |>> |is quite complex, and there are many scenarios that need |> |> |to be taken |> |> | |> |> |>> |into consideration. Sometimes flow =3D call, sometimes call |> |> |=3DNOT flow |> |> |>> |and sometimes there is a mix on the same path. In some |> |cases media |> |> |>> |gateways |> |> |>> |> |> |>> |are collocated with the edge nodes in some other cases |> |not. Even |> |> |>> |when flow =3D call there are two admission control layers |> |> |(network and |> |> | |> |> |>> |call) that are in dependency but not identical and separate=20 |> |> |>> |protocols run at transport and session. I am not sure |> |how much of |> |> |>> |all this falls under what PCN should do. |> |> |>> | |> |> |>> |Dan |> |> |>> | |> |> |>> | |> |> |>> | |> |> |>> | |> |> |>> | | | |> |> |>> |> -----Original Message----- |> |> |>> |> From: Lee, Richard FTC [mailto:Richard.Lee.FTC@FMR.COM] |> |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM |> |> |>> |> To: Black_David@emc.com; karagian@cs.utwente.nl |> |> |>> |> Cc: pcn@ietf.org |> |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |> |>> |> |> To all, |> |> |>> |> I agree that there must be a prioritization of flows |> |from the |> |> |> |>> aggregation devices However, it's not just the media |> |> |gateway that |> |> |> |>> should speak RSVP, but the edge proxy (or firewall "proxy") |> |> |as well - |> |> |>> |> |> |>> |> it is the signaling proxy at the edge that reserves |> the media |> |> |>> |> path. |> |> |> |>> The reservation protocol request to the network from |> the VoIP |> |> |> |>> proxy/gateway must reserve resources to the destination |> |in the |> |> |> |>> network. |> |> |>> |> The resource reservation request to the network by |> the edge |> |> |> |>> proxy/media gateway, must at the very minimum, meet the |> |following |> |> |> |>> conditions: |> |> |>> |> 1. it needs to specify the resources required for the |> |IP & ports |> |> |>> |> |> |> |> |>> (RTP/RTCP & bandwidth) |> |> |>> |> for example, G.711 and G.729 voice and various |> |MPEG-4 video |> |> |>> |> codecs |> |> |>> |> |> |>> |> all have very different requirements 2. it must be |> |mapped to the |> |> |>> |> |> |> |> |>> signaling request |> |> |>> |> for SIP, it must map the SDP for media with the |> |reservation |> |> |>> |> flow - |> |> |>> |> |> |>> |> for example something along the lines of RFC 3524 |> |> |>> |> while not the answer, the mapping of the media |> |flows is a |> |> |> |>> necessary component |> |> |>> |> It should be noted that the edge proxies/media |> |gateways may |> |> |>> |> have a |> |> |>> |> |> |>> |> large number of flows (and ports for each |> |> |>> |> RTP/RTCP flow) from the same source IP. The request |> |> |is made for |> |> | |> |> |>> |> |> |> |> |>> each flow or conversation 3. it must be honored by the |> |edge network |> |> |>> |> device. |> |> |>> |> The trust boundary must be extended to the edge |> |proxy/media |> |> |> |>> gateway for each new flow. |> |> |>> |> This brings up the issue of security authentication |> |> |of the edge |> |> | |> |> |>> |> |> |> |> |>> proxy/media gateway to the network |> |> |>> |> Does this happen in EAP, NAC, or just |> interoperability and |> |> |> |>> certification among vendors |> |> |>> |> If the resources are not available, then the signaling=20 |> |> |>> |> indicates |> |> |> |>> the session is not completed. For example a SIP |> |> |>> |> CANCEL from the edge proxy |> |> |>> |> |> In addition, the network device must have |> priority queuing |> |> |>> |> |> enabled |> |> |>> |> for input queues from the edge device. |> |> |>> |> The media flows must not be subject to input buffers |> |> |being filled |> |> |>> |> |> |> |> |>> prior to classification |> |> |>> |> |> Thanks, |> |> |>> |> Richard Lee |> |> |>> |> Fidelity Investments |> |> |>> |> Enterprise Technology and Architecture |> |> |>> |> 617-563-3278 |> |> |>> |> |> |> -----Original Message----- |> |> |>> |> From: Black_David@emc.com [mailto:Black_David@emc.com] |> |> |>> |> Sent: Wednesday, January 31, 2007 2:30 PM |> |> |>> |> To: karagian@cs.utwente.nl |> |> |>> |> Cc: pcn@ietf.org |> |> |>> |> Subject: RE: [PCN] charter, addition to scope |> |> |>> |> |> |> Georgios wrote: |> |> |>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: |> |> |>> |> > > > In the first phase of PCN work to reduce the list of |> |> |>> |> issues it was |> |> |>> |> |> > > > proposed that the WG focus on network |> |> |deployment scenario |> |> |>> where |> |> |>> |> all |> |> |>> |> > > > nodes can be trusted and delay work on deployment |> |> |>> |> scenarios where |> |> |>> |> some |> |> |>> |> > > > of the nodes are not trusted. |> |> |>> |> > > |> > > (by Lars:) If by "nodes" you mean routers, |> |then yes, I |> |> |>> agree. If |> |> |>> |> "nodes" |> > > include end systems, proxies or other |> |entities, |> |> |>> |> then I |> |> |>> don't |> > > agree we had agreement on that. |> |> |>> |> > |> > Georgios: This imposes an additional |> |restriction on the |> |> |>> |> > |> > scope |> |> |>> of |> > the charter, which has been not discussed yet. |> |> |>> |> > >From what I remember before, during and after |the PCN BOF |> |> |>> |> > there was no objection on using the term edge node, |> |that could |> |> |>> |> > mean something different than a edge |> |> |>> |> router. |> |> |>> |> > Please note that this is something different than a |> |> |>> |scenario covered |> |> |>> |> by |> |> |>> |> > an application based deployment model. |> |> |>> |> |> It's certainly not a new restriction based on the |> |> |discussion in |> |> | |> |> |>> |> |> the |> |> |>> |> BOF engendered about whether a SIP telephone (used on |> |some of the |> |> |>> |> slides) was a good example. I believe the BOF |> |> |conclusion was that |> |> | |> |> |>> |> a SIP telephone was a bad example. |> |> |>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the |> |> |>> |proposed work: |> |> |>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-) |> |The first set |> |> |>> |> of issues has already been discussed extensively - my=20 |> |> |>> |> understanding is that the SIP scenario is currently out |> |> |of scope, |> |> |>> |> and |> |> |>> |> |> |>> |> I don't care to reopen that discussion. |> |> |>> |> |> The "telephone" issues come up in two ways: |> |> |>> |> (2a) Small number of flows may make relatively fine-grained |> |> |>> |adjustment |> |> |>> |> on the link to the phone impossible. The PCN work |> |prior to the |> |> |>> |> BOF relied on the ability to make such adjustments. |> |> |>> |> (2b) While other sorts of phones may be trusted, a |SIP phone |> |> |>> |> (which may be software-only) is definitely not trustable in |> |> |general. |> |> |>> |> |> I would observe that Lars Westerberg's suggestion |> |of a Media |> |> |>> Gateway: |> |> |>> |> |> > I am referring telecom scenario where MGWs are |> |connected to |> |> |>> |> |> > an |> |> |>> |> IP-backbone. |> |> |>> |> > In these scenarios, the admission control function is |> |> |a part of |> |> |>> |> > the |> |> |>> |> MGW |> |> |>> |> > and not the routers. The IP-backbone is provisioned by |> |> |a network |> |> | |> |> |>> |> > |> |> |> |>> > management system. |> |> |>> |> |> could avoid all of these issues: |> |> |>> |> (1) The media gateway could speak RSVP to the network |> |management |> |> |>> |> |> |> |> |>> system, |> |> |>> |> avoiding any need to deal with SIP here. |> |> |>> |> (2a) A media gateway is likely to handle enough flows to be |> |> |>> |consistent |> |> |>> |> with the fine-grained adjustment assumed by the |work done to |> |> |>> date. |> |> |>> |> (2b) One can plausibly assume/require that media |gateways be |> |> |>> |> trusted with respect to the IP network. |> |> |>> |> To the extent that one can vest "edge" functionality in |> |> |a trusted |> |> |>> |> |> |> |> |>> media gateway, I see no reason to exclude that scenario. |> |> |>> |> |> Thanks, |> |> |>> |> --David |> |> |>> |> ---------------------------------------------------- |> |> |>> |> David L. Black, Senior Technologist EMC Corporation, |> |176 South |> |> |>> |> St., Hopkinton, MA 01748 |> |> |>> |> +1 (508) 293-7953 FAX: +1 (508) 293-7786 |> |> |>> |> black_david@emc.com Mobile: +1 (978) 394-7754 |> |> |>> |> ---------------------------------------------------- |> |> |>> |> |> _______________________________________________ |> |> |>> |> 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=20 |> |> |> 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 |> |> |> | |> |-- |> |Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 |> |Institute of Computer Science Am Hubland, D-97074 Wuerzburg,=20 |> |Germany, room B206 |> |phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 |> |mailto:menth@informatik.uni-wuerzburg.de |> |http://www3.informatik.uni-wuerzburg.de/research/ngn |> | |> | |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=20 |>=20 |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=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 Tue Feb 13 20:50:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH9Hx-0002j0-QF; Tue, 13 Feb 2007 20:50:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7Ps-0000ui-WA; Tue, 13 Feb 2007 18:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HH7Ps-0004qn-H7; Tue, 13 Feb 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 728751760A; Tue, 13 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HH7PO-0007pM-7J; Tue, 13 Feb 2007 18:50:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 13 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-Mailman-Approved-At: Tue, 13 Feb 2007 20:50:28 -0500 Cc: pcn@ietf.org Subject: [PCN] WG Review: Congestion and Pre-Congestion Notification (pcn) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 19th. +++ Congestion and Pre-Congestion Notification (pcn) ================================================= Current Status: Proposed Wroking Group Chair(s): tbd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. To allow for future extensions to the mechanisms and their application to new deployment scenarios, they are logically separated into several components, namely, encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. The WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and domain egress (4) metering of (pre-)congestion information at the domain egress (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the overall architecture, and specifically on the marking behavior and encoding and transport mechanisms needed to realize it. Standards-track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. If this WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Nov 2007 Flow Admission and Termination Architecture (Informational) Nov 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain (Informational) Mar 2008 Flow Admission and Termination within a DiffServ Domain (Informational) Mar 2008 (Pre-)Congestion Detection within a DiffServ Domain (Proposed Standard) Mar 2008 Requirements for Signaling of (Pre-)Congestion Information from Egress to Ingress in a DiffServ Domain (Informational) Jul 2008 Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress (Proposed Standard) Nov 2008 Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress (Proposed Standard) Jul 2008 Suggested Flow Admission and Termination Boundary Mechanisms (Informational) _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Feb 15 11:24:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjP2-0001Qx-Jy; Thu, 15 Feb 2007 11:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjP1-0001Qh-Jo for pcn@ietf.org; Thu, 15 Feb 2007 11:24:11 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHjOs-0005Jh-1F for pcn@ietf.org; Thu, 15 Feb 2007 11:24:11 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2090A204DE; Thu, 15 Feb 2007 17:23:51 +0100 (CET) X-AuditID: c1b4fb3e-af6d2bb0000007e1-f6-45d48917782b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0B477200A2; Thu, 15 Feb 2007 17:23:51 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 17:23:50 +0100 Received: from [153.88.24.75] ([153.88.24.75]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 17:23:50 +0100 Message-ID: <45D3CA2D.7030303@ericsson.com> Date: Thu, 15 Feb 2007 03:49:17 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model References: <6439282641581441A36F7F6F83ED2ED2CBFB0E@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFB0E@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2007 16:23:50.0055 (UTC) FILETIME=[ACEE5370:01C7511D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Geib, Ruediger skrev: > Magnus, > > then what's a good way to proceed? The current drafts > propose the CL QoS model. The PCN mechanism defined so > far is designed to avoid packet loss. I like both, CL > and the idea to react before packet loss occurs, at > least with regard to admitted traffic. > With the current charter it would be up to the WG to decide this. > Should PCN select one QoS model as an example and define > how to standardise application of PCN for other QoS > models? What to do if we can't reach consesus on one? > As an alternative, mechanisms for several QoS > models could be standardised immediately. That doesn't > sound tempting to me. On the other side, it would > preferable if the signaling between boundary nodes is > able to support different QoS models for which PCN > is applied. A discussion on "signaling" supporting > different "QoS models" is delaying progress of the NSIS > WG since a couple of months now. We should make sure > that PCN isn't running into similar problems. > I agree that the WG should focus on a single or very few models. In regards to the signalling. My understanding is that for certain usages and certain QoS models the signalling will look radically different. Thus the signalling should be developed for the model(s) chosen to work on for now. If you really like to lock down this in the charter you better get the discussion going. I am not convinced that this is necessary. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 Thu Feb 15 22:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHtj3-0003dE-2Q; Thu, 15 Feb 2007 22:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHtj2-0003d9-LW for pcn@ietf.org; Thu, 15 Feb 2007 22:25:32 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHtiy-00022R-0p for pcn@ietf.org; Thu, 15 Feb 2007 22:25:32 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDJ00CESDHG9X@szxga02-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 11:24:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JDJ00JSRDHFEI@szxga02-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 11:24:52 +0800 (CST) Received: from z24109a ([10.70.76.91]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDJ00E01DHF1F@szxml03-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 11:24:51 +0800 (CST) Date: Fri, 16 Feb 2007 11:24:51 +0800 From: Tina TSOU Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model To: "Geib, Ruediger" , Magnus Westerlund Message-id: <00e301c7517a$05341db0$5b4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6439282641581441A36F7F6F83ED2ED2CBFB0E@S4DE8PSAAFQ.mitte.t-com.de> <45D3CA2D.7030303@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 ----- Original Message ----- From: "Magnus Westerlund" To: "Geib, Ruediger" Cc: Sent: Thursday, February 15, 2007 10:49 AM Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model > Geib, Ruediger skrev: >> Magnus, >> >> then what's a good way to proceed? The current drafts propose the CL QoS >> model. The PCN mechanism defined so far is designed to avoid packet loss. >> I like both, CL and the idea to react before packet loss occurs, at least >> with regard to admitted traffic. >> > > With the current charter it would be up to the WG to decide this. I think both are reachable before the target date, allowing a bit delay:) > > >> Should PCN select one QoS model as an example and define how to >> standardise application of PCN for other QoS models? What to do if we >> can't reach consesus on one? >> As an alternative, mechanisms for several QoS models could be >> standardised immediately. That doesn't sound tempting to me. On the other >> side, it would preferable if the signaling between boundary nodes is able >> to support different QoS models for which PCN is applied. A discussion on >> "signaling" supporting different "QoS models" is delaying progress of the >> NSIS WG since a couple of months now. We should make sure that PCN isn't >> running into similar problems. > > I agree that the WG should focus on a single or very few models. > In regards to the signalling. My understanding is that for certain usages > and certain QoS models the signalling will look radically different. Thus > the signalling should be developed for the model(s) chosen to work on for > now. If you really like to lock down this in the charter you better get > the discussion going. I am not convinced that this is necessary. On the assumption that we work on CL QoS model and the model "react before packet loss occurs", are we going to have two kinds of signaling at least? I think it could be discussed after the WG is created. And the charter is not excluded is enough by now. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- B. R. Tina > > > _______________________________________________ > 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 Feb 16 02:18:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxMJ-0007Gn-KK; Fri, 16 Feb 2007 02:18:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxMI-0007Gf-F8 for pcn@ietf.org; Fri, 16 Feb 2007 02:18:18 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHxM8-0003tS-Qb for pcn@ietf.org; Fri, 16 Feb 2007 02:18:18 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 081C7205C1; Fri, 16 Feb 2007 08:18:04 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-64-45d55aabe7bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D4FB420210; Fri, 16 Feb 2007 08:18:03 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 08:18:03 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 08:18:03 +0100 Message-ID: <45D55AAB.3070504@ericsson.com> Date: Fri, 16 Feb 2007 08:18:03 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tina TSOU Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model References: <6439282641581441A36F7F6F83ED2ED2CBFB0E@S4DE8PSAAFQ.mitte.t-com.de> <45D3CA2D.7030303@ericsson.com> <00e301c7517a$05341db0$5b4c460a@china.huawei.com> In-Reply-To: <00e301c7517a$05341db0$5b4c460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2007 07:18:03.0317 (UTC) FILETIME=[98C46650:01C7519A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 comments Tina TSOU wrote: > > ----- Original Message ----- From: "Magnus Westerlund" > > To: "Geib, Ruediger" > Cc: > Sent: Thursday, February 15, 2007 10:49 AM > Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model > > >> Geib, Ruediger skrev: >> >>> Magnus, >>> >>> then what's a good way to proceed? The current drafts propose the CL >>> QoS model. The PCN mechanism defined so far is designed to avoid >>> packet loss. I like both, CL and the idea to react before packet >>> loss occurs, at least with regard to admitted traffic. >>> >> >> With the current charter it would be up to the WG to decide this. > > I think both are reachable before the target date, allowing a bit delay:) I think we need to have a better definition because controlled load is refers to Int.serv models. This solution is based on traffic measurement and this will give much less "guarantees" than a reservation based solution. One simple examples that the approach does not guaratee bandwidth for temporary "silent" traffic sources. The best results is acheived for "constant-bit rate" sources. > >> >> >>> Should PCN select one QoS model as an example and define how to >>> standardise application of PCN for other QoS models? What to do if >>> we can't reach consesus on one? >>> As an alternative, mechanisms for several QoS models could be >>> standardised immediately. That doesn't sound tempting to me. On the >>> other side, it would preferable if the signaling between boundary >>> nodes is able to support different QoS models for which PCN is >>> applied. A discussion on "signaling" supporting different "QoS >>> models" is delaying progress of the NSIS WG since a couple of months >>> now. We should make sure that PCN isn't running into similar problems. >> >> >> I agree that the WG should focus on a single or very few models. >> In regards to the signalling. My understanding is that for certain >> usages and certain QoS models the signalling will look radically >> different. Thus the signalling should be developed for the model(s) >> chosen to work on for now. If you really like to lock down this in >> the charter you better get the discussion going. I am not convinced >> that this is necessary. > > On the assumption that we work on CL QoS model and the model "react > before packet loss occurs", are we going to have two kinds of > signaling at least? I think it could be discussed after the WG is > created. And the charter is not excluded is enough by now. > >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> 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 >> ---------------------------------------------------------------------- > > > B. R. > Tina > >> >> >> _______________________________________________ >> 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 Feb 16 03:28:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHySD-0001Zc-PM; Fri, 16 Feb 2007 03:28:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHySC-0001ZU-Jv for pcn@ietf.org; Fri, 16 Feb 2007 03:28:28 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHySA-0002HH-Vr for pcn@ietf.org; Fri, 16 Feb 2007 03:28:28 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDJ005LKRFZJ0@szxga02-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 16:26:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JDJ00C2DRFZGE@szxga02-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 16:26:23 +0800 (CST) Received: from z24109a ([10.70.76.91]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDJ0068XRFY89@szxml04-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 16:26:22 +0800 (CST) Date: Fri, 16 Feb 2007 16:26:22 +0800 From: Tina TSOU Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model To: Lars Westberg Message-id: <017501c751a4$2463dfc0$5b4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6439282641581441A36F7F6F83ED2ED2CBFB0E@S4DE8PSAAFQ.mitte.t-com.de> <45D3CA2D.7030303@ericsson.com> <00e301c7517a$05341db0$5b4c460a@china.huawei.com> <45D55AAB.3070504@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 ----- Original Message ----- From: "Lars Westberg" To: "Tina TSOU" Cc: "Geib, Ruediger" ; "Magnus Westerlund" ; Sent: Friday, February 16, 2007 3:18 PM Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model > comments > > Tina TSOU wrote: > >> >> ----- Original Message ----- From: "Magnus Westerlund" >> >> To: "Geib, Ruediger" >> Cc: >> Sent: Thursday, February 15, 2007 10:49 AM >> Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model >> >> >>> Geib, Ruediger skrev: >>> >>>> Magnus, >>>> >>>> then what's a good way to proceed? The current drafts propose the CL >>>> QoS model. The PCN mechanism defined so far is designed to avoid packet >>>> loss. I like both, CL and the idea to react before packet loss occurs, >>>> at least with regard to admitted traffic. >>>> >>> >>> With the current charter it would be up to the WG to decide this. >> >> I think both are reachable before the target date, allowing a bit delay:) > > I think we need to have a better definition because controlled load is > refers to Int.serv models. This solution is based on traffic measurement > and this will give much less "guarantees" than a reservation based > solution. One simple examples that the approach does not guaratee > bandwidth for temporary "silent" traffic sources. The best results is > acheived for "constant-bit rate" sources. I agree with you. And it seems that few ppl has interest at Int.serv in core network in North America. > >> >>> >>> >>>> Should PCN select one QoS model as an example and define how to >>>> standardise application of PCN for other QoS models? What to do if we >>>> can't reach consesus on one? >>>> As an alternative, mechanisms for several QoS models could be >>>> standardised immediately. That doesn't sound tempting to me. On the >>>> other side, it would preferable if the signaling between boundary nodes >>>> is able to support different QoS models for which PCN is applied. A >>>> discussion on "signaling" supporting different "QoS models" is delaying >>>> progress of the NSIS WG since a couple of months now. We should make >>>> sure that PCN isn't running into similar problems. >>> >>> >>> I agree that the WG should focus on a single or very few models. >>> In regards to the signalling. My understanding is that for certain >>> usages and certain QoS models the signalling will look radically >>> different. Thus the signalling should be developed for the model(s) >>> chosen to work on for now. If you really like to lock down this in the >>> charter you better get the discussion going. I am not convinced that >>> this is necessary. >> >> On the assumption that we work on CL QoS model and the model "react >> before packet loss occurs", are we going to have two kinds of signaling >> at least? I think it could be discussed after the WG is created. And the >> charter is not excluded is enough by now. >> >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director & TSVWG Chair >>> ---------------------------------------------------------------------- >>> 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 >>> ---------------------------------------------------------------------- >> >> >> B. R. >> Tina >> >>> >>> >>> _______________________________________________ >>> 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 Feb 16 03:29:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHyTL-0001zj-BB; Fri, 16 Feb 2007 03:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHyTK-0001zd-9U for pcn@ietf.org; Fri, 16 Feb 2007 03:29:38 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHyTJ-0002WS-QS for pcn@ietf.org; Fri, 16 Feb 2007 03:29:38 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 16 Feb 2007 09:29:32 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 09:29:32 +0100 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: RE: [PCN] 3rd charter Goals and Milestones - QoS model Date: Fri, 16 Feb 2007 09:29:31 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB56@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <45D55AAB.3070504@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones - QoS model Thread-Index: AcdRmseNy3gg37/ATjOFdKj81qrmHAABJOuA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 16 Feb 2007 08:29:32.0041 (UTC) FILETIME=[950BBF90:01C751A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Lars, my take on PCN is that it exploits statistical multiplexing. CBR=20 traffic could be present, but VBR traffic is preferable. So also=20 on off sources should be tolerated. Simulation results should=20 help the WG to decide on acceptable and not acceptable traffic=20 sources. Regards, Ruediger=20 |-----Original Message----- |From: Lars Westberg [mailto:Lars.westberg@ericsson.com] |Sent: Friday, February 16, 2007 8:18 AM |To: Tina TSOU |Cc: pcn@ietf.org; Geib, R=FCdiger |Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model | | |comments | |Tina TSOU wrote: | |> |> ----- Original Message ----- From: "Magnus Westerlund"=20 |> |> To: "Geib, Ruediger" |> Cc: |> Sent: Thursday, February 15, 2007 10:49 AM |> Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model |> |> |>> Geib, Ruediger skrev: |>> |>>> Magnus, |>>> |>>> then what's a good way to proceed? The current drafts=20 |propose the CL=20 |>>> QoS model. The PCN mechanism defined so far is designed to avoid=20 |>>> packet loss. I like both, CL and the idea to react before packet=20 |>>> loss occurs, at least with regard to admitted traffic. |>>> |>> |>> With the current charter it would be up to the WG to decide this. |> |> I think both are reachable before the target date, allowing=20 |a bit delay:)=20 | | I think we need to have a better definition because=20 |controlled load is=20 |refers to Int.serv models. This solution is based on traffic=20 |measurement=20 |and this will give much less "guarantees" than a reservation based=20 |solution. One simple examples that the approach does not guaratee=20 |bandwidth for temporary "silent" traffic sources. The best results is=20 |acheived for "constant-bit rate" sources. | |> |>> |>> |>>> Should PCN select one QoS model as an example and define how to=20 |>>> standardise application of PCN for other QoS models? What to do if=20 |>>> we can't reach consesus on one? |>>> As an alternative, mechanisms for several QoS models could be=20 |>>> standardised immediately. That doesn't sound tempting to=20 |me. On the=20 |>>> other side, it would preferable if the signaling between boundary=20 |>>> nodes is able to support different QoS models for which PCN is=20 |>>> applied. A discussion on "signaling" supporting different "QoS=20 |>>> models" is delaying progress of the NSIS WG since a couple=20 |of months=20 |>>> now. We should make sure that PCN isn't running into=20 |similar problems. |>> |>> |>> I agree that the WG should focus on a single or very few models. |>> In regards to the signalling. My understanding is that for certain=20 |>> usages and certain QoS models the signalling will look radically=20 |>> different. Thus the signalling should be developed for the model(s)=20 |>> chosen to work on for now. If you really like to lock down this in=20 |>> the charter you better get the discussion going. I am not convinced=20 |>> that this is necessary. |> |> On the assumption that we work on CL QoS model and the model "react=20 |> before packet loss occurs", are we going to have two kinds of=20 |> signaling at least? I think it could be discussed after the WG is=20 |> created. And the charter is not excluded is enough by now. |> |>> |>> Cheers |>> |>> Magnus Westerlund |>> |>> IETF Transport Area Director & TSVWG Chair |>>=20 |---------------------------------------------------------------------- |>> Multimedia Technologies, Ericsson Research EAB/TVA/A |>>=20 |---------------------------------------------------------------------- |>> Ericsson AB | Phone +46 8 4048287 |>> Torshamsgatan 23 | Fax +46 8 7575550 |>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com |>>=20 |---------------------------------------------------------------------- |> |> |> B. R. |> Tina |> |>> |>> |>> _______________________________________________ |>> PCN mailing list |>> PCN@ietf.org |>> https://www1.ietf.org/mailman/listinfo/pcn=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 Fri Feb 16 04:51:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHzkb-0001Df-TY; Fri, 16 Feb 2007 04:51:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHzka-0001DX-Or for pcn@ietf.org; Fri, 16 Feb 2007 04:51:32 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHzkY-0006D9-M1 for pcn@ietf.org; Fri, 16 Feb 2007 04:51:32 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDJ0071YVCPP2@szxga03-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 17:50:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDJ00HUTVCOO0@szxga03-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 17:50:49 +0800 (CST) Received: from z24109a ([10.70.76.91]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDJ006UDVCO89@szxml04-in.huawei.com> for pcn@ietf.org; Fri, 16 Feb 2007 17:50:48 +0800 (CST) Date: Fri, 16 Feb 2007 17:50:48 +0800 From: Tina TSOU Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model To: Lars.westberg@ericsson.com, "Geib, Ruediger" Message-id: <01da01c751af$ef9deea0$5b4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <6439282641581441A36F7F6F83ED2ED2CBFB56@S4DE8PSAAFQ.mitte.t-com.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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, That makes sense. And at the time being, we don't have such simulatio= n=20 results by hand, is it more flexible that we leave it outside of char= ter? Or=20 we could have an informal document to describe how CBR and VBR co-exi= st in=20 PCN? B. R. Tina ----- Original Message -----=20 =46rom: "Geib, Ruediger" To: Cc: Sent: Friday, February 16, 2007 4:29 PM Subject: RE: [PCN] 3rd charter Goals and Milestones - QoS model Lars, my take on PCN is that it exploits statistical multiplexing. CBR traffic could be present, but VBR traffic is preferable. So also on off sources should be tolerated. Simulation results should help the WG to decide on acceptable and not acceptable traffic sources. Regards, Ruediger |-----Original Message----- |From: Lars Westberg [mailto:Lars.westberg@ericsson.com] |Sent: Friday, February 16, 2007 8:18 AM |To: Tina TSOU |Cc: pcn@ietf.org; Geib, R=FCdiger |Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model | | |comments | |Tina TSOU wrote: | |> |> ----- Original Message ----- From: "Magnus Westerlund" |> |> To: "Geib, Ruediger" |> Cc: |> Sent: Thursday, February 15, 2007 10:49 AM |> Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model |> |> |>> Geib, Ruediger skrev: |>> |>>> Magnus, |>>> |>>> then what's a good way to proceed? The current drafts |propose the CL |>>> QoS model. The PCN mechanism defined so far is designed to avoid |>>> packet loss. I like both, CL and the idea to react before packet |>>> loss occurs, at least with regard to admitted traffic. |>>> |>> |>> With the current charter it would be up to the WG to decide this. |> |> I think both are reachable before the target date, allowing |a bit delay:) | | I think we need to have a better definition because |controlled load is |refers to Int.serv models. This solution is based on traffic |measurement |and this will give much less "guarantees" than a reservation based |solution. One simple examples that the approach does not guaratee |bandwidth for temporary "silent" traffic sources. The best results = is |acheived for "constant-bit rate" sources. | |> |>> |>> |>>> Should PCN select one QoS model as an example and define how to |>>> standardise application of PCN for other QoS models? What to do = if |>>> we can't reach consesus on one? |>>> As an alternative, mechanisms for several QoS models could be |>>> standardised immediately. That doesn't sound tempting to |me. On the |>>> other side, it would preferable if the signaling between boundar= y |>>> nodes is able to support different QoS models for which PCN is |>>> applied. A discussion on "signaling" supporting different "QoS |>>> models" is delaying progress of the NSIS WG since a couple |of months |>>> now. We should make sure that PCN isn't running into |similar problems. |>> |>> |>> I agree that the WG should focus on a single or very few models. |>> In regards to the signalling. My understanding is that for certai= n |>> usages and certain QoS models the signalling will look radically |>> different. Thus the signalling should be developed for the model(= s) |>> chosen to work on for now. If you really like to lock down this i= n |>> the charter you better get the discussion going. I am not convinc= ed |>> that this is necessary. |> |> On the assumption that we work on CL QoS model and the model "reac= t |> before packet loss occurs", are we going to have two kinds of |> signaling at least? I think it could be discussed after the WG is |> created. And the charter is not excluded is enough by now. |> |>> |>> Cheers |>> |>> Magnus Westerlund |>> |>> IETF Transport Area Director & TSVWG Chair |>> |--------------------------------------------------------------------= -- |>> 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.c= om |>> |--------------------------------------------------------------------= -- |> |> |> B. R. |> Tina |> |>> |>> |>> _______________________________________________ |>> 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Feb 16 05:38:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Tt-0004ag-6L; Fri, 16 Feb 2007 05:38:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Tr-0004aZ-Ky for pcn@ietf.org; Fri, 16 Feb 2007 05:38:19 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI0Tj-0004vE-7U for pcn@ietf.org; Fri, 16 Feb 2007 05:38:19 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 16 Feb 2007 11:38:10 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 11:38:10 +0100 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: RE: [PCN] 3rd charter Goals and Milestones - QoS model Date: Fri, 16 Feb 2007 11:38:09 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB59@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <01da01c751af$ef9deea0$5b4c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones - QoS model Thread-Index: AcdRr/WK1hDXjFk+S0ajglvV7+ZkvQAAbx6A From: "Geib, Ruediger" To: X-OriginalArrivalTime: 16 Feb 2007 10:38:10.0059 (UTC) FILETIME=[8D57D5B0:01C751B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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 Tina, after having sent my email it came to my mind that I should=20 specify what I'm talking about with regard to a "QoS model".=20 PCN aims on ensuring a low packet loss for DiffServ traffic.=20 Selecting the CL model for the DiffServ section makes a lot=20 of sense, because I think the task of PCN would be=20 significantly harder if is to specify the performance=20 resulting from PCN in terms of "Guaranteed Packet Loss=20 Rates" within the DiffServ region. Now the "QoS model supported" also relates to the service=20 using PCN transport, i.e. the service supported by the per=20 flow signaling protocol terminating at the PCN edge. I don't=20 make assumptions on the QoS model of the "per flow section".=20 I'd prefer PCN to focus on the CL QoS model for the PCN=20 DiffServ domain initially. Once simultaions and operational=20 experience allow to work on quantiyable DiffServ QoS models,=20 PCN could do that too. The simulations performed by Anna and Michael certainly make=20 assumptions on the aggregated traffic and its statistical=20 behaviour. To avoid repeated requests for their (and may be=20 other) simulation results on measurement based admission=20 control, some volunteer may put together references to=20 documents which are helpful to understand PCN. Maybe as part=20 of the architecture or requirements draft? Regards, Ruediger |-----Original Message----- |From: Tina TSOU [mailto:tena@huawei.com] |Sent: Friday, February 16, 2007 10:51 AM |To: Lars.westberg@ericsson.com; Geib, R=FCdiger |Cc: pcn@ietf.org |Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model | | |Ruediger, |That makes sense. And at the time being, we don't have such simulation=20 |results by hand, is it more flexible that we leave it outside=20 |of charter? Or=20 |we could have an informal document to describe how CBR and VBR=20 |co-exist in=20 |PCN? | |B. R. |Tina | |----- Original Message -----=20 |From: "Geib, Ruediger" |To: |Cc: |Sent: Friday, February 16, 2007 4:29 PM |Subject: RE: [PCN] 3rd charter Goals and Milestones - QoS model | | |Lars, | |my take on PCN is that it exploits statistical multiplexing. CBR |traffic could be present, but VBR traffic is preferable. So also |on off sources should be tolerated. Simulation results should |help the WG to decide on acceptable and not acceptable traffic |sources. | |Regards, | |Ruediger | ||-----Original Message----- ||From: Lars Westberg [mailto:Lars.westberg@ericsson.com] ||Sent: Friday, February 16, 2007 8:18 AM ||To: Tina TSOU ||Cc: pcn@ietf.org; Geib, R=FCdiger ||Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model || || ||comments || ||Tina TSOU wrote: || ||> ||> ----- Original Message ----- From: "Magnus Westerlund" ||> ||> To: "Geib, Ruediger" ||> Cc: ||> Sent: Thursday, February 15, 2007 10:49 AM ||> Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model ||> ||> ||>> Geib, Ruediger skrev: ||>> ||>>> Magnus, ||>>> ||>>> then what's a good way to proceed? The current drafts ||propose the CL ||>>> QoS model. The PCN mechanism defined so far is designed to avoid ||>>> packet loss. I like both, CL and the idea to react before packet ||>>> loss occurs, at least with regard to admitted traffic. ||>>> ||>> ||>> With the current charter it would be up to the WG to decide this. ||> ||> I think both are reachable before the target date, allowing ||a bit delay:) || || I think we need to have a better definition because ||controlled load is ||refers to Int.serv models. This solution is based on traffic ||measurement ||and this will give much less "guarantees" than a reservation based ||solution. One simple examples that the approach does not guaratee ||bandwidth for temporary "silent" traffic sources. The best results is ||acheived for "constant-bit rate" sources. || ||> ||>> ||>> ||>>> Should PCN select one QoS model as an example and define how to ||>>> standardise application of PCN for other QoS models? What to do if ||>>> we can't reach consesus on one? ||>>> As an alternative, mechanisms for several QoS models could be ||>>> standardised immediately. That doesn't sound tempting to ||me. On the ||>>> other side, it would preferable if the signaling between boundary ||>>> nodes is able to support different QoS models for which PCN is ||>>> applied. A discussion on "signaling" supporting different "QoS ||>>> models" is delaying progress of the NSIS WG since a couple ||of months ||>>> now. We should make sure that PCN isn't running into ||similar problems. ||>> ||>> ||>> I agree that the WG should focus on a single or very few models. ||>> In regards to the signalling. My understanding is that for certain ||>> usages and certain QoS models the signalling will look radically ||>> different. Thus the signalling should be developed for the model(s) ||>> chosen to work on for now. If you really like to lock down this in ||>> the charter you better get the discussion going. I am not convinced ||>> that this is necessary. ||> ||> On the assumption that we work on CL QoS model and the model "react ||> before packet loss occurs", are we going to have two kinds of ||> signaling at least? I think it could be discussed after the WG is ||> created. And the charter is not excluded is enough by now. ||> ||>> ||>> Cheers ||>> ||>> Magnus Westerlund ||>> ||>> IETF Transport Area Director & TSVWG Chair ||>> ||---------------------------------------------------------------------- ||>> 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 ||>> ||---------------------------------------------------------------------- ||> ||> ||> B. R. ||> Tina ||> ||>> ||>> ||>> _______________________________________________ ||>> 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 | | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 19 08:59:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ93H-0001z6-Bn; Mon, 19 Feb 2007 08:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ8Qo-0008HB-Ui; Mon, 19 Feb 2007 08:19:50 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ8Qo-0001ES-DH; Mon, 19 Feb 2007 08:19:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l1JDJmQa003179; Mon, 19 Feb 2007 15:19:48 +0200 Date: Mon, 19 Feb 2007 15:19:48 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90/2597/Sun Feb 18 22:30:28 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 19 Feb 2007 08:59:34 -0500 Cc: pcn@ietf.org, ietf@ietf.org Subject: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification (pcn) 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 Tue, 13 Feb 2007, IESG Secretary wrote: > [logical components being:] encoding and transport along forward > path from marker to egress, metering of congestion information at > the egress, and transport of congestion information back to the > controlling ingress. I'd like to see it explicitly stated that transporting congestion information in the (metered) IP packets themselves is out of scope. This should exclude designs such as adding IP options en-route, defining new extension headers, or modifying the packets in any, currently undefined way. (I say this explicitly because based on a very quick look at the mailing list archives I saw discussion relating to IP header encoding and it unnerved me.) > Reaction mechanisms at the boundary consist of flow admission and > flow termination. In order to do flow admission, you'll first need to recognize a flow. How do you recognize at the borders (or in the core) which kind of flows should be considered to be treated as PCN? The mechanisms for accomplishing this in an operationally feasible way don't seem to be discussed in the charter. This may be easy if all the traffic you're interested of is using a few predetermined (and configured) protocols and port numbers, but I suspect that is not the case, and layer 7 packet inspection is not an option either.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 19 11:30:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBPF-00027T-15; Mon, 19 Feb 2007 11:30:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBMa-0001av-Q5; Mon, 19 Feb 2007 11:27:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBMY-0000U6-CV; Mon, 19 Feb 2007 11:27:40 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2007 08:27:39 -0800 X-IronPort-AV: i="4.14,191,1170662400"; d="scan'208"; a="390711912:sNHT50101820" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1JGRbgS001755; Mon, 19 Feb 2007 08:27:37 -0800 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 l1JGRUhw022808; Mon, 19 Feb 2007 08:27:37 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 08:27:32 -0800 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 08:27:31 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Mon, 19 Feb 2007 08:27:30 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Feb 2007 16:27:31.0719 (UTC) FILETIME=[DAB49170:01C75442] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2884; t=1171902457; x=1172766457; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20WG=20Review=3A=20Congestion=20and=20Pre-Congestion=20 Notification=20(pcn)=20 |Sender:=20; bh=b7Q4Vm9uQtKzMYBZn3wLiDyNSIQ75ZR8mA1QeDaYx3k=; b=bASp9s/T1/7mCYyfgdVPxqlhg0bZ8wlc+DD7R7JlqHnXzrzKiMpG0KK1wIbp3ZGWeUfW88Ig GYVYBBZ3DK6x9Igp1PX/NACvpV7yAmzKdrNlTSsl4bfUIdhzWz5bi5ci; Authentication-Results: sj-dkim-6; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Mon, 19 Feb 2007 11:30:24 -0500 Cc: pcn@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification (pcn) 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 Feb 19, 2007, at 5:19 AM, Pekka Savola wrote: > I'd like to see it explicitly stated that transporting congestion > information in the (metered) IP packets themselves is out of scope. > This should exclude designs such as adding IP options en-route, > defining new extension headers, or modifying the packets in any, > currently undefined way. (I say this explicitly because based on a > very quick look at the mailing list archives I saw discussion > relating to IP header encoding and it unnerved me.) I dunno, I think that horse is out of the barn. In the TCP arena, the XCP and RCP proposals and RFC 3168 could each be described in those terms, and the pre-congestion notification proposals on the table all encode congestion information in the IP packets, mostly in the ECN field. I'll agree that they should not attempt to insert things into the packet (add an option), but using space already set aside in the packet needs to be on the table. I would like to see some crossover between the TCP/SCTP congestion control proposals and the real-time pre-congestion proposals. That's not a matter of declaring something out of scope as much as it is to encourage thoughtful (and not knee-jerk) consideration of whether and how the two types of needs can be met. The drafts I know to be relevant (you'll note that some are in pwe) are: http://tools.ietf.org/html/draft-babiarz-pcn-sip-cap "SIP Controlled Admission and Preemption", Jozef Babiarz, 16-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, 26-Oct-06, http://tools.ietf.org/html/draft-chan-pcn-problem-statement "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25- Oct-06, http://tools.ietf.org/html/draft-davie-ecn-mpls "Explicit Congestion Marking in MPLS", Bruce Davie, 19-Oct-06, http://tools.ietf.org/html/draft-ietf-pwe3-congestion-frmwk "Pseudowire Congestion Control Framework", Stewart Bryant, 2-Feb-07, http://tools.ietf.org/html/draft-rosen-pwe3-congestion "Pseudowire Congestion Control Framework", Eric Rosen, 19-Oct-06, _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Feb 19 11:50:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBiN-00057g-Hg; Mon, 19 Feb 2007 11:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBiL-00057E-I1; Mon, 19 Feb 2007 11:50:09 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBiK-0004Zf-5I; Mon, 19 Feb 2007 11:50:09 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l1JGo7uS029271; Mon, 19 Feb 2007 11:50:07 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1JGnmma012522; Mon, 19 Feb 2007 11:50:04 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 11:49:38 -0500 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] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Date: Mon, 19 Feb 2007 11:49:37 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Thread-Index: AcdULkRJg46hgOM9Tce3NAkJRmiUlQAFwtZw References: To: , X-OriginalArrivalTime: 19 Feb 2007 16:49:38.0479 (UTC) FILETIME=[F18413F0:01C75445] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.19.81434 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: pcn@ietf.org, ietf@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 Pekka, > > [logical components being:] encoding and transport along forward=20 > > path from marker to egress, metering of congestion information at=20 > > the egress, and transport of congestion information back to the=20 > > controlling ingress. >=20 > I'd like to see it explicitly stated that transporting congestion=20 > information in the (metered) IP packets themselves is out of scope.=20 Forward transport of the basic congestion information has to be in scope as Fred has pointed out. Backwards transport needs to be scoped by application scenario - for example, backwards transport via SIP is clearly out of scope for the initial PCN work. OTOH, not specifying how to actually move any of this information around would turn PCN into the moral equivalent an IRTF Research Group, which (IMHO) would be bad - at the end of the day, PCN needs to produce something that actually works (need "running code" in addition to "rough consensus"). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 20 07:00:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTfL-0002LH-24; Tue, 20 Feb 2007 07:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTfJ-0002L3-4X; Tue, 20 Feb 2007 07:00:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJTfG-0005LO-Gy; Tue, 20 Feb 2007 07:00:13 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2007 04:00:10 -0800 X-IronPort-AV: i="4.14,196,1170662400"; d="scan'208"; a="391089273:sNHT58540944" 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/8.12.11) with ESMTP id l1KC09Gc021630; Tue, 20 Feb 2007 04:00:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1KC07nF003321; Tue, 20 Feb 2007 04:00:07 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 04:00:07 -0800 Received: from [192.168.1.7] ([10.21.152.99]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 04:00:06 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Date: Tue, 20 Feb 2007 07:00:03 -0500 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Feb 2007 12:00:06.0590 (UTC) FILETIME=[A979EDE0:01C754E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5934; t=1171972809; x=1172836809; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20Re=3A=20WG=20Review=3A=20Congestion=20and=20P re-Congestion=20Notification(pcn) |Sender:=20; bh=2unYEPXVuB8zpZ4mgC0uPf4NIw/aL5gR0vlHzAuBTas=; b=OBS85/Fu5To8VJl3Vi8yOxTzrcOfgKG6HJmr/MtF+HuyX+m6OQkXkn9cKU9qMuC3SwTr9tlL 8plq9nXci2POyoXavYeCxdmG1ocFwByGhFzaY8p5Dw7MtIi214yvtNWc; Authentication-Results: sj-dkim-6; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: pcn@ietf.org, ietf@ietf.org, iesg@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 Feb 20, 2007, at 4:51 AM, Pekka Savola wrote: > It seems that are assuming the transport needs to happen in the > packet itself. While this is a possible approach, I don't see that > it needs to be the only one. For example, a mechanism where the > mutually trusting network components would have another channel to > convey this information (e.g., using SNMP, IPFIX, or the like) > might also apply. On this, I would note the history of Source Quench, which could also be described in these terms. Source Quench was originally specified in RFC 777 (and later 792) as an optional communication: A gateway may discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network. If a gateway discards a datagram, it may send a source quench message to the internet source host of the datagram. A destination host may also send a source quench message if datagrams arrive too fast to be processed. The source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination. The gateway may send a source quench message for every message that it discards. On receipt of a source quench message, the source host should cut back the rate at which it is sending traffic to the specified destination until it no longer receives source quench messages from the gateway. The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives source quench messages. The gateway or host may send the source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded. This means that the data datagram which triggered the source quench message may be delivered. From a "building a service" perspective, an optional communication is one I can't rely on receiving, which means that I also have to have some other solution to the problem, which may in turn be adequate in the absence of the optional service. RFC 1009 goes on to make another interesting comment: Two problems for a gateway sending Source Quench are: (1) the consumption of bandwidth on the reverse path, and (2) the use of gateway CPU time. Generating new bandwidth use, and especially taking time away from forwarding datagrams to do so, at a time when there is too much traffic was deemed problematic. We could discuss the history of the SQuID experiment, which did not achieve wide deployment. The comments of KK Ramkrishnan (the inventor of ECN at DEC in the 1980's) in RFC 1254 should be considered as well. Another significant drawback of the Source Quench policy is that its details are discretionary, or, alternatively, that the policy is really a family of varied policies. Major Internet gateway manufacturers have implemented a variety of source quench frequencies. It is impossible for the end-system user on receiving a Source Quench to be certain of the circumstances in which it was issued. This makes the needed end-system response problematic: is the Source Quench an indication of heavy congestion, approaching congestion, a burst causing massive overload, or a burst slightly exceeding reasonable load? To the extent that gateways drop the last arrived datagram on overload, Source Quench messages may be distributed unfairly. This is because the position at the end of the queue may be unfairly often occupied by the packets of low demand, intermittent users, since these do not send regular bursts of packets that can preempt most of the queue space. I'll refer you in the end to the comments of RFC 1812, which I edited by did not write: 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. As specified in Section [4.3.2], a router which does originate Source Quench messages MUST be able to limit the rate at which they are generated. DISCUSSION: Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. A router MAY ignore any ICMP Source Quench messages it receives. DISCUSSION: A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([INTERNET:11], [INTERNET:12]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended. Personally, I would want to ensure that any mechanism used, whether in-band or out-of-band with the communications it applies to, addresses the concerns raised around Source Quench. > However, to be clear, I have no objection to using the ECN field(s) > if that does not hinder the current use (or lack thereof) of ECN. > What I specifically don't want is to define new fields for PCN, > especially extension headers or IP options. I should have been > clearer with my objection. OK, great _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 20 07:31:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJU9p-0001VU-53; Tue, 20 Feb 2007 07:31:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJRei-0007nz-AU; Tue, 20 Feb 2007 04:51:28 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJReg-0008Sr-Q9; Tue, 20 Feb 2007 04:51:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l1K9pEgm031863; Tue, 20 Feb 2007 11:51:14 +0200 Date: Tue, 20 Feb 2007 11:51:14 +0200 (EET) From: Pekka Savola To: Black_David@emc.com Subject: RE: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90/2609/Tue Feb 20 02:28:07 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, L_SPAM_COM_URL, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Tue, 20 Feb 2007 07:31:43 -0500 Cc: pcn@ietf.org, iesg@ietf.org, ietf@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 Mon, 19 Feb 2007, Black_David@emc.com wrote: >>> [logical components being:] encoding and transport along forward >>> path from marker to egress, metering of congestion information at >>> the egress, and transport of congestion information back to the >>> controlling ingress. >> >> I'd like to see it explicitly stated that transporting congestion >> information in the (metered) IP packets themselves is out of scope. > > Forward transport of the basic congestion information has to be in > scope as Fred has pointed out. Backwards transport needs to be scoped > by application scenario - for example, backwards transport via SIP > is clearly out of scope for the initial PCN work. OTOH, not specifying > how to actually move any of this information around would turn PCN > into the moral equivalent an IRTF Research Group, which (IMHO) would > be bad - at the end of the day, PCN needs to produce something that > actually works (need "running code" in addition to "rough consensus"). It seems that are assuming the transport needs to happen in the packet itself. While this is a possible approach, I don't see that it needs to be the only one. For example, a mechanism where the mutually trusting network components would have another channel to convey this information (e.g., using SNMP, IPFIX, or the like) might also apply. However, to be clear, I have no objection to using the ECN field(s) if that does not hinder the current use (or lack thereof) of ECN. What I specifically don't want is to define new fields for PCN, especially extension headers or IP options. I should have been clearer with my objection. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 20 08:15:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJUqA-0007dm-UU; Tue, 20 Feb 2007 08:15:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJUq9-0007dV-II; Tue, 20 Feb 2007 08:15:29 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJUq3-0000mF-Vj; Tue, 20 Feb 2007 08:15:29 -0500 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l1KDFCfP021679; Tue, 20 Feb 2007 14:15:12 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 20 Feb 2007 13:15:11 +0000 To: "Pekka Savola" , "Black_David@emc.com" Subject: RE: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Date: Tue, 20 Feb 2007 13:15:11 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 20 Feb 2007 14:15:12 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "pcn@ietf.org" , "iesg@ietf.org" , "ietf@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 Pekka Regarding your following remark: >However, to be clear, I have no objection to using the ECN field(s) if >that does not hinder the current use (or lack thereof) of ECN. What I >specifically don't want is to define new fields for PCN, especially >extension headers or IP options. I should have been clearer with my >objection. I assume that you also have no objection on using the DSCP fields for this purpose. Best regards, Georgios On 2/20/2007, "Pekka Savola" wrote: >On Mon, 19 Feb 2007, Black_David@emc.com wrote: >>>> [logical components being:] encoding and transport along forward >>>> path from marker to egress, metering of congestion information at >>>> the egress, and transport of congestion information back to the >>>> controlling ingress. >>> >>> I'd like to see it explicitly stated that transporting congestion >>> information in the (metered) IP packets themselves is out of scope. >> >> Forward transport of the basic congestion information has to be in >> scope as Fred has pointed out. Backwards transport needs to be scoped >> by application scenario - for example, backwards transport via SIP >> is clearly out of scope for the initial PCN work. OTOH, not specifying >> how to actually move any of this information around would turn PCN >> into the moral equivalent an IRTF Research Group, which (IMHO) would >> be bad - at the end of the day, PCN needs to produce something that >> actually works (need "running code" in addition to "rough consensus"). > >It seems that are assuming the transport needs to happen in the packet >itself. While this is a possible approach, I don't see that it needs >to be the only one. For example, a mechanism where the mutually >trusting network components would have another channel to convey this >information (e.g., using SNMP, IPFIX, or the like) might also apply. > >However, to be clear, I have no objection to using the ECN field(s) if >that does not hinder the current use (or lack thereof) of ECN. What I >specifically don't want is to define new fields for PCN, especially >extension headers or IP options. I should have been clearer with my >objection. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >_______________________________________________ >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 Feb 20 08:38:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJVCU-0003zs-SY; Tue, 20 Feb 2007 08:38:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJUWq-0005XT-6S; Tue, 20 Feb 2007 07:55:32 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJUWo-00060Y-Vg; Tue, 20 Feb 2007 07:55:32 -0500 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 <0JDR003TBIKI1Z@usaga01-in.huawei.com>; Tue, 20 Feb 2007 04:55:30 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDR002K7IKGGJ@usaga01-in.huawei.com>; Tue, 20 Feb 2007 04:55:30 -0800 (PST) Date: Tue, 20 Feb 2007 06:55:01 -0600 From: Spencer Dawkins Subject: Re: [PCN] Re: WG Review: Congestion and Pre-CongestionNotification(pcn) To: Fred Baker , Pekka Savola Message-id: <02ce01c754ee$56107fe0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Tue, 20 Feb 2007 08:38:33 -0500 Cc: iesg@ietf.org, pcn@ietf.org, ietf@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 FWIW, Fred's retelling of the trail of tears for ICMP Source Quench (as the concept moved from "please do this" to "please don't do this") is also useful, but > From a "building a service" perspective, an optional communication is one > I can't rely on receiving, which means that I also have to have some > other solution to the problem, which may in turn be adequate in the > absence of the optional service. is, I think, his most important point. This was the most critical comment when we were looking at advisory notifications in TRIGTRAN (also trying to "help" with congestion avoidance, but if you can't count on receiving the notifications, you're most likely to fail when there's congestion, and that's exactly the time you need to be most likely to succeed). Thanks, Spencer _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 20 09:31:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJW1m-00058A-8m; Tue, 20 Feb 2007 09:31:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJW1k-00057p-Or; Tue, 20 Feb 2007 09:31:32 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJW1j-0008LW-F9; Tue, 20 Feb 2007 09:31:32 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2007 06:31:31 -0800 X-IronPort-AV: i="4.14,196,1170662400"; d="scan'208"; a="465710951:sNHT46830392" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1KEVUCB028008; Tue, 20 Feb 2007 06:31:30 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1KEVTGk010579; Tue, 20 Feb 2007 06:31:29 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 06:31:29 -0800 Received: from [12.154.71.110] ([10.21.89.182]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 06:31:29 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Date: Tue, 20 Feb 2007 09:31:22 -0500 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Feb 2007 14:31:29.0229 (UTC) FILETIME=[CF26A7D0:01C754FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=668; t=1171981890; x=1172845890; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20Re=3A=20WG=20Review=3A=20Congestion=20and=20P re-Congestion=20Notification(pcn) |Sender:=20; bh=OuCcnHhQWHW7n1X5EjskPuBo1ee1V29DAihzUNxRO2A=; b=fh4gBYy3lxQwGeYo4y6r5yUW2g7Un2gk3ubOj7Wcg4zXwxLXIoosmGZKe/ybVX7hqq+7e/+e Hh+qiiuwVa8RXm2reJ/WcTJ3LqcBSJgYW5U6k6/0+AFloFv3UXAMWc/d; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "iesg@ietf.org" , "pcn@ietf.org" , "ietf@ietf.org" , Pekka Savola 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 Feb 20, 2007, at 8:15 AM, Georgios Karagiannis wrote: > I assume that you also have no objection on using the DSCP fields for > this purpose. actually, I do, at least in some ways that they might be used. The AF service (RFC 2597) is specifically designed to do as you say; EF isn't. setting the DSCP on an EF packet in a way that nullifies its EF behavior to communicate the onset of congestion mostly nullifies the EF service (which doesn't actually do much of anything when there is no congestion to perturb packet timing). So I would want any use of the DSCP to be coordinated with the other services that the datagram hopes for. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 21 04:00:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnLE-0003dr-Ed; Wed, 21 Feb 2007 04:00:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnLD-0003dc-17; Wed, 21 Feb 2007 04:00:47 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJnLB-0004GV-KS; Wed, 21 Feb 2007 04:00:47 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l1L90NDM012921; Wed, 21 Feb 2007 10:00:35 +0100 (MET) From: "Georgios Karagiannis" To: "'Fred Baker'" References: Subject: RE: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Date: Wed, 21 Feb 2007 10:00:18 +0100 Message-ID: <000001c75596$ba882b50$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdU+9RhJRL0w4P7TEWDtiWzNd0ebwAmqrHg X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 21 Feb 2007 10:00:36 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: iesg@ietf.org, pcn@ietf.org, ietf@ietf.org, 'Pekka Savola' 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 Fred I think that one of the goals of the PCN WG will be to investigate the implications of using ECN and/or DSCP for PCN encoding purposes. Best Regards, Georgios > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: dinsdag 20 februari 2007 15:31 > To: Georgios Karagiannis > Cc: Pekka Savola; Black_David@emc.com; pcn@ietf.org; > iesg@ietf.org; ietf@ietf.org > Subject: Re: [PCN] Re: WG Review: Congestion and > Pre-Congestion Notification(pcn) > > > On Feb 20, 2007, at 8:15 AM, Georgios Karagiannis wrote: > > > I assume that you also have no objection on using the DSCP > fields for > > this purpose. > > actually, I do, at least in some ways that they might be > used. The AF service (RFC 2597) is specifically designed to > do as you say; EF isn't. setting the DSCP on an EF packet in > a way that nullifies its EF behavior to communicate the onset > of congestion mostly nullifies the EF service (which doesn't > actually do much of anything when there is no congestion to > perturb packet timing). So I would want any use of the DSCP > to be coordinated with the other services that the datagram hopes for. > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 21 05:13:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoTM-0007AI-Bp; Wed, 21 Feb 2007 05:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoTK-00079v-BS; Wed, 21 Feb 2007 05:13:14 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJoTI-0007Cn-Si; Wed, 21 Feb 2007 05:13:14 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1LA8wgl011048; Wed, 21 Feb 2007 12:09:18 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 12:12:52 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 12:12:52 +0200 Received: from [10.140.224.6] (essapo-nirac252168.europe.nokia.com [10.162.252.168]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1LA84Em009630; Wed, 21 Feb 2007 12:09:14 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <82D42A1B-D57A-41C5-9400-12E7206216D2@nokia.com> From: Lars Eggert Subject: Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) Date: Wed, 21 Feb 2007 10:12:01 +0200 To: ext Pekka Savola X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Feb 2007 10:12:53.0370 (UTC) FILETIME=[D96435A0:01C755A0] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070221120918-2B12FBB0-23C599DE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pcn@ietf.org, ietf@ietf.org, iesg@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="===============0140367747==" Errors-To: pcn-bounces@ietf.org --===============0140367747== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-43-464793260; protocol="application/pkcs7-signature" --Apple-Mail-43-464793260 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-20, at 11:51, ext Pekka Savola wrote: > It seems that are assuming the transport needs to happen in the > packet itself. While this is a possible approach, I don't see that > it needs to be the only one. For example, a mechanism where the > mutually trusting network components would have another channel to > convey this information (e.g., using SNMP, IPFIX, or the like) > might also apply. > > However, to be clear, I have no objection to using the ECN field(s) > if that does not hinder the current use (or lack thereof) of ECN. > What I specifically don't want is to define new fields for PCN, > especially extension headers or IP options. I should have been > clearer with my objection. Right, there are multiple ways to encode and transport congestion information to and from the egress. The charter has a milestone for the WG to discuss various options before picking one for the initial standards-track documents: Nov 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain (Informational) Lars --Apple-Mail-43-464793260 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjEwODEyMDFaMCMGCSqGSIb3DQEJBDEWBBRUueHRrEYbck+9 pEVScwCbXFvu0TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAeR66WfRTmyFTD9HMJ79sJN+aEwgE2pbpHkl9bKizEd7R7y/e5/c8 AEnJfsq+nUthByXHOFJ9wSDa2QtVsKgpEJDmQ9MdJeHGp/CVSyRodIMCoZ6MyNDrf9AW6axW7m6O 9VyekboElPQxNLuhnScmxctcaVmTyX5xaSryXXQaUSelWiYb/IeXHZAXlzcmYrWix7FifUtAERjJ 1KTM6+jz0rFLh7GPT/KYE03Q2I8yGyzTFJVbDZhVeLQTOQKBdh4JoaNeQYTG5TL4i2NJVLZpg4eJ nmqIeu2AqjznTiSK1JiIt+FeoB7F9hYxTiAsXTmnzPnuq2q165xMCYPx28t4uAAAAAAAAA== --Apple-Mail-43-464793260-- --===============0140367747== 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 --===============0140367747==-- From pcn-bounces@ietf.org Wed Feb 21 05:46:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJozf-0007Iz-UO; Wed, 21 Feb 2007 05:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoze-0007In-AE; Wed, 21 Feb 2007 05:46:38 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJozd-0004UQ-15; Wed, 21 Feb 2007 05:46:38 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1LAkZEf031704; Wed, 21 Feb 2007 05:46:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Feb 2007 12:46:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Congestion and Pre-Congestion Notification (pcn) Thread-Index: AcdUKK23TvCtKtHURc2s64MbAJQCtwBfKmHQ References: From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: pcn@ietf.org Subject: [PCN] RE: WG Review: Congestion and Pre-Congestion Notification (pcn) 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 It would be useful to make clear in the charter what the dates in Goals and Milestones mean (submissions from the WG to the IESG?) Dan _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Feb 21 06:52:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJq1U-0006jO-9X; Wed, 21 Feb 2007 06:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJogZ-0005x9-19; Wed, 21 Feb 2007 05:26:55 -0500 Received: from mtagate8.uk.ibm.com ([195.212.29.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJogX-0001qI-KH; Wed, 21 Feb 2007 05:26:55 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l1LAQqcc213136; Wed, 21 Feb 2007 10:26:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1LAQqIh1302634; Wed, 21 Feb 2007 10:26:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1LAQp4S005968; Wed, 21 Feb 2007 10:26:52 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1LAQpUD005873; Wed, 21 Feb 2007 10:26:51 GMT Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA364540; Wed, 21 Feb 2007 11:26:50 +0100 Message-ID: <45DC1E68.60208@zurich.ibm.com> Date: Wed, 21 Feb 2007 11:26:48 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Fred Baker Subject: Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Wed, 21 Feb 2007 06:52:34 -0500 Cc: Pekka Savola , "iesg@ietf.org" , "pcn@ietf.org" , "ietf@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 2007-02-20 15:31, Fred Baker wrote: > > On Feb 20, 2007, at 8:15 AM, Georgios Karagiannis wrote: > >> I assume that you also have no objection on using the DSCP fields for >> this purpose. > > actually, I do, at least in some ways that they might be used. The AF > service (RFC 2597) is specifically designed to do as you say; EF isn't. > setting the DSCP on an EF packet in a way that nullifies its EF behavior > to communicate the onset of congestion mostly nullifies the EF service > (which doesn't actually do much of anything when there is no congestion > to perturb packet timing). So I would want any use of the DSCP to be > coordinated with the other services that the datagram hopes for. Exactly. The allowed uses of the DSCP are constrained by RFC 2474 and PCN can't go outside those constraints without causing unpredictable breakage. That needs to be explicit in the charter, I believe. While I'm writing, consider this assumption: > (A) these components are deployed in a single DiffServ domain, > where all boundary and interior nodes are PCN-enabled and > mutually trust each other That is fine from the point of view of the diffserv architecture, which is strictly domain-based. However, it isn't a get out of jail card for security: BCP 61 (RFC 3365) still applies. The comment about mutual trust should probably be removed. Brian _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Feb 27 07:54:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1qK-0004uP-9e; Tue, 27 Feb 2007 07:54:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1qJ-0004uK-EO for pcn@ietf.org; Tue, 27 Feb 2007 07:54:07 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1qH-0002G5-UU for pcn@ietf.org; Tue, 27 Feb 2007 07:54:07 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 27 Feb 2007 13:54:04 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:53:49 +0100 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: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification (pcn) Date: Tue, 27 Feb 2007 13:54:03 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFB84@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <01da01c751af$ef9deea0$5b4c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 3rd charter Goals and Milestones - QoS model Thread-Index: AcdRr/WK1hDXjFk+S0ajglvV7+ZkvQAAbx6A From: "Geib, Ruediger" To: X-OriginalArrivalTime: 27 Feb 2007 12:53:49.0366 (UTC) FILETIME=[534AC560:01C75A6E] 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 Fred, TCP or "unknown" Pseudo Wire traffic and PCN real time traffic=20 will not share the same queues. Your proposal wants to suggest=20 a common mechanism resulting in traffic passing one queue to=20 be marked by a PCN/ECN codepoint? May be also the determination=20 of the rate of congestion marked traffic between an ingress=20 and egress edge could be shared. Parts of the feed back mechanism=20 between egress and ingress edge may be agreed to. The control=20 plane more likely differs, so does the interpretation and=20 reaction on a congestion indication.=20 Should the above be possible, a router could apply the same=20 basic congestion indication and evaluation mechanisms for=20 different traffic types. Queuing and the reaction on the=20 congestion indication would remain traffic type specific. Would this rough description point to the right direction? Regards, Ruediger ---------Text excerpt from a reply of Fred Baker to Pekka Savola--- # From: Fred Baker # Date: Mon, 19 Feb 2007 08:27:30 -0800 I dunno, I think that horse is out of the barn. In the TCP arena,=20 the XCP and RCP proposals and RFC 3168 could each be described in=20 those terms, and the pre-congestion notification proposals on the=20 table all encode congestion information in the IP packets, mostly=20 in the ECN field. I'll agree that they should not attempt to=20 insert things into the packet (add an option), but using space=20 already set aside in the packet needs to be on the table. I would like to see some crossover between the TCP/SCTP congestion=20 control proposals and the real-time pre-congestion proposals.=20 That's not a matter of declaring something out of scope as much as=20 it is to encourage thoughtful (and not knee-jerk) consideration of=20 whether and how the two types of needs can be met. The drafts I know to be relevant (you'll note that some are in pwe)=20 are: http://tools.ietf.org/html/draft-babiarz-pcn-sip-cap "SIP Controlled Admission and Preemption", Jozef Babiarz, 16-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture "An edge-to-edge Deployment Model for Pre-Congestion Notification: = Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, 26-Oct-06, http://tools.ietf.org/html/draft-chan-pcn-problem-statement "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25- = Oct-06, http://tools.ietf.org/html/draft-davie-ecn-mpls "Explicit Congestion Marking in MPLS", Bruce Davie, 19-Oct-06, http://tools.ietf.org/html/draft-ietf-pwe3-congestion-frmwk "Pseudowire Congestion Control Framework", Stewart Bryant, 2-Feb-07, http://tools.ietf.org/html/draft-rosen-pwe3-congestion "Pseudowire Congestion Control Framework", Eric Rosen, 19-Oct-06, _______________________________________________ PCN mailing list PCN at 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 Feb 27 11:26:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5A3-0007eO-DZ; Tue, 27 Feb 2007 11:26:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5A1-0007dU-St for pcn@ietf.org; Tue, 27 Feb 2007 11:26:41 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM5A0-0002KE-5s for pcn@ietf.org; Tue, 27 Feb 2007 11:26:41 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2007 08:26:39 -0800 X-IronPort-AV: i="4.14,226,1170662400"; d="txt'?scan'208"; a="116501802:sNHT98941518" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1RGQdnc027922; Tue, 27 Feb 2007 08:26:39 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1RGQdUw027787; Tue, 27 Feb 2007 08:26:39 -0800 (PST) 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); Tue, 27 Feb 2007 08:26:39 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 08:26:38 -0800 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFB84@S4DE8PSAAFQ.mitte.t-com.de> References: <6439282641581441A36F7F6F83ED2ED2CBFB84@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/mixed; boundary=Apple-Mail-15-1012870135 Message-Id: <507424C8-EA50-4DE5-9040-682063AC6A42@cisco.com> From: Fred Baker Subject: Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification (pcn) Date: Tue, 27 Feb 2007 08:26:38 -0800 To: "Geib, Ruediger" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Feb 2007 16:26:38.0524 (UTC) FILETIME=[0E4DA7C0:01C75A8C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9981; t=1172593599; x=1173457599; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20Re=3A=20WG=20Review=3A=20Congestion=20and=20P re-Congestion=20Notification=20(pcn) |Sender:=20; bh=nwz/5U1VTZJzMo/uw2ZGcWPINx21iF7REdqcHs2D9D0=; b=Y/10ia3eyGmU9MDtrHKwkEJ+LUO7PLx9O5/8Uj3nZRHqekGGVzyEo8CxrOtEFd7/Z6dSSDK1 9AwyZXSbgywrRnz6XKhvMvolQvR6dX+JiCAkkEjIjFM7LOxzG3eBPDCnzNbQo78g+wFQ7wDfSp R8SSaaMmUqhjU+WbotqzKc6bk=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae 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 --Apple-Mail-15-1012870135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 27, 2007, at 4:54 AM, Geib, Ruediger wrote: > TCP or "unknown" Pseudo Wire traffic and PCN real time traffic will > not share the same queues. In the vast majority of the network today, they do in fact share the same queues, and I'm not sure I can say that this will change any time soon. My concern is this. The equipment folks buy and install in networks doesn't come pre-configured with any complex policy. Cisco product has something called "AutoQoS" that will - when requested to - install a certain policy, but that policy is pretty limited. Generally speaking, the initial policy is "FIFO, Tall Drop", and anything else that needs to happen has to be configured. So you can't assume that all interfaces in the Internet are configured in the same way. They will be configured in the way their network administration wants them configured, and anything different than default is likely to be something someone paid them to do and which they believe materially affects their network's ability to deliver that stated service. I have attached two configurations for generic Cisco equipment. One is to deploy the classes specified in RFC 4594, which is the set of classes we believe are appropriate to an access link. The other is for the Core-facing links. Note that both are significantly more complex than are currently deployed by default. --Apple-Mail-15-1012870135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-mac-type=54455854; x-unix-mode=0644; x-mac-creator=21526368; name=rfc4594-config.txt Content-Disposition: attachment; filename=rfc4594-config.txt ! ! Configuration to implement RFC 4594 classes, the EF-ADMIT class ! defined in draft-ietf-tsvwg-admitted-realtime-dscp, and a ! "preferred" service class as described to US DoD in November 2004. ! class-map match-any Telephony-admit description requires RSVP implementation as well match ip dscp 44 class-map match-any Telephony description Telephony class as described in RFC 4592 match ip dscp ef class-map match-any Routing description Network Control class as described in RFC 4592 match ip dscp cs6 class-map match-any Signaling description Telephony Signaling class as described in RFC 4592 match ip dscp cs5 class-map match-any RT_Interactive description Realtime Interactive class as described in RFC 4592 match ip dscp cs4 class-map match-any Bcst_Video description Broadcast Video class as described in RFC 4592 match ip dscp cs3 class-map match-any OAM description Realtime Interactive class as described in RFC 4592 match ip dscp cs2 class-map match-any Scavenger description Low Priority Data class as described in RFC 4592 match ip dscp cs1 class-map match-any High_Throughput_Data description High Throughput Data class as described in RFC 4592 match ip dscp af11 match ip dscp af12 match ip dscp af13 class-map match-any Low_Latency_Data description Low Latency Data class as described in RFC 4592 match ip dscp af21 match ip dscp af22 match ip dscp af23 class-map match-any Multimedia_Streaming description Multimedia Streaming class as described in RFC 4592 match ip dscp af31 match ip dscp af32 match ip dscp af33 class-map match-any RT_Multimedia description Realtime Multimedia class as described in RFC 4592 match ip dscp af41 match ip dscp af42 match ip dscp af43 class-map match-any Preferred description uses local use code points as specified in RFC 2474 match ip dscp 11 match ip dscp 13 match ip dscp 15 ! ! policy-map rfc4594_egress_with_admit_and_preferred class Telephony-admit priority percent 10 class Telephony priority percent 10 class Routing bandwidth percent 1 random-detect random-detect ecn class Signaling bandwidth percent 1 random-detect random-detect ecn class RT_Interactive bandwidth percent 10 class Bcst_Video bandwidth percent 10 class OAM bandwidth percent 10 class Scavenger random-detect random-detect ecn class Preferred bandwidth percent 10 random-detect dscp-based random-detect ecn random-detect dscp 11 20 40 10 random-detect dscp 13 10 20 10 random-detect dscp 15 5 10 10 class High_Throughput_Data bandwidth percent 10 random-detect dscp-based random-detect ecn random-detect dscp 10 20 40 10 random-detect dscp 12 10 20 10 random-detect dscp 14 5 10 10 class Low_Latency_Data bandwidth percent 10 random-detect dscp-based random-detect ecn random-detect dscp 18 20 40 10 random-detect dscp 20 10 20 10 random-detect dscp 22 5 10 10 class Multimedia_Streaming bandwidth percent 10 random-detect dscp-based random-detect ecn random-detect dscp 26 20 40 10 random-detect dscp 28 10 20 10 random-detect dscp 30 5 10 10 class RT_Multimedia bandwidth percent 10 random-detect dscp-based random-detect ecn random-detect dscp 34 20 40 10 random-detect dscp 36 10 20 10 random-detect dscp 38 5 10 10 class class-default random-detect random-detect ecn ! ! interface Serial0/0 service-policy output rfc4594_egress_with_admit_and_preferred ip rsvp bandwidth 128 128 ip rsvp signalling dscp 40 ! --Apple-Mail-15-1012870135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-mac-type=54455854; x-unix-mode=0644; x-mac-creator=21526368; name=draft-ietf-tsvwg-diffserv-class-aggr-config.txt Content-Disposition: attachment; filename=draft-ietf-tsvwg-diffserv-class-aggr-config.txt ! ! Configuration to implement ! draft-ietf-tsvwg-diffserv-class-aggr classes, the EF-ADMIT class ! defined in draft-ietf-tsvwg-admitted-realtime-dscp, and a ! "preferred" service class as described to US DoD in November 2004. ! class-map match-any Telephony-admit description requires RSVP implementation as well match ip dscp 44 class-map match-any Realtime-core description Telephony class as described in RFC 4592 match ip dscp ef description Realtime Interactive class as described in RFC 4592 match ip dscp cs4 description Broadcast Video class as described in RFC 4592 match ip dscp cs3 description Realtime Multimedia class as described in RFC 4592 match ip dscp af41 match ip dscp af42 match ip dscp af43 class-map match-any Routing-core description Network Control class as described in RFC 4592 match ip dscp cs6 class-map match-any AF_Data-core description High Throughput Data class as described in RFC 4592 match ip dscp af11 match ip dscp af12 match ip dscp af13 description Low Latency Data class as described in RFC 4592 match ip dscp af21 match ip dscp af22 match ip dscp af23 description Multimedia Streaming class as described in RFC 4592 match ip dscp af31 match ip dscp af32 match ip dscp af33 class-map match-any Preferred description uses local use code points as specified in RFC 2474 match ip dscp 11 match ip dscp 13 match ip dscp 15 ! ! policy-map rfc4594_egress_with_admit_and_preferred class Telephony-admit priority percent 10 class Realtime-core priority percent 20 class Routing random-detect random-detect ecn class Preferred bandwidth percent 20 random-detect dscp-based random-detect ecn random-detect dscp 11 20 40 10 random-detect dscp 13 10 20 10 random-detect dscp 15 5 10 10 class AF_Data-core bandwidth percent 20 random-detect dscp-based random-detect ecn random-detect dscp 10 20 40 10 random-detect dscp 12 10 20 10 random-detect dscp 14 5 10 10 random-detect dscp 18 20 40 10 random-detect dscp 20 10 20 10 random-detect dscp 22 5 10 10 random-detect dscp 26 20 40 10 random-detect dscp 28 10 20 10 random-detect dscp 30 5 10 10 random-detect dscp 34 20 40 10 random-detect dscp 36 10 20 10 random-detect dscp 38 5 10 10 class class-default priority percent 10 random-detect random-detect ecn ! ! interface Serial0/0 service-policy output rfc4594_egress_with_admit_and_preferred ip rsvp bandwidth 128 128 ip rsvp signalling dscp 40 ! --Apple-Mail-15-1012870135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed You'll notice that ECN has to be turned on. Implication: in the general case it is not turned on. You are proposing that the ECN implementation differ by service class. If the service classes aren't uniformly configured, explain to me how this works? > Your proposal wants to suggest a common mechanism resulting in > traffic passing one queue to be marked by a PCN/ECN codepoint? I want one marking algorithm that can be applied to all traffic in the backbone and be interpreted by the edge device resulting in it doing the right thing. Note that the right thing differs by service class - a G.711 codec isn't going to send less data because someone in the network is signaling congestion, but TCP will, and that is a huge difference. --Apple-Mail-15-1012870135 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 --Apple-Mail-15-1012870135-- From pcn-bounces@ietf.org Wed Feb 28 15:52:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVmk-0003cV-Gb; Wed, 28 Feb 2007 15:52:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVkS-0006vD-H6; Wed, 28 Feb 2007 15:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMVkQ-0001d3-Cg; Wed, 28 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 53CBA328EB; Wed, 28 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMVkQ-0004u4-61; Wed, 28 Feb 2007 15:50:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 28 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-Mailman-Approved-At: Wed, 28 Feb 2007 15:52:23 -0500 Cc: Steven Blake , pcn@ietf.org Subject: [PCN] WG Action: Congestion and Pre-Congestion Notification (pcn) 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 A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Congestion and Pre-Congestion Notification (pcn) ================================================= Current Status: Active Working Group Chair(s): Scott Bradner (sob@harvard.edu) Steven Blake (steven.blake@ericsson.com) Transport Area Director(s): Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@nokia.com) Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. To allow for future extensions to the mechanisms and their application to new deployment scenarios, they are logically separated into several components, namely, encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. The WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and domain egress (4) metering of (pre-)congestion information at the domain egress (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the marking behavior and encoding and transport mechanisms needed to realize the overall PCN architecture. Standards- track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. All PCN mechanisms, including transport and encoding of (pre-congestion) information, are required to cleanly integrate with existing architectures and protocols such as DiffServ and ECN. If the PCN WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and trust each other for correct PCN marking, encoding, transport and aggregation (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/ termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Nov 2007 Submit "Flow Admission and Termination Architecture" to the IESG for consideration as an Informational RFC Nov 2007 Submit "Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain" to the IESG for consideration as an Informational RFC Mar 2008 Submit "Flow Admission and Termination within a DiffServ Domain" to the IESG for consideration as an Informational RFC Mar 2008 Submit "(Pre-)Congestion Detection within a DiffServ Domain" to the IESG for consideration as a Proposed Standard RFC Mar 2008 Submit "Requirements for Signaling of (Pre-)Congestion Information from Egress to Ingress in a DiffServ Domain" to the IESG for consideration as a Informational RFC Jul 2008 Submit "Encoding and Transport of (Pre-)Congestion Information from within a DiffServ Domain to the Egress" to the IESG for consideration as a Proposed Standard RFC Nov 2008 Submit "Encoding and Transport of (Pre-)Congestion Information from the Domain Egress to the Ingress" to the IESG for consideration as a Proposed Standard RFC Jul 2008 Submit "Suggested Flow Admission and Termination Boundary Mechanisms" to the IESG for consideration as an Informational RFC _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn