From pcn-bounces@ietf.org Sun Nov 05 12:03:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglP1-0006QD-Cb; Sun, 05 Nov 2006 12:03:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglP0-0006Q7-AL for pcn@ietf.org; Sun, 05 Nov 2006 12:03:22 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglOu-0002EO-T2 for pcn@ietf.org; Sun, 05 Nov 2006 12:03:22 -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 kA5H2uAh004228 for ; Sun, 5 Nov 2006 17:02:56 GMT Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 17:02:56 +0000 From: "Robert Hancock" To: Date: Sun, 5 Nov 2006 09:03:14 -0800 Message-ID: <007501c700fc$49185b00$0ffa12ac@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: <4513E837.4020301@informatik.uni-wuerzburg.de> X-OriginalArrivalTime: 05 Nov 2006 17:02:56.0421 (UTC) FILETIME=[3D56DD50:01C700FC] 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: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [PCN] a question on PCN scope 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've just been reading the problem statement, and there is still one question about PCN (as a WG) which I am unclear about. I know this has = been discussed on the list but the text which is actually available is still = hard for me to interpret.=20 Problem 3 on the charter is "3. How should these markings (at packet granularity) be converted into=20 admission control and flow pre-emption decisions (at flow = granularity)?" What does 'converted into ... decisions' actually mean? This could potentially cover a huge range of things to do with network dimensioning = and planning, risk/benefit tradeoffs of admitting when close to capacity, pre-emption flow selection policies, and so on. To a large extent, these seem to be orthogonal to the other parts of the PCN story. Indeed, one = can imagine many ways to find out what is going on in the interior of a = network at the aggregate level (tunnel or diffserv aggregation for example), = which are clearly different to points 1 and 2 on the charter, but which would possibly invoke exactly the same functionality under point 3. It would = seem a bad thing if every aggregation mechanism defined its own algorithms = for CAC/pre-mption of flows within the aggregate. Does point 3 mean more than "How do we turn individual markings into a = CLE which the egress can then do what it likes with?" If so, what? cheers, Robert H. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Nov 05 12:04:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglPn-0006UT-RS; Sun, 05 Nov 2006 12:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglPn-0006UO-5M for pcn@ietf.org; Sun, 05 Nov 2006 12:04:11 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglPl-0002J3-Ni for pcn@ietf.org; Sun, 05 Nov 2006 12:04:11 -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 kA5H44XX004393 for ; Sun, 5 Nov 2006 17:04:04 GMT Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 17:04:04 +0000 From: "Robert Hancock" To: Date: Sun, 5 Nov 2006 09:04:23 -0800 Message-ID: <007601c700fc$71bb7e20$0ffa12ac@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: <4513E837.4020301@informatik.uni-wuerzburg.de> X-OriginalArrivalTime: 05 Nov 2006 17:04:04.0593 (UTC) FILETIME=[65F91610:01C700FC] 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: 082a9cbf4d599f360ac7f815372a6a15 Subject: [PCN] a couple of questions on PCN engineering 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, Reading the latest versions of the drafts (especially cl-phb and cl-architecture) I have a couple of questions about how this all works. Superficially, I can't tell if these have been discussed on the list up = to now (apologies if they have). 1. So far as I can tell, there are (at least) two smoothing mechanisms = in effect: - the 1 or 2 marking thresholds in the virtual queue, or (very roughly equivalently) the bucket size in the token bucket, which apply at the interior nodes (PINs) and - the EWMA process which applies at the egress edge node (PEN) Both these mechanisms have the rough effect that a "short" traffic burst will have a "small" effect on the CLE. If these mechanisms are = parametrised to operate on different timescales, it would seem that one will have no effect. If they are parametrised to operate on the same timescale, it = would seem to make the whole system much harder to analyse. (I think I recall similar questions in the context of RED for TFRC but I can't find the reference right now.) Or is the purpose of the EWMA stage purely to turn the sequence of = binary 1-0 markings into a real number, over the shortest timescale possible, = with no intention to smooth over time? (In which case, that would be helpful = to clarify in the draft. For example, TEWMA would presumably be no benefit = for this functionality.) 2. My understanding, at least of the virtual queue approach, is that the overall approach is that for each link there is a regime in which a proportion 0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] a question on PCN scope Thread-Index: AccA/Gih/k/XwEDfQGmSPSeFLYvUwgADqb9Q From: "Anna Charny \(acharny\)" To: "Robert Hancock" , X-OriginalArrivalTime: 05 Nov 2006 19:02:17.0929 (UTC) FILETIME=[E9EE4390:01C7010C] DKIM-Signature: a=rsa-sha1; q=dns; l=2804; t=1162753338; x=1163617338; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20a=20question=20on=20PCN=20scope |To:=22Robert=20Hancock=22=20,=20; X=v=3Dcisco.com=3B=20h=3DNMwtLkUFBxvrRkQn8TxgysL2Y4k=3D; b=JjLl4aoNTYKn4xdO6HmAucwP7E1ws9pESAvVhsO0xPQbRb9wM1CGn94srFouXuYQxy1Z9svf RKPbxUlFDGdHZioLbSrBuR0D+r8xWTecz93UBx3gI3JhTG4/eNzKtfOp; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Robert, The question in the problem statement you refer to=20 "3. How should these markings (at packet granularity) be converted into=20 admission control and flow pre-emption decisions (at flow granularity)?" means, in my opinion, the following: 1) how should the measurement at the egress be done to get a CLE or a sustainable pre-emption rate (one example of each in cl-phb draft) - but more importantly - what exactly about these measurements that needs to be standardized? 2) once the CLE and/or sustainable aggregate rate are computed and communicated to the ingress - what exactly does the ingress do with this info - and most importantly how much of this needs to be standardized? The current drafts (cl-architecture and cl-phb) give possible answers to how/what can be done wrt to the mechanisms at the ingress/egress. What the WG (if created) needs to decide, IMHO, is to what extent these behaviors need to be standardized, and how much flexibility can be left to the implementation. Does this answer your question? Anna=20 -----Original Message----- From: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 Sent: Sunday, November 05, 2006 12:03 PM To: pcn@ietf.org Subject: [PCN] a question on PCN scope Hi, I've just been reading the problem statement, and there is still one question about PCN (as a WG) which I am unclear about. I know this has been discussed on the list but the text which is actually available is still hard for me to interpret.=20 Problem 3 on the charter is "3. How should these markings (at packet granularity) be converted into=20 admission control and flow pre-emption decisions (at flow granularity)?" What does 'converted into ... decisions' actually mean? This could potentially cover a huge range of things to do with network dimensioning and planning, risk/benefit tradeoffs of admitting when close to capacity, pre-emption flow selection policies, and so on. To a large extent, these seem to be orthogonal to the other parts of the PCN story. Indeed, one can imagine many ways to find out what is going on in the interior of a network at the aggregate level (tunnel or diffserv aggregation for example), which are clearly different to points 1 and 2 on the charter, but which would possibly invoke exactly the same functionality under point 3. It would seem a bad thing if every aggregation mechanism defined its own algorithms for CAC/pre-mption of flows within the aggregate. Does point 3 mean more than "How do we turn individual markings into a CLE which the egress can then do what it likes with?" If so, what? cheers, Robert H. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Nov 05 19:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgsWC-0000Pc-9X; Sun, 05 Nov 2006 19:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgsWB-0000PS-IZ for pcn@ietf.org; Sun, 05 Nov 2006 19:39:15 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgsW7-00033y-Sf for pcn@ietf.org; Sun, 05 Nov 2006 19:39:15 -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 kA60ceha015868; Mon, 6 Nov 2006 00:38:40 GMT Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 00:38:40 +0000 From: "Robert Hancock" To: "'Anna Charny \(acharny\)'" , Subject: RE: [PCN] a question on PCN scope Date: Sun, 5 Nov 2006 16:39:00 -0800 Message-ID: <00a901c7013b$f498eeb0$0ffa12ac@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 06 Nov 2006 00:38:40.0544 (UTC) FILETIME=[E7B4EA00:01C7013B] 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: 5ebbf074524e58e662bc8209a6235027 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, > Hi Robert, > > The question in the problem statement you refer to > > "3. How should these markings (at packet granularity) be > converted into > admission control and flow pre-emption decisions (at flow > granularity)?" > > means, in my opinion, the following: > > 1) how should the measurement at the egress be done to get a > CLE or a sustainable pre-emption rate (one example of each in > cl-phb draft) - but more importantly - what exactly about > these measurements that needs to be standardized? i think it's clear that this needs to be done as an integrated activity with the other parts of PCN work (i.e. problems 1 and 2 from the outline charter), or at least that it's reasonable to do so. > > 2) once the CLE and/or sustainable aggregate rate are > computed and communicated to the ingress - what exactly does > the ingress do with this info - and most importantly how much > of this needs to be standardized? this is the bit that I am unclear about. i suppose there could be two ways of approaching the question: a) finding out and documenting that the PCN approach to managing the domain interior places certain constraints on the policy and mechanisms that control ingress and egress operation. this seems to me to be important to understand as part of the overall PCN work. b) beyond this, mandating particular signalling mechanisms or cac/pre-emption policies and mechanisms. I can see that this is interesting and maybe even needs to be standardised, but if it doesn't have to be hard-wired to the rest of the PCN technology I'm not sure whether it is a good idea to do this at the same time and in the same place as the rest of the PCN work. > > The current drafts (cl-architecture and cl-phb) give possible > answers to how/what can be done wrt to the mechanisms at the > ingress/egress. What the WG (if created) needs to decide, > IMHO, is to what extent these behaviors need to be > standardized, and how much flexibility can be left to the > implementation. > > Does this answer your question? It certainly clarifies it. cheers, robert h. > > Anna > > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > Sent: Sunday, November 05, 2006 12:03 PM > To: pcn@ietf.org > Subject: [PCN] a question on PCN scope > > Hi, > > I've just been reading the problem statement, and there is > still one question about PCN (as a WG) which I am unclear > about. I know this has been discussed on the list but the > text which is actually available is still hard for me to interpret. > > Problem 3 on the charter is > > "3. How should these markings (at packet granularity) be > converted into > admission control and flow pre-emption decisions (at flow > granularity)?" > > What does 'converted into ... decisions' actually mean? This > could potentially cover a huge range of things to do with > network dimensioning and planning, risk/benefit tradeoffs of > admitting when close to capacity, pre-emption flow selection > policies, and so on. To a large extent, these seem to be > orthogonal to the other parts of the PCN story. Indeed, one > can imagine many ways to find out what is going on in the > interior of a network at the aggregate level (tunnel or > diffserv aggregation for example), which are clearly > different to points 1 and 2 on the charter, but which would > possibly invoke exactly the same functionality under point 3. > It would seem a bad thing if every aggregation mechanism > defined its own algorithms for CAC/pre-mption of flows within > the aggregate. > > Does point 3 mean more than "How do we turn individual > markings into a CLE which the egress can then do what it > likes with?" If so, what? > > cheers, > > Robert H. > > > _______________________________________________ > PCN mailing 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 Nov 06 12:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8Ta-0008CV-32; Mon, 06 Nov 2006 12:41:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh843-0007G0-Kr for pcn@ietf.org; Mon, 06 Nov 2006 12:15:15 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh841-0005NG-FF for pcn@ietf.org; Mon, 06 Nov 2006 12:15:15 -0500 Received: from lars.local (dhcp70-102.ietf67.org [130.129.70.102]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AB9F613CF84 for ; Mon, 6 Nov 2006 18:17:26 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id A320A27EC10 for ; Mon, 6 Nov 2006 09:15:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) To: pcn@ietf.org Message-Id: <64C52B99-3B10-4F70-86AE-FDE5DC13D438@netlab.nec.de> From: Lars Eggert Date: Mon, 6 Nov 2006 09:15:04 -0800 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Mon, 06 Nov 2006 12:41:36 -0500 Subject: [PCN] use tsvarea jabber room for 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: , Content-Type: multipart/mixed; boundary="===============0100203116==" Errors-To: pcn-bounces@ietf.org --===============0100203116== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--157488976; protocol="application/pkcs7-signature" --Apple-Mail-9--157488976 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The jabber room for PCN didn't get set up; please use the TSVAREA one for this BOF. Sorry, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-9--157488976 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA2 MTcxNTA1WjAjBgkqhkiG9w0BCQQxFgQUPrd6kOfT0h3pgTKkC5NajKzgh1cwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAFLUfzOodO0ZwcUelZy4 Ju/FmvHM1LP/AqzlAFBMeHE5cGM7X0hZiHPophNCdHwJP4xB0qeNJ5YHsYoTuvadaQbjA743YEyc 7kGhjDvTBE5G9Sk87UXhUT0Krgs4pU0WxpT9Cp1oYBOyPx1t00i4JGfj1ovp2DtamMlqNWACatIL 2eo10CYcKvF+IPb2dm63uUTUcCPs9K29Eg8rqWiUEBqF1Hhe3qdHAKFsMpMXzP/v0F0fjxPu/ZLb 3iGvKxoUM/622YfI/er0MnLmVnPBd8cVIAzOTglBo9Y0RnuLWaZdgJFY+DRn5wQ1bEqHG9INJsN4 MAnN5BoMn6ieqckVjcYAAAAAAAA= --Apple-Mail-9--157488976-- --===============0100203116== 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 --===============0100203116==-- From pcn-bounces@ietf.org Tue Nov 07 13:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWAi-00069F-QR; Tue, 07 Nov 2006 13:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWAh-000694-AW for pcn@ietf.org; Tue, 07 Nov 2006 13:59:43 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWAb-0007IJ-UT for pcn@ietf.org; Tue, 07 Nov 2006 13:59:43 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 18:59:37 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Nov 2006 18:59:36 +0000 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 Date: Tue, 7 Nov 2006 18:59:36 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA50132BDA6@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: differences between PCN deployment scenarios Thread-Index: AccCnt5FE7QEP9uFTl2lH2JDTAc6ZQ== From: To: X-OriginalArrivalTime: 07 Nov 2006 18:59:36.0906 (UTC) FILETIME=[DEC79AA0:01C7029E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [PCN] differences between PCN deployment scenarios 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 wanted to understand the differences between the two PCN deployment = scenarios =96 the original one [IntServ over Diffserv, = draft-briscoe-tsvwg-cl-architecture-04] and the new one = [draft-babiarz-pcn-sip-cap-00] (application-controlled admission and = flow pre-emption - trying to avoid the SIP word after yesterday=92s = meeting!) In particular, what additional things it means that the WG (if formed) = has to keep in mind during its work (as the draft charter puts it, the = deployment scenarios =93initially help focus the problem statement and = later to check that the solutions being developed satisfy the deployment = scenario=94). So it seems important to understand what the key differences are.=20 I think there are two main differences: 1. On-path vs off-path decision point =96 the original deployment model = has the admission control decision made by the ingress gateway of the = PCN region. In the new deployment model it=92s made by an application = proxy, which doesn=92t have to be at the ingress gateway. 2. Many vs few flows between each pair of PCN gateways =96 the original = deployment model talks about the PCN-region being the core of a network, = so it=92s likely that there are many flows between each pair of PCN = gateways. The new deployment model talks about the PCN-region possibly = even extending to the end host, so there then will be few flows between = each pair of PCN gateways. (Note that even in this case, the Charter = says that we will assume there are sufficient flows on any relevant = bottleneck link in the PCN-region.) Are there any other significant differences? Are people OK with these = extra constraints on the work? best wishes, philip eardley _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Nov 10 17:29:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiesB-0005vG-L7; Fri, 10 Nov 2006 17:29:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiesB-0005uh-20 for pcn@ietf.org; Fri, 10 Nov 2006 17:29:19 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gies5-0001i0-IB for pcn@ietf.org; Fri, 10 Nov 2006 17:29:19 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 14:29:12 -0800 X-IronPort-AV: i="4.09,411,1157353200"; d="scan'208"; a="833691:sNHT198326898" 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 kAAMTCi1015917 for ; Fri, 10 Nov 2006 17:29:12 -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 kAAMT9DO014304 for ; Fri, 10 Nov 2006 17:29:12 -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, 10 Nov 2006 17:29:11 -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: Fri, 10 Nov 2006 17:29:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: first draft of PCN BOF minutes Thread-Index: AccFF6SGYNG+wENKSk+BiG3I4pMplQ== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 10 Nov 2006 22:29:11.0620 (UTC) FILETIME=[A521F040:01C70517] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=22456; t=1163197752; x=1164061752; 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:=20first=20draft=20of=20PCN=20BOF=20minutes |Sender:=20 |To:=20; bh=hyitcbawrZBRaf7XvE/buhk9sXZs89976a/RHEViic8=; b=crAadat16R5Rocl7huIlHlcPQQkUprqxA3nOVtUn24rI8dx0ldwcI/Cp3v08J/szQDOtADNG S+GqfZA1Hamu/KkHNXycsXtH4mVzwaYWjxiwHSa1lALAahRfPECP94Tq; 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: 0489daa2bca46f53f2cc9214d1b54371 Subject: [PCN] first draft of PCN BOF minutes 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 Dear all, Here is the first draft of PCN BOF minutes. Those who were present, please take a look and send your corrections. Thank you, Anna Charny =3D=3D=3D=3D Pre-Congestion Notification BOF Monday, November 6 at 0900-1130 Room: Grande Ballroom C BOF Co-Chairs: Anna Charny and Scott Bradner =20 PCN BOF Agenda 1. Agenda Bashing and Administrativia (5 min) =20 Scott Bradner: Robert Schaffer will be talking about work in another SDO. =20 No comments. =20 2. Overview and Introduction (20 min) =20 Anna Charny (& Scott Bradner), BoF co-chairs: =20 Details: =20 http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01. txt=20 =20 1/ What is PCN? * Admission control & pre-emption using packet marking Either core nodes or edge nodes 2/ Why it's a technical problem of interest * Why admission control (AC)? - stretching traffic assumptions beyond current typical mix to large proportions of inelastic traffic, dealing with failures & anomalous traffic scenarios * Why yet another AC mechanism? A further scalability step beyond Intserv over diffserv, aggregate reservations and reservation-based RMD (no core state but still signalling in core) * State of Maturity: builds on substantial body of prior theoretical work, and substantial recent work by those working on PCN 3/ Why an IETF problem? * Progressed to stage where standardisation of packet marking would be reasonable * Some open issues, where consensus still hasn't converged (see Phil Eardley's presentation next) - marking behaviour - marking encoding - how much aggregation is 'enough' - consensus best formed around discussing these issues wrt well-understood deployment models. * Connection with other groups: - RFC3168 ECN compatibility (tsvwg) - signalling extensions to be done in relevant groups - RSVP (tsv), NSIS (nsis), SIP (mmusic) - pcn over MPLS (tsv) - relevance to certain pseudo-wires? (pwe3) - Ensuring emergency services work across a PCN cloud (ieprep & ecrit) * summary: legitimate tech problem, needs standardisation, bounded problem, reasonable number of open issues to resolve 4/ Summary: * There is a legitimate technical problem * There is need of standardization effort * The solution is sufficiently mature * There are a bounded number of open issues needing resolution =20 Hannes Tschofenig: There was no official design team working on PCN in TSVWG, correct? =20 Scott Bradner: Correct. =20 Stuart Goldman: Are you interacting with organizations outside the IETF? =20 Scott Bradner: After forming a working group a message is sent to the new work=20 mailing list where many other SDOs are subscribed to announce it and to=20 determine overlaps. =20 3. Key Open Issues (10 min) ------------------ Phil Eardley =20 1/ Standardization issues * packet marking (without defining algorithm, but ensuring interoperability) * mark encoding (ECN, DSCP?) * conversion of packet marking into flow-granularity AC & pre-emption decisions (exactly one behavior, or more than one - perhaps different deployment scenarios need different behaviors: current consensus: exactly one behavior is doable) =20 * Focusing the work - community consensus required on deployment models - then community consensus required on assumptions (loosen assumptions for re-chartered phase II) underlying these deployment models that are necessary for PCN to work. * Main assumptions - PCN region is fully enclosed by edge nodes that ensure no PCN traffic can enter without AC. (controlled environment) - Avoid cheating issues (but likely to be the issues that comes up after re-chartering) - Specific handling of emergency and flow-level precedence out of w-g scope, but ensure we don't preclude what others are doing =20 2/ Technical issues - compatibility of coding with RFC3168 - sub-optimalities: ECMP, bi-directional flows & pre-emption WG will need to reach consensus on the extent to which standardization effort should address these =20 =20 Jongwon Choe (name not clear), DoD: Why to exclude the emergency service work on preemption? =20 Philip Eardley: It would add a lot of complexity. They are not really in the expertise of the PCN group. =20 Anna Charny: Not focusing on *standardizing* MLP, but scope does include working with other groups who do =20 Kwok Ho Chan: Clarification: Policy on MLP etc is an edge-edge issue, that we don't need to preclude in focusing on the interior to edge interface =20 Robert Shafer: Chair of the Network Interconnection Interoperability=20 Forum gives a brief overview of their organizations and the work they do. They started with work on PSTN and now focus more on IP. Their group is looking forward to interact with the PCN group. Scott Bradner suggests that members from their group subscribe to the mailing list. Stuart Goldman: ATIS BTSC SAG & ITU-T would be groups to talk to. Scott Bradner: Information from these groups would be useful. Robert Schafer: Emergency announcements to local areas over PSTN - ultimately NIIF may extend into this space. These calls look like regular calls, not specially marked. This would be a hard problem. 4. Overview of Existing Work (10 min) Kwok Ho Chan * Deployment Models - Controlled Load : RSVP as signalling protocol outside and between PCN edge nodes see =20 =20 - SIP controlled flow admission & pre-emption model see =20 =20 James Polk: Where does a phone fit in the middle? Kwok Ho Chan: Phone on edge of PCN region=20 Dave Oran: Find picture incredibly confusing but suggest to move on Joe Babiarz: PCN region extends to end-points=20 David Black: Is the assumption that phones are trusted? Kwok Ho Chan: Yes Francois le Faucheur: the call-server is meant to be *above* the data plane, not on the edge of the PCN region Bruce Davie: Confusingly described. Also may not be legitimate. But the w-g can decide whether or not it is a legitimate model to take on board, don't have to decide in the BoF. Dave Oran: Is it that the real issue is what the data plane is doing to determine whether to admit the call, with some signalling to set up the call that may be SIP (or anything else) Dave Oran: This has nothing todo with SIP. There is something that is=20 required to clue SIP together with PCN. David Black: Yes, you need a control plane and SIP may be an example. Kwok Ho Chan continues his presentation=20 * Measurement and Encoding at Interior Router - http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-03.txt =20 - http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt=20 - http://standards.nortel.com/pcn/simulation_results_00.pdf =20 - Example packet marking method described in the cl-phb draft above for AC & flow pre-emption - Measurement of marking of aggregate for AC & flow pre-emption also described Lars Eggert: BCP upcoming on how you safely redefine ECN. Stuart Goldman: How fast does it take to get back to normal? Anna Charny: Depending on the parameters it might take more than 1 second=20 but for set of "reasonable" parameters used in simulation it does preempt within 1 second. A few seconds is the target preemption time=20 Normally, a call is 2 min. But if quality of service degrades dramatically, then in a few sec most of the users hang up. And if all users are affected, all users can hang up. Therefore you want to preempt before that time, so that you only preempt enough calls to make sure that other calls are not affected. Kwok Ho Chan: In some jurisdictions it is not allowed to preempt calls. Question: Does preemption by the network allow information to be returned to the end host. Francois Le Faucheur: Yes. Bob Briscoe: You don't have to use preemption, but an operator could use it. Francois: The idea is to add some determinism when a failure happens.=20 There will be signaling to tear down the call properly to give the end=20 host (user) some feedback. Kwok Ho Chan continues with the slides: List of drafts at nortel holding place http://standards.nortel.com/pcn/ =20 Pre-Congestion Notification Problem Statement http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01. txt =20 Pre-Congestion Notification marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-03.txt=20 An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 04.txt=20 SIP Controlled Admission and Preemption http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt=20 Pre-Congestion Notification Using Single Marking for Admission and Pre-emption=20 http://www.ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.t xt=20 Performance Evaluation of CL-PHB Admission and pre-emption Algorithms http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt =20 5. Open Discussion on PCN (20 min) ------------------------- David Black: The PCN region roughly corresponds to a Diffserv domain. However, when we did Diffserv, we looked at cross-domain. There is the risk of making the problem space larger than it initially was. Where this starts from is the trust discussion. The assumption was=20 pretty good and corresponds to DiffServ. Failing to look at the cross=20 domain stuff is too narrow scoped. It does not need to be on the=20 MUST-to-be-solved items. Scott Bradner: We talked about this. We thought about rechartering to add this cross domain aspect later. Is this something to be solved already in the first round? I don't know. It needs to be addressed at some point in time. David Black: How much keeping in mind needs to be done to ensure that it can be done later? Bob Briscoe: Only brought PCN to the IETF a year or so ago once I had a solution for inter-domain deployment where they don't trust each other not to cheat. However, agree it is best to get the necessary parts standardized for single trust region most urgently, then working on multi-domain with no mutual trust after re-chartering. However, there are some issues that have to be decided for a single domain that may impact on the anti-cheating solution, e.g. PCN wire encoding. So we have to keep in mind the multi-trust-domain scenario during initial standardization. David Black: As long as 'keep in mind' is taken strongly. Yakhov Stein: What's all this for? Detect congestion because of a failure? Isn't there an easier mechanism when there is a failure? Anna Charny: Pre-emption deals with failure, Admission Control does not - it is more for the situations when provisioning may not be the right solution. Dave Oran: I assumed we could have multiple classes, all with admission control=20 Bob Briscoe: Can isolate link capacities for each class, and can have borrowing from other classes, but not priority access by another class to the admission controlled resources Yakhov Stein: What is the timescale of these pre-emption events? Bruce Davie: Timescale is that of flow admission arrivals. Yakhov Stein: Congestion causes packet forwarding to slow down - performance hit. Anything that works on buffer level is already too slow. Anna Charny: We do not do that. The idea of pre-congestion is to get the notification before the congestion happens. Francois Le Faucheur: You trigger before you are congested. The mechanism is not to trigger the queue. You can use some sort of threshold or virtual queues. =20 Dave Oran: I made the naive assumption that this stuff works on a DiffServ class domain only. Anna Charny: The assumption that it is applied to a DiffServ class is correct. The traffic in the class is not elastic.=20 Dave Oran: Is this necessary? Do we have mechanisms for elastic traffic that work just fine. Can we say inelastic traffic? Anna Charny: Yes. Dave Oran: The ability of bandwidth sharing between different classes is not provided. Bob Briscoe: You don't need to have complete isolation =20 Liam Casey: I have read the simulation draft. Stability is a huge=20 factor. I am not sure there are large scale simulations show it is stable. This has to go to work with millions of calls. It is not only about simulations of 5 servers. =20 Anna Charny: Yes, the current simulation do not come close to real-world systems. However, we need to talk off-line about what stability means here. We need to understand to what extent stability concerns for traditional congestion control are applicable here.=20 Scott Bradner: You haven't tried large scale stability simulations? Anna Charny: No, not yet. Lars Eggert: How quickly do you react to congestion notification? Anna Charny: It has to react quickly before people hang up. Lars Eggert: Is the detection of congestion slower than the detection of pre-congestion? Anna Charny: Yes Josepf Babiarz: The detection is fast but there is the question on how long it needs to take before taking some actions. =20 Scott Bradner: Being very aggressive leads to instability. Lars Eggert: Is there any algorithm between the preemption vs. going down with admitting new flows? Anna Charny: There is an algorithm in the cl-arcitecture and Cl-phb drafts. (speaker at the mike, name not recorded): Preempting is a rather a difficult thing todo. Have you thought about notifying users to fall back to a different codec rather than preempting their conversation. This, however, requires feedback to a user. Josef Babiarz: Yes. Anna Charny: There are two different questions: a) Have we looked at it? b) Should the working group do it? Regarding (a): yes. Regarding (b): No under the proposed charter. Scott Bradner: That's a reasonable thing to discuss on the mailing list. Dana Blair: Is there a formal definition of stability? Scott: Do you have some suggestions? Anna: I don't know how to answer this question in this context. Stability is typically applied to congestion control systems where the function of interest can adjust up or down. In the framework we propose, Admission Control can only stop admission, and pre-emption can only bring the amount of traffic down. So there are two questions of interest: a) Admission: Does it stop admitting when expected or does it over- or under-admit? b) Preemption: Does it pre-empt the right amount or does it over- or under-shoot)? Jim Bound: There is a lot of momentum for admission control. There is a lot of things important in the proposed scope. Scott Bradner: There are two things: a) Propose work in the IETF b) Keep in mind when designing the core protocol. You need to know what the requirements are to design the protocol. =20 6. Proposed Charter (20 min) Anna Charny presents=20 http://standards.nortel.com/pcn/PCN_draft_charter_v01.txt * Standards track docs to address 3 areas: 1. When should an interior router mark a packet (i.e. at what traffic level) in order to give early warning of its own congestion? 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? 3. How should these markings (at packet granularity) be converted into admission control and flow pre-emption decisions (at flow granularity)? =20 Jacob Stein: When should a router mark a packet sounds like implementation. Scott Bradner/Bruce Davie (both said same thing): Shouldn't describe hardware, but should describe behavior for interoperability. =20 Anna Charny continues presentation: =20 * Informational documents: =20 1. a Problem Statement =20 James Polk: Don't see requrements doc. Problem statement isn't the same=20 Scott Bradner: In general believe reqs doc is a good idea. Also worried about getting bogged down. Anna Charny continues 2. at least two deployment models, possibly from: - like IntServ over DiffServ (RFC2998) but with PCN-enabled DiffServ region and edge nodes decide about admission and flow pre-emption - SIP Controlled Admission and Preemption: using trusted SIP endpoints (gateway or host) performing admission and flow pre-emption and PCN-capable routers within the DiffServ region James Polk: Sounds like a SIP doc for SIPPING=20 Scott Bradner: This represents requirements to SIPPING Stuart Goldman: Is it reasonable to add a boilerplate to the charter to say that work will be done with other working group. Anna: Sounds good to me. Scott: Also useful. =20 Anna Charny continues presentation: =20 - Pseudowire: PCN may be used as a congestion avoidance mechanism for end-user deployed pseudowires (collaborate with the PWE3 WG) Lars Eggert: Not solving the whole pseudo-wire problem, so won't be useful. Yakhov Stein: Nowhere does it say PWE3 should be over provisioned paths=20 Lars Eggert: There is an statement that does say this. Dave Oran: If it requires SIP to change, we have problems, but I doubt it does. It has a dependency on SDP, which has the QoS pre-conditions. Anna Charny: What would you suggest? Dave Oran: Change the wording to Application-controlled (rather than SIP-controlled) admission & pre-emption Stuart Goldman: As SIPPING says they take all changes to SIP, shouldn't this w-g say it takes all PCN-related aspects? Scott Bradner: Good point Bruce Davie: Reservation on using PCN for pseudo-wire is that concern with PWE3 is immediate deployment of Internet as-is. There is precious little ECN, let alone PCN deployment (given it's not standardized yet) in the current Internet. Anna Charny: Should pseudo-wires stay in the charter? Bruce Davie: No, too forward looking for a phase 1 charter Anna Charny continues presentation: =20 3. analysis of the signaling extensions required to support PCN - actual extensions in other w-gs (RSVP, NSIS, SIP) not PCN=20 4. at least one example solution implementing the framework and its performance evaluation (e.g. simulation) =20 5. tradeoffs between different encoding possibilities (e.g. ECN and DCSP marking) * Initial restriction of scope (assumptions): 1. Trust assumption: PCN region is a controlled environment David Black: Trust assumption: need to add 'keeping in mind' interconnection. I won't let you forget that. 2. aggregation: many flows on any link =20 3. inelastic traffic: QoS assurance for r-t apps generating inelastic traffic - voice & video low delay, jitter and packet loss, i.e. Controlled Load Svc [RFC2211]. =20 4. Specific handling of emergency and other precedence (911, GETS, WPS, MLPP etc.) calls out of scope, - *but* PCN must ensure using PCN technology doesn't preclude edge nodes from taking the appropriate emergency actions required by these standards/initiatives - PCN Internal Nodes may not be MLPP-aware but they are DSCP aware =20 Bob Briscoe: Assumption 2 (aggregation) doesn't seem to include SIP endpoint=20 Matt Mathis: Change assumption 2 to "There are sufficient flows where relevant bottlenecks" Anna Charny: Will do Francois le Faucheur: Assumption 2: Add applicability statement to the charter. * Re-chartering later May relax some of the assumptions when re-chartering (e.g. single trust domain assumption) =20 Out of scope: general investigation of AC mechs - we build on considerable academic and prior IETF work on measurement-based admission control (MBAC) =20 Milestones ---------- Nov 2006 initial Problem statement Nov 2006 initial deployment models March 2007 initial router marking behavior (including encoding) March 2007 initial flow admission control and pre-emption mechanism (including edge node behavior) March/July 2007 submit Problem statement March/July 2007 submit deployment models Nov 2007 submit router marking behavior Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism Nov 2007 initial signaling analysis Mar 2008 re-charter or close =20 Francois le Faucheur: How would applicability statement fit into milestones? Scott Bradner: Personally a stand-alone applicability statement would be my preference. David Black: Would need an applicability statement specific to the endpoint model.=20 Scott Bradner: Or not signalling protocol specific=20 David Black: Need to use SIP as an example app signalling protocol=20 Dave Oran: Most important aspect is endpoint-endpoint in that deployment model. Georgios Karagiannis: SIP applicability statement. Yes, SIP just an example application signalling protocol. Also need end-to-concentrator, or concentrator-to-concentrator. =20 7. Discussion of Proposed Charter (20 min) =20 No further discussion =20 8. Summary and Conclusions (10 min) =20 Scott Bradner: Is this ready for IETF w-g? =20 [About 150 people in the room.] Of which about 100 voted: ~98 for; 2 against =20 Scott Bradner: Now the task is to work with the ADs on a charter, to post to list. This BoF does not presuppose who the w-g chairs are in any way. =20 Lars Eggert: Show of hands please, on who is interested (other than the authors of the drafts) in helping in this w-g? 7 hands up. =20 Question from the room: Is there a mailing list? =20 Anna Charny: pcn@ietf.org =20 =20 [Subscribe via: ] =20 =20 =20 =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Nov 11 11:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiveJ-0003FN-Rg; Sat, 11 Nov 2006 11:24:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiveI-0003D5-3x for pcn@ietf.org; Sat, 11 Nov 2006 11:24:06 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiveA-0004eu-Je for pcn@ietf.org; Sat, 11 Nov 2006 11:24:06 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 16:23:47 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Nov 2006 16:23:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1163262225725; Sat, 11 Nov 2006 16:23:45 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.200]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id kABGNcLZ020649; Sat, 11 Nov 2006 16:23:42 GMT Message-Id: <5.2.1.1.2.20061111161932.03a82de8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 11 Nov 2006 16:23:43 +0000 To: "Anna Charny \(acharny\)" From: Bob Briscoe Subject: Re: [PCN] first draft of PCN BOF minutes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 11 Nov 2006 16:23:47.0039 (UTC) FILETIME=[C37A1EF0:01C705AD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Anna, At 22:29 10/11/2006, Anna Charny \(acharny\) wrote: >Dear all, > >Here is the first draft of PCN BOF minutes. > >Those who were present, please take a look and send your corrections. Look OK to me, but sending back & forth by mail has introduced some odd line breaking and equally it has removed some sensible line breaking (probably Dos-Unix-DoS problems). I suggest this is produced as a txt file, which I assume you will be doing anyway for the uploaded minutes to Cheers Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Nov 12 13:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKLJ-0004ym-DO; Sun, 12 Nov 2006 13:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKLI-0004yJ-83 for pcn@ietf.org; Sun, 12 Nov 2006 13:46:08 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjKLG-0005Zo-EB for pcn@ietf.org; Sun, 12 Nov 2006 13:46:08 -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 kACIjhD16293; Sun, 12 Nov 2006 13:45:43 -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] first draft of PCN BOF minutes Date: Sun, 12 Nov 2006 13:45:41 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D228087@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] first draft of PCN BOF minutes Thread-Index: AccFF6SGYNG+wENKSk+BiG3I4pMplQBbuqwg From: "Jozef Babiarz" To: "Anna Charny \(acharny\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 142968907492cd6b805bce4edf0aec7b 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 Anna, The BOF minutes look OK to me. Would like to suggest that you fix, some typos and format (remove black lines) as well. Correct "Jongwon Choe" to "Yong Xue". Change MLP to MLPP. 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: Friday, November 10, 2006 5:29 PM To: pcn@ietf.org Subject: [PCN] first draft of PCN BOF minutes Dear all, Here is the first draft of PCN BOF minutes. Those who were present, please take a look and send your corrections. Thank you, Anna Charny =3D=3D=3D=3D Pre-Congestion Notification BOF Monday, November 6 at 0900-1130 Room: Grande Ballroom C BOF Co-Chairs: Anna Charny and Scott Bradner =20 PCN BOF Agenda 1. Agenda Bashing and Administrativia (5 min) =20 Scott Bradner: Robert Schaffer will be talking about work in another SDO. =20 No comments. =20 2. Overview and Introduction (20 min) =20 Anna Charny (& Scott Bradner), BoF co-chairs: =20 Details: =20 http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01. txt=20 =20 1/ What is PCN? * Admission control & pre-emption using packet marking Either core nodes or edge nodes 2/ Why it's a technical problem of interest * Why admission control (AC)? - stretching traffic assumptions beyond current typical mix to large proportions of inelastic traffic, dealing with failures & anomalous traffic scenarios * Why yet another AC mechanism? A further scalability step beyond Intserv over diffserv, aggregate reservations and reservation-based RMD (no core state but still signalling in core) * State of Maturity: builds on substantial body of prior theoretical work, and substantial recent work by those working on PCN 3/ Why an IETF problem? * Progressed to stage where standardisation of packet marking would be reasonable * Some open issues, where consensus still hasn't converged (see Phil Eardley's presentation next) - marking behaviour - marking encoding - how much aggregation is 'enough' - consensus best formed around discussing these issues wrt well-understood deployment models. * Connection with other groups: - RFC3168 ECN compatibility (tsvwg) - signalling extensions to be done in relevant groups - RSVP (tsv), NSIS (nsis), SIP (mmusic) - pcn over MPLS (tsv) - relevance to certain pseudo-wires? (pwe3) - Ensuring emergency services work across a PCN cloud (ieprep & ecrit) * summary: legitimate tech problem, needs standardisation, bounded problem, reasonable number of open issues to resolve 4/ Summary: * There is a legitimate technical problem * There is need of standardization effort * The solution is sufficiently mature * There are a bounded number of open issues needing resolution =20 Hannes Tschofenig: There was no official design team working on PCN in TSVWG, correct? =20 Scott Bradner: Correct. =20 Stuart Goldman: Are you interacting with organizations outside the IETF? =20 Scott Bradner: After forming a working group a message is sent to the new work=20 mailing list where many other SDOs are subscribed to announce it and to=20 determine overlaps. =20 3. Key Open Issues (10 min) ------------------ Phil Eardley =20 1/ Standardization issues * packet marking (without defining algorithm, but ensuring interoperability) * mark encoding (ECN, DSCP?) * conversion of packet marking into flow-granularity AC & pre-emption decisions (exactly one behavior, or more than one - perhaps different deployment scenarios need different behaviors: current consensus: exactly one behavior is doable) =20 * Focusing the work - community consensus required on deployment models - then community consensus required on assumptions (loosen assumptions for re-chartered phase II) underlying these deployment models that are necessary for PCN to work. * Main assumptions - PCN region is fully enclosed by edge nodes that ensure no PCN traffic can enter without AC. (controlled environment) - Avoid cheating issues (but likely to be the issues that comes up after re-chartering) - Specific handling of emergency and flow-level precedence out of w-g scope, but ensure we don't preclude what others are doing =20 2/ Technical issues - compatibility of coding with RFC3168 - sub-optimalities: ECMP, bi-directional flows & pre-emption WG will need to reach consensus on the extent to which standardization effort should address these =20 =20 Jongwon Choe (name not clear), DoD: Why to exclude the emergency service work on preemption? =20 Philip Eardley: It would add a lot of complexity. They are not really in the expertise of the PCN group. =20 Anna Charny: Not focusing on *standardizing* MLP, but scope does include working with other groups who do =20 Kwok Ho Chan: Clarification: Policy on MLP etc is an edge-edge issue, that we don't need to preclude in focusing on the interior to edge interface =20 Robert Shafer: Chair of the Network Interconnection Interoperability=20 Forum gives a brief overview of their organizations and the work they do. They started with work on PSTN and now focus more on IP. Their group is looking forward to interact with the PCN group. Scott Bradner suggests that members from their group subscribe to the mailing list. Stuart Goldman: ATIS BTSC SAG & ITU-T would be groups to talk to. Scott Bradner: Information from these groups would be useful. Robert Schafer: Emergency announcements to local areas over PSTN - ultimately NIIF may extend into this space. These calls look like regular calls, not specially marked. This would be a hard problem. 4. Overview of Existing Work (10 min) Kwok Ho Chan * Deployment Models - Controlled Load : RSVP as signalling protocol outside and between PCN edge nodes see =20 =20 - SIP controlled flow admission & pre-emption model see =20 =20 James Polk: Where does a phone fit in the middle? Kwok Ho Chan: Phone on edge of PCN region=20 Dave Oran: Find picture incredibly confusing but suggest to move on Joe Babiarz: PCN region extends to end-points=20 David Black: Is the assumption that phones are trusted? Kwok Ho Chan: Yes Francois le Faucheur: the call-server is meant to be *above* the data plane, not on the edge of the PCN region Bruce Davie: Confusingly described. Also may not be legitimate. But the w-g can decide whether or not it is a legitimate model to take on board, don't have to decide in the BoF. Dave Oran: Is it that the real issue is what the data plane is doing to determine whether to admit the call, with some signalling to set up the call that may be SIP (or anything else) Dave Oran: This has nothing todo with SIP. There is something that is=20 required to clue SIP together with PCN. David Black: Yes, you need a control plane and SIP may be an example. Kwok Ho Chan continues his presentation=20 * Measurement and Encoding at Interior Router - http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-03.txt =20 - http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt=20 - http://standards.nortel.com/pcn/simulation_results_00.pdf =20 - Example packet marking method described in the cl-phb draft above for AC & flow pre-emption - Measurement of marking of aggregate for AC & flow pre-emption also described Lars Eggert: BCP upcoming on how you safely redefine ECN. Stuart Goldman: How fast does it take to get back to normal? Anna Charny: Depending on the parameters it might take more than 1 second=20 but for set of "reasonable" parameters used in simulation it does preempt within 1 second. A few seconds is the target preemption time=20 Normally, a call is 2 min. But if quality of service degrades dramatically, then in a few sec most of the users hang up. And if all users are affected, all users can hang up. Therefore you want to preempt before that time, so that you only preempt enough calls to make sure that other calls are not affected. Kwok Ho Chan: In some jurisdictions it is not allowed to preempt calls. Question: Does preemption by the network allow information to be returned to the end host. Francois Le Faucheur: Yes. Bob Briscoe: You don't have to use preemption, but an operator could use it. Francois: The idea is to add some determinism when a failure happens.=20 There will be signaling to tear down the call properly to give the end=20 host (user) some feedback. Kwok Ho Chan continues with the slides: List of drafts at nortel holding place http://standards.nortel.com/pcn/ =20 Pre-Congestion Notification Problem Statement http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01. txt =20 Pre-Congestion Notification marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-03.txt=20 An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 04.txt=20 SIP Controlled Admission and Preemption http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt=20 Pre-Congestion Notification Using Single Marking for Admission and Pre-emption=20 http://www.ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.t xt=20 Performance Evaluation of CL-PHB Admission and pre-emption Algorithms http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt =20 5. Open Discussion on PCN (20 min) ------------------------- David Black: The PCN region roughly corresponds to a Diffserv domain. However, when we did Diffserv, we looked at cross-domain. There is the risk of making the problem space larger than it initially was. Where this starts from is the trust discussion. The assumption was=20 pretty good and corresponds to DiffServ. Failing to look at the cross=20 domain stuff is too narrow scoped. It does not need to be on the=20 MUST-to-be-solved items. Scott Bradner: We talked about this. We thought about rechartering to add this cross domain aspect later. Is this something to be solved already in the first round? I don't know. It needs to be addressed at some point in time. David Black: How much keeping in mind needs to be done to ensure that it can be done later? Bob Briscoe: Only brought PCN to the IETF a year or so ago once I had a solution for inter-domain deployment where they don't trust each other not to cheat. However, agree it is best to get the necessary parts standardized for single trust region most urgently, then working on multi-domain with no mutual trust after re-chartering. However, there are some issues that have to be decided for a single domain that may impact on the anti-cheating solution, e.g. PCN wire encoding. So we have to keep in mind the multi-trust-domain scenario during initial standardization. David Black: As long as 'keep in mind' is taken strongly. Yakhov Stein: What's all this for? Detect congestion because of a failure? Isn't there an easier mechanism when there is a failure? Anna Charny: Pre-emption deals with failure, Admission Control does not - it is more for the situations when provisioning may not be the right solution. Dave Oran: I assumed we could have multiple classes, all with admission control=20 Bob Briscoe: Can isolate link capacities for each class, and can have borrowing from other classes, but not priority access by another class to the admission controlled resources Yakhov Stein: What is the timescale of these pre-emption events? Bruce Davie: Timescale is that of flow admission arrivals. Yakhov Stein: Congestion causes packet forwarding to slow down - performance hit. Anything that works on buffer level is already too slow. Anna Charny: We do not do that. The idea of pre-congestion is to get the notification before the congestion happens. Francois Le Faucheur: You trigger before you are congested. The mechanism is not to trigger the queue. You can use some sort of threshold or virtual queues. =20 Dave Oran: I made the naive assumption that this stuff works on a DiffServ class domain only. Anna Charny: The assumption that it is applied to a DiffServ class is correct. The traffic in the class is not elastic.=20 Dave Oran: Is this necessary? Do we have mechanisms for elastic traffic that work just fine. Can we say inelastic traffic? Anna Charny: Yes. Dave Oran: The ability of bandwidth sharing between different classes is not provided. Bob Briscoe: You don't need to have complete isolation =20 Liam Casey: I have read the simulation draft. Stability is a huge=20 factor. I am not sure there are large scale simulations show it is stable. This has to go to work with millions of calls. It is not only about simulations of 5 servers. =20 Anna Charny: Yes, the current simulation do not come close to real-world systems. However, we need to talk off-line about what stability means here. We need to understand to what extent stability concerns for traditional congestion control are applicable here.=20 Scott Bradner: You haven't tried large scale stability simulations? Anna Charny: No, not yet. Lars Eggert: How quickly do you react to congestion notification? Anna Charny: It has to react quickly before people hang up. Lars Eggert: Is the detection of congestion slower than the detection of pre-congestion? Anna Charny: Yes Josepf Babiarz: The detection is fast but there is the question on how long it needs to take before taking some actions. =20 Scott Bradner: Being very aggressive leads to instability. Lars Eggert: Is there any algorithm between the preemption vs. going down with admitting new flows? Anna Charny: There is an algorithm in the cl-arcitecture and Cl-phb drafts. (speaker at the mike, name not recorded): Preempting is a rather a difficult thing todo. Have you thought about notifying users to fall back to a different codec rather than preempting their conversation. This, however, requires feedback to a user. Josef Babiarz: Yes. Anna Charny: There are two different questions: a) Have we looked at it? b) Should the working group do it? Regarding (a): yes. Regarding (b): No under the proposed charter. Scott Bradner: That's a reasonable thing to discuss on the mailing list. Dana Blair: Is there a formal definition of stability? Scott: Do you have some suggestions? Anna: I don't know how to answer this question in this context. Stability is typically applied to congestion control systems where the function of interest can adjust up or down. In the framework we propose, Admission Control can only stop admission, and pre-emption can only bring the amount of traffic down. So there are two questions of interest: a) Admission: Does it stop admitting when expected or does it over- or under-admit? b) Preemption: Does it pre-empt the right amount or does it over- or under-shoot)? Jim Bound: There is a lot of momentum for admission control. There is a lot of things important in the proposed scope. Scott Bradner: There are two things: a) Propose work in the IETF b) Keep in mind when designing the core protocol. You need to know what the requirements are to design the protocol. =20 6. Proposed Charter (20 min) Anna Charny presents=20 http://standards.nortel.com/pcn/PCN_draft_charter_v01.txt * Standards track docs to address 3 areas: 1. When should an interior router mark a packet (i.e. at what traffic level) in order to give early warning of its own congestion? 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? 3. How should these markings (at packet granularity) be converted into admission control and flow pre-emption decisions (at flow granularity)? =20 Jacob Stein: When should a router mark a packet sounds like implementation. Scott Bradner/Bruce Davie (both said same thing): Shouldn't describe hardware, but should describe behavior for interoperability. =20 Anna Charny continues presentation: =20 * Informational documents: =20 1. a Problem Statement =20 James Polk: Don't see requrements doc. Problem statement isn't the same=20 Scott Bradner: In general believe reqs doc is a good idea. Also worried about getting bogged down. Anna Charny continues 2. at least two deployment models, possibly from: - like IntServ over DiffServ (RFC2998) but with PCN-enabled DiffServ region and edge nodes decide about admission and flow pre-emption - SIP Controlled Admission and Preemption: using trusted SIP endpoints (gateway or host) performing admission and flow pre-emption and PCN-capable routers within the DiffServ region James Polk: Sounds like a SIP doc for SIPPING=20 Scott Bradner: This represents requirements to SIPPING Stuart Goldman: Is it reasonable to add a boilerplate to the charter to say that work will be done with other working group. Anna: Sounds good to me. Scott: Also useful. =20 Anna Charny continues presentation: =20 - Pseudowire: PCN may be used as a congestion avoidance mechanism for end-user deployed pseudowires (collaborate with the PWE3 WG) Lars Eggert: Not solving the whole pseudo-wire problem, so won't be useful. Yakhov Stein: Nowhere does it say PWE3 should be over provisioned paths=20 Lars Eggert: There is an statement that does say this. Dave Oran: If it requires SIP to change, we have problems, but I doubt it does. It has a dependency on SDP, which has the QoS pre-conditions. Anna Charny: What would you suggest? Dave Oran: Change the wording to Application-controlled (rather than SIP-controlled) admission & pre-emption Stuart Goldman: As SIPPING says they take all changes to SIP, shouldn't this w-g say it takes all PCN-related aspects? Scott Bradner: Good point Bruce Davie: Reservation on using PCN for pseudo-wire is that concern with PWE3 is immediate deployment of Internet as-is. There is precious little ECN, let alone PCN deployment (given it's not standardized yet) in the current Internet. Anna Charny: Should pseudo-wires stay in the charter? Bruce Davie: No, too forward looking for a phase 1 charter Anna Charny continues presentation: =20 3. analysis of the signaling extensions required to support PCN - actual extensions in other w-gs (RSVP, NSIS, SIP) not PCN=20 4. at least one example solution implementing the framework and its performance evaluation (e.g. simulation) =20 5. tradeoffs between different encoding possibilities (e.g. ECN and DCSP marking) * Initial restriction of scope (assumptions): 1. Trust assumption: PCN region is a controlled environment David Black: Trust assumption: need to add 'keeping in mind' interconnection. I won't let you forget that. 2. aggregation: many flows on any link =20 3. inelastic traffic: QoS assurance for r-t apps generating inelastic traffic - voice & video low delay, jitter and packet loss, i.e. Controlled Load Svc [RFC2211]. =20 4. Specific handling of emergency and other precedence (911, GETS, WPS, MLPP etc.) calls out of scope, - *but* PCN must ensure using PCN technology doesn't preclude edge nodes from taking the appropriate emergency actions required by these standards/initiatives - PCN Internal Nodes may not be MLPP-aware but they are DSCP aware =20 Bob Briscoe: Assumption 2 (aggregation) doesn't seem to include SIP endpoint=20 Matt Mathis: Change assumption 2 to "There are sufficient flows where relevant bottlenecks" Anna Charny: Will do Francois le Faucheur: Assumption 2: Add applicability statement to the charter. * Re-chartering later May relax some of the assumptions when re-chartering (e.g. single trust domain assumption) =20 Out of scope: general investigation of AC mechs - we build on considerable academic and prior IETF work on measurement-based admission control (MBAC) =20 Milestones ---------- Nov 2006 initial Problem statement Nov 2006 initial deployment models March 2007 initial router marking behavior (including encoding) March 2007 initial flow admission control and pre-emption mechanism (including edge node behavior) March/July 2007 submit Problem statement March/July 2007 submit deployment models Nov 2007 submit router marking behavior Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism Nov 2007 initial signaling analysis Mar 2008 re-charter or close =20 Francois le Faucheur: How would applicability statement fit into milestones? Scott Bradner: Personally a stand-alone applicability statement would be my preference. David Black: Would need an applicability statement specific to the endpoint model.=20 Scott Bradner: Or not signalling protocol specific=20 David Black: Need to use SIP as an example app signalling protocol=20 Dave Oran: Most important aspect is endpoint-endpoint in that deployment model. Georgios Karagiannis: SIP applicability statement. Yes, SIP just an example application signalling protocol. Also need end-to-concentrator, or concentrator-to-concentrator. =20 7. Discussion of Proposed Charter (20 min) =20 No further discussion =20 8. Summary and Conclusions (10 min) =20 Scott Bradner: Is this ready for IETF w-g? =20 [About 150 people in the room.] Of which about 100 voted: ~98 for; 2 against =20 Scott Bradner: Now the task is to work with the ADs on a charter, to post to list. This BoF does not presuppose who the w-g chairs are in any way. =20 Lars Eggert: Show of hands please, on who is interested (other than the authors of the drafts) in helping in this w-g? 7 hands up. =20 Question from the room: Is there a mailing list? =20 Anna Charny: pcn@ietf.org =20 =20 [Subscribe via: ] =20 =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 Nov 13 05:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjZSB-0004xW-R0; Mon, 13 Nov 2006 05:54:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjZSB-0004xR-B8 for pcn@ietf.org; Mon, 13 Nov 2006 05:54:15 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjZS3-00073a-64 for pcn@ietf.org; Mon, 13 Nov 2006 05:54:15 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 10:53:54 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Nov 2006 10:53:53 +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] first draft of PCN BOF minutes Date: Mon, 13 Nov 2006 10:53:51 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CE0F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650D228087@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] first draft of PCN BOF minutes Thread-Index: AccFF6SGYNG+wENKSk+BiG3I4pMplQBbuqwgACKLKiA= From: To: , X-OriginalArrivalTime: 13 Nov 2006 10:53:53.0190 (UTC) FILETIME=[023FF460:01C70712] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5e5718a4acb1341e4ece2ac23728c219 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 Anna, Here are some extra things that were in my notes of the BoF Part 5 "Open discussion on PCN" After Bob Briscoe's comment "Can isolate link capacities..." Add Dave Oran: In assumption about inelastic traffic, remove "real time" Change,=20 > Yakhov Stein: What is the timescale of these pre-emption events? To Yakhov Stein: What is the timescale to detect congestion events? Change >(speaker at the mike, name not recorded): to Yakhov Stein After > Scott Bradner: That's a reasonable thing to discuss on the mailing list. Add Bob Briscoe: Trust assumption means can't assume applications will react. Part 6 "Proposed charter" after "initial restrictions of scope ... 3 inelastic traffic" add John Kenney: could several DSCPs all be subject to the same treatment Anna Charny: Yes. But haven't looked at possible interactions if different drop priorities. phil -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 12 November 2006 18:46 To: Anna Charny (acharny); pcn@ietf.org Subject: RE: [PCN] first draft of PCN BOF minutes Anna, The BOF minutes look OK to me. Would like to suggest that you fix, some typos and format (remove black lines) as well. Correct "Jongwon Choe" to "Yong Xue". Change MLP to MLPP. 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: Friday, November 10, 2006 5:29 PM To: pcn@ietf.org Subject: [PCN] first draft of PCN BOF minutes Dear all, Here is the first draft of PCN BOF minutes. Those who were present, please take a look and send your corrections. Thank you, Anna Charny =3D=3D=3D=3D Pre-Congestion Notification BOF Monday, November 6 at 0900-1130 Room: Grande Ballroom C BOF Co-Chairs: Anna Charny and Scott Bradner =20 PCN BOF Agenda 1. Agenda Bashing and Administrativia (5 min) =20 Scott Bradner: Robert Schaffer will be talking about work in another SDO. =20 No comments. =20 2. Overview and Introduction (20 min) =20 Anna Charny (& Scott Bradner), BoF co-chairs: =20 Details: =20 http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01. txt=20 =20 1/ What is PCN? * Admission control & pre-emption using packet marking Either core nodes or edge nodes 2/ Why it's a technical problem of interest * Why admission control (AC)? - stretching traffic assumptions beyond current typical mix to large proportions of inelastic traffic, dealing with failures & anomalous traffic scenarios * Why yet another AC mechanism? A further scalability step beyond Intserv over diffserv, aggregate reservations and reservation-based RMD (no core state but still signalling in core) * State of Maturity: builds on substantial body of prior theoretical work, and substantial recent work by those working on PCN 3/ Why an IETF problem? * Progressed to stage where standardisation of packet marking would be reasonable * Some open issues, where consensus still hasn't converged (see Phil Eardley's presentation next) - marking behaviour - marking encoding - how much aggregation is 'enough' - consensus best formed around discussing these issues wrt well-understood deployment models. * Connection with other groups: - RFC3168 ECN compatibility (tsvwg) - signalling extensions to be done in relevant groups - RSVP (tsv), NSIS (nsis), SIP (mmusic) - pcn over MPLS (tsv) - relevance to certain pseudo-wires? (pwe3) - Ensuring emergency services work across a PCN cloud (ieprep & ecrit) * summary: legitimate tech problem, needs standardisation, bounded problem, reasonable number of open issues to resolve 4/ Summary: * There is a legitimate technical problem * There is need of standardization effort * The solution is sufficiently mature * There are a bounded number of open issues needing resolution =20 Hannes Tschofenig: There was no official design team working on PCN in TSVWG, correct? =20 Scott Bradner: Correct. =20 Stuart Goldman: Are you interacting with organizations outside the IETF? =20 Scott Bradner: After forming a working group a message is sent to the new work=20 mailing list where many other SDOs are subscribed to announce it and to=20 determine overlaps. =20 3. Key Open Issues (10 min) ------------------ Phil Eardley =20 1/ Standardization issues * packet marking (without defining algorithm, but ensuring interoperability) * mark encoding (ECN, DSCP?) * conversion of packet marking into flow-granularity AC & pre-emption decisions (exactly one behavior, or more than one - perhaps different deployment scenarios need different behaviors: current consensus: exactly one behavior is doable) =20 * Focusing the work - community consensus required on deployment models - then community consensus required on assumptions (loosen assumptions for re-chartered phase II) underlying these deployment models that are necessary for PCN to work. * Main assumptions - PCN region is fully enclosed by edge nodes that ensure no PCN traffic can enter without AC. (controlled environment) - Avoid cheating issues (but likely to be the issues that comes up after re-chartering) - Specific handling of emergency and flow-level precedence out of w-g scope, but ensure we don't preclude what others are doing =20 2/ Technical issues - compatibility of coding with RFC3168 - sub-optimalities: ECMP, bi-directional flows & pre-emption WG will need to reach consensus on the extent to which standardization effort should address these =20 =20 Jongwon Choe (name not clear), DoD: Why to exclude the emergency service work on preemption? =20 Philip Eardley: It would add a lot of complexity. They are not really in the expertise of the PCN group. =20 Anna Charny: Not focusing on *standardizing* MLP, but scope does include working with other groups who do =20 Kwok Ho Chan: Clarification: Policy on MLP etc is an edge-edge issue, that we don't need to preclude in focusing on the interior to edge interface =20 Robert Shafer: Chair of the Network Interconnection Interoperability=20 Forum gives a brief overview of their organizations and the work they do. They started with work on PSTN and now focus more on IP. Their group is looking forward to interact with the PCN group. Scott Bradner suggests that members from their group subscribe to the mailing list. Stuart Goldman: ATIS BTSC SAG & ITU-T would be groups to talk to. Scott Bradner: Information from these groups would be useful. Robert Schafer: Emergency announcements to local areas over PSTN - ultimately NIIF may extend into this space. These calls look like regular calls, not specially marked. This would be a hard problem. 4. Overview of Existing Work (10 min) Kwok Ho Chan * Deployment Models - Controlled Load : RSVP as signalling protocol outside and between PCN edge nodes see =20 =20 - SIP controlled flow admission & pre-emption model see =20 =20 James Polk: Where does a phone fit in the middle? Kwok Ho Chan: Phone on edge of PCN region=20 Dave Oran: Find picture incredibly confusing but suggest to move on Joe Babiarz: PCN region extends to end-points=20 David Black: Is the assumption that phones are trusted? Kwok Ho Chan: Yes Francois le Faucheur: the call-server is meant to be *above* the data plane, not on the edge of the PCN region Bruce Davie: Confusingly described. Also may not be legitimate. But the w-g can decide whether or not it is a legitimate model to take on board, don't have to decide in the BoF. Dave Oran: Is it that the real issue is what the data plane is doing to determine whether to admit the call, with some signalling to set up the call that may be SIP (or anything else) Dave Oran: This has nothing todo with SIP. There is something that is=20 required to clue SIP together with PCN. David Black: Yes, you need a control plane and SIP may be an example. Kwok Ho Chan continues his presentation=20 * Measurement and Encoding at Interior Router - http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-03.txt =20 - http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt=20 - http://standards.nortel.com/pcn/simulation_results_00.pdf =20 - Example packet marking method described in the cl-phb draft above for AC & flow pre-emption - Measurement of marking of aggregate for AC & flow pre-emption also described Lars Eggert: BCP upcoming on how you safely redefine ECN. Stuart Goldman: How fast does it take to get back to normal? Anna Charny: Depending on the parameters it might take more than 1 second=20 but for set of "reasonable" parameters used in simulation it does preempt within 1 second. A few seconds is the target preemption time=20 Normally, a call is 2 min. But if quality of service degrades dramatically, then in a few sec most of the users hang up. And if all users are affected, all users can hang up. Therefore you want to preempt before that time, so that you only preempt enough calls to make sure that other calls are not affected. Kwok Ho Chan: In some jurisdictions it is not allowed to preempt calls. Question: Does preemption by the network allow information to be returned to the end host. Francois Le Faucheur: Yes. Bob Briscoe: You don't have to use preemption, but an operator could use it. Francois: The idea is to add some determinism when a failure happens.=20 There will be signaling to tear down the call properly to give the end=20 host (user) some feedback. Kwok Ho Chan continues with the slides: List of drafts at nortel holding place http://standards.nortel.com/pcn/ =20 Pre-Congestion Notification Problem Statement http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01. txt =20 Pre-Congestion Notification marking http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-03.txt=20 An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 04.txt=20 SIP Controlled Admission and Preemption http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt=20 Pre-Congestion Notification Using Single Marking for Admission and Pre-emption=20 http://www.ietf.org/internet-drafts/draft-charny-pcn-single-marking-00.t xt=20 Performance Evaluation of CL-PHB Admission and pre-emption Algorithms http://www.ietf.org/internet-drafts/draft-zhang-pcn-performance-evaluati on-00.txt =20 5. Open Discussion on PCN (20 min) ------------------------- David Black: The PCN region roughly corresponds to a Diffserv domain. However, when we did Diffserv, we looked at cross-domain. There is the risk of making the problem space larger than it initially was. Where this starts from is the trust discussion. The assumption was=20 pretty good and corresponds to DiffServ. Failing to look at the cross=20 domain stuff is too narrow scoped. It does not need to be on the=20 MUST-to-be-solved items. Scott Bradner: We talked about this. We thought about rechartering to add this cross domain aspect later. Is this something to be solved already in the first round? I don't know. It needs to be addressed at some point in time. David Black: How much keeping in mind needs to be done to ensure that it can be done later? Bob Briscoe: Only brought PCN to the IETF a year or so ago once I had a solution for inter-domain deployment where they don't trust each other not to cheat. However, agree it is best to get the necessary parts standardized for single trust region most urgently, then working on multi-domain with no mutual trust after re-chartering. However, there are some issues that have to be decided for a single domain that may impact on the anti-cheating solution, e.g. PCN wire encoding. So we have to keep in mind the multi-trust-domain scenario during initial standardization. David Black: As long as 'keep in mind' is taken strongly. Yakhov Stein: What's all this for? Detect congestion because of a failure? Isn't there an easier mechanism when there is a failure? Anna Charny: Pre-emption deals with failure, Admission Control does not - it is more for the situations when provisioning may not be the right solution. Dave Oran: I assumed we could have multiple classes, all with admission control=20 Bob Briscoe: Can isolate link capacities for each class, and can have borrowing from other classes, but not priority access by another class to the admission controlled resources Yakhov Stein: What is the timescale of these pre-emption events? Bruce Davie: Timescale is that of flow admission arrivals. Yakhov Stein: Congestion causes packet forwarding to slow down - performance hit. Anything that works on buffer level is already too slow. Anna Charny: We do not do that. The idea of pre-congestion is to get the notification before the congestion happens. Francois Le Faucheur: You trigger before you are congested. The mechanism is not to trigger the queue. You can use some sort of threshold or virtual queues. =20 Dave Oran: I made the naive assumption that this stuff works on a DiffServ class domain only. Anna Charny: The assumption that it is applied to a DiffServ class is correct. The traffic in the class is not elastic.=20 Dave Oran: Is this necessary? Do we have mechanisms for elastic traffic that work just fine. Can we say inelastic traffic? Anna Charny: Yes. Dave Oran: The ability of bandwidth sharing between different classes is not provided. Bob Briscoe: You don't need to have complete isolation =20 Liam Casey: I have read the simulation draft. Stability is a huge=20 factor. I am not sure there are large scale simulations show it is stable. This has to go to work with millions of calls. It is not only about simulations of 5 servers. =20 Anna Charny: Yes, the current simulation do not come close to real-world systems. However, we need to talk off-line about what stability means here. We need to understand to what extent stability concerns for traditional congestion control are applicable here.=20 Scott Bradner: You haven't tried large scale stability simulations? Anna Charny: No, not yet. Lars Eggert: How quickly do you react to congestion notification? Anna Charny: It has to react quickly before people hang up. Lars Eggert: Is the detection of congestion slower than the detection of pre-congestion? Anna Charny: Yes Josepf Babiarz: The detection is fast but there is the question on how long it needs to take before taking some actions. =20 Scott Bradner: Being very aggressive leads to instability. Lars Eggert: Is there any algorithm between the preemption vs. going down with admitting new flows? Anna Charny: There is an algorithm in the cl-arcitecture and Cl-phb drafts. (speaker at the mike, name not recorded): Preempting is a rather a difficult thing todo. Have you thought about notifying users to fall back to a different codec rather than preempting their conversation. This, however, requires feedback to a user. Josef Babiarz: Yes. Anna Charny: There are two different questions: a) Have we looked at it? b) Should the working group do it? Regarding (a): yes. Regarding (b): No under the proposed charter. Scott Bradner: That's a reasonable thing to discuss on the mailing list. Dana Blair: Is there a formal definition of stability? Scott: Do you have some suggestions? Anna: I don't know how to answer this question in this context. Stability is typically applied to congestion control systems where the function of interest can adjust up or down. In the framework we propose, Admission Control can only stop admission, and pre-emption can only bring the amount of traffic down. So there are two questions of interest: a) Admission: Does it stop admitting when expected or does it over- or under-admit? b) Preemption: Does it pre-empt the right amount or does it over- or under-shoot)? Jim Bound: There is a lot of momentum for admission control. There is a lot of things important in the proposed scope. Scott Bradner: There are two things: a) Propose work in the IETF b) Keep in mind when designing the core protocol. You need to know what the requirements are to design the protocol. =20 6. Proposed Charter (20 min) Anna Charny presents=20 http://standards.nortel.com/pcn/PCN_draft_charter_v01.txt * Standards track docs to address 3 areas: 1. When should an interior router mark a packet (i.e. at what traffic level) in order to give early warning of its own congestion? 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? 3. How should these markings (at packet granularity) be converted into admission control and flow pre-emption decisions (at flow granularity)? =20 Jacob Stein: When should a router mark a packet sounds like implementation. Scott Bradner/Bruce Davie (both said same thing): Shouldn't describe hardware, but should describe behavior for interoperability. =20 Anna Charny continues presentation: =20 * Informational documents: =20 1. a Problem Statement =20 James Polk: Don't see requrements doc. Problem statement isn't the same=20 Scott Bradner: In general believe reqs doc is a good idea. Also worried about getting bogged down. Anna Charny continues 2. at least two deployment models, possibly from: - like IntServ over DiffServ (RFC2998) but with PCN-enabled DiffServ region and edge nodes decide about admission and flow pre-emption - SIP Controlled Admission and Preemption: using trusted SIP endpoints (gateway or host) performing admission and flow pre-emption and PCN-capable routers within the DiffServ region James Polk: Sounds like a SIP doc for SIPPING=20 Scott Bradner: This represents requirements to SIPPING Stuart Goldman: Is it reasonable to add a boilerplate to the charter to say that work will be done with other working group. Anna: Sounds good to me. Scott: Also useful. =20 Anna Charny continues presentation: =20 - Pseudowire: PCN may be used as a congestion avoidance mechanism for end-user deployed pseudowires (collaborate with the PWE3 WG) Lars Eggert: Not solving the whole pseudo-wire problem, so won't be useful. Yakhov Stein: Nowhere does it say PWE3 should be over provisioned paths=20 Lars Eggert: There is an statement that does say this. Dave Oran: If it requires SIP to change, we have problems, but I doubt it does. It has a dependency on SDP, which has the QoS pre-conditions. Anna Charny: What would you suggest? Dave Oran: Change the wording to Application-controlled (rather than SIP-controlled) admission & pre-emption Stuart Goldman: As SIPPING says they take all changes to SIP, shouldn't this w-g say it takes all PCN-related aspects? Scott Bradner: Good point Bruce Davie: Reservation on using PCN for pseudo-wire is that concern with PWE3 is immediate deployment of Internet as-is. There is precious little ECN, let alone PCN deployment (given it's not standardized yet) in the current Internet. Anna Charny: Should pseudo-wires stay in the charter? Bruce Davie: No, too forward looking for a phase 1 charter Anna Charny continues presentation: =20 3. analysis of the signaling extensions required to support PCN - actual extensions in other w-gs (RSVP, NSIS, SIP) not PCN=20 4. at least one example solution implementing the framework and its performance evaluation (e.g. simulation) =20 5. tradeoffs between different encoding possibilities (e.g. ECN and DCSP marking) * Initial restriction of scope (assumptions): 1. Trust assumption: PCN region is a controlled environment David Black: Trust assumption: need to add 'keeping in mind' interconnection. I won't let you forget that. 2. aggregation: many flows on any link =20 3. inelastic traffic: QoS assurance for r-t apps generating inelastic traffic - voice & video low delay, jitter and packet loss, i.e. Controlled Load Svc [RFC2211]. =20 4. Specific handling of emergency and other precedence (911, GETS, WPS, MLPP etc.) calls out of scope, - *but* PCN must ensure using PCN technology doesn't preclude edge nodes from taking the appropriate emergency actions required by these standards/initiatives - PCN Internal Nodes may not be MLPP-aware but they are DSCP aware =20 Bob Briscoe: Assumption 2 (aggregation) doesn't seem to include SIP endpoint=20 Matt Mathis: Change assumption 2 to "There are sufficient flows where relevant bottlenecks" Anna Charny: Will do Francois le Faucheur: Assumption 2: Add applicability statement to the charter. * Re-chartering later May relax some of the assumptions when re-chartering (e.g. single trust domain assumption) =20 Out of scope: general investigation of AC mechs - we build on considerable academic and prior IETF work on measurement-based admission control (MBAC) =20 Milestones ---------- Nov 2006 initial Problem statement Nov 2006 initial deployment models March 2007 initial router marking behavior (including encoding) March 2007 initial flow admission control and pre-emption mechanism (including edge node behavior) March/July 2007 submit Problem statement March/July 2007 submit deployment models Nov 2007 submit router marking behavior Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism Nov 2007 initial signaling analysis Mar 2008 re-charter or close =20 Francois le Faucheur: How would applicability statement fit into milestones? Scott Bradner: Personally a stand-alone applicability statement would be my preference. David Black: Would need an applicability statement specific to the endpoint model.=20 Scott Bradner: Or not signalling protocol specific=20 David Black: Need to use SIP as an example app signalling protocol=20 Dave Oran: Most important aspect is endpoint-endpoint in that deployment model. Georgios Karagiannis: SIP applicability statement. Yes, SIP just an example application signalling protocol. Also need end-to-concentrator, or concentrator-to-concentrator. =20 7. Discussion of Proposed Charter (20 min) =20 No further discussion =20 8. Summary and Conclusions (10 min) =20 Scott Bradner: Is this ready for IETF w-g? =20 [About 150 people in the room.] Of which about 100 voted: ~98 for; 2 against =20 Scott Bradner: Now the task is to work with the ADs on a charter, to post to list. This BoF does not presuppose who the w-g chairs are in any way. =20 Lars Eggert: Show of hands please, on who is interested (other than the authors of the drafts) in helping in this w-g? 7 hands up. =20 Question from the room: Is there a mailing list? =20 Anna Charny: pcn@ietf.org =20 =20 [Subscribe via: ] =20 =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 Nov 14 16:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5Wo-00033e-By; Tue, 14 Nov 2006 16:09:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5Wn-00033S-3X for pcn@ietf.org; Tue, 14 Nov 2006 16:09:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk5Wh-0005q7-Tp for pcn@ietf.org; Tue, 14 Nov 2006 16:09:09 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 13:09:03 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAEL93Ah017523; Tue, 14 Nov 2006 13:09:03 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAEL8idY008202; Tue, 14 Nov 2006 13:08:52 -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); Tue, 14 Nov 2006 16:08:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C70831.117ABEF7" Date: Tue, 14 Nov 2006 16:08:43 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: updated PCN BOF minutes Thread-Index: AccIMRD4NhR0a4E/Qy+QMtAMX7rPvQ== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 14 Nov 2006 21:08:44.0628 (UTC) FILETIME=[11AC6940:01C70831] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=29869; t=1163538543; x=1164402543; 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:=20updated=20PCN=20BOF=20minutes |Sender:=20; bh=gbuc7qFx/K0MvH5weMwDPU1ev3qaUhbtz0/ZaGlVPaA=; b=ABCqaayLKsNOudj+4B4t3BziZe4h/4hb1nVZBtw4o/1OG0VsqzvdZQdIFk8b0kIMCpQo0v8a ViAH0kjiCz1RdRZPW741tOTkNT7EykCl6etJnDJ8Z/+wTCWVGcgVDKIs; Authentication-Results: sj-dkim-7; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: Lars Eggert , Scott O Bradner Subject: [PCN] updated PCN BOF minutes 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C70831.117ABEF7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 Attached are the PCN BOF minutes updated based on the comments already received. Please send any corrections by November 21. =20 Thank you, Anna and Scott PCN BOF Chairs ------_=_NextPart_001_01C70831.117ABEF7 Content-Type: text/plain; name="PCN BOF Minutes.txt" Content-Transfer-Encoding: base64 Content-Description: PCN BOF Minutes.txt Content-Disposition: attachment; filename="PCN BOF Minutes.txt" UHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIEJPRg0KDQpNb25kYXksIE5vdmVtYmVyIDYgYXQg MDkwMC0xMTMwDQpSb29tOiBHcmFuZGUgQmFsbHJvb20gQw0KDQpCT0YgQ28tQ2hhaXJzOiBBbm5h IENoYXJueSBhbmQgU2NvdHQgQnJhZG5lcg0KIA0KDQoxLiBBZ2VuZGEgQmFzaGluZyBhbmQgQWRt aW5pc3RyYXRpdmlhICg1IG1pbikNCg0KU2NvdHQgQnJhZG5lcjogUm9iZXJ0IFNjaGFmZmVyIHdp bGwgYmUgdGFsa2luZyBhYm91dCB3b3JrIGluIGFub3RoZXIgU0RPLg0KDQpObyBjb21tZW50cy4N Cg0KMi4gT3ZlcnZpZXcgYW5kIEludHJvZHVjdGlvbiAoMjAgbWluKQ0KDQpBbm5hIENoYXJueToN Cg0KRGV0YWlsczogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNo YW4tcGNuLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dCANCiANCg0KKiBXaGF0IGlzIFBDTj8NCg0K ICAtIEFkbWlzc2lvbiBjb250cm9sICYgcHJlLWVtcHRpb24gdXNpbmcgcGFja2V0IG1hcmtpbmcN CiAgLSBTZXBhcmF0aW9uIG9mIGNvcmUgYW5kIGVkZ2UgYmVoYXZpb3JzOiBjb3JlIG1hcmtzLCBl ZGdlcyBtZWFzdXJlIGFuZCBhY3Qgb24gbWFya2luZw0KDQoqIFdoeSBpdCdzIGEgdGVjaG5pY2Fs IHByb2JsZW0gb2YgaW50ZXJlc3QNCg0KKiBXaHkgYWRtaXNzaW9uIGNvbnRyb2wgKEFDKT8gDQoN CnN0cmV0Y2hpbmcgdHJhZmZpYyBhc3N1bXB0aW9ucyBiZXlvbmQgY3VycmVudCB0eXBpY2FsIG1p eCB0byBsYXJnZSBwcm9wb3J0aW9ucyBvZiBpbmVsYXN0aWMgdHJhZmZpYywgZGVhbGluZyB3aXRo IGZhaWx1cmVzICYgYW5vbWFsb3VzIHRyYWZmaWMgc2NlbmFyaW9zDQoNCiogV2h5IHlldCBhbm90 aGVyIEFDIG1lY2hhbmlzbT8NCg0KQSBmdXJ0aGVyIHNjYWxhYmlsaXR5IHN0ZXAgYmV5b25kIElu dHNlcnYgb3ZlciBEaWZmU2VydiwgYWdncmVnYXRlIHJlc2VydmF0aW9ucyBhbmQgcmVzZXJ2YXRp b24tYmFzZWQgUk1EIChubyBjb3JlIHN0YXRlIGJ1dCBzdGlsbCBzaWduYWxpbmcgaW4gY29yZSkN Cg0KKiBTdGF0ZSBvZiBNYXR1cml0eTogYnVpbGRzIG9uIHN1YnN0YW50aWFsIGJvZHkgb2YgcHJp b3IgdGhlb3JldGljYWwgd29yaywgYW5kIHN1YnN0YW50aWFsIHJlY2VudCB3b3JrIGJ5IHRob3Nl IHdvcmtpbmcgb24gUENOIDMvIFdoeSBhbiBJRVRGIHByb2JsZW0/DQoNCiogUHJvZ3Jlc3NlZCB0 byBzdGFnZSB3aGVyZSBzdGFuZGFyZGl6YXRpb24gb2YgcGFja2V0IG1hcmtpbmcgd291bGQgYmUg cmVhc29uYWJsZQ0KDQoqIFNvbWUgb3BlbiBpc3N1ZXMsIHdoZXJlIGNvbnNlbnN1cyBzdGlsbCBo YXNuJ3QgY29udmVyZ2VkIChzZWUgUGhpbCBFYXJkbGV5J3MgcHJlc2VudGF0aW9uIG5leHQpDQoN CiAgIC0gbWFya2luZyBiZWhhdmlvcg0KICAgLSBtYXJraW5nIGVuY29kaW5nDQogICAtIGhvdyBt dWNoIGFnZ3JlZ2F0aW9uIGlzICdlbm91Z2gnDQogICAtIGNvbnNlbnN1cyBiZXN0IGZvcm1lZCBh cm91bmQgZGlzY3Vzc2luZyB0aGVzZSBpc3N1ZXMgd3J0IHdlbGwtdW5kZXJzdG9vZCBkZXBsb3lt ZW50IG1vZGVscy4NCg0KKiBDb25uZWN0aW9uIHdpdGggb3RoZXIgZ3JvdXBzOg0KDQogICAtIFJG QzMxNjggRUNOIGNvbXBhdGliaWxpdHkgKHRzdndnKQ0KICAgLSBzaWduYWxpbmcgZXh0ZW5zaW9u cyB0byBiZSBkb25lIGluIHJlbGV2YW50IGdyb3Vwcw0KICAgLSBSU1ZQICh0c3YpLCBOU0lTIChu c2lzKSwgU0lQIChtbXVzaWMpDQogICAtIHBjbiBvdmVyIE1QTFMgKHRzdikNCiAgIC0gcmVsZXZh bmNlIHRvIGNlcnRhaW4gcHNldWRvLXdpcmVzPyAocHdlMykNCiAgIC0gRW5zdXJpbmcgZW1lcmdl bmN5IHNlcnZpY2VzIHdvcmsgYWNyb3NzIGEgUENOIGNsb3VkIChpZXByZXAgJiBlY3JpdCkNCg0K KiBTdW1tYXJ5OiANCiAgIC0gVGhlcmUgaXMgYSBsZWdpdGltYXRlIHRlY2huaWNhbCBwcm9ibGVt DQogICAtIFRoZXJlIGlzIG5lZWQgb2Ygc3RhbmRhcmRpemF0aW9uIGVmZm9ydA0KICAgLSBUaGUg c29sdXRpb24gaXMgc3VmZmljaWVudGx5IG1hdHVyZQ0KICAgLSBUaGVyZSBhcmUgYSBib3VuZGVk IG51bWJlciBvZiBvcGVuIGlzc3VlcyBuZWVkaW5nIHJlc29sdXRpb24NCg0KSGFubmVzIFRzY2hv ZmVuaWc6IFRoZXJlIHdhcyBubyBvZmZpY2lhbCBkZXNpZ24gdGVhbSB3b3JraW5nIG9uIFBDTiBp biBUU1ZXRywgY29ycmVjdD8NCg0KU2NvdHQgQnJhZG5lcjogIENvcnJlY3QuDQoNClN0dWFydCBH b2xkbWFuOiBBcmUgeW91IGludGVyYWN0aW5nIHdpdGggb3JnYW5pemF0aW9ucyBvdXRzaWRlIHRo ZSBJRVRGPw0KDQpTY290dCBCcmFkbmVyOiBBZnRlciBmb3JtaW5nIGEgd29ya2luZyBncm91cCBh IG1lc3NhZ2UgaXMgc2VudCB0byB0aGUgbmV3IHdvcmsgbWFpbGluZyBsaXN0IHdoZXJlIG1hbnkg b3RoZXIgU0RPcyBhcmUgc3Vic2NyaWJlZCB0byBhbm5vdW5jZSBpdCBhbmQgdG8gZGV0ZXJtaW5l IG92ZXJsYXBzLg0KDQoNCjMvLiBLZXkgT3BlbiBJc3N1ZXMgKDEwIG1pbikNCg0KUGhpbCBFYXJk bGV5DQoNCiogU3RhbmRhcmRpemF0aW9uIGlzc3Vlcw0KDQogICAtIHBhY2tldCBtYXJraW5nICh3 aXRob3V0IGRlZmluaW5nIGFsZ29yaXRobSwgYnV0IGVuc3VyaW5nIGludGVyb3BlcmFiaWxpdHkp DQogICAtIG1hcmsgZW5jb2RpbmcgKEVDTiwgRFNDUD8pDQogICAtIGNvbnZlcnNpb24gb2YgcGFj a2V0IG1hcmtpbmcgaW50byBmbG93LWdyYW51bGFyaXR5IEFDICYgcHJlLWVtcHRpb24gZGVjaXNp b25zIChleGFjdGx5IG9uZSBiZWhhdmlvciwgb3IgbW9yZSB0aGFuIG9uZSAtIHBlcmhhcHMgZGlm ZmVyZW50IGRlcGxveW1lbnQgc2NlbmFyaW9zIG5lZWQgZGlmZmVyZW50IGJlaGF2aW9yczogY3Vy cmVudCBjb25zZW5zdXM6IGV4YWN0bHkgb25lIGJlaGF2aW9yIGlzIGRvYWJsZSkgDQoNCiogRm9j dXNpbmcgdGhlIHdvcmsNCg0KICAgLSBjb21tdW5pdHkgY29uc2Vuc3VzIHJlcXVpcmVkIG9uIGRl cGxveW1lbnQgbW9kZWxzDQogICAtIHRoZW4gY29tbXVuaXR5IGNvbnNlbnN1cyByZXF1aXJlZCBv biBhc3N1bXB0aW9ucyAobG9vc2VuIGFzc3VtcHRpb25zIGZvciByZS1jaGFydGVyZWQgcGhhc2Ug SUkpIHVuZGVybHlpbmcgdGhlc2UgZGVwbG95bWVudCBtb2RlbHMgdGhhdCBhcmUgbmVjZXNzYXJ5 IGZvciBQQ04gdG8gd29yay4NCg0KKiBNYWluIGFzc3VtcHRpb25zDQoNCiAgIC0gUENOIHJlZ2lv biBpcyBmdWxseSBlbmNsb3NlZCBieSBlZGdlIG5vZGVzIHRoYXQgZW5zdXJlIG5vIFBDTiB0cmFm ZmljIGNhbiBlbnRlciB3aXRob3V0IEFDLiAoY29udHJvbGxlZCBlbnZpcm9ubWVudCkNCiAgIC0g YXZvaWQgY2hlYXRpbmcgaXNzdWVzIChidXQgdHJ1c3QgaXMgdGhlIGlzc3VlIHRoYXQgaXMgbGlr ZWx5IHRvIGNvbWUgdXAgYWZ0ZXIgcmUtY2hhcnRlcmluZykNCiAgIC0gc3BlY2lmaWMgaGFuZGxp bmcgb2YgZW1lcmdlbmN5IGFuZCBmbG93LWxldmVsIHByZWNlZGVuY2Ugb3V0IG9mIHctZyBzY29w ZSwgYnV0IGVuc3VyZSB3ZSBkb24ndCBwcmVjbHVkZSB3aGF0IG90aGVycyBhcmUgZG9pbmcNCg0K KiBUZWNobmljYWwgaXNzdWVzDQoNCiAgIC0gY29tcGF0aWJpbGl0eSBvZiBjb2Rpbmcgd2l0aCBS RkMzMTY4DQogICAtIHN1Yi1vcHRpbWFsaXRpZXM6IEVDTVAsIGJpLWRpcmVjdGlvbmFsIGZsb3dz ICYgcHJlLWVtcHRpb24gV0cgd2lsbCBuZWVkIHRvIHJlYWNoIGNvbnNlbnN1cyBvbiB0aGUgZXh0 ZW50IHRvIHdoaWNoIHN0YW5kYXJkaXphdGlvbiBlZmZvcnQgc2hvdWxkIGFkZHJlc3MgdGhlc2UN Cg0KWW9uZyBYdWUsIERvRDogV2h5IHRvIGV4Y2x1ZGUgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyB3 b3JrIG9uIHByZWVtcHRpb24/DQoNClBoaWxpcCBFYXJkbGV5OiBJdCB3b3VsZCBhZGQgYSBsb3Qg b2YgY29tcGxleGl0eS4gVGhleSBhcmUgbm90IHJlYWxseSBpbiB0aGUgIGV4cGVydGlzZSBvZiB0 aGUgUENOIGdyb3VwLg0KDQpBbm5hIENoYXJueTogIE5vdCBmb2N1c2luZyBvbiAqc3RhbmRhcmRp emluZyogZW1lcmdlbmN5IHNlcnZpY2VzLCBidXQgc2NvcGUgZG9lcyBpbmNsdWRlIHdvcmtpbmcg d2l0aCBvdGhlciBncm91cHMgd2hvIGRvDQogDQpLd29rIEhvIENoYW46IENsYXJpZmljYXRpb246 IFBvbGljeSBvbiBNTFAgZXRjIGlzIGFuIGVkZ2UtZWRnZSBpc3N1ZSwgdGhhdCB3ZSBkb24ndCBu ZWVkIHRvIHByZWNsdWRlIGluIGZvY3VzaW5nIG9uIHRoZSBpbnRlcmlvciB0byBlZGdlIGludGVy ZmFjZQ0KDQpSb2JlcnQgU2hhZmVyOiBDaGFpciBvZiB0aGUgTmV0d29yayBJbnRlcmNvbm5lY3Rp b24gSW50ZXJvcGVyYWJpbGl0eSANCg0KRm9ydW0gZ2l2ZXMgYSBicmllZiBvdmVydmlldyBvZiB0 aGVpciBvcmdhbml6YXRpb25zIGFuZCB0aGUgd29yayB0aGV5IGRvLiBUaGV5IHN0YXJ0ZWQgd2l0 aCB3b3JrIG9uIFBTVE4gYW5kIG5vdyBmb2N1cyBtb3JlIG9uIElQLiBUaGVpciBncm91cCBpcyBs b29raW5nIGZvcndhcmQgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgUENOIGdyb3VwLg0KDQpTY290dCBC cmFkbmVyIHN1Z2dlc3RzIHRoYXQgbWVtYmVycyBmcm9tIHRoZWlyIGdyb3VwIHN1YnNjcmliZSB0 byB0aGUgbWFpbGluZyBsaXN0Lg0KDQpTdHVhcnQgR29sZG1hbjogQVRJUyBCVFNDIFNBRyAmIElU VS1UIHdvdWxkIGJlIGdyb3VwcyB0byB0YWxrIHRvLg0KDQpTY290dCBCcmFkbmVyOiBJbmZvcm1h dGlvbiBmcm9tIHRoZXNlIGdyb3VwcyB3b3VsZCBiZSB1c2VmdWwuDQoNClJvYmVydCBTY2hhZmVy OiBFbWVyZ2VuY3kgYW5ub3VuY2VtZW50cyB0byBsb2NhbCBhcmVhcyBvdmVyIFBTVE4gLSB1bHRp bWF0ZWx5IE5JSUYgbWF5IGV4dGVuZCBpbnRvIHRoaXMgc3BhY2UuIFRoZXNlIGNhbGxzIGxvb2sg bGlrZSByZWd1bGFyIGNhbGxzLCBub3Qgc3BlY2lhbGx5IG1hcmtlZC4gVGhpcyB3b3VsZCBiZSBh IGhhcmQgcHJvYmxlbS4NCg0KNC4gT3ZlcnZpZXcgb2YgRXhpc3RpbmcgV29yayAoMTAgbWluKQ0K DQpLd29rIEhvIENoYW4NCg0KKiBEZXBsb3ltZW50IE1vZGVscw0KDQogICAtIENvbnRyb2xsZWQg TG9hZCA6IFJTVlAgYXMgc2lnbmFsaW5nIHByb3RvY29sIG91dHNpZGUgYW5kIGJldHdlZW4gUENO IGVkZ2Ugbm9kZXMgc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWJyaXNjb2UtY2wtYXJjaGl0ZWN0dXJlLTA0LnR4dCANCiAgIC0gU0lQIGNvbnRyb2xsZWQgZmxv dyBhZG1pc3Npb24gJiBwcmUtZW1wdGlvbiBtb2RlbCBzZWUNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJhYmlhcnotcGNuLXNpcC1jYXAtMDAudHh0ICANCg0KDQpK YW1lcyBQb2xrOiBXaGVyZSBkb2VzIGEgcGhvbmUgZml0IGluIHRoZSBtaWRkbGU/DQoNCkt3b2sg SG8gQ2hhbjogUGhvbmUgb24gZWRnZSBvZiBQQ04gcmVnaW9uIA0KDQpEYXZlIE9yYW46IEZpbmQg cGljdHVyZSBpbmNyZWRpYmx5IGNvbmZ1c2luZyBidXQgc3VnZ2VzdCB0byBtb3ZlIG9uDQoNCkpv ZSBCYWJpYXJ6OiBQQ04gcmVnaW9uIGV4dGVuZHMgdG8gZW5kLXBvaW50cyANCg0KRGF2aWQgQmxh Y2s6IElzIHRoZSBhc3N1bXB0aW9uIHRoYXQgcGhvbmVzIGFyZSB0cnVzdGVkPw0KDQpLd29rIEhv IENoYW46IFllcw0KDQpGcmFuY29pcyBsZSBGYXVjaGV1cjogdGhlIGNhbGwtc2VydmVyIGlzIG1l YW50IHRvIGJlICphYm92ZSogdGhlIGRhdGEgcGxhbmUsIG5vdCBvbiB0aGUgZWRnZSBvZiB0aGUg UENOIHJlZ2lvbg0KDQpCcnVjZSBEYXZpZTogQ29uZnVzaW5nbHkgZGVzY3JpYmVkLiBBbHNvIG1h eSBub3QgYmUgbGVnaXRpbWF0ZS4gQnV0IHRoZSB3LWcgY2FuIGRlY2lkZSB3aGV0aGVyIG9yIG5v dCBpdCBpcyBhIGxlZ2l0aW1hdGUgbW9kZWwgdG8gdGFrZSBvbiBib2FyZCwgZG9uJ3QgaGF2ZSB0 byBkZWNpZGUgaW4gdGhlIEJPRi4NCg0KRGF2ZSBPcmFuOiBJcyBpdCB0aGF0IHRoZSByZWFsIGlz c3VlIGlzIHdoYXQgdGhlIGRhdGEgcGxhbmUgaXMgZG9pbmcgdG8gZGV0ZXJtaW5lIHdoZXRoZXIg dG8gYWRtaXQgdGhlIGNhbGwsIHdpdGggc29tZSBzaWduYWxpbmcgdG8gc2V0IHVwIHRoZSBjYWxs IHRoYXQgbWF5IGJlIFNJUCAob3IgYW55dGhpbmcgZWxzZSkNCg0KRGF2ZSBPcmFuOiBUaGlzIGhh cyBub3RoaW5nIHRvIGRvIHdpdGggU0lQLiBUaGVyZSBpcyBzb21ldGhpbmcgdGhhdCBpcyAgcmVx dWlyZWQgdG8gY2x1ZSBTSVAgdG9nZXRoZXIgd2l0aCBQQ04uDQoNCkRhdmlkIEJsYWNrOiBZZXMs IHlvdSBuZWVkIGEgY29udHJvbCBwbGFuZSBhbmQgU0lQIG1heSBiZSBhbiBleGFtcGxlLg0KDQpL d29rIEhvIENoYW4gY29udGludWVzIGhpcyBwcmVzZW50YXRpb24gDQoNCiogTWVhc3VyZW1lbnQg YW5kIEVuY29kaW5nIGF0IEludGVyaW9yIFJvdXRlcg0KDQogICAtIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJyaXNjb2UtdHN2d2ctY2wtcGhiLTAzLnR4dCAgIA0K ICAgLSBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1wY24t cGVyZm9ybWFuY2UtZXZhbHVhdGlvbi0wMC50eHQgDQogICAtIGh0dHA6Ly9zdGFuZGFyZHMubm9y dGVsLmNvbS9wY24vc2ltdWxhdGlvbl9yZXN1bHRzXzAwLnBkZiAgDQoNCiAgICAtIEV4YW1wbGUg cGFja2V0IG1hcmtpbmcgbWV0aG9kIGRlc2NyaWJlZCBpbiB0aGUgY2wtcGhiIGRyYWZ0IGFib3Zl IGZvciBBQyAmIGZsb3cgcHJlLWVtcHRpb24NCg0KICAgIC0gTWVhc3VyZW1lbnQgb2YgbWFya2lu ZyBvZiBhZ2dyZWdhdGUgZm9yIEFDICYgZmxvdyBwcmUtZW1wdGlvbiBhbHNvIGRlc2NyaWJlZA0K DQpMYXJzIEVnZ2VydDogQkNQIHVwY29taW5nIG9uIGhvdyB5b3Ugc2FmZWx5IHJlZGVmaW5lIEVD Ti4NCg0KU3R1YXJ0IEdvbGRtYW46IEhvdyBmYXN0IGRvZXMgaXQgdGFrZSB0byBnZXQgYmFjayB0 byBub3JtYWw/DQoNCkFubmEgQ2hhcm55OiAgRGVwZW5kaW5nIG9uIHRoZSBwYXJhbWV0ZXJzIGl0 IG1pZ2h0IHRha2UgbW9yZSB0aGFuIDEgc2Vjb25kLCBidXQgZm9yIHNldCBvZiCTcmVhc29uYWJs ZZQgcGFyYW1ldGVycyB1c2VkIGluIHNpbXVsYXRpb24gaXQgZG9lcyBwcmVlbXB0IHdpdGhpbiAx IHNlY29uZC4gIEEgZmV3IHNlY29uZHMgaXMgdGhlIHRhcmdldCBwcmVlbXB0aW9uIHRpbWUuICBO b3JtYWxseSwgYSBjYWxsIGlzIDIgbWluLiBCdXQgaWYgcXVhbGl0eSBvZiBzZXJ2aWNlIGRlZ3Jh ZGVzIGRyYW1hdGljYWxseSwgdGhlbiBpbiBhIGZldyBzZWMgbW9zdCBvZiB0aGUgdXNlcnMgaGFu ZyB1cC4gIEFuZCBpZiBhbGwgdXNlcnMgYXJlIGFmZmVjdGVkLCBhbGwgdXNlcnMgY2FuIGhhbmcg dXAuIFRoZXJlZm9yZSB5b3Ugd2FudCB0byBwcmVlbXB0IGJlZm9yZSB0aGF0IHRpbWUsIHNvIHRo YXQgeW91IG9ubHkgcHJlZW1wdCBlbm91Z2ggY2FsbHMgdG8gbWFrZSBzdXJlIHRoYXQgb3RoZXIg Y2FsbHMgYXJlIG5vdCBhZmZlY3RlZC4gVGhhdCBkZWZpbmVzIHRoZSByZXF1aXJlbWVudCB0aGF0 IHByZS1lbXB0aW9uIG11c3Qgd29yayB3aXRoaW4gMS0yIHNlY29uZHMuDQoNCkt3b2sgSG8gQ2hh bjogSW4gc29tZSBqdXJpc2RpY3Rpb25zIGl0IGlzIG5vdCBhbGxvd2VkIHRvIHByZWVtcHQgY2Fs bHMuDQoNClF1ZXN0aW9uIGZyb20gdGhlIGZsb29yKG5hbWUgbm9yIHJlY29yZGVkKTogIERvZXMg cHJlZW1wdGlvbiBieSB0aGUgbmV0d29yayBhbGxvdyBpbmZvcm1hdGlvbiB0byBiZSByZXR1cm5l ZCB0byB0aGUgZW5kIGhvc3Q/DQoNCkZyYW5jb2lzIExlIEZhdWNoZXVyOiBZZXMuDQoNCkJvYiBC cmlzY29lOiBZb3UgZG9uJ3QgaGF2ZSB0byB1c2UgcHJlZW1wdGlvbiwgYnV0IGFuIG9wZXJhdG9y IGNvdWxkIHVzZSBpdC4NCg0KRnJhbmNvaXM6IFRoZSBpZGVhIGlzIHRvIGFkZCBzb21lIGRldGVy bWluaXNtIHdoZW4gYSBmYWlsdXJlIGhhcHBlbnMuIFRoZXJlIHdpbGwgYmUgc2lnbmFsaW5nIHRv IHRlYXIgZG93biB0aGUgY2FsbCBwcm9wZXJseSB0byBnaXZlIHRoZSBlbmQgDQpob3N0ICh1c2Vy KSBzb21lIGZlZWRiYWNrLg0KDQpLd29rIEhvIENoYW4gY29udGludWVzIHdpdGggdGhlIHNsaWRl czoNCg0KUmVwb3NpdG9yeSBvZiBQQ04gZHJhZnRzIGF0IGlzIGF0IGh0dHA6Ly9zdGFuZGFyZHMu bm9ydGVsLmNvbS9wY24vDQogDQoNClByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiBQcm9ibGVt IFN0YXRlbWVudCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGFu LXBjbi1wcm9ibGVtLXN0YXRlbWVudC0wMS50eHQgIA0KDQpQcmUtQ29uZ2VzdGlvbiBOb3RpZmlj YXRpb24gbWFya2luZw0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt YnJpc2NvZS10c3Z3Zy1jbC1waGItMDMudHh0IA0KDQpBbiBlZGdlLXRvLWVkZ2UgRGVwbG95bWVu dCBNb2RlbCBmb3IgUHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIA0KaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJpc2NvZS10c3Z3Zy1jbC1hcmNoaXRlY3R1cmUt MDQudHh0IA0KDQpTSVAgQ29udHJvbGxlZCBBZG1pc3Npb24gYW5kIFByZWVtcHRpb24gDQpodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iYWJpYXJ6LXBjbi1zaXAtY2Fw LTAwLnR4dCANCg0KUHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFVzaW5nIFNpbmdsZSBNYXJr aW5nIGZvciBBZG1pc3Npb24gYW5kIFByZS1lbXB0aW9uIA0KaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hhcm55LXBjbi1zaW5nbGUtbWFya2luZy0wMC50eHQgDQoN ClBlcmZvcm1hbmNlIEV2YWx1YXRpb24gb2YgQ0wtUEhCIEFkbWlzc2lvbiBhbmQgcHJlLWVtcHRp b24gQWxnb3JpdGhtcyBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16 aGFuZy1wY24tcGVyZm9ybWFuY2UtZXZhbHVhdGlvbi0wMC50eHQgIA0KDQo1LiBPcGVuIERpc2N1 c3Npb24gb24gUENOICgyMCBtaW4pDQoNCkRhdmlkIEJsYWNrOiAgVGhlIFBDTiByZWdpb24gcm91 Z2hseSBjb3JyZXNwb25kcyB0byBhIERpZmZTZXJ2IGRvbWFpbi4gIEhvd2V2ZXIsIHdoZW4gd2Ug ZGlkIERpZmZTZXJ2LCB3ZSBsb29rZWQgYXQgY3Jvc3MtZG9tYWluLiBUaGVyZSBpcyB0aGUgcmlz ayBvZiBtYWtpbmcgdGhlIHByb2JsZW0gc3BhY2UgbGFyZ2VyIHRoYW4gaXQgaW5pdGlhbGx5IHdh cy4gV2hlcmUgdGhpcyBzdGFydHMgZnJvbSBpcyB0aGUgdHJ1c3QgZGlzY3Vzc2lvbi4gVGhlIGFz c3VtcHRpb24gd2FzIHByZXR0eSBnb29kIGFuZCBjb3JyZXNwb25kcyB0byBEaWZmU2Vydi4gRmFp bGluZyB0byBsb29rIGF0IHRoZSBjcm9zcyBkb21haW4gc3R1ZmYgaXMgdG9vIG5hcnJvdyBzY29w ZWQuIEl0IGRvZXMgbm90IG5lZWQgdG8gYmUgb24gdGhlIE1VU1QtdG8tYmUtc29sdmVkIGl0ZW1z Lg0KDQoNClNjb3R0IEJyYWRuZXI6ICBXZSB0YWxrZWQgYWJvdXQgdGhpcy4gV2UgdGhvdWdodCBh Ym91dCByZWNoYXJ0ZXJpbmcgdG8gYWRkIHRoaXMgY3Jvc3MgZG9tYWluIGFzcGVjdCBsYXRlci4g SXMgdGhpcyBzb21ldGhpbmcgdG8gYmUgc29sdmVkIGFscmVhZHkgaW4gdGhlIGZpcnN0IHJvdW5k PyBJIGRvbid0IGtub3cuIEl0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBhdCBzb21lIHBvaW50IGlu IHRpbWUuDQoNCkRhdmlkIEJsYWNrOiBIb3cgbXVjaCBrZWVwaW5nIGluIG1pbmQgbmVlZHMgdG8g YmUgZG9uZSB0byBlbnN1cmUgdGhhdCBpdCBjYW4gYmUgZG9uZSBsYXRlcj8NCg0KQm9iIEJyaXNj b2U6ICBPbmx5IGJyb3VnaHQgUENOIHRvIHRoZSBJRVRGIGEgeWVhciBvciBzbyBhZ28gb25jZSBJ IGhhZCBhIHNvbHV0aW9uIGZvciBpbnRlci1kb21haW4gZGVwbG95bWVudCB3aGVyZSB0aGV5IGRv bid0IHRydXN0IGVhY2ggb3RoZXIgbm90IHRvIGNoZWF0LiBIb3dldmVyLCBhZ3JlZSBpdCBpcyBi ZXN0IHRvIGdldCB0aGUgbmVjZXNzYXJ5IHBhcnRzIHN0YW5kYXJkaXplZCBmb3Igc2luZ2xlIHRy dXN0IHJlZ2lvbiBtb3N0IHVyZ2VudGx5LCB0aGVuIHdvcmtpbmcgb24gbXVsdGktZG9tYWluIHdp dGggbm8gbXV0dWFsIHRydXN0IGFmdGVyIHJlLWNoYXJ0ZXJpbmcuIEhvd2V2ZXIsIHRoZXJlIGFy ZSBzb21lIGlzc3VlcyB0aGF0IGhhdmUgdG8gYmUgZGVjaWRlZCBmb3IgYSBzaW5nbGUgZG9tYWlu IHRoYXQgbWF5IGltcGFjdCBvbiB0aGUgYW50aS1jaGVhdGluZyBzb2x1dGlvbiwgZS5nLiBQQ04g d2lyZSBlbmNvZGluZy4gU28gd2UgaGF2ZSB0byBrZWVwIGluIG1pbmQgdGhlIG11bHRpLXRydXN0 LWRvbWFpbiBzY2VuYXJpbyBkdXJpbmcgaW5pdGlhbCBzdGFuZGFyZGl6YXRpb24uDQoNCkRhdmlk IEJsYWNrOiBBcyBsb25nIGFzICdrZWVwIGluIG1pbmQnIGlzIHRha2VuIHN0cm9uZ2x5Lg0KDQpZ YWtob3YgU3RlaW46IFdoYXQncyBhbGwgdGhpcyBmb3I/IERldGVjdCBjb25nZXN0aW9uIGJlY2F1 c2Ugb2YgYSBmYWlsdXJlPyAgSXNuJ3QgdGhlcmUgYW4gZWFzaWVyIG1lY2hhbmlzbSB3aGVuIHRo ZXJlIGlzIGEgZmFpbHVyZT8NCg0KQW5uYSBDaGFybnk6ICBQcmUtZW1wdGlvbiBkZWFscyB3aXRo IGZhaWx1cmUsIEFkbWlzc2lvbiBDb250cm9sIGRvZXMgbm90IC0gaXQgaXMgbW9yZSBmb3IgdGhl IHNpdHVhdGlvbnMgd2hlbiBwcm92aXNpb25pbmcgbWF5IG5vdCBiZSB0aGUgcmlnaHQgc29sdXRp b24uDQoNCkRhdmUgT3JhbjogSSBhc3N1bWVkIHdlIGNvdWxkIGhhdmUgbXVsdGlwbGUgY2xhc3Nl cywgYWxsIHdpdGggYWRtaXNzaW9uIGNvbnRyb2wgDQoNCkJvYiBCcmlzY29lOiBDYW4gaXNvbGF0 ZSBsaW5rIGNhcGFjaXRpZXMgZm9yIGVhY2ggY2xhc3MsIGFuZCBjYW4gaGF2ZSBib3Jyb3dpbmcg ZnJvbSBvdGhlciBjbGFzc2VzLCBidXQgbm90IHByaW9yaXR5IGFjY2VzcyBieSBhbm90aGVyIGNs YXNzIHRvIHRoZSBhZG1pc3Npb24gY29udHJvbGxlZCByZXNvdXJjZXMNCg0KWWFraG92IFN0ZWlu OiBXaGF0IGlzIHRoZSB0aW1lc2NhbGUgb2YgdGhlc2UgYWRtaXNzaW9uIGFuZCBwcmVlbXB0aW9u IGV2ZW50cz8NCg0KQnJ1Y2UgRGF2aWU6IFRpbWVzY2FsZSBpcyB0aGF0IG9mIGZsb3cgYWRtaXNz aW9uIGFycml2YWxzLg0KDQpZYWtob3YgU3RlaW46IENvbmdlc3Rpb24gY2F1c2VzIHBhY2tldCBm b3J3YXJkaW5nIHRvIHNsb3cgZG93biBpcyBhIHBlcmZvcm1hbmNlIGhpdC4gQW55dGhpbmcgdGhh dCB3b3JrcyBvbiBidWZmZXIgbGV2ZWwgaXMgYWxyZWFkeSB0b28gc2xvdy4NCg0KQW5uYSBDaGFy bnk6IFdlIGRvIG5vdCBkbyB0aGF0IChkbyBub3Qgd29yayBhdCB0aGUgYnVmZmVyIGxldmVsKS4g IFRoZSBpZGVhIG9mIHByZS1jb25nZXN0aW9uIGlzIHRvIGdldCB0aGUgbm90aWZpY2F0aW9uIGJl Zm9yZSB0aGUgY29uZ2VzdGlvbiBoYXBwZW5zLg0KDQpGcmFuY29pcyBMZSBGYXVjaGV1cjogWW91 IHRyaWdnZXIgYmVmb3JlIHlvdSBhcmUgY29uZ2VzdGVkLiBUaGUgbWVjaGFuaXNtIGlzIG5vdCB0 byB0cmlnZ2VyIHRoZSBxdWV1ZS4gWW91IGNhbiB1c2Ugc29tZSBzb3J0IG9mIHRocmVzaG9sZCBv ciB2aXJ0dWFsIHF1ZXVlcy4NCiANCkRhdmUgT3JhbjogSSBtYWRlIHRoZSBuYWl2ZSBhc3N1bXB0 aW9uIHRoYXQgdGhpcyBzdHVmZiB3b3JrcyBvbiBhIERpZmZTZXJ2IGNsYXNzIGRvbWFpbiBvbmx5 Lg0KDQpBbm5hIENoYXJueTogVGhlIGFzc3VtcHRpb24gdGhhdCBpdCBpcyBhcHBsaWVkIHRvIGEg RGlmZlNlcnYgY2xhc3MgaXMgY29ycmVjdCBmb3IgdGhlIGN1cnJlbnQgc2NvcGUuICBBbm90aGVy IGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgdHJhZmZpYyBpbiB0aGUgRGlmZlNlcnYgY2xhc3MgaXMg bm90IGVsYXN0aWMuIA0KDQpEYXZlIE9yYW46IElzIHRoaXMgbmVjZXNzYXJ5PyBEbyB3ZSBoYXZl IG1lY2hhbmlzbXMgZm9yIGVsYXN0aWMgdHJhZmZpYyB0aGF0IHdvcmsganVzdCBmaW5lPyBDYW4g d2Ugc2F5IGluZWxhc3RpYyB0cmFmZmljPw0KDQpBbm5hIENoYXJueTogWWVzLg0KDQpEYXZlIE9y YW46IFRoZSBhYmlsaXR5IG9mIGJhbmR3aWR0aCBzaGFyaW5nIGJldHdlZW4gZGlmZmVyZW50IGNs YXNzZXMgaXMgbm90IHByb3ZpZGVkLg0KDQpCb2IgQnJpc2NvZTogWW91IGRvbid0IG5lZWQgdG8g aGF2ZSBjb21wbGV0ZSBpc29sYXRpb24NCiANCkxpYW0gQ2FzZXk6ICBJIGhhdmUgcmVhZCB0aGUg c2ltdWxhdGlvbiBkcmFmdC4gU3RhYmlsaXR5IGlzIGEgaHVnZSANCmZhY3Rvci4gSSBhbSBub3Qg c3VyZSB0aGVyZSBhcmUgbGFyZ2Ugc2NhbGUgc2ltdWxhdGlvbnMgd2hpY2ggc2hvdyBpdCBpcyBz dGFibGUuIFRoaXMgaGFzIHRvIGdvIHRvIHdvcmsgd2l0aCBtaWxsaW9ucyBvZiBjYWxscy4gSXQg aXMgbm90IG9ubHkgYWJvdXQgc2ltdWxhdGlvbnMgb2YgNSBzZXJ2ZXJzLg0KIA0KQW5uYSBDaGFy bnk6IFllcywgdGhlIGN1cnJlbnQgc2ltdWxhdGlvbnMgZG8gbm90IGNvbWUgY2xvc2UgdG8gdGhl IHNjYWxlIG9mIHJlYWwtd29ybGQgc3lzdGVtcy4gSG93ZXZlciwgd2UgbmVlZCB0byB0YWxrIG9m Zi1saW5lIGFib3V0IHdoYXQgc3RhYmlsaXR5IG1lYW5zIGhlcmUuIFdlIG5lZWQgdG8gdW5kZXJz dGFuZCB0byB3aGF0IGV4dGVudCBzdGFiaWxpdHkgY29uY2VybnMgZm9yIHRyYWRpdGlvbmFsIGNv bmdlc3Rpb24gY29udHJvbCBhcmUgYXBwbGljYWJsZSBoZXJlLiANCg0KU2NvdHQgQnJhZG5lcjog WW91IGhhdmVuJ3QgdHJpZWQgbGFyZ2Ugc2NhbGUgc3RhYmlsaXR5IHNpbXVsYXRpb25zPw0KDQpB bm5hIENoYXJueTogTm8sIG5vdCB5ZXQuDQoNCkxhcnMgRWdnZXJ0OiBIb3cgcXVpY2tseSBkbyB5 b3UgcmVhY3QgdG8gY29uZ2VzdGlvbiBub3RpZmljYXRpb24/DQoNCkFubmEgQ2hhcm55OiBJdCBo YXMgdG8gcmVhY3QgcXVpY2tseSBiZWZvcmUgcGVvcGxlIGhhbmcgdXAsIHdpdGhpbiAxLTIgc2Vj Lg0KDQpMYXJzIEVnZ2VydDogSXMgdGhlIGRldGVjdGlvbiBvZiBjb25nZXN0aW9uIHNsb3dlciB0 aGFuIHRoZSBkZXRlY3Rpb24gb2YgcHJlLWNvbmdlc3Rpb24/DQoNCkFubmEgQ2hhcm55OiBZZXMN Cg0KSm9zZXBmIEJhYmlhcno6IFRoZSBkZXRlY3Rpb24gaXMgZmFzdCBidXQgdGhlcmUgaXMgdGhl IHF1ZXN0aW9uIG9uIGhvdyBsb25nIGl0IG5lZWRzIHRvIHRha2UgYmVmb3JlIHRha2luZyBzb21l IGFjdGlvbnMuDQogDQpTY290dCBCcmFkbmVyOiBCZWluZyB2ZXJ5IGFnZ3Jlc3NpdmUgbGVhZHMg dG8gaW5zdGFiaWxpdHkuDQoNCkxhcnMgRWdnZXJ0OiBJcyB0aGVyZSBhbnkgYWxnb3JpdGhtIGJl dHdlZW4gdGhlIHByZWVtcHRpb24gdnMuIGdvaW5nIGRvd24gd2l0aCBhZG1pdHRpbmcgbmV3IGZs b3dzPw0KDQpBbm5hIENoYXJueTogVGhlcmUgaXMgYW4gYWxnb3JpdGhtIGZvciBlYWNoIGluIHRo ZSBjbC1hcmNoaXRlY3R1cmUgYW5kIGNsLXBoYiBkcmFmdHMuDQoNClNwZWFrZXIgYXQgdGhlIG1p a2UgKG5hbWUgbm90IHJlY29yZGVkKTogUHJlZW1wdGluZyBpcyBhIHJhdGhlciBhIGRpZmZpY3Vs dCB0aGluZyB0byBkby4gSGF2ZSB5b3UgdGhvdWdodCBhYm91dCBub3RpZnlpbmcgdXNlcnMgdG8g ZmFsbCBiYWNrIHRvIGEgZGlmZmVyZW50IGNvZGVjIHJhdGhlciB0aGFuIHByZWVtcHRpbmcgdGhl IGNvbnZlcnNhdGlvbi4NClRoaXMsIGhvd2V2ZXIsIHJlcXVpcmVzIGZlZWRiYWNrIHRvIGEgdXNl ci4NCg0KSm9zZWYgQmFiaWFyejogWWVzLg0KDQpBbm5hIENoYXJueTogVGhlcmUgYXJlIHR3byBk aWZmZXJlbnQgcXVlc3Rpb25zOiAoYSkgSGF2ZSB3ZSBsb29rZWQgYXQgaXQ/IChiKSBTaG91bGQg dGhlIHdvcmtpbmcgZ3JvdXAgZG8gaXQ/ICBSZWdhcmRpbmcgKGEpOiB5ZXMuIFJlZ2FyZGluZyAo Yik6IE5vLCBub3QgdW5kZXIgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIuDQoNClNjb3R0IEJyYWRuZXI6 IFRoYXQncyBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZGlzY3VzcyBvbiB0aGUgbWFpbGluZyBsaXN0 Lg0KDQpEYW5hIEJsYWlyOiBJcyB0aGVyZSBhIGZvcm1hbCBkZWZpbml0aW9uIG9mIHN0YWJpbGl0 eT8NCg0KU2NvdHQ6IERvIHlvdSBoYXZlIHNvbWUgc3VnZ2VzdGlvbnM/DQoNCkFubmE6IEkgZG9u J3Qga25vdyBob3cgdG8gYW5zd2VyIHRoaXMgcXVlc3Rpb24gaW4gdGhpcyBjb250ZXh0LiBTdGFi aWxpdHkgaXMgdHlwaWNhbGx5IGFwcGxpZWQgdG8gY29uZ2VzdGlvbiBjb250cm9sIHN5c3RlbXMg d2hlcmUgdGhlIGZ1bmN0aW9uIG9mIGludGVyZXN0IGNhbiBhZGp1c3QgdXAgb3IgZG93bi4gIElu IHRoZSBmcmFtZXdvcmsgd2UgcHJvcG9zZSwgQWRtaXNzaW9uIENvbnRyb2wgY2FuIG9ubHkgc3Rv cCBhZG1pc3Npb24sIGFuZCBwcmUtZW1wdGlvbiBjYW4gb25seSBicmluZyB0aGUgYW1vdW50IG9m IHRyYWZmaWMgZG93bi4gIFNvIHRoZXJlIGFyZSB0d28gcXVlc3Rpb25zIG9mIGludGVyZXN0OiAo YSkgQWRtaXNzaW9uOiBEb2VzIGl0IHN0b3AgYWRtaXR0aW5nIHdoZW4gZXhwZWN0ZWQgb3IgZG9l cyBpdCBvdmVyLSBvciB1bmRlci1hZG1pdD8gIChiKSBQcmVlbXB0aW9uOiBEb2VzIGl0IHByZS1l bXB0IHRoZSByaWdodCBhbW91bnQgb3IgZG9lcyBpdCBvdmVyLSBvciB1bmRlci1zaG9vdCk/DQoN CkppbSBCb3VuZDogVGhlcmUgaXMgYSBsb3Qgb2YgbW9tZW50dW0gZm9yIGFkbWlzc2lvbiBjb250 cm9sLiBUaGVyZSBpcyBhIGxvdCBvZiB0aGluZ3MgaW1wb3J0YW50IGluIHRoZSBwcm9wb3NlZCBz Y29wZS4NCg0KU2NvdHQgQnJhZG5lcjogVGhlcmUgYXJlIHR3byB0aGluZ3M6IChhKSBQcm9wb3Nl IHdvcmsgaW4gdGhlIElFVEYsIChiKSBLZWVwIGluIG1pbmQgd2hlbiBkZXNpZ25pbmcgdGhlIGNv cmUgcHJvdG9jb2wuIFlvdSBuZWVkIHRvIGtub3cgd2hhdCB0aGUgcmVxdWlyZW1lbnRzIGFyZSB0 byBkZXNpZ24gdGhlIHByb3RvY29sLg0KIA0KDQo2LiBQcm9wb3NlZCBDaGFydGVyICgyMCBtaW4p DQoNCkFubmEgQ2hhcm55IHByZXNlbnRzIGh0dHA6Ly9zdGFuZGFyZHMubm9ydGVsLmNvbS9wY24v UENOX2RyYWZ0X2NoYXJ0ZXJfdjAxLnR4dA0KDQoqIFN0YW5kYXJkcyB0cmFjayBkb2NzIHRvIGFk ZHJlc3MgMyBhcmVhczoNCg0KICAgMS4gV2hlbiBzaG91bGQgYW4gaW50ZXJpb3Igcm91dGVyIG1h cmsgYSBwYWNrZXQgKGkuZS4gYXQgd2hhdCB0cmFmZmljIGxldmVsKSBpbiBvcmRlciB0byBnaXZl IGVhcmx5IHdhcm5pbmcgb2YgaXRzIG93biBjb25nZXN0aW9uPw0KDQogICAyLiBIb3cgc2hvdWxk IHN1Y2ggYSBtYXJrIGJlIGVuY29kZWQgaW4gYSBwYWNrZXQgKGluIHRoZSBFQ04gYW5kL29yIERT Q1AgZmllbGRzKT8NCg0KICAgMy4gSG93IHNob3VsZCB0aGVzZSBtYXJraW5ncyAoYXQgcGFja2V0 IGdyYW51bGFyaXR5KSBiZSBjb252ZXJ0ZWQgaW50byBhZG1pc3Npb24gY29udHJvbCBhbmQgZmxv dyBwcmUtZW1wdGlvbiBkZWNpc2lvbnMgKGF0IGZsb3cgZ3JhbnVsYXJpdHkpPw0KIA0KDQpKYWNv YiBTdGVpbjogV2hlbiBzaG91bGQgYSByb3V0ZXIgbWFyayBhIHBhY2tldCBzb3VuZHMgbGlrZSBp bXBsZW1lbnRhdGlvbi4NCg0KU2NvdHQgQnJhZG5lci9CcnVjZSBEYXZpZSAoYm90aCBzYWlkIHNh bWUgdGhpbmcpOiBTaG91bGRuJ3QgZGVzY3JpYmUgaGFyZHdhcmUsIGJ1dCBzaG91bGQgZGVzY3Jp YmUgYmVoYXZpb3IgZm9yIGludGVyb3BlcmFiaWxpdHkuDQoNCkFubmEgQ2hhcm55IGNvbnRpbnVl cyBwcmVzZW50YXRpb246DQoNCiANCg0KKiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50czoNCg0KICAg MS4gYSBQcm9ibGVtIFN0YXRlbWVudA0KIA0KSmFtZXMgUG9sazogRG9uJ3Qgc2VlIHJlcXVpcmVt ZW50cyBkb2MuIFByb2JsZW0gc3RhdGVtZW50IGlzbid0IHRoZSBzYW1lIA0KDQpTY290dCBCcmFk bmVyOiBJbiBnZW5lcmFsIGJlbGlldmUgcmVxdWlyZW1lbnRzIGRvYyBpcyBhIGdvb2QgaWRlYS4g QWxzbyB3b3JyaWVkIGFib3V0IGdldHRpbmcgYm9nZ2VkIGRvd24uDQoNCkFubmEgQ2hhcm55IGNv bnRpbnVlcw0KDQogICAyLiBhdCBsZWFzdCB0d28gZGVwbG95bWVudCBtb2RlbHMsIHBvc3NpYmx5 IGZyb206DQoNCiAgICAtIGxpa2UgSW5zZXJ0IG92ZXIgRGlmZlNlcnYgKFJGQzI5OTgpIGJ1dCB3 aXRoIFBDTi1lbmFibGVkIERpZmZTZXJ2IHJlZ2lvbiBhbmQgZWRnZSBub2RlcyBkZWNpZGUgYWJv dXQgYWRtaXNzaW9uIGFuZCBmbG93IHByZS1lbXB0aW9uDQoNCiAgICAtIFNJUCBDb250cm9sbGVk IEFkbWlzc2lvbiBhbmQgUHJlZW1wdGlvbjogdXNpbmcgdHJ1c3RlZCBTSVAgZW5kcG9pbnRzIChn YXRld2F5IG9yIGhvc3QpIHBlcmZvcm1pbmcgYWRtaXNzaW9uIGFuZCBmbG93IHByZS1lbXB0aW9u IGFuZCBQQ04tY2FwYWJsZSByb3V0ZXJzIHdpdGhpbiB0aGUgRGlmZlNlcnYgcmVnaW9uDQoNCg0K SmFtZXMgUG9sazogU291bmRzIGxpa2UgYSBTSVAgZG9jIGZvciBTSVBQSU5HIA0KDQpTY290dCBC cmFkbmVyOiBUaGlzIHJlcHJlc2VudHMgcmVxdWlyZW1lbnRzIHRvIFNJUFBJTkcNCg0KDQpTdHVh cnQgR29sZG1hbjogSXMgaXQgcmVhc29uYWJsZSB0byBhZGQgYSBib2lsZXJwbGF0ZSB0byB0aGUg Y2hhcnRlciB0byBzYXkgdGhhdCB3b3JrIHdpbGwgYmUgZG9uZSB3aXRoIG90aGVyIHdvcmtpbmcg Z3JvdXAuDQoNCkFubmE6IFNvdW5kcyBnb29kIHRvIG1lLg0KDQpTY290dDogQWxzbyB1c2VmdWwu DQogDQpBbm5hIENoYXJueSBjb250aW51ZXMgcHJlc2VudGF0aW9uOg0KIA0KICAgIC0gUHNldWRv d2lyZTogUENOIG1heSBiZSB1c2VkIGFzIGEgY29uZ2VzdGlvbiBhdm9pZGFuY2UgbWVjaGFuaXNt IGZvciBlbmQtdXNlciBkZXBsb3llZCBwc2V1ZG93aXJlcyAoY29sbGFib3JhdGUgd2l0aCB0aGUg UFdFMyBXRykNCg0KDQpMYXJzIEVnZ2VydDogTm90IHNvbHZpbmcgdGhlIHdob2xlIHBzZXVkby13 aXJlIHByb2JsZW0sIHNvIHdvbid0IGJlIHVzZWZ1bC4NCg0KWWFraG92IFN0ZWluOiBOb3doZXJl IGRvZXMgaXQgc2F5IFBXRTMgc2hvdWxkIGJlIG92ZXIgcHJvdmlzaW9uZWQgcGF0aHMgDQoNCkxh cnMgRWdnZXJ0OiBUaGVyZSBpcyBhIHN0YXRlbWVudCB0aGF0IGRvZXMgc2F5IHRoaXMuDQoNCkRh dmUgT3JhbjogSWYgaXQgcmVxdWlyZXMgU0lQIHRvIGNoYW5nZSwgd2UgaGF2ZSBwcm9ibGVtcywg YnV0IEkgZG91YnQgaXQgZG9lcy4gSXQgaGFzIGEgZGVwZW5kZW5jeSBvbiBTRFAsIHdoaWNoIGhh cyB0aGUgUW9TIHByZS1jb25kaXRpb25zLg0KDQpBbm5hIENoYXJueTogV2hhdCB3b3VsZCB5b3Ug c3VnZ2VzdD8NCg0KRGF2ZSBPcmFuOiBDaGFuZ2UgdGhlIHdvcmRpbmcgdG8gQXBwbGljYXRpb24t Y29udHJvbGxlZCAocmF0aGVyIHRoYW4gU0lQLWNvbnRyb2xsZWQpIGFkbWlzc2lvbiAmIHByZS1l bXB0aW9uDQoNClN0dWFydCBHb2xkbWFuOiBBcyBTSVBQSU5HIHNheXMgdGhleSB0YWtlIGFsbCBj aGFuZ2VzIHRvIFNJUCwgc2hvdWxkbid0IHRoaXMgdy1nIHNheSBpdCB0YWtlcyBhbGwgUENOLXJl bGF0ZWQgYXNwZWN0cz8NCg0KU2NvdHQgQnJhZG5lcjogR29vZCBwb2ludA0KDQpCcnVjZSBEYXZp ZTogUmVzZXJ2YXRpb24gb24gdXNpbmcgUENOIGZvciBwc2V1ZG8td2lyZSBpcyB0aGF0IGNvbmNl cm4gd2l0aCBQV0UzIGlzIGltbWVkaWF0ZSBkZXBsb3ltZW50IG9mIEludGVybmV0IGFzLWlzLiBU aGVyZSBpcyBwcmVjaW91cyBsaXR0bGUgRUNOLCBsZXQgYWxvbmUgUENOIGRlcGxveW1lbnQgKGdp dmVuIGl0J3Mgbm90IHN0YW5kYXJkaXplZCB5ZXQpIGluIHRoZSBjdXJyZW50IEludGVybmV0Lg0K DQpBbm5hIENoYXJueTogU2hvdWxkIHBzZXVkby13aXJlcyBzdGF5IGluIHRoZSBjaGFydGVyPw0K DQpCcnVjZSBEYXZpZTogTm8sIHRvbyBmb3J3YXJkIGxvb2tpbmcgZm9yIGEgcGhhc2UgMSBjaGFy dGVyDQoNCkFubmEgQ2hhcm55IGNvbnRpbnVlcyBwcmVzZW50YXRpb246DQogDQogICAzLiBhbmFs eXNpcyBvZiB0aGUgc2lnbmFsaW5nIGV4dGVuc2lvbnMgcmVxdWlyZWQgdG8gc3VwcG9ydCBQQ04N Cg0KICAgICAtIGFjdHVhbCBleHRlbnNpb25zIGluIG90aGVyIHctZ3MgKFJTVlAsIE5TSVMsIFNJ UCkgbm90IFBDTiANCg0KICAgNC4gYXQgbGVhc3Qgb25lIGV4YW1wbGUgc29sdXRpb24gaW1wbGVt ZW50aW5nIHRoZSBmcmFtZXdvcmsgYW5kIGl0cyBwZXJmb3JtYW5jZSBldmFsdWF0aW9uIChlLmcu IHNpbXVsYXRpb24pDQoNCiAgIDUuIHRyYWRlb2ZmcyBiZXR3ZWVuIGRpZmZlcmVudCBlbmNvZGlu ZyBwb3NzaWJpbGl0aWVzIChlLmcuIEVDTiBhbmQgRENTUCBtYXJraW5nKQ0KDQoNCiogSW5pdGlh bCByZXN0cmljdGlvbiBvZiBzY29wZSAoYXNzdW1wdGlvbnMpOg0KDQogICAxLiBUcnVzdCBhc3N1 bXB0aW9uOiBQQ04gcmVnaW9uIGlzIGEgY29udHJvbGxlZCBlbnZpcm9ubWVudA0KDQpEYXZpZCBC bGFjazogVHJ1c3QgYXNzdW1wdGlvbjogbmVlZCB0byBhZGQgJ2tlZXBpbmcgaW4gbWluZCcgaW50 ZXJjb25uZWN0aW9uLiBJIHdvbid0IGxldCB5b3UgZm9yZ2V0IHRoYXQuDQoNCiAgIDIuIGFnZ3Jl Z2F0aW9uOiBtYW55IGZsb3dzIG9uIGFueSBsaW5rDQoNCiAgIDMuIGluZWxhc3RpYyB0cmFmZmlj OiBRb1MgYXNzdXJhbmNlIGZvciByLXQgYXBwcyBnZW5lcmF0aW5nIGluZWxhc3RpYyB0cmFmZmlj IC0gdm9pY2UgJiB2aWRlbyBsb3cgZGVsYXksIGppdHRlciBhbmQgcGFja2V0IGxvc3MsIGkuZS4g Q29udHJvbGxlZCBMb2FkIFN2YyBbUkZDMjIxMV0uDQoNCiAgIDQuIFNwZWNpZmljIGhhbmRsaW5n IG9mIGVtZXJnZW5jeSBhbmQgb3RoZXIgcHJlY2VkZW5jZSAoOTExLCBHRVRTLCBXUFMsIE1MUFAg ZXRjLikgY2FsbHMgb3V0IG9mIHNjb3BlLA0KDQogICAtICpidXQqIFBDTiBtdXN0IGVuc3VyZSB1 c2luZyBQQ04gdGVjaG5vbG9neSBkb2Vzbid0IHByZWNsdWRlIGVkZ2Ugbm9kZXMgZnJvbSB0YWtp bmcgdGhlIGFwcHJvcHJpYXRlIGVtZXJnZW5jeSBhY3Rpb25zIHJlcXVpcmVkIGJ5IHRoZXNlIHN0 YW5kYXJkcy9pbml0aWF0aXZlcw0KDQogICAtIFBDTiBJbnRlcm5hbCBOb2RlcyBtYXkgbm90IGJl IE1MUFAtYXdhcmUgYnV0IHRoZXkgYXJlIERTQ1AgYXdhcmUNCg0KQm9iIEJyaXNjb2U6IEFzc3Vt cHRpb24gMiAoYWdncmVnYXRpb24pIGRvZXNuJ3Qgc2VlbSB0byBpbmNsdWRlIFNJUCBlbmRwb2lu dCANCg0KTWF0dCBNYXRoaXM6IENoYW5nZSBhc3N1bXB0aW9uIDIgdG8gIlRoZXJlIGFyZSBzdWZm aWNpZW50IGZsb3dzIHdoZXJlIHJlbGV2YW50IGJvdHRsZW5lY2tzIg0KDQpBbm5hIENoYXJueTog V2lsbCBkbw0KDQpGcmFuY29pcyBsZSBGYXVjaGV1cjogQXNzdW1wdGlvbiAyOiBBZGQgYXBwbGlj YWJpbGl0eSBzdGF0ZW1lbnQgdG8gdGhlIGNoYXJ0ZXIuDQoNCkFubmEgQ2hhcm55IGNvbnRpbnVl cyBwcmVzZW50YXRpb246DQoNCiogUmUtY2hhcnRlcmluZyBsYXRlcg0KDQoNCk1heSByZWxheCBz b21lIG9mIHRoZSBhc3N1bXB0aW9ucyB3aGVuIHJlLWNoYXJ0ZXJpbmcgKGUuZy4gc2luZ2xlIHRy dXN0IGRvbWFpbiBhc3N1bXB0aW9uKQ0KIA0KT3V0IG9mIHNjb3BlOiBnZW5lcmFsIGludmVzdGln YXRpb24gb2YgQUMgbWVjaGFuaXNtcyAtIHdlIGJ1aWxkIG9uIGNvbnNpZGVyYWJsZSBhY2FkZW1p YyBhbmQgcHJpb3IgSUVURiB3b3JrIG9uIG1lYXN1cmVtZW50LWJhc2VkIGFkbWlzc2lvbiBjb250 cm9sIChNQkFDKQ0KDQoqIE1pbGVzdG9uZXMNCg0KTm92IDIwMDYgaW5pdGlhbCBQcm9ibGVtIHN0 YXRlbWVudA0KDQpOb3YgMjAwNiBpbml0aWFsIGRlcGxveW1lbnQgbW9kZWxzDQoNCk1hcmNoIDIw MDcgaW5pdGlhbCByb3V0ZXIgbWFya2luZyBiZWhhdmlvciAoaW5jbHVkaW5nIGVuY29kaW5nKSBN YXJjaCAyMDA3IGluaXRpYWwgZmxvdyBhZG1pc3Npb24gY29udHJvbCBhbmQgcHJlLWVtcHRpb24g bWVjaGFuaXNtIChpbmNsdWRpbmcgZWRnZSBub2RlIGJlaGF2aW9yKSBNYXJjaC9KdWx5IDIwMDcg c3VibWl0IFByb2JsZW0gc3RhdGVtZW50IE1hcmNoL0p1bHkgMjAwNyBzdWJtaXQgZGVwbG95bWVu dCBtb2RlbHMgTm92IDIwMDcgc3VibWl0IHJvdXRlciBtYXJraW5nIGJlaGF2aW9yIE5vdiAyMDA3 L01hciAyMDA4IHN1Ym1pdCBmbG93IGFkbWlzc2lvbiBjb250cm9sIGFuZCBwcmUtZW1wdGlvbiBt ZWNoYW5pc20gTm92IDIwMDcgaW5pdGlhbCBzaWduYWxpbmcgYW5hbHlzaXMgTWFyIDIwMDggcmUt Y2hhcnRlciBvciBjbG9zZQ0KDQpGcmFuY29pcyBsZSBGYXVjaGV1cjogSG93IHdvdWxkIGFwcGxp Y2FiaWxpdHkgc3RhdGVtZW50IGZpdCBpbnRvIG1pbGVzdG9uZXM/DQoNClNjb3R0IEJyYWRuZXI6 IFBlcnNvbmFsbHkgYSBzdGFuZC1hbG9uZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB3b3VsZCBi ZSBteSBwcmVmZXJlbmNlLg0KDQpEYXZpZCBCbGFjazogV291bGQgbmVlZCBhbiBhcHBsaWNhYmls aXR5IHN0YXRlbWVudCBzcGVjaWZpYyB0byB0aGUgZW5kcG9pbnQgbW9kZWwuIA0KDQpTY290dCBC cmFkbmVyOiBPciBub3Qgc2lnbmFsaW5nIHByb3RvY29sIHNwZWNpZmljIA0KDQpEYXZpZCBCbGFj azogTmVlZCB0byB1c2UgU0lQIGFzIGFuIGV4YW1wbGUgYXBwIHNpZ25hbGluZyBwcm90b2NvbCAN Cg0KRGF2ZSBPcmFuOiBNb3N0IGltcG9ydGFudCBhc3BlY3QgaXMgZW5kcG9pbnQtZW5kcG9pbnQg aW4gdGhhdCBkZXBsb3ltZW50IG1vZGVsLg0KDQpHZW9yZ2lvcyBLYXJhZ2lhbm5pczogU0lQIGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50LiBZZXMsIFNJUCBqdXN0IGFuIGV4YW1wbGUgYXBwbGljYXRp b24gc2lnbmFsaW5nIHByb3RvY29sLiBBbHNvIG5lZWQgZW5kLXRvLWNvbmNlbnRyYXRvciwgb3Ig Y29uY2VudHJhdG9yLXRvLWNvbmNlbnRyYXRvci4NCg0KNy4gRGlzY3Vzc2lvbiBvZiBQcm9wb3Nl ZCBDaGFydGVyICgyMCBtaW4pDQoNCiANCg0KTm8gZnVydGhlciBkaXNjdXNzaW9uDQoNCiANCg0K OC4gU3VtbWFyeSBhbmQgQ29uY2x1c2lvbnMgKDEwIG1pbikNCiANCg0KU2NvdHQgQnJhZG5lcjog SXMgdGhpcyByZWFkeSBmb3IgSUVURiB3LWc/DQoNCltBYm91dCAxNTAgcGVvcGxlIGluIHRoZSBy b29tLl0gT2Ygd2hpY2ggYWJvdXQgMTAwIHZvdGVkOg0KDQp+OTggZm9yOyAyIGFnYWluc3QNCg0K DQpTY290dCBCcmFkbmVyOiBOb3cgdGhlIHRhc2sgaXMgdG8gd29yayB3aXRoIHRoZSBBRHMgb24g YSBjaGFydGVyLCB0byBwb3N0IHRvIGxpc3QuIFRoaXMgQk9GIGRvZXMgbm90IHByZXN1cHBvc2Ug d2hvIHRoZSB3LWcgY2hhaXJzIGFyZSBpbiBhbnkgd2F5Lg0KDQpMYXJzIEVnZ2VydDogU2hvdyBv ZiBoYW5kcyBwbGVhc2UsIG9uIHdobyBpcyBpbnRlcmVzdGVkIChvdGhlciB0aGFuIHRoZSBhdXRo b3JzIG9mIHRoZSBkcmFmdHMpIGluIGhlbHBpbmcgaW4gdGhpcyB3LWc/IDcgaGFuZHMgdXAuDQoN ClF1ZXN0aW9uIGZyb20gdGhlIHJvb206IElzIHRoZXJlIGEgbWFpbGluZyBsaXN0Pw0KDQpBbm5h IENoYXJueTogIHBjbkBpZXRmLm9yZyA8bWFpbHRvOnBjbkBpZXRmLm9yZz4gDQoNCiANCg== ------_=_NextPart_001_01C70831.117ABEF7 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 ------_=_NextPart_001_01C70831.117ABEF7-- From pcn-bounces@ietf.org Fri Nov 17 11:06:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6EA-00066I-H3; Fri, 17 Nov 2006 11:06:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6E9-000654-K5 for pcn@ietf.org; Fri, 17 Nov 2006 11:06:05 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6Dz-0006jz-0q for pcn@ietf.org; Fri, 17 Nov 2006 11:06:05 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 43C4B1086 for ; Fri, 17 Nov 2006 17:05:52 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 17:05:52 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 17:05:51 +0100 Message-ID: <455DDDDF.40200@ericsson.com> Date: Fri, 17 Nov 2006 17:05:51 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 16:05:51.0972 (UTC) FILETIME=[412A6A40:01C70A62] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [PCN] Managability of 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 Hi, Have people considered how an operator actually is going to manage its deployment of a PCN enabled network domain? I think it will be an important factor for PCN if it is reasonably easy to manage and monitor. Thus I at least would like to see something in the charter about this. I think the output document would need to have sections discussing how this is done for the different components. Also the frame work would need to have this discussion to bind together the parts. 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 Nov 17 13:21:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8LX-0000GT-VU; Fri, 17 Nov 2006 13:21:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8LW-0000EV-1A for pcn@ietf.org; Fri, 17 Nov 2006 13:21:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8Kb-0005vQ-Vl for pcn@ietf.org; Fri, 17 Nov 2006 13:21:50 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2006 10:19:33 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAHIJWfU022965; Fri, 17 Nov 2006 13:19:32 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAHIJWYJ015418; Fri, 17 Nov 2006 13:19: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); Fri, 17 Nov 2006 13:19: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Nov 2006 13:19:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN modified charter and PCN BOF minutes uploaded Thread-Index: AccKdO0QGs95ERlSQomjzjh5Y9SSpQ== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 17 Nov 2006 18:19:32.0463 (UTC) FILETIME=[EDC037F0:01C70A74] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8587; t=1163787572; x=1164651572; 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:=20PCN=20modified=20charter=20and=20=20PCN=20BOF=20minutes=20upl oaded |Sender:=20 |To:=20; bh=ppSzmoPWxCmwawl7Cf9koaQ5S0EsQj8YZ+EBsTTHI/E=; b=SnwxsKnGxna3NbRYV+qI3tDn3kAU/HhR1TcjwfQTR09Hqwy0eu2lg7QOZULFwTHS1KauQXAm nz3cOGO7j6sE+i3BJZSPz4tS2dTyzV+r+9ePw/4L0CBcx3+h0dwO3RrV; 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: 17e5edc4dfd335965c1d21372171c01c Cc: Lars Eggert Subject: [PCN] PCN modified charter and PCN BOF minutes uploaded 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 Dear all,=20 The draft PCN BOF minutes and the modified Draft Charter have now been uploaded. The modified draft charter is also attached below.=20 The following is the summary of changes to the charter based on the comments made during the PCN BOF and a later comment from Magnus about manageability: 1) Replaced "SIP-controlled Admission and Preemption" by "Application-controlled Admission and Pre-emption" where applicable. 2) Removed PWE3-related deployment model as the initial deployment model of interest (this may be possibly revisited if a later re-chartering if necessary) 3) Added the need for an applicability statement and related milestones 4) Replaced the assumption of "many flows on the bottleneck link" by "sufficient flows on the bottleneck link" 5) Removed the explicit "real time traffic" assumption (leaving "inelastic" only) 6) Added "MLPP" before "precedence-aware" for clarification of Assumption=20 7) Added the following clarification related to the trust assumption: 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. 8) Added an explicit statement that the WG will work with other groups in the IETF and other standards bodies if appropriate 9) Added the need to work on/discuss manageability issues and related milestones 10) made the milestones more specific (e.g. submit as an Informational RFC rather that just "submit") Please send your questions and comments! Anna Charny and Scott Bradner PCN BOF Chairs ------------------------------------------------- PCN Draft Charter (Pre-Congestion Notification) =20 The PCN WG will tackle the problem of how to provide scalable, resilient admission control and strong QoS assurance while using packet marking techniques.=20 Current attempts to deliver QoS using only packet marking (e.g. DiffServ) are=20 limited in the level of QoS assurance that can be provided without substantial=20 over-provisioning. To improve the QoS assurance, PCN will add flow admission=20 control and flow pre-emption. In normal circumstances admission control should=20 protect the QoS of previously admitted flows. In times of heavy congestion=20 (for example caused by route changes due to link or router failure) pre-emption=20 of some flows should preserve the QoS of remaining flows. While the WG will=20 address both admission and pre-emption, it is assumed that these mechanisms can be used independently of each other, and the use of one does not mandate the use of the other. =20 The initial scope of the WG is the use of PCN within a single DiffServ region.=20 The overall approach will be based on a separation of functionality between the=20 interior routers and edge nodes of the DiffServ region. Interior routers mark=20 packet headers when their traffic is above a certain level, as an early warning=20 of incipient congestion ("pre-congestion"); this builds on concepts from RFC 3168 "The Addition of Explicit Congestion Notification to IP". Edge nodes=20 of the DiffServ Region monitor the markings and that information is used to=20 make flow admission control and pre-emption decisions. The decisions could be=20 made by the edge nodes or by a centralized system (which is informed of the=20 edge nodes measurements).=20 The WG will address the following specific problems and develop standards=20 track solutions to them: 1. When should an interior router mark a packet (i.e. at what traffic level)=20 in order to give early warning of its own congestion? 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? 3. How should these markings (at packet granularity) be converted into=20 admission control and flow pre-emption decisions (at flow granularity)? =20 To support this, the WG will work on the following Informational documents: 1. a Problem Statement, to describe the problems the group is tackling=20 and the assumptions made 2. at least two deployment models, initially to help focus the problem statement=20 and later to check that the solutions being developed satisfy the deployment=20 scenario. Possible deployment models may be:=20 (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN-enabled=20 and its edge nodes decide about admission and flow pre-emption (b) Application-controlled Admission and Pre-emption: routers within the DiffServ region are PCN-capable and trusted e.g. SIP endpoints (gateway or host) perform admission and flow pre-emption. =20 3. a generic analysis of the signaling extensions required to support PCN.=20 Note that extensions/enhancements to specific signaling protocols=20 (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. 4. at least one example solution implementing the framework and its performance=20 evaluation (e.g. simulation results), to provide evidence of the viability=20 of the proposed standard in the proposed deployment models 5. an analysis of the tradeoffs of different encoding possibilities (e.g. ECN=20 and DCSP marking) 6. an applicability statement (the decision on whether applicability statement=20 will be delivered as a standalone document or will be incorporated into other documents such as deployment models is TBD). 7. an analysis of the manageability issues of a PCN region =20 The initial scope of the WG will restrict the problem space in the following ways: 1. By assuming the PCN-enabled Internet Region is a controlled environment,=20 i.e. all the interior routers and edge nodes of the region run PCN and=20 trust each other 2. By assuming there are sufficient flows on any relevant bottleneck link in the=20 PCN-enabled region=20 3. By focusing on the QoS assurance required by applications generating=20 inelastic traffic like voice and video requiring low delay, jitter and=20 packet loss, i.e. as defined by the Controlled Load Service [RFC2211].=20 4. By keeping specific handling of emergency and other precedence (911, GETS,=20 WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring that the edge nodes are not precluded from taking appropriate actions that may be necessary for handling such calls and (b) assuming that PCN Internal Nodes may not be MLPP precedence-aware but are DSCP aware. Subsequent re-chartering may investigate solutions for when some of these=20 restrictions are not in place.=20 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 impact on e.g. the choice of encoding. =20 Topics out of scope for the WG include a general investigation of admission=20 control mechanisms.=20 The WG will draw on the substantial prior academic and IETF work on=20 measurement-based admission control. The WG will work with relevant IETF WGs and, where appropriate, with external groups. =20 Milestones: Nov 2006 initial problem statement Internet Draft Nov 2006 initial deployment models Internet Drafts March 2007 initial router marking behavior (including encoding) Internet Drafts March 2007 initial flow admission control and pre-emption mechanisms Internet Drafts (including edge node measurements) March 2007 initial applicability statement Internet Draft March/July 2007 submit Problem statement to IESG for approval as informational RFC July 2007 submit deployment models to IESG for approval as informational RFC July 2007 submit applicability statement to IESG for approval as informational RFC (may be part of the deployment models) July 2007 initial manageability issues document Internet Draft Nov 2007 submit router marking behavior to IESG for approval as standards track RFC Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism as standard track RFC Nov 2007 initial signaling analysis Internet Draft=20 Nov 2007 submit manageability issues document to IESG for approval as informational RFC Mar 2008 re-charter or close _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Nov 17 13:28:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8Rs-0002v1-Ah; Fri, 17 Nov 2006 13:28:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8Rq-0002un-Vs for pcn@ietf.org; Fri, 17 Nov 2006 13:28:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gl8Rm-0003bz-H6 for pcn@ietf.org; Fri, 17 Nov 2006 13:28:22 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2006 10:28:17 -0800 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 kAHISEYh004530; Fri, 17 Nov 2006 10:28:14 -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 kAHIS6Oh005453; Fri, 17 Nov 2006 10:28:13 -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); Fri, 17 Nov 2006 13:28:11 -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] Managability of PCN Date: Fri, 17 Nov 2006 13:28:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Managability of PCN Thread-Index: AccKYmXLby3wP0BiSVGvBE4oN3beEAAE3UYA From: "Anna Charny \(acharny\)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 17 Nov 2006 18:28:11.0494 (UTC) FILETIME=[231E1060:01C70A76] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1479; t=1163788094; x=1164652094; 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]=20Managability=20of=20PCN |Sender:=20; bh=Tcx2gd2mYkM86INOm7xE343krPeVBTrrgs/bNLdVBcI=; b=cFItUhqeEnetHvh6B6pR8GNwtVsTTuFyV6442ztJ6mKNByF7o7hgibyn0CYvZIdlMXVVOmpP 25hL64EIUWGEcF1kn2/HQfemh2jjJIaX5l2oP0A17XIuklyPiTACuCCd; 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: a7d6aff76b15f3f56fcb94490e1052e4 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 Hello Magnus, Thanks for the comments. Makes sense. Added manageability to the updated draft charter. =20 Anna and Scott PCN BOF Chairs -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, November 17, 2006 11:06 AM To: pcn@ietf.org Subject: [PCN] Managability of PCN Hi, Have people considered how an operator actually is going to manage its deployment of a PCN enabled network domain? I think it will be an important factor for PCN if it is reasonably easy to manage and monitor. Thus I at least would like to see something in the charter about this. I think the output document would need to have sections discussing how this is done for the different components. Also the frame work would need to have this discussion to bind together the parts. 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 Nov 17 14:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl99n-00080R-Sm; Fri, 17 Nov 2006 14:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl99m-00080L-SG for pcn@ietf.org; Fri, 17 Nov 2006 14:13:46 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl99b-0004mQ-Ef for pcn@ietf.org; Fri, 17 Nov 2006 14:13:46 -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 kAHJCNM29435; Fri, 17 Nov 2006 14:12:24 -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] Manageability of PCN Date: Fri, 17 Nov 2006 14:12:22 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D407B9E@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Manageability of PCN Thread-Index: AccKYmXLby3wP0BiSVGvBE4oN3beEAAE3UYAAAF9Y2A= From: "Jozef Babiarz" To: "Anna Charny \(acharny\)" , "Magnus Westerlund" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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'm thinking that the manageability part belongs in each of the deployment models. 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: Friday, November 17, 2006 1:28 PM To: Magnus Westerlund; pcn@ietf.org Subject: RE: [PCN] Managability of PCN Hello Magnus, Thanks for the comments. Makes sense. Added manageability to the updated draft charter. =20 Anna and Scott PCN BOF Chairs -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, November 17, 2006 11:06 AM To: pcn@ietf.org Subject: [PCN] Managability of PCN Hi, Have people considered how an operator actually is going to manage its deployment of a PCN enabled network domain? I think it will be an important factor for PCN if it is reasonably easy to manage and monitor. Thus I at least would like to see something in the charter about this. I think the output document would need to have sections discussing how this is done for the different components. Also the frame work would need to have this discussion to bind together the parts. 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Nov 17 22:44:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlH85-0003gt-TA; Fri, 17 Nov 2006 22:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlH85-0003go-5X for pcn@ietf.org; Fri, 17 Nov 2006 22:44:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlH83-0008Hu-QV for pcn@ietf.org; Fri, 17 Nov 2006 22:44:33 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2006 19:44:31 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kAI3iV2n000676; Fri, 17 Nov 2006 19:44:31 -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 kAI3iQOV002170; Fri, 17 Nov 2006 19:44:30 -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); Fri, 17 Nov 2006 22:44:26 -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] Manageability of PCN Date: Fri, 17 Nov 2006 22:44:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Manageability of PCN Thread-Index: AccKYmXLby3wP0BiSVGvBE4oN3beEAAE3UYAAAF9Y2AAEeqMMA== From: "Anna Charny \(acharny\)" To: "Jozef Babiarz" , "Magnus Westerlund" , X-OriginalArrivalTime: 18 Nov 2006 03:44:26.0039 (UTC) FILETIME=[D7E57C70:01C70AC3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2469; t=1163821471; x=1164685471; c=relaxed/relaxed; s=sjdkim8002; 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]=20Manageability=20of=20PCN |Sender:=20; bh=HzwdAATVLGwu3r8SaCcqYI5UtFmF3eWijJRIgfpj6Bs=; b=REpOc07q6a42jV1mADn0zaXX/QJ0Kl/z9FgMJ3inxiQaQf5ajnU9o5JR5EnZO2L4Q6aH4CKw a/6PtIrLNCMbnxN003qLVeyPOlqk20uWDfNCjMjdTZepSp7PVkll+DPQ; Authentication-Results: sj-dkim-8; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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,=20 >I'm thinking that the manageability part belongs in each of the=20 >deployment models. I do not think the current wording of the draft charter prevents doing so, if that is deemed better than putting it in a standalone document. =20 Anna =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Friday, November 17, 2006 2:12 PM To: Anna Charny (acharny); Magnus Westerlund; pcn@ietf.org Subject: RE: [PCN] Manageability of PCN I'm thinking that the manageability part belongs in each of the deployment models. 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] Sent: Friday, November 17, 2006 1:28 PM To: Magnus Westerlund; pcn@ietf.org Subject: RE: [PCN] Managability of PCN Hello Magnus, Thanks for the comments. Makes sense. Added manageability to the updated draft charter. =20 Anna and Scott PCN BOF Chairs -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Friday, November 17, 2006 11:06 AM To: pcn@ietf.org Subject: [PCN] Managability of PCN Hi, Have people considered how an operator actually is going to manage its deployment of a PCN enabled network domain? I think it will be an important factor for PCN if it is reasonably easy to manage and monitor. Thus I at least would like to see something in the charter about this. I think the output document would need to have sections discussing how this is done for the different components. Also the frame work would need to have this discussion to bind together the parts. 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Nov 19 12:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glqoc-0001qT-CR; Sun, 19 Nov 2006 12:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glqoa-0001qD-VD for pcn@ietf.org; Sun, 19 Nov 2006 12:50:48 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlqoZ-0002cx-Jx for pcn@ietf.org; Sun, 19 Nov 2006 12:50:48 -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 kAJHoVE3019409 for ; Sun, 19 Nov 2006 12:50:34 -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] Manageability of PCN Date: Sun, 19 Nov 2006 19:50:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Manageability of PCN Thread-Index: AccKYmXLby3wP0BiSVGvBE4oN3beEAAE3UYAAAF9Y2AAEeqMMABPsb8g From: "Romascanu, Dan \(Dan\)" To: "Anna Charny \(acharny\)" , "Jozef Babiarz" , "Magnus Westerlund" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 would agree that manageability needs not necessarily require a standalone document, but I would prefer to have it mentioned explicitly in the wording of the charter. It will prevent us forgetting about it when dealing with the deployment models.=20 Dan =20 =20 =20 > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 > Sent: Saturday, November 18, 2006 5:44 AM > To: Jozef Babiarz; Magnus Westerlund; pcn@ietf.org > Subject: RE: [PCN] Manageability of PCN >=20 > Hi Joe,=20 >=20 > >I'm thinking that the manageability part belongs in each of the=20 > >deployment models. >=20 > I do not think the current wording of the draft charter=20 > prevents doing so, if that is deemed better than putting it=20 > in a standalone document. =20 >=20 > Anna =20 >=20 > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: Friday, November 17, 2006 2:12 PM > To: Anna Charny (acharny); Magnus Westerlund; pcn@ietf.org > Subject: RE: [PCN] Manageability of PCN >=20 > I'm thinking that the manageability part belongs in each of=20 > the deployment models. >=20 > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com >=20 > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: Friday, November 17, 2006 1:28 PM > To: Magnus Westerlund; pcn@ietf.org > Subject: RE: [PCN] Managability of PCN >=20 > Hello Magnus, >=20 > Thanks for the comments. Makes sense. Added manageability to=20 > the updated > draft charter. =20 >=20 > Anna and Scott > PCN BOF Chairs >=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, November 17, 2006 11:06 AM > To: pcn@ietf.org > Subject: [PCN] Managability of PCN >=20 > Hi, >=20 > Have people considered how an operator actually is going to=20 > manage its deployment of a PCN enabled network domain? I=20 > think it will be an important factor for PCN if it is=20 > reasonably easy to manage and monitor. >=20 > Thus I at least would like to see something in the charter=20 > about this. I think the output document would need to have=20 > sections discussing how this is done for the different=20 > components. Also the frame work would need to have this=20 > discussion to bind together the parts. >=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 >=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 Fri Nov 24 11:43:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gne8t-0000dd-Ow; Fri, 24 Nov 2006 11:43:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gne8s-0000dL-6q for pcn@ietf.org; Fri, 24 Nov 2006 11:43:10 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gne8q-0005g0-I6 for pcn@ietf.org; Fri, 24 Nov 2006 11:43:10 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2006 08:43:08 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAOGh7AK030026 for ; Fri, 24 Nov 2006 08:43:07 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAOGggdS019987 for ; Fri, 24 Nov 2006 08:43:07 -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); Fri, 24 Nov 2006 11:43:06 -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: Fri, 24 Nov 2006 11:43:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN updated charter Thread-Index: AccP5510nerysDs7TaWjWLWLE+ZwLQ== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 24 Nov 2006 16:43:06.0623 (UTC) FILETIME=[9E0358F0:01C70FE7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7893; t=1164386588; x=1165250588; 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:=20PCN=20=20updated=20charter |Sender:=20; bh=N5ZHr73zKRYMLZmbSEEsE9IFw2KxkxAySitKc0VNDT8=; b=DCTgHvTMR/IIf540jUPGEGiaTVwHprXUiyqukKdXzMWt6t9kCt0K3XDHuHlXM3giO3xYhPcf oVRAF8msEX7cQEE2fAFTErP8gpiA6OsVhkLW+VD+2Pye1d1NC8aAnoFm; Authentication-Results: sj-dkim-7; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Subject: [PCN] PCN updated charter X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear all, =20 The proposed PCN charter has been updated based on the (very few) recent comments we received. The new version has been uploaded, and is also attached at the end of this email for convenience. The only difference from the previously posted version is a wording change below: 2. .... (b) Application-controlled Admission and Pre-emption: routers within the DiffServ region are PCN-capable and trusted e.g. SIP endpoints (gateway or host) perform admission and flow pre-emption =20 =20 TO: 2. ..... (b) Application-controlled Admission and Pre-emption: routers within the DiffServ region are PCN-capable and trusted application-controlled=20 (e.g., SIP) endpoints (gateway or host) based on the marking, perform=20 admission and flow pre-emption. If you had sent us any email with proposed changes that was inadvertently missed and not reflected, please let us know right away. =20 =20 Best Regards, Anna and Scott PCN BOF Co-Chairs ------------- PCN Draft Charter (Pre-Congestion Notification) =20 The PCN WG will tackle the problem of how to provide scalable, resilient admission control and strong QoS assurance while using packet marking techniques.=20 Current attempts to deliver QoS using only packet marking (e.g. DiffServ) are=20 limited in the level of QoS assurance that can be provided without substantial=20 over-provisioning. To improve the QoS assurance, PCN will add flow admission=20 control and flow pre-emption. In normal circumstances admission control should=20 protect the QoS of previously admitted flows. In times of heavy congestion=20 (for example caused by route changes due to link or router failure) pre-emption=20 of some flows should preserve the QoS of remaining flows. While the WG will=20 address both admission and pre-emption, it is assumed that these mechanisms can be used independently of each other, and the use of one does not mandate the use of the other. =20 The initial scope of the WG is the use of PCN within a single DiffServ region.=20 The overall approach will be based on a separation of functionality between the=20 interior routers and edge nodes of the DiffServ region. Interior routers mark=20 packet headers when their traffic is above a certain level, as an early warning=20 of incipient congestion ("pre-congestion"); this builds on concepts from RFC 3168 "The Addition of Explicit Congestion Notification to IP". Edge nodes=20 of the DiffServ Region monitor the markings and that information is used to=20 make flow admission control and pre-emption decisions. The decisions could be=20 made by the edge nodes or by a centralized system (which is informed of the=20 edge nodes measurements).=20 The WG will address the following specific problems and develop standards=20 track solutions to them: 1. When should an interior router mark a packet (i.e. at what traffic level)=20 in order to give early warning of its own congestion? 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? 3. How should these markings (at packet granularity) be converted into=20 admission control and flow pre-emption decisions (at flow granularity)? =20 To support this, the WG will work on the following Informational documents: 1. a Problem Statement, to describe the problems the group is tackling=20 and the assumptions made 2. at least two deployment models, initially to help focus the problem statement=20 and later to check that the solutions being developed satisfy the deployment=20 scenario. Possible deployment models may be:=20 (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN-enabled=20 and its edge nodes decide about admission and flow pre-emption (b) Application-controlled Admission and Pre-emption: routers within the DiffServ region are PCN-capable and trusted application-controlled=20 (e.g., SIP) endpoints (gateway or host) based on the marking, perform=20 admission and flow pre-emption. 3. a generic analysis of the signaling extensions required to support PCN.=20 Note that extensions/enhancements to specific signaling protocols=20 (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. 4. at least one example solution implementing the framework and its performance=20 evaluation (e.g. simulation results), to provide evidence of the viability=20 of the proposed standard in the proposed deployment models 5. an analysis of the tradeoffs of different encoding possibilities (e.g. ECN=20 and DCSP marking) 6. an applicability statement the decision on whether applicability statement=20 will be delivered as a standalone document or will be incorporated into other documents such as deployment models is TBD) 7. an analysis of the manageability issues of a PCN region =20 The initial scope of the WG will restrict the problem space in the following ways: 1. By assuming the PCN-enabled Internet Region is a controlled environment,=20 i.e. all the interior routers and edge nodes of the region run PCN and=20 trust each other 2. By assuming there are sufficient flows on any relevant bottleneck link in the=20 PCN-enabled region=20 3. By focusing on the QoS assurance required by applications generating=20 inelastic traffic like voice and video requiring low delay, jitter and=20 packet loss, i.e. as defined by the Controlled Load Service [RFC2211].=20 4. By keeping specific handling of emergency and other precedence (911, GETS,=20 WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring that the edge nodes are not precluded from taking appropriate actions that may be necessary for handling such calls and (b) assuming that PCN Internal Nodes may not be MLPP precedence-aware but are DSCP aware. Subsequent re-chartering may investigate solutions for when some of these=20 restrictions are not in place.=20 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 impact on e.g. the choice of encoding. =20 Topics out of scope for the WG include a general investigation of admission=20 control mechanisms.=20 The WG will draw on the substantial prior academic and IETF work on=20 measurement-based admission control. The WG will work with relevant IETF WGs and, where appropriate, with external groups. =20 Milestones: Nov 2006 initial problem statement Internet Draft Nov 2006 initial deployment models Internet Drafts March 2007 initial router marking behavior (including encoding) Internet Drafts March 2007 initial flow admission control and pre-emption mechanisms Internet Drafts (including edge node measurements) March 2007 initial applicability statement Internet Draft March/July 2007 submit Problem statement to IESG for approval as informational RFC July 2007 submit deployment models to IESG for approval as informational RFC July 2007 submit applicability statement to IESG for approval as informational RFC (may be part of the deployment models) July 2007 initial manageability issues document Internet Draft Nov 2007 submit router marking behavior to IESG for approval as standards track RFC Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism as standard track RFC Nov 2007 initial signaling analysis Internet Draft=20 Nov 2007 submit manageability issues document to IESG for approval as informational RFC Mar 2008 re-charter or close _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Nov 24 11:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneAK-00018h-U7; Fri, 24 Nov 2006 11:44:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneAJ-00018c-Fj for pcn@ietf.org; Fri, 24 Nov 2006 11:44:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GneAH-0005q9-QQ for pcn@ietf.org; Fri, 24 Nov 2006 11:44:39 -0500 Received: (qmail invoked by alias); 24 Nov 2006 16:44:36 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp037) with SMTP; 24 Nov 2006 17:44:36 +0100 X-Authenticated: #29516787 Message-ID: <45672173.8030207@gmx.net> Date: Fri, 24 Nov 2006 17:44:35 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] PCN updated charter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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, obviously the milestones are not realistic. Ciao Hannes Anna Charny (acharny) wrote: > Dear all, > > The proposed PCN charter has been updated based on the (very few) recent > comments we received. > The new version has been uploaded, and is also attached at the end of > this email for convenience. > > The only difference from the previously posted version is a wording > change below: > > 2. > .... > (b) Application-controlled Admission and Pre-emption: routers within > the DiffServ region are PCN-capable and trusted e.g. SIP > endpoints > (gateway or host) perform admission and flow pre-emption > > TO: > 2. > ..... > (b) Application-controlled Admission and Pre-emption: routers within > the DiffServ region are PCN-capable and trusted > application-controlled > (e.g., SIP) endpoints (gateway or host) based on the marking, > perform > admission and flow pre-emption. > > If you had sent us any email with proposed changes that was > inadvertently missed and not reflected, > please let us know right away. > > > Best Regards, > Anna and Scott > PCN BOF Co-Chairs > > ------------- > > PCN Draft Charter (Pre-Congestion Notification) > > The PCN WG will tackle the problem of how to provide scalable, resilient > > admission control and strong QoS assurance while using packet marking > techniques. > Current attempts to deliver QoS using only packet marking (e.g. > DiffServ) are > limited in the level of QoS assurance that can be provided without > substantial > over-provisioning. To improve the QoS assurance, PCN will add flow > admission > control and flow pre-emption. In normal circumstances admission control > should > protect the QoS of previously admitted flows. In times of heavy > congestion > (for example caused by route changes due to link or router failure) > pre-emption > of some flows should preserve the QoS of remaining flows. While the WG > will > address both admission and pre-emption, it is assumed that these > mechanisms can > be used independently of each other, and the use of one does not mandate > the > use of the other. > > The initial scope of the WG is the use of PCN within a single DiffServ > region. > The overall approach will be based on a separation of functionality > between the > interior routers and edge nodes of the DiffServ region. Interior routers > mark > packet headers when their traffic is above a certain level, as an early > warning > of incipient congestion ("pre-congestion"); this builds on concepts from > > RFC 3168 "The Addition of Explicit Congestion Notification to IP". Edge > nodes > of the DiffServ Region monitor the markings and that information is used > to > make flow admission control and pre-emption decisions. The decisions > could be > made by the edge nodes or by a centralized system (which is informed of > the > edge nodes measurements). > > The WG will address the following specific problems and develop > standards > track solutions to them: > 1. When should an interior router mark a packet (i.e. at what traffic > level) > in order to give early warning of its own congestion? > 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP > fields)? > 3. How should these markings (at packet granularity) be converted into > admission control and flow pre-emption decisions (at flow > granularity)? > > To support this, the WG will work on the following Informational > documents: > 1. a Problem Statement, to describe the problems the group is tackling > and the assumptions made > 2. at least two deployment models, initially to help focus the problem > statement > and later to check that the solutions being developed satisfy the > deployment > scenario. Possible deployment models may be: > (a) IntServ over DiffServ (RFC2998): the DiffServ region is > PCN-enabled > and its edge nodes decide about admission and flow pre-emption > (b) Application-controlled Admission and Pre-emption: routers within > the DiffServ region are PCN-capable and trusted > application-controlled > (e.g., SIP) endpoints (gateway or host) based on the marking, > perform > admission and flow pre-emption. > 3. a generic analysis of the signaling extensions required to support > PCN. > Note that extensions/enhancements to specific signaling protocols > (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. > 4. at least one example solution implementing the framework and its > performance > evaluation (e.g. simulation results), to provide evidence of the > viability > of the proposed standard in the proposed deployment models > 5. an analysis of the tradeoffs of different encoding possibilities > (e.g. ECN > and DCSP marking) > 6. an applicability statement the decision on whether applicability > statement > will be delivered as a standalone document or will be incorporated > into other > documents such as deployment models is TBD) > 7. an analysis of the manageability issues of a PCN region > > The initial scope of the WG will restrict the problem space in the > following ways: > 1. By assuming the PCN-enabled Internet Region is a controlled > environment, > i.e. all the interior routers and edge nodes of the region run PCN > and > trust each other > 2. By assuming there are sufficient flows on any relevant bottleneck > link in the > PCN-enabled region > 3. By focusing on the QoS assurance required by applications generating > inelastic traffic like voice and video requiring low delay, jitter > and > packet loss, i.e. as defined by the Controlled Load Service > [RFC2211]. > 4. By keeping specific handling of emergency and other precedence (911, > GETS, > WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring that > the edge > nodes are not precluded from taking appropriate actions that may be > necessary > for handling such calls and (b) assuming that PCN Internal Nodes may > not be > MLPP precedence-aware but are DSCP aware. > > Subsequent re-chartering may investigate solutions for when some of > these > restrictions are not in place. > 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 impact on e.g. the choice of encoding. > > > Topics out of scope for the WG include a general investigation of > admission > control mechanisms. > > The WG will draw on the substantial prior academic and IETF work on > measurement-based admission control. > > The WG will work with relevant IETF WGs and, where appropriate, with > external groups. > > Milestones: > > Nov 2006 initial problem statement Internet Draft > Nov 2006 initial deployment models Internet Drafts > March 2007 initial router marking behavior (including encoding) > Internet Drafts > March 2007 initial flow admission control and pre-emption > mechanisms Internet Drafts > (including edge node measurements) > March 2007 initial applicability statement Internet Draft > March/July 2007 submit Problem statement to IESG for approval as > informational RFC > July 2007 submit deployment models to IESG for approval as > informational RFC > July 2007 submit applicability statement to IESG for approval as > informational RFC > (may be part of the deployment models) > July 2007 initial manageability issues document Internet Draft > Nov 2007 submit router marking behavior to IESG for approval as > standards track RFC > Nov 2007/Mar 2008 submit flow admission control and pre-emption > mechanism as standard track RFC > Nov 2007 initial signaling analysis Internet Draft > Nov 2007 submit manageability issues document to IESG for > approval as informational RFC > Mar 2008 re-charter or close > > _______________________________________________ > PCN mailing 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 Nov 24 11:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneE6-0001cq-QC; Fri, 24 Nov 2006 11:48:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneE5-0001ck-Dm for pcn@ietf.org; Fri, 24 Nov 2006 11:48:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GneE3-0006li-PY for pcn@ietf.org; Fri, 24 Nov 2006 11:48:33 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2006 08:48:31 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAOGmUqx031624; Fri, 24 Nov 2006 08:48:30 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAOGmUdE021605; Fri, 24 Nov 2006 08:48:30 -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); Fri, 24 Nov 2006 11:48:30 -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 updated charter Date: Fri, 24 Nov 2006 11:48:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccP59oJjv/AarYiROC+5/GRCEs0QwAAEkiw From: "Anna Charny \(acharny\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 24 Nov 2006 16:48:30.0261 (UTC) FILETIME=[5EEA9650:01C70FE8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8995; t=1164386910; x=1165250910; 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]=20PCN=20=20updated=20charter |Sender:=20; bh=WHFF9KRimoVB2fIVDFlbI7Ti5KlPzhze4rKODl0FF70=; b=lgIcqKW6+skkGPyGEArW0mxnG7iSx5+SpVS+3tW8nRyY4vub1L8J6SSXIKkqIzXc5bwQDWV7 Bh3AysKGZULX9OXV15yZzgK0rbIJz91NpekK8Uq4O2SFj6Z4NvpW9SVM; Authentication-Results: sj-dkim-7; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f 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 Hannes, Thanks for your feedback. Do you have specific suggestions on how to change the milestones? What specifically makes you think the current ones are not realistic? Thanks, Anna =20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, November 24, 2006 11:45 AM To: Anna Charny (acharny) Cc: pcn@ietf.org Subject: Re: [PCN] PCN updated charter Hi Anna, obviously the milestones are not realistic. Ciao Hannes Anna Charny (acharny) wrote: > Dear all, > =20 > The proposed PCN charter has been updated based on the (very few)=20 > recent comments we received. > The new version has been uploaded, and is also attached at the end of=20 > this email for convenience. >=20 > The only difference from the previously posted version is a wording=20 > change below: >=20 > 2. > .... > (b) Application-controlled Admission and Pre-emption: routers within > the DiffServ region are PCN-capable and trusted e.g. SIP=20 > endpoints > (gateway or host) perform admission and flow pre-emption > =20 > TO: > 2. > ..... > (b) Application-controlled Admission and Pre-emption: routers within > the DiffServ region are PCN-capable and trusted=20 > application-controlled > (e.g., SIP) endpoints (gateway or host) based on the marking,=20 > perform > admission and flow pre-emption. >=20 > If you had sent us any email with proposed changes that was=20 > inadvertently missed and not reflected, please let us know right away. > =20 > =20 > Best Regards, > Anna and Scott > PCN BOF Co-Chairs >=20 > ------------- >=20 > PCN Draft Charter (Pre-Congestion Notification) > =20 > The PCN WG will tackle the problem of how to provide scalable,=20 > resilient >=20 > admission control and strong QoS assurance while using packet marking=20 > techniques. > Current attempts to deliver QoS using only packet marking (e.g. > DiffServ) are > limited in the level of QoS assurance that can be provided without=20 > substantial over-provisioning. To improve the QoS assurance, PCN will=20 > add flow admission control and flow pre-emption. In normal=20 > circumstances admission control should protect the QoS of previously=20 > admitted flows. In times of heavy congestion (for example caused by=20 > route changes due to link or router failure) pre-emption of some flows > should preserve the QoS of remaining flows. While the WG will address=20 > both admission and pre-emption, it is assumed that these mechanisms=20 > can be used independently of each other, and the use of one does not=20 > mandate the use of the other. >=20 > The initial scope of the WG is the use of PCN within a single DiffServ > region. > The overall approach will be based on a separation of functionality=20 > between the interior routers and edge nodes of the DiffServ region.=20 > Interior routers mark packet headers when their traffic is above a=20 > certain level, as an early warning of incipient congestion=20 > ("pre-congestion"); this builds on concepts from >=20 > RFC 3168 "The Addition of Explicit Congestion Notification to IP".=20 > Edge nodes of the DiffServ Region monitor the markings and that=20 > information is used to make flow admission control and pre-emption=20 > decisions. The decisions could be made by the edge nodes or by a=20 > centralized system (which is informed of the edge nodes measurements). >=20 > The WG will address the following specific problems and develop=20 > standards track solutions to them: > 1. When should an interior router mark a packet (i.e. at what traffic > level)=20 > in order to give early warning of its own congestion? > 2. How should such a mark be encoded in a packet (in the ECN and/or=20 > DSCP fields)? > 3. How should these markings (at packet granularity) be converted into > admission control and flow pre-emption decisions (at flow=20 > granularity)? > =20 > To support this, the WG will work on the following Informational > documents: > 1. a Problem Statement, to describe the problems the group is tackling > and the assumptions made > 2. at least two deployment models, initially to help focus the problem > statement > and later to check that the solutions being developed satisfy the=20 > deployment > scenario. Possible deployment models may be:=20 > (a) IntServ over DiffServ (RFC2998): the DiffServ region is=20 > PCN-enabled > and its edge nodes decide about admission and flow pre-emption > (b) Application-controlled Admission and Pre-emption: routers within > the DiffServ region are PCN-capable and trusted=20 > application-controlled > (e.g., SIP) endpoints (gateway or host) based on the marking,=20 > perform > admission and flow pre-emption. > 3. a generic analysis of the signaling extensions required to support=20 > PCN. > Note that extensions/enhancements to specific signaling protocols=20 > (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. > 4. at least one example solution implementing the framework and its=20 > performance > evaluation (e.g. simulation results), to provide evidence of the=20 > viability > of the proposed standard in the proposed deployment models 5. an=20 > analysis of the tradeoffs of different encoding possibilities (e.g.=20 > ECN > and DCSP marking) > 6. an applicability statement the decision on whether applicability=20 > statement > will be delivered as a standalone document or will be incorporated=20 > into other > documents such as deployment models is TBD) 7. an analysis of the=20 > manageability issues of a PCN region > =20 > The initial scope of the WG will restrict the problem space in the=20 > following ways: > 1. By assuming the PCN-enabled Internet Region is a controlled=20 > environment, > i.e. all the interior routers and edge nodes of the region run PCN=20 > and > trust each other > 2. By assuming there are sufficient flows on any relevant bottleneck=20 > link in the > PCN-enabled region > 3. By focusing on the QoS assurance required by applications generating=20 > inelastic traffic like voice and video requiring low delay, jitter=20 > and > packet loss, i.e. as defined by the Controlled Load Service=20 > [RFC2211]. > 4. By keeping specific handling of emergency and other precedence=20 > (911, GETS, > WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring=20 > that the edge > nodes are not precluded from taking appropriate actions that may be > necessary > for handling such calls and (b) assuming that PCN Internal Nodes=20 > may not be > MLPP precedence-aware but are DSCP aware. >=20 > Subsequent re-chartering may investigate solutions for when some of=20 > these restrictions are not in place. > In particular, after re-chartering it's expected that the WG will=20 > cover the case with multiple, non-trusting domains. However, even=20 > during the initial standardization phase, this case needs to be kept=20 > in mind, as the anti-cheating solution will impact on e.g. the choice of encoding. > =20 >=20 > Topics out of scope for the WG include a general investigation of=20 > admission control mechanisms. >=20 > The WG will draw on the substantial prior academic and IETF work on=20 > measurement-based admission control. >=20 > The WG will work with relevant IETF WGs and, where appropriate, with=20 > external groups. > =20 > Milestones: >=20 > Nov 2006 initial problem statement Internet Draft > Nov 2006 initial deployment models Internet Drafts > March 2007 initial router marking behavior (including encoding) > Internet Drafts > March 2007 initial flow admission control and pre-emption > mechanisms Internet Drafts > (including edge node measurements) > March 2007 initial applicability statement Internet Draft > March/July 2007 submit Problem statement to IESG for approval as > informational RFC > July 2007 submit deployment models to IESG for approval as > informational RFC > July 2007 submit applicability statement to IESG for approval as > informational RFC > (may be part of the deployment models) > July 2007 initial manageability issues document Internet Draft > Nov 2007 submit router marking behavior to IESG for approval as > standards track RFC > Nov 2007/Mar 2008 submit flow admission control and pre-emption=20 > mechanism as standard track RFC > Nov 2007 initial signaling analysis Internet Draft=20 > Nov 2007 submit manageability issues document to IESG for > approval as informational RFC > Mar 2008 re-charter or close >=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 Nov 24 13:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gng14-0007Kh-0q; Fri, 24 Nov 2006 13:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gng12-0007Kc-Oh for pcn@ietf.org; Fri, 24 Nov 2006 13:43:12 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gng11-00048R-TT for pcn@ietf.org; Fri, 24 Nov 2006 13:43:12 -0500 Received: (qmail invoked by alias); 24 Nov 2006 18:43:09 -0000 Received: from p549853FE.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.83.254] by mail.gmx.net (mp001) with SMTP; 24 Nov 2006 19:43:09 +0100 X-Authenticated: #29516787 Message-ID: <45673D3C.9020003@gmx.net> Date: Fri, 24 Nov 2006 19:43:08 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] PCN updated charter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 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, sorry for not being specific in my previous mail. Note that it depends on your opinion about milestones, but I think they should somehow reflect that is being done in the working group. It gives the outside world the impression that the IETF is always too slow with their work if the group does not hit milestones. After some experience with IETF work I tend to be a bit more realistic of how long it takes to produce sound documents; no matter who is author of the document or how simple the subject is (or seems to be). >> Nov 2006 initial problem statement Internet Draft >> Nov 2006 initial deployment models Internet Drafts These two documents can only refer to the submission of the individual submissions once the working group is chartered, I guess. It is not realistic to assume that the WG will be chartered by November 2006. >> March 2007 initial router marking behavior (including encoding) >> Internet Drafts >> March 2007 initial flow admission control and pre-emption >> mechanisms Internet Drafts >> (including edge node measurements) >> March 2007 initial applicability statement Internet Draft Do you think you can accomplish some work within the next two months to have * all these individual submissions ready by " February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) " ? Or do these documents even refer to the initial version of working group documents? If yes, then this pretty much impossible to accomplish. You might want to differentiate these two cases since charters typically refer to working group documents rather than some arbitrary docs that have been sent to the working group. >> March/July 2007 submit Problem statement to IESG for approval as >> informational RFC Decide whether you want the milestone to be March or July. If it is March and let us assume that the working group is created early December then you need to have an individual submission turned into a working group document. You need to confirm this decision on the mailing list and that takes about two weeks. Since you have XMAS breaks you will have the working group document sometime late in Dec. / beginning of Jan. since only the document authors (and their co-workers) will be excited about the idea of making them a working group item (everyone else in on holiday). Then, you need to work on the document. You need reviews, draft updates since you cannot assume that the first version is already ready for IESG. Now, if the submission deadline is March 5 you need to start a working group last call early February since that takes at best 2 weeks. Then, give the authors about 2 weeks to update the document in such a way that it does not require another review cycle and to get it ready for the submission deadline. >> July 2007 submit deployment models to IESG for approval as >> informational RFC >> July 2007 submit applicability statement to IESG for approval > as >> informational RFC >> (may be part of the deployment models) >> July 2007 initial manageability issues document Internet Draft I also think that these milestones are far too optimistic. They just seem to assume that everything just works great with every document and nobody raises issues that require some level of discussions. >> Nov 2007 submit router marking behavior to IESG for approval > as >> standards track RFC >> Nov 2007/Mar 2008 submit flow admission control and pre-emption >> mechanism as standard track RFC Hard to tell whether these documents will be completed by this time. Could be possible. >> Nov 2007 initial signaling analysis Internet Draft Why cannot the work on this draft started earlier? Is there a dependency on another draft? >> Nov 2007 submit manageability issues document to IESG for >> approval as informational RFC >> Mar 2008 re-charter or close Does this make sense to you? Ciao Hannes Anna Charny (acharny) wrote: > Hi Hannes, > > Thanks for your feedback. Do you have specific suggestions on how to > change the milestones? What specifically makes you think the current > ones are not realistic? > > Thanks, > Anna > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, November 24, 2006 11:45 AM > To: Anna Charny (acharny) > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter > > Hi Anna, > > obviously the milestones are not realistic. > > Ciao > Hannes > > Anna Charny (acharny) wrote: >> Dear all, >> >> The proposed PCN charter has been updated based on the (very few) >> recent comments we received. >> The new version has been uploaded, and is also attached at the end of >> this email for convenience. >> >> The only difference from the previously posted version is a wording >> change below: >> >> 2. >> .... >> (b) Application-controlled Admission and Pre-emption: routers within >> the DiffServ region are PCN-capable and trusted e.g. SIP >> endpoints >> (gateway or host) perform admission and flow pre-emption >> >> TO: >> 2. >> ..... >> (b) Application-controlled Admission and Pre-emption: routers > within >> the DiffServ region are PCN-capable and trusted >> application-controlled >> (e.g., SIP) endpoints (gateway or host) based on the marking, >> perform >> admission and flow pre-emption. >> >> If you had sent us any email with proposed changes that was >> inadvertently missed and not reflected, please let us know right away. >> >> >> Best Regards, >> Anna and Scott >> PCN BOF Co-Chairs >> >> ------------- >> >> PCN Draft Charter (Pre-Congestion Notification) >> >> The PCN WG will tackle the problem of how to provide scalable, >> resilient >> >> admission control and strong QoS assurance while using packet marking >> techniques. >> Current attempts to deliver QoS using only packet marking (e.g. >> DiffServ) are >> limited in the level of QoS assurance that can be provided without >> substantial over-provisioning. To improve the QoS assurance, PCN will >> add flow admission control and flow pre-emption. In normal >> circumstances admission control should protect the QoS of previously >> admitted flows. In times of heavy congestion (for example caused by >> route changes due to link or router failure) pre-emption of some flows > >> should preserve the QoS of remaining flows. While the WG will address >> both admission and pre-emption, it is assumed that these mechanisms >> can be used independently of each other, and the use of one does not >> mandate the use of the other. >> >> The initial scope of the WG is the use of PCN within a single DiffServ > >> region. >> The overall approach will be based on a separation of functionality >> between the interior routers and edge nodes of the DiffServ region. >> Interior routers mark packet headers when their traffic is above a >> certain level, as an early warning of incipient congestion >> ("pre-congestion"); this builds on concepts from >> >> RFC 3168 "The Addition of Explicit Congestion Notification to IP". >> Edge nodes of the DiffServ Region monitor the markings and that >> information is used to make flow admission control and pre-emption >> decisions. The decisions could be made by the edge nodes or by a >> centralized system (which is informed of the edge nodes measurements). >> >> The WG will address the following specific problems and develop >> standards track solutions to them: >> 1. When should an interior router mark a packet (i.e. at what traffic >> level) >> in order to give early warning of its own congestion? >> 2. How should such a mark be encoded in a packet (in the ECN and/or >> DSCP fields)? >> 3. How should these markings (at packet granularity) be converted into > >> admission control and flow pre-emption decisions (at flow >> granularity)? >> >> To support this, the WG will work on the following Informational >> documents: >> 1. a Problem Statement, to describe the problems the group is tackling > >> and the assumptions made >> 2. at least two deployment models, initially to help focus the problem > >> statement >> and later to check that the solutions being developed satisfy the >> deployment >> scenario. Possible deployment models may be: >> (a) IntServ over DiffServ (RFC2998): the DiffServ region is >> PCN-enabled >> and its edge nodes decide about admission and flow pre-emption >> (b) Application-controlled Admission and Pre-emption: routers > within >> the DiffServ region are PCN-capable and trusted >> application-controlled >> (e.g., SIP) endpoints (gateway or host) based on the marking, >> perform >> admission and flow pre-emption. >> 3. a generic analysis of the signaling extensions required to support >> PCN. >> Note that extensions/enhancements to specific signaling protocols >> (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. >> 4. at least one example solution implementing the framework and its >> performance >> evaluation (e.g. simulation results), to provide evidence of the >> viability >> of the proposed standard in the proposed deployment models 5. an >> analysis of the tradeoffs of different encoding possibilities (e.g. >> ECN >> and DCSP marking) >> 6. an applicability statement the decision on whether applicability >> statement >> will be delivered as a standalone document or will be incorporated >> into other >> documents such as deployment models is TBD) 7. an analysis of the >> manageability issues of a PCN region >> >> The initial scope of the WG will restrict the problem space in the >> following ways: >> 1. By assuming the PCN-enabled Internet Region is a controlled >> environment, >> i.e. all the interior routers and edge nodes of the region run PCN >> and >> trust each other >> 2. By assuming there are sufficient flows on any relevant bottleneck >> link in the >> PCN-enabled region >> 3. By focusing on the QoS assurance required by applications > generating >> inelastic traffic like voice and video requiring low delay, jitter >> and >> packet loss, i.e. as defined by the Controlled Load Service >> [RFC2211]. >> 4. By keeping specific handling of emergency and other precedence >> (911, GETS, >> WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring >> that the edge >> nodes are not precluded from taking appropriate actions that may be > >> necessary >> for handling such calls and (b) assuming that PCN Internal Nodes >> may not be >> MLPP precedence-aware but are DSCP aware. >> >> Subsequent re-chartering may investigate solutions for when some of >> these restrictions are not in place. >> 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 impact on e.g. the choice > of encoding. >> >> >> Topics out of scope for the WG include a general investigation of >> admission control mechanisms. >> >> The WG will draw on the substantial prior academic and IETF work on >> measurement-based admission control. >> >> The WG will work with relevant IETF WGs and, where appropriate, with >> external groups. >> >> Milestones: >> >> Nov 2006 initial problem statement Internet Draft >> Nov 2006 initial deployment models Internet Drafts >> March 2007 initial router marking behavior (including encoding) >> Internet Drafts >> March 2007 initial flow admission control and pre-emption >> mechanisms Internet Drafts >> (including edge node measurements) >> March 2007 initial applicability statement Internet Draft >> March/July 2007 submit Problem statement to IESG for approval as >> informational RFC >> July 2007 submit deployment models to IESG for approval as >> informational RFC >> July 2007 submit applicability statement to IESG for approval > as >> informational RFC >> (may be part of the deployment models) >> July 2007 initial manageability issues document Internet Draft >> Nov 2007 submit router marking behavior to IESG for approval > as >> standards track RFC >> Nov 2007/Mar 2008 submit flow admission control and pre-emption >> mechanism as standard track RFC >> Nov 2007 initial signaling analysis Internet Draft >> Nov 2007 submit manageability issues document to IESG for >> approval as informational RFC >> Mar 2008 re-charter or close >> >> _______________________________________________ >> PCN mailing 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 Nov 27 09:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goh6i-00047W-Cs; Mon, 27 Nov 2006 09:05:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goh6g-00046y-4x for pcn@ietf.org; Mon, 27 Nov 2006 09:05:14 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goh6f-00047m-JW for pcn@ietf.org; Mon, 27 Nov 2006 09:05:14 -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 kARE54V06343; Mon, 27 Nov 2006 09:05:05 -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 updated charter Date: Mon, 27 Nov 2006 09:05:02 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D5E8FDA@zcarhxm1.corp.nortel.com> In-Reply-To: <45673D3C.9020003@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccP+Hvm+fUtCPKuTwavjUufO1DhRACMTF1w From: "Jozef Babiarz" To: "Hannes Tschofenig" , "Anna Charny \(acharny\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 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 Hannes is suggesting makes sense. The schedule is too aggressive and it would not allow time for WG to discuss and analyze the different proposals. I would like to suggest that the deliverables be moved out by one or two meetings.=20 Hannes asked: ">> Nov 2007 initial signaling analysis Internet Draft Why cannot the work on this draft started earlier? Is there a dependency on another draft?" [joe]Signalling analysis can start anytime, however, it can not be finished until router marking behavior, flow admission control and pre-emption mechanisms are agreed to. Regards, Joe Telephone: 613-763-6098=20 Email: babiarz@nortel.com -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, November 24, 2006 1:43 PM To: Anna Charny (acharny) Cc: pcn@ietf.org Subject: Re: [PCN] PCN updated charter Hi Anna, sorry for not being specific in my previous mail. Note that it depends=20 on your opinion about milestones, but I think they should somehow=20 reflect that is being done in the working group. It gives the outside=20 world the impression that the IETF is always too slow with their work if the group does not hit milestones. After some experience with IETF work=20 I tend to be a bit more realistic of how long it takes to produce sound=20 documents; no matter who is author of the document or how simple the=20 subject is (or seems to be). >> Nov 2006 initial problem statement Internet Draft >> Nov 2006 initial deployment models Internet Drafts These two documents can only refer to the submission of the individual=20 submissions once the working group is chartered, I guess. It is not realistic to assume that the WG will be chartered by November=20 2006. >> March 2007 initial router marking behavior (including encoding) >> Internet Drafts >> March 2007 initial flow admission control and pre-emption >> mechanisms Internet Drafts >> (including edge node measurements) >> March 2007 initial applicability statement Internet Draft Do you think you can accomplish some work within the next two months to=20 have * all these individual submissions ready by " February 26, Monday - Internet Draft Cut-off for initial document (-00)=20 submission by 09:00 ET (14:00 UTC/GMT) " ? Or do these documents even refer to the initial version of working group documents? If yes, then this pretty much impossible to accomplish. You might want to differentiate these two cases since charters typically refer to working group documents rather than some arbitrary docs that=20 have been sent to the working group. >> March/July 2007 submit Problem statement to IESG for approval as >> informational RFC Decide whether you want the milestone to be March or July. If it is March and let us assume that the working group is created early December then you need to have an individual submission turned into a=20 working group document. You need to confirm this decision on the mailing list and that takes about two weeks. Since you have XMAS breaks you will have the working group document sometime late in Dec. / beginning of=20 Jan. since only the document authors (and their co-workers) will be=20 excited about the idea of making them a working group item (everyone=20 else in on holiday). Then, you need to work on the document. You need=20 reviews, draft updates since you cannot assume that the first version is already ready for IESG. Now, if the submission deadline is March 5 you=20 need to start a working group last call early February since that takes at best 2 weeks. Then, give the authors about 2 weeks to update the=20 document in such a way that it does not require another review cycle and to get it ready for the submission deadline. >> July 2007 submit deployment models to IESG for approval as >> informational RFC >> July 2007 submit applicability statement to IESG for approval > as >> informational RFC >> (may be part of the deployment models) >> July 2007 initial manageability issues document Internet Draft I also think that these milestones are far too optimistic. They just=20 seem to assume that everything just works great with every document and=20 nobody raises issues that require some level of discussions. >> Nov 2007 submit router marking behavior to IESG for approval > as >> standards track RFC >> Nov 2007/Mar 2008 submit flow admission control and pre-emption >> mechanism as standard track RFC Hard to tell whether these documents will be completed by this time.=20 Could be possible. >> Nov 2007 initial signaling analysis Internet Draft Why cannot the work on this draft started earlier? Is there a dependency on another draft? >> Nov 2007 submit manageability issues document to IESG for >> approval as informational RFC >> Mar 2008 re-charter or close Does this make sense to you? Ciao Hannes Anna Charny (acharny) wrote: > Hi Hannes, >=20 > Thanks for your feedback. Do you have specific suggestions on how to > change the milestones? What specifically makes you think the current > ones are not realistic? >=20 > Thanks, > Anna =20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, November 24, 2006 11:45 AM > To: Anna Charny (acharny) > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > Hi Anna, >=20 > obviously the milestones are not realistic. >=20 > Ciao > Hannes >=20 > Anna Charny (acharny) wrote: >> Dear all, >> =20 >> The proposed PCN charter has been updated based on the (very few)=20 >> recent comments we received. >> The new version has been uploaded, and is also attached at the end of >> this email for convenience. >> >> The only difference from the previously posted version is a wording=20 >> change below: >> >> 2. >> .... >> (b) Application-controlled Admission and Pre-emption: routers within >> the DiffServ region are PCN-capable and trusted e.g. SIP=20 >> endpoints >> (gateway or host) perform admission and flow pre-emption >> =20 >> TO: >> 2. >> ..... >> (b) Application-controlled Admission and Pre-emption: routers > within >> the DiffServ region are PCN-capable and trusted=20 >> application-controlled >> (e.g., SIP) endpoints (gateway or host) based on the marking,=20 >> perform >> admission and flow pre-emption. >> >> If you had sent us any email with proposed changes that was=20 >> inadvertently missed and not reflected, please let us know right away. >> =20 >> =20 >> Best Regards, >> Anna and Scott >> PCN BOF Co-Chairs >> >> ------------- >> >> PCN Draft Charter (Pre-Congestion Notification) >> =20 >> The PCN WG will tackle the problem of how to provide scalable,=20 >> resilient >> >> admission control and strong QoS assurance while using packet marking >> techniques. >> Current attempts to deliver QoS using only packet marking (e.g. >> DiffServ) are >> limited in the level of QoS assurance that can be provided without=20 >> substantial over-provisioning. To improve the QoS assurance, PCN will >> add flow admission control and flow pre-emption. In normal=20 >> circumstances admission control should protect the QoS of previously=20 >> admitted flows. In times of heavy congestion (for example caused by=20 >> route changes due to link or router failure) pre-emption of some flows >=20 >> should preserve the QoS of remaining flows. While the WG will address >> both admission and pre-emption, it is assumed that these mechanisms=20 >> can be used independently of each other, and the use of one does not=20 >> mandate the use of the other. >> >> The initial scope of the WG is the use of PCN within a single DiffServ >=20 >> region. >> The overall approach will be based on a separation of functionality=20 >> between the interior routers and edge nodes of the DiffServ region.=20 >> Interior routers mark packet headers when their traffic is above a=20 >> certain level, as an early warning of incipient congestion=20 >> ("pre-congestion"); this builds on concepts from >> >> RFC 3168 "The Addition of Explicit Congestion Notification to IP".=20 >> Edge nodes of the DiffServ Region monitor the markings and that=20 >> information is used to make flow admission control and pre-emption=20 >> decisions. The decisions could be made by the edge nodes or by a=20 >> centralized system (which is informed of the edge nodes measurements). >> >> The WG will address the following specific problems and develop=20 >> standards track solutions to them: >> 1. When should an interior router mark a packet (i.e. at what traffic >> level)=20 >> in order to give early warning of its own congestion? >> 2. How should such a mark be encoded in a packet (in the ECN and/or=20 >> DSCP fields)? >> 3. How should these markings (at packet granularity) be converted into >=20 >> admission control and flow pre-emption decisions (at flow=20 >> granularity)? >> =20 >> To support this, the WG will work on the following Informational >> documents: >> 1. a Problem Statement, to describe the problems the group is tackling >=20 >> and the assumptions made >> 2. at least two deployment models, initially to help focus the problem >=20 >> statement >> and later to check that the solutions being developed satisfy the=20 >> deployment >> scenario. Possible deployment models may be:=20 >> (a) IntServ over DiffServ (RFC2998): the DiffServ region is=20 >> PCN-enabled >> and its edge nodes decide about admission and flow pre-emption >> (b) Application-controlled Admission and Pre-emption: routers > within >> the DiffServ region are PCN-capable and trusted=20 >> application-controlled >> (e.g., SIP) endpoints (gateway or host) based on the marking,=20 >> perform >> admission and flow pre-emption. >> 3. a generic analysis of the signaling extensions required to support >> PCN. >> Note that extensions/enhancements to specific signaling protocols=20 >> (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. >> 4. at least one example solution implementing the framework and its=20 >> performance >> evaluation (e.g. simulation results), to provide evidence of the=20 >> viability >> of the proposed standard in the proposed deployment models 5. an=20 >> analysis of the tradeoffs of different encoding possibilities (e.g.=20 >> ECN >> and DCSP marking) >> 6. an applicability statement the decision on whether applicability=20 >> statement >> will be delivered as a standalone document or will be incorporated >> into other >> documents such as deployment models is TBD) 7. an analysis of the=20 >> manageability issues of a PCN region >> =20 >> The initial scope of the WG will restrict the problem space in the=20 >> following ways: >> 1. By assuming the PCN-enabled Internet Region is a controlled=20 >> environment, >> i.e. all the interior routers and edge nodes of the region run PCN >> and >> trust each other >> 2. By assuming there are sufficient flows on any relevant bottleneck=20 >> link in the >> PCN-enabled region >> 3. By focusing on the QoS assurance required by applications > generating=20 >> inelastic traffic like voice and video requiring low delay, jitter >> and >> packet loss, i.e. as defined by the Controlled Load Service=20 >> [RFC2211]. >> 4. By keeping specific handling of emergency and other precedence=20 >> (911, GETS, >> WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring=20 >> that the edge >> nodes are not precluded from taking appropriate actions that may be >=20 >> necessary >> for handling such calls and (b) assuming that PCN Internal Nodes=20 >> may not be >> MLPP precedence-aware but are DSCP aware. >> >> Subsequent re-chartering may investigate solutions for when some of=20 >> these restrictions are not in place. >> In particular, after re-chartering it's expected that the WG will=20 >> cover the case with multiple, non-trusting domains. However, even=20 >> during the initial standardization phase, this case needs to be kept=20 >> in mind, as the anti-cheating solution will impact on e.g. the choice > of encoding. >> =20 >> >> Topics out of scope for the WG include a general investigation of=20 >> admission control mechanisms. >> >> The WG will draw on the substantial prior academic and IETF work on=20 >> measurement-based admission control. >> >> The WG will work with relevant IETF WGs and, where appropriate, with=20 >> external groups. >> =20 >> Milestones: >> >> Nov 2006 initial problem statement Internet Draft >> Nov 2006 initial deployment models Internet Drafts >> March 2007 initial router marking behavior (including encoding) >> Internet Drafts >> March 2007 initial flow admission control and pre-emption >> mechanisms Internet Drafts >> (including edge node measurements) >> March 2007 initial applicability statement Internet Draft >> March/July 2007 submit Problem statement to IESG for approval as >> informational RFC >> July 2007 submit deployment models to IESG for approval as >> informational RFC >> July 2007 submit applicability statement to IESG for approval > as >> informational RFC >> (may be part of the deployment models) >> July 2007 initial manageability issues document Internet Draft >> Nov 2007 submit router marking behavior to IESG for approval > as >> standards track RFC >> Nov 2007/Mar 2008 submit flow admission control and pre-emption=20 >> mechanism as standard track RFC >> Nov 2007 initial signaling analysis Internet Draft=20 >> Nov 2007 submit manageability issues document to IESG for >> approval as informational RFC >> Mar 2008 re-charter or close >> >> _______________________________________________ >> PCN mailing 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 Nov 27 09:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohEW-0000YR-8g; Mon, 27 Nov 2006 09:13:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohEV-0000YM-Ko for pcn@ietf.org; Mon, 27 Nov 2006 09:13:19 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GohET-0005EA-PY for pcn@ietf.org; Mon, 27 Nov 2006 09:13:19 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2006 06:13:17 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAREDGUq004465; Mon, 27 Nov 2006 09:13:16 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAREDGYJ008787; Mon, 27 Nov 2006 09:13:16 -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); Mon, 27 Nov 2006 09:13:16 -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 updated charter Date: Mon, 27 Nov 2006 09:13:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccP+GZf4XKQZGvAT0qUAZfL8tem4gCNS1Nw From: "Anna Charny \(acharny\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 27 Nov 2006 14:13:16.0215 (UTC) FILETIME=[2E8D3470:01C7122E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13972; t=1164636796; x=1165500796; 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]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Hannes=20Tschofenig=22=20; bh=HtPE13avdkJIymzHXz8TcWzEItrRLbHY8ElBUSgfzC0=; b=qUxrbcJsijIBL6W9FC69oqJ4UTA7DuUKrrf6KHVYFY0bivf5MNoB0Txp5yabkb8ILBgWyndS rUsq0se/cKzS2gGNFxy5/7gkxOglXzRXu37WPaY4y3q3TBk95MxMcuqG; 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: b058151374d77ee76edaac850f7449fb 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 Hannes, Thank you for the thoughtful analysis. I believe it makes a lot of sense. Scott and I will take a closer look at the dates and discuss them with the ADs. Joe's suggestion of simply moving the dates a meeting or two may be an easy way to address it. =20 Anna=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, November 24, 2006 1:43 PM To: Anna Charny (acharny) Cc: pcn@ietf.org Subject: Re: [PCN] PCN updated charter Hi Anna, sorry for not being specific in my previous mail. Note that it depends on your opinion about milestones, but I think they should somehow reflect that is being done in the working group. It gives the outside world the impression that the IETF is always too slow with their work if the group does not hit milestones. After some experience with IETF work I tend to be a bit more realistic of how long it takes to produce sound documents; no matter who is author of the document or how simple the subject is (or seems to be). >> Nov 2006 initial problem statement Internet Draft >> Nov 2006 initial deployment models Internet Drafts These two documents can only refer to the submission of the individual submissions once the working group is chartered, I guess. It is not realistic to assume that the WG will be chartered by November 2006. >> March 2007 initial router marking behavior (including encoding) >> Internet Drafts >> March 2007 initial flow admission control and pre-emption >> mechanisms Internet Drafts >> (including edge node measurements) >> March 2007 initial applicability statement Internet Draft Do you think you can accomplish some work within the next two months to have * all these individual submissions ready by " February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) " ? Or do these documents even refer to the initial version of working group documents? If yes, then this pretty much impossible to accomplish. You might want to differentiate these two cases since charters typically refer to working group documents rather than some arbitrary docs that have been sent to the working group. >> March/July 2007 submit Problem statement to IESG for approval as >> informational RFC Decide whether you want the milestone to be March or July. If it is March and let us assume that the working group is created early December then you need to have an individual submission turned into a working group document. You need to confirm this decision on the mailing list and that takes about two weeks. Since you have XMAS breaks you will have the working group document sometime late in Dec. / beginning of Jan. since only the document authors (and their co-workers) will be excited about the idea of making them a working group item (everyone else in on holiday). Then, you need to work on the document. You need reviews, draft updates since you cannot assume that the first version is already ready for IESG. Now, if the submission deadline is March 5 you need to start a working group last call early February since that takes at best 2 weeks. Then, give the authors about 2 weeks to update the document in such a way that it does not require another review cycle and to get it ready for the submission deadline. >> July 2007 submit deployment models to IESG for approval as >> informational RFC >> July 2007 submit applicability statement to IESG for approval > as >> informational RFC >> (may be part of the deployment models) >> July 2007 initial manageability issues document Internet Draft I also think that these milestones are far too optimistic. They just seem to assume that everything just works great with every document and nobody raises issues that require some level of discussions. >> Nov 2007 submit router marking behavior to IESG for approval > as >> standards track RFC >> Nov 2007/Mar 2008 submit flow admission control and pre-emption >> mechanism as standard track RFC Hard to tell whether these documents will be completed by this time.=20 Could be possible. >> Nov 2007 initial signaling analysis Internet Draft Why cannot the work on this draft started earlier? Is there a dependency on another draft? >> Nov 2007 submit manageability issues document to IESG for >> approval as informational RFC >> Mar 2008 re-charter or close Does this make sense to you? Ciao Hannes Anna Charny (acharny) wrote: > Hi Hannes, >=20 > Thanks for your feedback. Do you have specific suggestions on how to=20 > change the milestones? What specifically makes you think the current=20 > ones are not realistic? >=20 > Thanks, > Anna >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, November 24, 2006 11:45 AM > To: Anna Charny (acharny) > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter >=20 > Hi Anna, >=20 > obviously the milestones are not realistic. >=20 > Ciao > Hannes >=20 > Anna Charny (acharny) wrote: >> Dear all, >> =20 >> The proposed PCN charter has been updated based on the (very few)=20 >> recent comments we received. >> The new version has been uploaded, and is also attached at the end of >> this email for convenience. >> >> The only difference from the previously posted version is a wording=20 >> change below: >> >> 2. >> .... >> (b) Application-controlled Admission and Pre-emption: routers within >> the DiffServ region are PCN-capable and trusted e.g. SIP=20 >> endpoints >> (gateway or host) perform admission and flow pre-emption >> =20 >> TO: >> 2. >> ..... >> (b) Application-controlled Admission and Pre-emption: routers > within >> the DiffServ region are PCN-capable and trusted=20 >> application-controlled >> (e.g., SIP) endpoints (gateway or host) based on the marking,=20 >> perform >> admission and flow pre-emption. >> >> If you had sent us any email with proposed changes that was=20 >> inadvertently missed and not reflected, please let us know right away. >> =20 >> =20 >> Best Regards, >> Anna and Scott >> PCN BOF Co-Chairs >> >> ------------- >> >> PCN Draft Charter (Pre-Congestion Notification) >> =20 >> The PCN WG will tackle the problem of how to provide scalable,=20 >> resilient >> >> admission control and strong QoS assurance while using packet marking >> techniques. >> Current attempts to deliver QoS using only packet marking (e.g. >> DiffServ) are >> limited in the level of QoS assurance that can be provided without=20 >> substantial over-provisioning. To improve the QoS assurance, PCN will >> add flow admission control and flow pre-emption. In normal=20 >> circumstances admission control should protect the QoS of previously=20 >> admitted flows. In times of heavy congestion (for example caused by=20 >> route changes due to link or router failure) pre-emption of some=20 >> flows >=20 >> should preserve the QoS of remaining flows. While the WG will address >> both admission and pre-emption, it is assumed that these mechanisms=20 >> can be used independently of each other, and the use of one does not=20 >> mandate the use of the other. >> >> The initial scope of the WG is the use of PCN within a single=20 >> DiffServ >=20 >> region. >> The overall approach will be based on a separation of functionality=20 >> between the interior routers and edge nodes of the DiffServ region. >> Interior routers mark packet headers when their traffic is above a=20 >> certain level, as an early warning of incipient congestion=20 >> ("pre-congestion"); this builds on concepts from >> >> RFC 3168 "The Addition of Explicit Congestion Notification to IP".=20 >> Edge nodes of the DiffServ Region monitor the markings and that=20 >> information is used to make flow admission control and pre-emption=20 >> decisions. The decisions could be made by the edge nodes or by a=20 >> centralized system (which is informed of the edge nodes measurements). >> >> The WG will address the following specific problems and develop=20 >> standards track solutions to them: >> 1. When should an interior router mark a packet (i.e. at what traffic >> level)=20 >> in order to give early warning of its own congestion? >> 2. How should such a mark be encoded in a packet (in the ECN and/or=20 >> DSCP fields)? >> 3. How should these markings (at packet granularity) be converted=20 >> into >=20 >> admission control and flow pre-emption decisions (at flow=20 >> granularity)? >> =20 >> To support this, the WG will work on the following Informational >> documents: >> 1. a Problem Statement, to describe the problems the group is=20 >> tackling >=20 >> and the assumptions made >> 2. at least two deployment models, initially to help focus the=20 >> problem >=20 >> statement >> and later to check that the solutions being developed satisfy the=20 >> deployment >> scenario. Possible deployment models may be:=20 >> (a) IntServ over DiffServ (RFC2998): the DiffServ region is=20 >> PCN-enabled >> and its edge nodes decide about admission and flow pre-emption >> (b) Application-controlled Admission and Pre-emption: routers > within >> the DiffServ region are PCN-capable and trusted=20 >> application-controlled >> (e.g., SIP) endpoints (gateway or host) based on the marking,=20 >> perform >> admission and flow pre-emption. >> 3. a generic analysis of the signaling extensions required to support >> PCN. >> Note that extensions/enhancements to specific signaling protocols=20 >> (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. >> 4. at least one example solution implementing the framework and its=20 >> performance >> evaluation (e.g. simulation results), to provide evidence of the=20 >> viability >> of the proposed standard in the proposed deployment models 5. an=20 >> analysis of the tradeoffs of different encoding possibilities (e.g. >> ECN >> and DCSP marking) >> 6. an applicability statement the decision on whether applicability=20 >> statement >> will be delivered as a standalone document or will be incorporated >> into other >> documents such as deployment models is TBD) 7. an analysis of the=20 >> manageability issues of a PCN region >> =20 >> The initial scope of the WG will restrict the problem space in the=20 >> following ways: >> 1. By assuming the PCN-enabled Internet Region is a controlled=20 >> environment, >> i.e. all the interior routers and edge nodes of the region run PCN >> and >> trust each other >> 2. By assuming there are sufficient flows on any relevant bottleneck=20 >> link in the >> PCN-enabled region >> 3. By focusing on the QoS assurance required by applications > generating >> inelastic traffic like voice and video requiring low delay, jitter >> and >> packet loss, i.e. as defined by the Controlled Load Service=20 >> [RFC2211]. >> 4. By keeping specific handling of emergency and other precedence=20 >> (911, GETS, >> WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring=20 >> that the edge >> nodes are not precluded from taking appropriate actions that may=20 >> be >=20 >> necessary >> for handling such calls and (b) assuming that PCN Internal Nodes=20 >> may not be >> MLPP precedence-aware but are DSCP aware. >> >> Subsequent re-chartering may investigate solutions for when some of=20 >> these restrictions are not in place. >> In particular, after re-chartering it's expected that the WG will=20 >> cover the case with multiple, non-trusting domains. However, even=20 >> during the initial standardization phase, this case needs to be kept=20 >> in mind, as the anti-cheating solution will impact on e.g. the choice > of encoding. >> =20 >> >> Topics out of scope for the WG include a general investigation of=20 >> admission control mechanisms. >> >> The WG will draw on the substantial prior academic and IETF work on=20 >> measurement-based admission control. >> >> The WG will work with relevant IETF WGs and, where appropriate, with=20 >> external groups. >> =20 >> Milestones: >> >> Nov 2006 initial problem statement Internet Draft >> Nov 2006 initial deployment models Internet Drafts >> March 2007 initial router marking behavior (including encoding) >> Internet Drafts >> March 2007 initial flow admission control and pre-emption >> mechanisms Internet Drafts >> (including edge node measurements) >> March 2007 initial applicability statement Internet Draft >> March/July 2007 submit Problem statement to IESG for approval as >> informational RFC >> July 2007 submit deployment models to IESG for approval as >> informational RFC >> July 2007 submit applicability statement to IESG for approval > as >> informational RFC >> (may be part of the deployment models) >> July 2007 initial manageability issues document Internet Draft >> Nov 2007 submit router marking behavior to IESG for approval > as >> standards track RFC >> Nov 2007/Mar 2008 submit flow admission control and pre-emption=20 >> mechanism as standard track RFC >> Nov 2007 initial signaling analysis Internet Draft=20 >> Nov 2007 submit manageability issues document to IESG for >> approval as informational RFC >> Mar 2008 re-charter or close >> >> _______________________________________________ >> PCN mailing 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 Nov 28 21:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpF11-0002PJ-0u; Tue, 28 Nov 2006 21:17:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpF0z-0002N4-Vk for pcn@ietf.org; Tue, 28 Nov 2006 21:17:37 -0500 Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpF0y-0000rW-6s for pcn@ietf.org; Tue, 28 Nov 2006 21:17:37 -0500 Received: from [64.169.29.211] (unverified [64.169.29.211]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 4.2.425.4) with ESMTP id for ; Tue, 28 Nov 2006 20:54:07 -0500 X-Modus-BlackList: 64.169.29.211=OK;lars.eggert@netlab.nec.de=OK X-Modus-Trusted: 64.169.29.211=NO Received: from lars.local ([142.131.240.172]) by [64.169.29.211] (8.13.6/8.13.6) with ESMTP id kAT2HDKh027621 for ; Tue, 28 Nov 2006 18:17:13 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 4DE3929A020 for ; Tue, 28 Nov 2006 18:17:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Message-Id: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Tue, 28 Nov 2006 18:17:14 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sc1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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="===============0202360806==" Errors-To: pcn-bounces@ietf.org --===============0202360806== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-104--371642272; protocol="application/pkcs7-signature" --Apple-Mail-104--371642272 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, I think feedback on PCN in San Diego was overall mostly positive, and a large reason was that the BOF was really well prepared and chaired. Nice job! However, some discussions in and after San Diego brought up valid points that a revised charter should reflect. Let me briefly outline them below, so we can start discussing them here: (1) Both the SIP- and PWE3-related deployment models have been questioned by the respective communities, and will require non- trivial coordination to align with the existing work in those areas. I'd therefore like to propose to exclude them from the initial scope of PCN at this time, and limit PCN to the "IntServ over DiffServ" case at this time. (2) The different options of encoding markings in packets require further investigation. This is an important component, because the deployability of PCN hinges on well-defined marking mechanisms. I'd therefore like to propose that PCN in the first phase should focus its energies on working on the problem statement, deployment model and marking mechanisms only. Work on the actual admission and preemption mechanisms should kick off only after these initial work items are stable. Comments? Thanks, Lars --Apple-Mail-104--371642272 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI5 MDIxNzE1WjAjBgkqhkiG9w0BCQQxFgQU4sFjiLl9nJOC9xK2udpKWBtBXmcwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAAmOjbjFHQdjxFjp4d0K Uo0Y9BK94F+5BFODtWuvglM6FLCSuuPuHXzJ6CUtxhTj4cFZd6saP3KT7U9icbc4VZY//5so+f1Y kVDxbDSqoFPnLz/JTTEwqptv7q0qrxGvvi9cj/KA9Inz069o1XddxzaKE/s8dwJH25l9Y1u9iBNl TXoTfoXMI1EY4VG3UaGcIzt80fIRrdAH8LLLeBlieGF1b5d5KdEtHY5vrVf2OwNVv1XxA/bPYYlL Y/Crq04CQjDbnpGq0RxkGC42RIkeZA5bhL1RCGZ5jPuzPP7EYegkYVgXkd5Zy38k3SfsuH5t1cmD wwURFh+pR/mfEe8tlEgAAAAAAAA= --Apple-Mail-104--371642272-- --===============0202360806== 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 --===============0202360806==-- From pcn-bounces@ietf.org Tue Nov 28 21:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFZh-00086z-Lk; Tue, 28 Nov 2006 21:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFZg-00086k-Cu for pcn@ietf.org; Tue, 28 Nov 2006 21:53:28 -0500 Received: from hermes.hosts.co.uk ([85.233.160.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpFZf-0005b1-3v for pcn@ietf.org; Tue, 28 Nov 2006 21:53:28 -0500 Received: from [69.250.221.255] (helo=[192.168.1.2]) by hermes.hosts.co.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1GpFZQ-0004EM-TQ; Wed, 29 Nov 2006 02:53:13 +0000 In-Reply-To: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> References: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> 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] PCN updated charter Date: Tue, 28 Nov 2006 21:53:11 -0500 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) 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 Lars, > (2) The different options of encoding markings in packets require > further investigation. This is an important component, because the > deployability of PCN hinges on well-defined marking mechanisms. I'd > therefore like to propose that PCN in the first phase should focus > its energies on working on the problem statement, deployment model > and marking mechanisms only. Work on the actual admission and > preemption mechanisms should kick off only after these initial work > items are stable. I'd like to advocate against having a problem statement deliverable. Normally, for new WGs the standard approach is a problem statement, usually a requirements, and then whatever (architecture, BCP, etc.). But in this case, we have a number of pre-existing documents (including an architecture) that have already gone through some discussions and presentations in TSVWG....so in my mind, there is a measure of a known problem space and approach that is relatively mature. In addition, given your more narrow scope for the group, we have more focus. So from my perspective, the exercise of a problem statement (in this particular case) would result in the group going a in lateral direction with not much of a contribution to existing drafts/work. my 2 cents, -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 04:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLj7-0008M0-5S; Wed, 29 Nov 2006 04:27:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLj5-0008Hg-JS for pcn@ietf.org; Wed, 29 Nov 2006 04:27:35 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpLj4-0001o1-7F for pcn@ietf.org; Wed, 29 Nov 2006 04:27: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 kAT9RDPO014785; Wed, 29 Nov 2006 10:27:25 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" , Subject: RE: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 10:27:15 +0100 Message-ID: <001901c71398$93c70940$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: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccTXJpMmjkMfw0/QhqQWQWd7+cFRQAO0uyQ 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, 29 Nov 2006 10:27:25 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Lars Regarding the SIP based deployment model, from what I remember there was a consensus to concentrate on an application based deployment model, instead of concentarting on a SIP deployment model. SIP could be then used as an example. However, we could concentrate on the application based deployment model without using SIP as a signaling application example. What is your opinion on this? Best Regards, Georgios > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: woensdag 29 november 2006 3:17 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter > > Hi, > > I think feedback on PCN in San Diego was overall mostly > positive, and a large reason was that the BOF was really well > prepared and chaired. > Nice job! > > However, some discussions in and after San Diego brought up > valid points that a revised charter should reflect. Let me > briefly outline them below, so we can start discussing them here: > > (1) Both the SIP- and PWE3-related deployment models have > been questioned by the respective communities, and will > require non- trivial coordination to align with the existing > work in those areas. > I'd therefore like to propose to exclude them from the > initial scope of PCN at this time, and limit PCN to the > "IntServ over DiffServ" > case at this time. > > (2) The different options of encoding markings in packets > require further investigation. This is an important > component, because the deployability of PCN hinges on > well-defined marking mechanisms. I'd therefore like to > propose that PCN in the first phase should focus its energies > on working on the problem statement, deployment model and > marking mechanisms only. Work on the actual admission and > preemption mechanisms should kick off only after these > initial work items are stable. > > Comments? > > Thanks, > Lars > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 11:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSE7-0002Pp-AW; Wed, 29 Nov 2006 11:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSE5-0002Nh-Us for pcn@ietf.org; Wed, 29 Nov 2006 11:24:01 -0500 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSE1-0002lq-C3 for pcn@ietf.org; Wed, 29 Nov 2006 11:24:01 -0500 Received: (qmail 29988 invoked by uid 0); 29 Nov 2006 16:21:24 -0000 Received: by simscan 1.2.0 ppid: 29973, pid: 29984, t: 0.6986s scanners: clamav: 0.88.4/m:40/d:1991 spam: 3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on hiltonsmtp.worldspice.net X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_95 autolearn=disabled version=3.1.7 Received: from unknown (HELO lars.local) (nec-smtp@67.99.198.2) by hiltonsmtp.worldspice.net with ESMTPA; 29 Nov 2006 16:21:23 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 1F96929A502 for ; Wed, 29 Nov 2006 08:23:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> Message-Id: From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 08:23:37 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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="===============0395679800==" Errors-To: pcn-bounces@ietf.org --===============0395679800== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--320859462; protocol="application/pkcs7-signature" --Apple-Mail-6--320859462 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Ken, On Nov 28, 2006, at 18:53, ken carlberg wrote: > I'd like to advocate against having a problem statement > deliverable. Normally, for new WGs the standard approach is a > problem statement, usually a requirements, and then whatever > (architecture, BCP, etc.). But in this case, we have a number of > pre-existing documents (including an architecture) that have > already gone through some discussions and presentations in > TSVWG....so in my mind, there is a measure of a known problem space > and approach that is relatively mature. In addition, given your > more narrow scope for the group, we have more focus. > > So from my perspective, the exercise of a problem statement (in > this particular case) would result in the group going a in lateral > direction with not much of a contribution to existing drafts/work. I came up with the initial milestones by selecting a subset if the ones on the current draft charter at http://standards.nortel.com/pcn/ PCN_draft_charter_v01.txt, which does have a "problem statement" listed. But I see your point, and maybe PCN wants to discuss replacing that milestone with an architecture document that also describes the problem space and requirements for the individual marking and admission/preemption mechanisms to be developed later? Lars --Apple-Mail-6--320859462 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI5 MTYyMzM4WjAjBgkqhkiG9w0BCQQxFgQU/jyjdLQMv6qn17SMnnUHf164eoYwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBALssqKgEPr5WQsCz7fPL Jup+zeTRTqOuFepQaQVhT9cz2UpKFyTaQLGamYkefdD+nH0C3K7/WqBVXMntKV09itPRhCxgICn2 +dPQVBZwwBAVCm6enp/fYKcSzASl+y2nz+TBqX/1H3BScJy/XUk68+Dcfb8QOJtPU0pV7viCup4k tg+uw+klRHcTnvEuO+KjMZolJXEiHKL6KLOmSntR3wYGSAltvWiAQOw2UpucJ+Gnlfuhga533ft0 mIy9nyH1aMQsn2N+MZhD7S6MEQ6cuvzVbl0QE6VuDAlxTO8jVisEDZtQ6AilrCHl3fJ+o/t51X/P ao7iTcLATwC+CkSwU1MAAAAAAAA= --Apple-Mail-6--320859462-- --===============0395679800== 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 --===============0395679800==-- From pcn-bounces@ietf.org Wed Nov 29 11:26:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSGV-0004TI-T5; Wed, 29 Nov 2006 11:26:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSGU-0004Rr-Lz for pcn@ietf.org; Wed, 29 Nov 2006 11:26:30 -0500 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSGT-0003DM-Bm for pcn@ietf.org; Wed, 29 Nov 2006 11:26:30 -0500 Received: (qmail 30214 invoked by uid 0); 29 Nov 2006 16:23:58 -0000 Received: by simscan 1.2.0 ppid: 30202, pid: 30210, t: 0.4163s scanners: clamav: 0.88.4/m:40/d:1991 spam: 3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on hiltonsmtp.worldspice.net X-Spam-Level: *** X-Spam-Status: No, score=3.9 required=5.0 tests=BAYES_99 autolearn=disabled version=3.1.7 Received: from unknown (HELO lars.local) (nec-smtp@67.99.198.2) by hiltonsmtp.worldspice.net with ESMTPA; 29 Nov 2006 16:23:58 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 3E91429A505 for ; Wed, 29 Nov 2006 08:26:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <001901c71398$93c70940$4c0d5982@dynamic.ewi.utwente.nl> References: <001901c71398$93c70940$4c0d5982@dynamic.ewi.utwente.nl> Message-Id: From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 08:26:12 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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="===============0020788276==" Errors-To: pcn-bounces@ietf.org --===============0020788276== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--320704585; protocol="application/pkcs7-signature" --Apple-Mail-7--320704585 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Georgios, On Nov 29, 2006, at 1:27, Georgios Karagiannis wrote: > Regarding the SIP based deployment model, from what I > remember there was a consensus to concentrate on an application > based deployment model, instead of concentarting on a > SIP deployment model. SIP could be then used as an example. > > However, we could concentrate on the application based > deployment model without using SIP as a signaling application example. > > What is your opinion on this? I'm not sure what you mean by "application-based deployment model." These three models were discussed in the PCN BOF and are also in the current charter: > (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN- > enabled > and its edge nodes decide about admission and flow pre-emption > (b) SIP Controlled Admission and Preemption: routers within the > DiffServ > region are PCN-capable and trusted SIP endpoints (gateway or > host) > perform admission and flow pre-emption > (c) Pseudowire: PCN may be used as a congestion avoidance > mechanism for > end-user deployed pseudowires (collaborate with the PWE3 WG) I was arguing to restrict the initisal scope to (a) only. Lars --Apple-Mail-7--320704585 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI5 MTYyNjEzWjAjBgkqhkiG9w0BCQQxFgQUEhxnnghtcFXOt6nTMKWWntWzhuYwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAAdPIMjGFjQnscKA/CK1 Km0UFKwJx1B/+s0G9HN08j+w7J7MnN4O+gZtU9ittbi+JYshFSkJKGYJdlz0Kx5PIx5HmmciyH8t xiiq1qXJGIky1MZP2IHatCWSsT4Kmbmpy9lqlBC5lr0LG4ArTbEX5XfUO+opgDbwT75nO1qO4dv0 rocRAy/mm2L8I2AwE8qRvOzNoulFr6vJmczEjH5wGkNfUr8bEsalR1K5UxM5De3bWs6t/aa2wsVd 8ZE7Fcponps9QfBBp4GLFF+6zNMpqLM6bK1sYgkEYvr3LGcN+831uBTu+vWUxHGUDKn+7MudFiMG fZvI7EigzqjJARvBq8AAAAAAAAA= --Apple-Mail-7--320704585-- --===============0020788276== 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 --===============0020788276==-- From pcn-bounces@ietf.org Wed Nov 29 11:58:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSlY-00051L-6u; Wed, 29 Nov 2006 11:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSlW-0004yt-V8 for pcn@ietf.org; Wed, 29 Nov 2006 11:58:34 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSlV-0008GW-Ia for pcn@ietf.org; Wed, 29 Nov 2006 11:58:34 -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 kATGw1BQ005167; Wed, 29 Nov 2006 17:58:16 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" , Subject: RE: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 17:58:02 +0100 Message-ID: <008701c713d7$8b18c060$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccT0zfj2amVS8PHTGSp9RnjhTG2lwAAdH0A X-Spam-Score: 0.124 () 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]); Wed, 29 Nov 2006 17:58:17 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'Lars Westberg' , =?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?= 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 During the PCN BOF, concerns have been expressed on the "SIP based deployment model", but several opinions were in favour of including in the PCN charter instead of the "SIP based deployment model" an "Application based deployment model". Thus the (b) deployment model has to be redefined and presented as the "Application based deployment model", where SIP could be seen as an example. Please note that also the RU-PDB concept (presented during the tsvwg meeting) could be seen as an "Application based deployment model". Please see some discussion on the tsvwg mailing list on this (that took place during the IETF meeting in San Diego). Best Regards, Georgios > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: woensdag 29 november 2006 17:26 > To: pcn@ietf.org > Subject: Re: [PCN] PCN updated charter > > Hi, Georgios, > > On Nov 29, 2006, at 1:27, Georgios Karagiannis wrote: > > Regarding the SIP based deployment model, from what I > remember there > > was a consensus to concentrate on an application based deployment > > model, instead of concentarting on a SIP deployment model. > SIP could > > be then used as an example. > > > > However, we could concentrate on the application based deployment > > model without using SIP as a signaling application example. > > > > What is your opinion on this? > > I'm not sure what you mean by "application-based deployment model." > > These three models were discussed in the PCN BOF and are also > in the current charter: > > > (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN- > > enabled > > and its edge nodes decide about admission and flow > pre-emption > > (b) SIP Controlled Admission and Preemption: routers within the > > DiffServ > > region are PCN-capable and trusted SIP endpoints (gateway or > > host) > > perform admission and flow pre-emption > > (c) Pseudowire: PCN may be used as a congestion > avoidance mechanism > > for > > end-user deployed pseudowires (collaborate with the PWE3 WG) > > I was arguing to restrict the initisal scope to (a) only. > > Lars > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 12:04:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSrV-00014J-Ms; Wed, 29 Nov 2006 12:04:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpSrU-0000za-QV for pcn@ietf.org; Wed, 29 Nov 2006 12:04:44 -0500 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpSrT-0000di-FL for pcn@ietf.org; Wed, 29 Nov 2006 12:04:44 -0500 Received: (qmail 11644 invoked by uid 0); 29 Nov 2006 17:02:12 -0000 Received: by simscan 1.2.0 ppid: 11499, pid: 11624, t: 0.5181s scanners: clamav: 0.88.4/m:40/d:1991 spam: 3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on hiltonsmtp.worldspice.net X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_60 autolearn=disabled version=3.1.7 Received: from unknown (HELO lars.local) (nec-smtp@67.99.198.2) by hiltonsmtp.worldspice.net with ESMTPA; 29 Nov 2006 17:02:12 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 35C9B29A569; Wed, 29 Nov 2006 09:04:32 -0800 (PST) In-Reply-To: <008701c713d7$8b18c060$4c0d5982@dynamic.ewi.utwente.nl> References: <008701c713d7$8b18c060$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 09:04:30 -0800 To: Georgios Karagiannis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: pcn@ietf.org, 'Lars Westberg' , =?ISO-8859-1?Q? 'Attila_B=E1der_=28IJ/ETH=29' ?= 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="===============1552586603==" Errors-To: pcn-bounces@ietf.org --===============1552586603== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--318406056; protocol="application/pkcs7-signature" --Apple-Mail-13--318406056 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Nov 29, 2006, at 8:58, Georgios Karagiannis wrote: > During the PCN BOF, concerns have been expressed on > the "SIP based deployment model", but several opinions > were in favour of including in the PCN charter > instead of the "SIP based deployment model" an > "Application based deployment model". > Thus the (b) deployment model has to be redefined and > presented as the "Application based deployment model", > where SIP could be seen as an example. I fail to see how broadening this deployment model from "SIP only" to "arbitrary applications, SIP one example" is making it easier to make progress. The general problem will be harder to solve, and with SIP as an example the SIP details still would need to be gotten right. > Please note that also the RU-PDB concept (presented > during the tsvwg meeting) could be seen as an > "Application based deployment model". > Please see some discussion on the tsvwg mailing > list on this (that took place during the IETF meeting > in San Diego). Lars --Apple-Mail-13--318406056 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI5 MTcwNDMxWjAjBgkqhkiG9w0BCQQxFgQUIilPCpkysuneeRebJdOc2ovLOgQwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBADNOcEwNNUJYpErWR9p8 pZOfkJnwUXazy7IBGqlhn88FYSHz+E235BAnbCp/s7JjkzWUkfDjKWzGAG9EOxzxsB4tG5KkXd1j LZ6ifEPZ/fL9fGjWuAZx8EGU1n7CpZE6BW8/688oE2dbcDHHGkSp05LUeWDRxdGepSNEKAZjumTH OshcbZ0HltQm4a9pZAiRIqETQkq9V+U/ZjA0Y1RZ1EpTauqz6xjUYfWAlzGbASZ+PgR87X9KpElZ Le1cdwCWr9+Nztu6MTK8UNW1N2ZSiHaAlWCfNddDlnA8s9iZtsWL6sVajVFkaR4SomkZOK0yRUU7 BiDRQSZfqdxq3J3SbSMAAAAAAAA= --Apple-Mail-13--318406056-- --===============1552586603== 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 --===============1552586603==-- From pcn-bounces@ietf.org Wed Nov 29 16:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWq0-0005dd-RC; Wed, 29 Nov 2006 16:19:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWpz-0005Y4-0i for pcn@ietf.org; Wed, 29 Nov 2006 16:19:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWpx-0006zj-G8 for pcn@ietf.org; Wed, 29 Nov 2006 16:19:27 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 13:19:24 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kATLJOfj001406; Wed, 29 Nov 2006 16:19:24 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kATLJNYJ005946; Wed, 29 Nov 2006 16:19:23 -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); Wed, 29 Nov 2006 16:19:23 -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 updated charter Date: Wed, 29 Nov 2006 16:19:22 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccTXJnDuyW/hYfjS8i1vizw0sHy1gAnOxzA From: "Anna Charny \(acharny\)" To: "Lars Eggert" , X-OriginalArrivalTime: 29 Nov 2006 21:19:23.0728 (UTC) FILETIME=[0ACD9500:01C713FC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4631; t=1164835164; x=1165699164; 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]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Lars=20Eggert=22=20, =20; bh=ASy0qJzOyJxLX+xBY7fTbskAkBUXjW0OcliYepX2KbE=; b=HJyhNhyinV5ozQfhE+T8rPVB4tJeKhR/GH57T+kzctvzKDTkniocWNizXAk6F0euVtxKx/ll VaS6OYErFrDIj6/o6xuUqD37hlkM0WHDKhezNLNDTZXNCTX/FoSPpYhB; 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: 5ebbf074524e58e662bc8209a6235027 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 Lars, Please see below (marked Anna): Anna=20 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] Sent: Tuesday, November 28, 2006 9:17 PM To: pcn@ietf.org Subject: Re: [PCN] PCN updated charter Hi, I think feedback on PCN in San Diego was overall mostly positive, and a large reason was that the BOF was really well prepared and chaired. =20 Nice job! However, some discussions in and after San Diego brought up valid points that a revised charter should reflect. Let me briefly outline them below, so we can start discussing them here: (1) Both the SIP- and PWE3-related deployment models have been questioned by the respective communities, and will require non- trivial coordination to align with the existing work in those areas. =20 I'd therefore like to propose to exclude them from the initial scope of PCN at this time, and limit PCN to the "IntServ over DiffServ" =20 case at this time. Anna begin> PWE3-related deployment model has already been taken out of the updated charter, based on the BOF input. =20 As to SIP-related one - there is one aspect of it that actually potentially affects the marking at the ingress node, namely the aggregation assumptions, and especially aggregation level on a per-ingress-egress aggregate. This specific model is likely to assume both lower levels of aggregation on the PCN internal links, but especially on a per-ingress-egress pair basis. From the work available by now it seems relatively clear that if the core marking is to accommodate this, the decision on *when* to mark packes may be affected, and that additional flexibility in the marking at the internal node may be potentially needed. So in the very least this needs to be "kept in mind" even if the SIP (or application-related) deployment is taken out of the charter. =20 Perhaps stressing in the charter that the WG will consider the implications of the lower levels of ingress-egress aggregation on the marking mechanisms may address this issue? (2) The different options of encoding markings in packets require further investigation. This is an important component, because the deployability of PCN hinges on well-defined marking mechanisms. I'd therefore like to propose that PCN in the first phase should focus its energies on working on the problem statement, deployment model and marking mechanisms only.=20 With respect to your discussion with Ken on the problem statement draft, I do not see any problem with combining it with the architecture document. A large portion of the work has been already done in this in the various individual drafts, so this particular deliverable does not appear to be terribly limiting to me either way. Work on the actual admission and preemption mechanisms should kick off only after these initial work items are stable. I interpret he above to mean that you propose to work on the encoding and the actual marking decisions at the internal PCN router (as well as one deployment model and prob statement), but that the edge behavior should come later (after re-chartering). Is that a correct interpretation? I worry about taking the consideration of edge behaviors out of the charter. The primary cause of this worry is that edge behaviors depend on the meaning of the marking. For example, if the marking is "red-like" (e.g. virtual-queue based) its meaning is quite different than if the marking is excess-rate based (e.g. token-bucket based", and the appropriate edge behavior, to do "the right thing", needs to reflect the meaning of the marking. I just cannot see how you can completely divorce one from the other meaningfully. =20 Also, in any further evaluation of performance issues needs to be done, such work must necessarily assume some edge behavior. My understanding from the BOF was that further evaluation work was desirable (e.g. for larger scale networks). Such evaluation would not be possible unless at least some constraints on the edge behavior are specified. =20 Another point is that if the first phase of the work does only the marking behavior, and does not get re-chartered, than the product of the WG might not result in a standard that allows interoperability (as different edge devices may do things incompatible with the meaning of the marking and/or with each other). So I would argue against taking the consideration of edge behaviors out of the charter, even in the first phase. Comments? Thanks, Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 16:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWxG-000447-QQ; Wed, 29 Nov 2006 16:26:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWxF-00040F-Fk for pcn@ietf.org; Wed, 29 Nov 2006 16:26:57 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWxE-0007xt-59 for pcn@ietf.org; Wed, 29 Nov 2006 16:26:57 -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 kATLQr604739; Wed, 29 Nov 2006 16:26:53 -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 updated charter Date: Wed, 29 Nov 2006 16:26:48 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D722D83@zcarhxm1.corp.nortel.com> In-Reply-To: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccTXJ2nWpguh908S1u2Wyywz2COFQAl4Qbw From: "Jozef Babiarz" To: "Lars Eggert" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Lars,=20 On the deployment models, I believe that it is important for the pre-congestion mechanism to be tested against more than one deployment scenario or technology. ITEF needs to generate protocols that are generic and have wide applicability. My understanding from the BOF was that SIP-controlled admission and preemption model needs to be made more generic with SIP as an example. For admission control and preemption to work properly there needs to be information passed to the application as it needs to know when it can start to sending packets (session setup successful) or when it must stop (session needs to be terminated). I do not believe much coordination is required between PCN WG and any of the WGs that are currently working on signaling related protocols. My view is that once the PCN WG has agreed on the pre-congestion marking mechanism, than any needed changes to signaling protocols, RSVP, SIP meaning SDP extensions, etc. would be submitted as a draft to the appropriated WG.=20 I support that the application-control admission control deployment model to be in the PCN WG charter.=20 =20 Regards, Joe Telephone: 613-763-6098=20 Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 Sent: Tuesday, November 28, 2006 9:17 PM To: pcn@ietf.org Subject: Re: [PCN] PCN updated charter Hi, I think feedback on PCN in San Diego was overall mostly positive, and =20 a large reason was that the BOF was really well prepared and chaired. =20 Nice job! However, some discussions in and after San Diego brought up valid =20 points that a revised charter should reflect. Let me briefly outline =20 them below, so we can start discussing them here: (1) Both the SIP- and PWE3-related deployment models have been =20 questioned by the respective communities, and will require non-=20 trivial coordination to align with the existing work in those areas. =20 I'd therefore like to propose to exclude them from the initial scope =20 of PCN at this time, and limit PCN to the "IntServ over DiffServ" =20 case at this time. (2) The different options of encoding markings in packets require =20 further investigation. This is an important component, because the =20 deployability of PCN hinges on well-defined marking mechanisms. I'd =20 therefore like to propose that PCN in the first phase should focus =20 its energies on working on the problem statement, deployment model =20 and marking mechanisms only. Work on the actual admission and =20 preemption mechanisms should kick off only after these initial work =20 items are stable. Comments? Thanks, Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 16:44:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXE7-0008Rh-NR; Wed, 29 Nov 2006 16:44:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXE6-0008KR-0J for pcn@ietf.org; Wed, 29 Nov 2006 16:44:22 -0500 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXE3-0001sB-KS for pcn@ietf.org; Wed, 29 Nov 2006 16:44:21 -0500 Received: (qmail 10335 invoked by uid 0); 29 Nov 2006 21:41:52 -0000 Received: by simscan 1.2.0 ppid: 10136, pid: 10319, t: 0.5879s scanners: clamav: 0.88.4/m:40/d:1991 spam: 3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on hiltonsmtp.worldspice.net X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_95 autolearn=disabled version=3.1.7 Received: from unknown (HELO lars.local) (nec-smtp@67.99.198.2) by hiltonsmtp.worldspice.net with ESMTPA; 29 Nov 2006 21:41:51 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 3640529BD50 for ; Wed, 29 Nov 2006 13:44:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Message-Id: <3D6DAA6C-2AD4-4708-8D43-853A8F0B3AA3@netlab.nec.de> From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 13:44:10 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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="===============0142507134==" Errors-To: pcn-bounces@ietf.org --===============0142507134== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-23--301626512; protocol="application/pkcs7-signature" --Apple-Mail-23--301626512 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > Perhaps stressing in the charter that the WG will consider the > implications of the lower levels of ingress-egress aggregation on the > marking mechanisms may address this issue? Maybe. I think I need to digest this issue a bit more. > With respect to your discussion with Ken on the problem statement > draft, > I do not see any problem with combining it with the architecture > document. A large portion of the work has been already done in > this in > the various individual drafts, so this particular deliverable does not > appear to be terribly limiting to me either way. Right. The existing documents may have much of the required material already. Whether there will be one vs. a number of documents that convey this content is mostly a matter of presentation. > I interpret he above to mean that you propose to work on the encoding > and the actual marking decisions at the internal PCN router (as > well as > one deployment model and prob statement), but that the edge behavior > should come later (after re-chartering). Is that a correct > interpretation? Right. > I worry about taking the consideration of edge behaviors out of the > charter. > The primary cause of this worry is that edge behaviors depend on the > meaning of the marking. For example, if the marking is "red- > like" (e.g. > virtual-queue based) its meaning is quite different than if the > marking > is excess-rate based (e.g. token-bucket based", and the appropriate > edge > behavior, to do "the right thing", needs to reflect the meaning of > the > marking. I just cannot see how you can completely divorce one from > the > other meaningfully. I agree that the meaning of the markings is important for the edge algorithm and that the two are difficult to separate. But that wasn't my point. Without even going into the semantics of various markings, a number of issues have been brought up with regards to _encoding_ this information using the ECN bits, DSCPs, IP options, etc. This should be worked out first, because the encoding choices may limit what marking semantics can be defined later, which in turn affects what edge behaviors are possible. > Another point is that if the first phase of the work does only the > marking behavior, and does not get re-chartered, than the product > of the > WG might not result in a standard that allows interoperability (as > different edge devices may do things incompatible with the meaning of > the marking and/or with each other). If this first phase of work completes successfully, I fully expect a rechartering to occur, and the initial charter should probably contain an explicit rechartering milestone together with a brief paragraph about what the goal of the rechartering should be. If for some reason the WG runs aground in the first phase or decides not to recharter, yes, the set of RFCs it has produced won't be terribly useful. Frankly, that isn't the worst possible outcome in such a case. (But I don't think there is a real danger of this here.) > So I would argue against taking the consideration of edge behaviors > out > of the charter, even in the first phase. Lars --Apple-Mail-23--301626512 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI5 MjE0NDExWjAjBgkqhkiG9w0BCQQxFgQU3xondGhWor8OQmiAohwYIi2X8xwwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAIf/mbr+tQ3EW+kDbS8F qzEu5YRuMVjOXtaC3Hsw2Fiagfwh2foU6kmtFEQkU5dBjQzOxmZYhsNXy695qjNCSIwhjijS2zrC 1I5jWQLGrdWCpdTRZjFokSfQnIjGnVGK6UuT/e2OacwYLX+3H6iFSWaeLT22bbIlFzp+nFuJRe04 tl9cVXRnkmvV01YuICMvKIgPxDcCJq9kfhidTWKaV7nUqpmXXwk1rWaHBeSWIVoMLSzdjEWbG0Pv gkq+ugKJCbLIBA0h0tph06Rd0FgY9L5kbIjQfDW5L7ND/s5ghUZRj1Nr1TBhMXvCodporujWE+eL cAEd0LARL+LIU/BUYzEAAAAAAAA= --Apple-Mail-23--301626512-- --===============0142507134== 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 --===============0142507134==-- From pcn-bounces@ietf.org Wed Nov 29 16:46:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXGJ-00015Y-KL; Wed, 29 Nov 2006 16:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXGI-00015R-6J for pcn@ietf.org; Wed, 29 Nov 2006 16:46:38 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXGH-00023M-11 for pcn@ietf.org; Wed, 29 Nov 2006 16:46:38 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 458F8D60C6; Wed, 29 Nov 2006 16:46:35 -0500 (EST) To: lars.eggert@netlab.nec.de, pcn@ietf.org Subject: Re: [PCN] PCN updated charter In-Reply-To: <3D6DAA6C-2AD4-4708-8D43-853A8F0B3AA3@netlab.nec.de> Message-Id: <20061129214635.458F8D60C6@newdev.harvard.edu> Date: Wed, 29 Nov 2006 16:46:35 -0500 (EST) From: sob@harvard.edu (Scott O Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 initial charter should probably > contain an explicit rechartering milestone together with a brief > paragraph about what the goal of the rechartering should be. makes sense to me Scott _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 17:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXv2-0008HM-Ui; Wed, 29 Nov 2006 17:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXv2-0008Do-5x for pcn@ietf.org; Wed, 29 Nov 2006 17:28:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXuz-0007Qv-Qk for pcn@ietf.org; Wed, 29 Nov 2006 17:28:44 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 14:28:41 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kATMSehn007217; Wed, 29 Nov 2006 17:28:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kATMSeYJ001777; Wed, 29 Nov 2006 17:28:40 -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); Wed, 29 Nov 2006 17:28:40 -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 updated charter Date: Wed, 29 Nov 2006 17:28:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/5XSHzhef1jDR06ieEzd2XS6RgAAp2SA From: "Anna Charny \(acharny\)" To: "Lars Eggert" , X-OriginalArrivalTime: 29 Nov 2006 22:28:40.0130 (UTC) FILETIME=[B8363220:01C71405] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3283; t=1164839320; x=1165703320; 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]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Lars=20Eggert=22=20, =20; bh=7X4ZN1DM/fly13hjU4h/iryfxbI3gB7quh8+cdAi3Mk=; b=S6HLvIyBRV+sWY7lA/8Y7iq29aakvjUxZ5x0WrnNchgOXaZABaHei94BpY5n6FOktcU6pI2l xheWx2CkK3FW168CJrkTA82vtaO8pEoeyWmQ2sjh+tGC1WZMPOOT0Cok; 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: 31247fb3be228bb596db9127becad0bc 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 Lars, More below...=20 >> I interpret he above to mean that you propose to work on the encoding >> and the actual marking decisions at the internal PCN router (as well=20 >> as one deployment model and prob statement), but that the edge=20 >> behavior should come later (after re-chartering). Is that a correct=20 >> interpretation? >Right. >> I worry about taking the consideration of edge behaviors out of the=20 >> charter. >> The primary cause of this worry is that edge behaviors depend on the >> meaning of the marking. For example, if the marking is "red- like"=20 >> (e.g. >> virtual-queue based) its meaning is quite different than if the=20 >> marking is excess-rate based (e.g. token-bucket based", and the=20 >> appropriate edge behavior, to do "the right thing", needs to reflect >> the meaning of the marking. I just cannot see how you can completely >>divorce one from the other meaningfully. >I agree that the meaning of the markings is important for the edge algorithm and that=20 >the two are difficult to separate. >But that wasn't my point. Without even going into the semantics of various markings, a=20 >number of issues have been brought up with regards to _encoding_ this information using=20 >the ECN bits, DSCPs, IP options, etc. This should be worked out first, because the >encoding choices may limit what marking semantics can be defined later, which in turn >affects what edge behaviors are possible. So just to make sure we are on the same page: I think the above means that=20 A) you propose to first deal with the encoding=20 B) you agree that marking semantics (and hence any standardization of the marking *mechanisms* (e.g. when to mark)) must be looked at together C) you propose to not deal with edge behaviours until recahrtering If that is correct, then this implies that we will NOT discuss the marking semantics/mechanisms (beyond encoding) before rechartering at all. That would mean, I think the following 1) limit the current charter to:=20 * problem/arcitecture draft * encoding=20 * Intserv over DiffServ deployment model * include a rechartering milestone with specific work items (see below) 2) move to after the *after-rechartering* * marking behavior at the interior node * edge behavior * other deployment models * other stuff currently listed in the proposed charter, which includes: ->a generic analysis of the signaling extensions required to support PCN. ->at least one example solution implementing the framework and its performance evaluation (e.g. simulation results), to provide evidence of the viability of the proposed standard in the proposed deployment models -> an applicability statement=20 -> an analysis of the manageability issues of a PCN region * other stuff initially planned to be dealt with after rechartering (e.g. other trust models, multiple PCN domains, etc) I guess this is possible in principle, but doesn't it seems to be a bit light on the near-term deliverables before the rechartering, and overly heavy on the after-rechartering phase? =20 =20 Anna=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 17:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY1G-0005qX-F0; Wed, 29 Nov 2006 17:35:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpY1F-0005qS-CM for pcn@ietf.org; Wed, 29 Nov 2006 17:35:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpY1E-00087b-0B for pcn@ietf.org; Wed, 29 Nov 2006 17:35:09 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 14:35:07 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kATMZ7N1004261; Wed, 29 Nov 2006 14:35:07 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kATMYbdq022490; Wed, 29 Nov 2006 14:35:07 -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); Wed, 29 Nov 2006 17:35:02 -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: FW: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 17:35:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/5XSHzhef1jDR06ieEzd2XS6RgAAp2SAAAD2IrA= From: "Anna Charny \(acharny\)" To: "Lars Eggert" , X-OriginalArrivalTime: 29 Nov 2006 22:35:02.0617 (UTC) FILETIME=[9C311490:01C71406] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3516; t=1164839707; x=1165703707; c=relaxed/relaxed; s=sjdkim8002; 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:=20FW=3A=20[PCN]=20PCN=20=20updated=20charter |Sender:=20; bh=5au46umanqiGOjxMi7VI8h8MQCsIv/dwvuVyEh3LF3w=; b=PFXl+xAFAP4awFRbup+nkrHXsvhvL5Dkg9sw6iA3zCrRrgFTAUoGNj2D4X9QzEODFXGRO9Cb qXvnq4AL7hQ0WYO79bjPX7oRhfFNFd+qexxiMh1ePJisZb82E0bbGZMl; Authentication-Results: sj-dkim-8; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Noticed that I left asentence unfinished - resending with the part missed in the first email highlighted. Here it is (already corrected) below.... Sorry -----Original Message----- From: Anna Charny (acharny)=20 Sent: Wednesday, November 29, 2006 5:29 PM To: 'Lars Eggert'; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Lars, More below...=20 >> I interpret he above to mean that you propose to work on the encoding >> and the actual marking decisions at the internal PCN router (as well=20 >> as one deployment model and prob statement), but that the edge=20 >> behavior should come later (after re-chartering). Is that a correct=20 >> interpretation? >Right. >> I worry about taking the consideration of edge behaviors out of the =20 >>charter. >> The primary cause of this worry is that edge behaviors depend on the >>meaning of the marking. For example, if the marking is "red- like" >> (e.g. >> virtual-queue based) its meaning is quite different than if the =20 >>marking is excess-rate based (e.g. token-bucket based", and the =20 >>appropriate edge behavior, to do "the right thing", needs to reflect >>the meaning of the marking. I just cannot see how you can completely=20 >>divorce one from the other meaningfully. >I agree that the meaning of the markings is important for the edge=20 >algorithm and that the two are difficult to separate. >But that wasn't my point. Without even going into the semantics of=20 >various markings, a number of issues have been brought up with regards=20 >to _encoding_ this information using the ECN bits, DSCPs, IP options,=20 >etc. This should be worked out first, because the encoding choices may=20 >limit what marking semantics can be defined later, which in turn affects what edge behaviors are possible. So just to make sure we are on the same page: I think the above means that=20 A) you propose to first deal with the encoding B) you agree that marking semantics (and hence any standardization of the marking *mechanisms* (e.g. when to mark)) must be looked at together *with the edge mechanisms* C) you propose to not deal with edge behaviours until recahrtering If that is correct, then this implies that we will NOT discuss the marking semantics/mechanisms (beyond encoding) before rechartering at all. That would mean, I think the following 1) limit the current charter to:=20 * problem/arcitecture draft * encoding=20 * Intserv over DiffServ deployment model * include a rechartering milestone with specific work items (see below) 2) move to after the *after-rechartering* * marking behavior at the interior node * edge behavior * other deployment models * other stuff currently listed in the proposed charter, which includes: ->a generic analysis of the signaling extensions required to support PCN. ->at least one example solution implementing the framework and its performance evaluation (e.g. simulation results), to provide evidence of the viability of the proposed standard in the proposed deployment models -> an applicability statement=20 -> an analysis of the manageability issues of a PCN region * other stuff initially planned to be dealt with after rechartering (e.g. other trust models, multiple PCN domains, etc) I guess this is possible in principle, but doesn't it seems to be a bit light on the near-term deliverables before the rechartering, and overly heavy on the after-rechartering phase? =20 =20 Anna=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 29 19:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpZmM-0001EH-E5; Wed, 29 Nov 2006 19:27:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpZmL-0001EA-Ae for pcn@ietf.org; Wed, 29 Nov 2006 19:27:53 -0500 Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpZmK-0001M7-00 for pcn@ietf.org; Wed, 29 Nov 2006 19:27:53 -0500 Received: from [64.169.29.211] (unverified [64.169.29.211]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 4.2.425.4) with ESMTP id for ; Wed, 29 Nov 2006 19:04:23 -0500 X-Modus-BlackList: 64.169.29.211=OK;lars.eggert@netlab.nec.de=OK X-Modus-Trusted: 64.169.29.211=NO Received: from lars.local ([142.131.240.248]) by [64.169.29.211] (8.13.6/8.13.6) with ESMTP id kAU0RVZ7016582 for ; Wed, 29 Nov 2006 16:27:32 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id B492529BD9D for ; Wed, 29 Nov 2006 16:27:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Message-Id: <1CF3D146-D4B0-45AD-8BAD-74B6A8C3A498@netlab.nec.de> From: Lars Eggert Subject: Re: [PCN] PCN updated charter Date: Wed, 29 Nov 2006 16:27:28 -0800 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sc1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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="===============1769315350==" Errors-To: pcn-bounces@ietf.org --===============1769315350== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-27--291828416; protocol="application/pkcs7-signature" --Apple-Mail-27--291828416 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 29, 2006, at 14:28, Anna Charny (acharny) wrote: > So just to make sure we are on the same page: > I think the above means that > > A) you propose to first deal with the encoding > B) you agree that marking semantics (and hence any standardization of > the marking *mechanisms* (e.g. when to mark)) must be looked at > together > C) you propose to not deal with edge behaviours until recahrtering > > If that is correct, then this implies that we will NOT discuss the > marking semantics/mechanisms (beyond encoding) before rechartering at > all. That would mean, I think the following > > 1) limit the current charter to: > * problem/arcitecture draft > * encoding > * Intserv over DiffServ deployment model > * include a rechartering milestone with specific work items > (see > below) Exactly. > 2) move to after the *after-rechartering* > * marking behavior at the interior node > * edge behavior > * other deployment models > * other stuff currently listed in the proposed charter, which > includes: > ->a generic analysis of the signaling extensions > required to > support PCN. > ->at least one example solution implementing the framework > and its performance evaluation (e.g. simulation results), to provide > evidence of the viability of the proposed standard in the proposed > deployment models > -> an applicability statement > -> an analysis of the manageability issues of a PCN region > * other stuff initially planned to be dealt with after > rechartering > (e.g. other trust models, multiple PCN domains, etc) I'd probably like to move some of this into a third charter phase, such as the "other deployment models" and maybe some of the "other stuff". But at least the marking behavior and edge behavior should come after the first recharter. > I guess this is possible in principle, but doesn't it seems to be a > bit > light on the near-term deliverables before the rechartering, and > overly > heavy on the after-rechartering phase? It is. We're trying to charter new work with more restrictive initial scopes and have more frequent recharter points than WGs with "old" charters. The idea is that this will focus the energy of the group on fewer current work items and hopefully aid overall progress. Minor recharters such as the ones I proposed for PCN tend to go through the IESG relatively quickly these days. Lars --Apple-Mail-27--291828416 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTMw MDAyNzI5WjAjBgkqhkiG9w0BCQQxFgQUtLAfaJEhBzstaf0qutxbKbl8qCEwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAAZwoyarGrxlBkRdLuXm JzHjypqx6Hr7RdB4H4kv7/4gt+dWjBQ2GwE+mdwm2lBxs94O/Zcvh5mknrVTPIWOJZ48z8z8wkod bqCfdDriL2h3m/9bcJGQU/RGenGLdUs23YQ3g4YDurxQf5l1TyMgnsQ2nXJf3cAn1ls/+vBNdXWL j59wBwga6EFnRCgo/kvZx/RpgkfQzO7nabHWJKUctfzoR0NVc/8w2T+9+mqBEBf8tL+YWQK533hM X+GfZJ8n8WZCg0zPDIuOKkzITc8B+U2RWvPpVe5j1bWFlays1Xs+NWA9DR4dUFf8CDgfDvOs33Jn QF9pfK0rcPBPhvlEzR8AAAAAAAA= --Apple-Mail-27--291828416-- --===============1769315350== 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 --===============1769315350==-- From pcn-bounces@ietf.org Thu Nov 30 04:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpiJ0-0008OD-Nd; Thu, 30 Nov 2006 04:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpiIz-0008Nz-JN for pcn@ietf.org; Thu, 30 Nov 2006 04:34:09 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpiIt-0004bO-0I for pcn@ietf.org; Thu, 30 Nov 2006 04:34:09 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 09:34:02 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Nov 2006 09:34: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 updated charter Date: Thu, 30 Nov 2006 09:34:00 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CEC9@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccTXJnDuyW/hYfjS8i1vizw0sHy1gAnOxzAABnreOA= From: To: , , X-OriginalArrivalTime: 30 Nov 2006 09:34:01.0412 (UTC) FILETIME=[AB266840:01C71462] X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 In-line below phil -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: 29 November 2006 21:19 To: Lars Eggert; pcn@ietf.org Subject: RE: [PCN] PCN updated charter Hi Lars, Please see below (marked Anna): Anna=20 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] Sent: Tuesday, November 28, 2006 9:17 PM To: pcn@ietf.org Subject: Re: [PCN] PCN updated charter Hi, I think feedback on PCN in San Diego was overall mostly positive, and a large reason was that the BOF was really well prepared and chaired. =20 Nice job! However, some discussions in and after San Diego brought up valid points that a revised charter should reflect. Let me briefly outline them below, so we can start discussing them here: (1) Both the SIP- and PWE3-related deployment models have been questioned by the respective communities, and will require non- trivial coordination to align with the existing work in those areas. =20 I'd therefore like to propose to exclude them from the initial scope of PCN at this time, and limit PCN to the "IntServ over DiffServ" =20 case at this time. Anna begin> PWE3-related deployment model has already been taken out of the updated charter, based on the BOF input. =20 As to SIP-related one - there is one aspect of it that actually potentially affects the marking at the ingress node, namely the aggregation assumptions, and especially aggregation level on a per-ingress-egress aggregate. This specific model is likely to assume both lower levels of aggregation on the PCN internal links, but especially on a per-ingress-egress pair basis. From the work available by now it seems relatively clear that if the core marking is to accommodate this, the decision on *when* to mark packes may be affected, and that additional flexibility in the marking at the internal node may be potentially needed. So in the very least this needs to be "kept in mind" even if the SIP (or application-related) deployment is taken out of the charter. =20 Perhaps stressing in the charter that the WG will consider the implications of the lower levels of ingress-egress aggregation on the marking mechanisms may address this issue? [phil start]=20 either like this or as a separate deployment model would work for me. I think the most important thing is the impact on the aggregation assumption, as anna mentions [phil end] (2) The different options of encoding markings in packets require further investigation. This is an important component, because the deployability of PCN hinges on well-defined marking mechanisms. I'd therefore like to propose that PCN in the first phase should focus its energies on working on the problem statement, deployment model and marking mechanisms only.=20 With respect to your discussion with Ken on the problem statement draft, I do not see any problem with combining it with the architecture document. A large portion of the work has been already done in this in the various individual drafts, so this particular deliverable does not appear to be terribly limiting to me either way. [phil start] problem statement/arch doc is fine with me. The main reason for writing the problem statement I-D was to help get the draft charter & BoF better. The most useful content/format is probably best judged by someone who's been less involved than me.=20 [phil end] Work on the actual admission and preemption mechanisms should kick off only after these initial work items are stable. I interpret he above to mean that you propose to work on the encoding and the actual marking decisions at the internal PCN router (as well as one deployment model and prob statement), but that the edge behavior should come later (after re-chartering). Is that a correct interpretation? I worry about taking the consideration of edge behaviors out of the charter. The primary cause of this worry is that edge behaviors depend on the meaning of the marking. For example, if the marking is "red-like" (e.g. virtual-queue based) its meaning is quite different than if the marking is excess-rate based (e.g. token-bucket based", and the appropriate edge behavior, to do "the right thing", needs to reflect the meaning of the marking. I just cannot see how you can completely divorce one from the other meaningfully. =20 Also, in any further evaluation of performance issues needs to be done, such work must necessarily assume some edge behavior. My understanding from the BOF was that further evaluation work was desirable (e.g. for larger scale networks). Such evaluation would not be possible unless at least some constraints on the edge behavior are specified. =20 Another point is that if the first phase of the work does only the marking behavior, and does not get re-chartered, than the product of the WG might not result in a standard that allows interoperability (as different edge devices may do things incompatible with the meaning of the marking and/or with each other). So I would argue against taking the consideration of edge behaviors out of the charter, even in the first phase. Comments? Thanks, 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 Nov 30 04:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpiVZ-00069y-NF; Thu, 30 Nov 2006 04:47:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpiVY-00069t-5m for pcn@ietf.org; Thu, 30 Nov 2006 04:47:08 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpiVS-00060F-O0 for pcn@ietf.org; Thu, 30 Nov 2006 04:47:08 -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, 30 Nov 2006 09:47:00 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Nov 2006 09:46:58 +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 updated charter Date: Thu, 30 Nov 2006 09:46:58 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CECA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <3D6DAA6C-2AD4-4708-8D43-853A8F0B3AA3@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQ From: To: , X-OriginalArrivalTime: 30 Nov 2006 09:46:58.0886 (UTC) FILETIME=[7A8F8660:01C71464] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 >>This [=3D the encoding choice] should be worked out first, because the encoding choices may limit what marking semantics can be defined later, which in turn affects what edge behaviors are possible. >> I'm not sure the encoding choices do limit the marking semantics that much. I think the main impact of the encoding choice is on non-PCN things like compatibility with RFC3168 & DSCP usage.=20 phil -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 Sent: 29 November 2006 21:44 To: pcn@ietf.org Subject: Re: [PCN] PCN updated charter On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > Perhaps stressing in the charter that the WG will consider the > implications of the lower levels of ingress-egress aggregation on the > marking mechanisms may address this issue? Maybe. I think I need to digest this issue a bit more. > With respect to your discussion with Ken on the problem statement =20 > draft, > I do not see any problem with combining it with the architecture > document. A large portion of the work has been already done in =20 > this in > the various individual drafts, so this particular deliverable does not > appear to be terribly limiting to me either way. Right. The existing documents may have much of the required material =20 already. Whether there will be one vs. a number of documents that =20 convey this content is mostly a matter of presentation. > I interpret he above to mean that you propose to work on the encoding > and the actual marking decisions at the internal PCN router (as =20 > well as > one deployment model and prob statement), but that the edge behavior > should come later (after re-chartering). Is that a correct > interpretation? Right. > I worry about taking the consideration of edge behaviors out of the > charter. > The primary cause of this worry is that edge behaviors depend on the > meaning of the marking. For example, if the marking is "red-=20 > like" (e.g. > virtual-queue based) its meaning is quite different than if the =20 > marking > is excess-rate based (e.g. token-bucket based", and the appropriate =20 > edge > behavior, to do "the right thing", needs to reflect the meaning of =20 > the > marking. I just cannot see how you can completely divorce one from =20 > the > other meaningfully. I agree that the meaning of the markings is important for the edge =20 algorithm and that the two are difficult to separate. But that wasn't my point. Without even going into the semantics of =20 various markings, a number of issues have been brought up with =20 regards to _encoding_ this information using the ECN bits, DSCPs, IP =20 options, etc. This should be worked out first, because the encoding =20 choices may limit what marking semantics can be defined later, which =20 in turn affects what edge behaviors are possible. > Another point is that if the first phase of the work does only the > marking behavior, and does not get re-chartered, than the product =20 > of the > WG might not result in a standard that allows interoperability (as > different edge devices may do things incompatible with the meaning of > the marking and/or with each other). If this first phase of work completes successfully, I fully expect a =20 rechartering to occur, and the initial charter should probably =20 contain an explicit rechartering milestone together with a brief =20 paragraph about what the goal of the rechartering should be. If for some reason the WG runs aground in the first phase or decides =20 not to recharter, yes, the set of RFCs it has produced won't be =20 terribly useful. Frankly, that isn't the worst possible outcome in =20 such a case. (But I don't think there is a real danger of this here.) > So I would argue against taking the consideration of edge behaviors =20 > out > of the charter, even in the first phase. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 30 08:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpllY-0004D3-CT; Thu, 30 Nov 2006 08:15:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpgAy-00056y-Un for pcn@ietf.org; Thu, 30 Nov 2006 02:17:44 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpgAs-00088s-GD for pcn@ietf.org; Thu, 30 Nov 2006 02:17:44 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8168E4F0002; Thu, 30 Nov 2006 08:17:31 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 08:17:31 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 08:17:31 +0100 Message-ID: <456E858A.5080707@ericsson.com> Date: Thu, 30 Nov 2006 08:17:30 +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] PCN updated charter References: <008701c713d7$8b18c060$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2006 07:17:31.0110 (UTC) FILETIME=[99598060:01C7144F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Thu, 30 Nov 2006 08:15:51 -0500 Cc: pcn@ietf.org, =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= 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 commenst inline Lars Eggert wrote: > Hi, > > On Nov 29, 2006, at 8:58, Georgios Karagiannis wrote: > >> During the PCN BOF, concerns have been expressed on >> the "SIP based deployment model", but several opinions >> were in favour of including in the PCN charter >> instead of the "SIP based deployment model" an >> "Application based deployment model". >> Thus the (b) deployment model has to be redefined and >> presented as the "Application based deployment model", >> where SIP could be seen as an example. > > > I fail to see how broadening this deployment model from "SIP only" to > "arbitrary applications, SIP one example" is making it easier to make > progress. The general problem will be harder to solve, and with SIP > as an example the SIP details still would need to be gotten right. I have the opposite problem. By limitating the deoplyment model, the applicabillity will be so narrow so the the working group may not consider deployment scenarios that are more general applicable that just a single one. A deployment scenarion that assume that the whole world will use RSVP-signalling seems for me very strange. We have plenty of operator discussions and I haven't seen anyone that have been committed to use RSVP as it is proposed into that deployment scenario. The assumption that the admission control should be implemented in a router is for me very strange. This may be of interest for som persons but not as a general way of solving a problem for the infrastructure. therefore a flexibillity of putting the admission contrl function outside the routed infrastructure should also be considered. Was this actually aggreed on the BOF ? > > >> Please note that also the RU-PDB concept (presented >> during the tsvwg meeting) could be seen as an >> "Application based deployment model". >> Please see some discussion on the tsvwg mailing >> list on this (that took place during the IETF meeting >> in San Diego). > > > Lars > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 30 08:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpmKr-0007Ri-Gb; Thu, 30 Nov 2006 08:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpmKp-0007Pf-Nk for pcn@ietf.org; Thu, 30 Nov 2006 08:52:19 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpmKk-0008SA-8o for pcn@ietf.org; Thu, 30 Nov 2006 08:52:19 -0500 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 13:52:08 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Nov 2006 13:52:06 +0000 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] PCN updated charter Date: Thu, 30 Nov 2006 13:52:05 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CED6@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <456E858A.5080707@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccUgbxpzaDEi4NaSFGwvxlIZWY1VgABI0XQ From: To: , X-OriginalArrivalTime: 30 Nov 2006 13:52:06.0923 (UTC) FILETIME=[B93BDDB0:01C71486] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: pcn@ietf.org, attila.bader@ericsson.com 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 don't think the RSVP /signalling aspects of the deployment model are = the important bits - what matters is the impact on the assumptions/goals = as they affect PCN.=20 phil -----Original Message----- From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: 30 November 2006 07:18 To: Lars Eggert Cc: pcn@ietf.org; "Attila B=E1der (IJ/ETH)" Subject: Re: [PCN] PCN updated charter commenst inline Lars Eggert wrote: > Hi, > > On Nov 29, 2006, at 8:58, Georgios Karagiannis wrote: > >> During the PCN BOF, concerns have been expressed on >> the "SIP based deployment model", but several opinions >> were in favour of including in the PCN charter >> instead of the "SIP based deployment model" an >> "Application based deployment model". >> Thus the (b) deployment model has to be redefined and >> presented as the "Application based deployment model", >> where SIP could be seen as an example. > > > I fail to see how broadening this deployment model from "SIP only" to = > "arbitrary applications, SIP one example" is making it easier to make = > progress. The general problem will be harder to solve, and with SIP =20 > as an example the SIP details still would need to be gotten right.=20 I have the opposite problem. By limitating the deoplyment model, the=20 applicabillity will be so narrow so the the working group may not=20 consider deployment scenarios that are more general applicable that just = a single one. A deployment scenarion that assume that the whole world will use=20 RSVP-signalling seems for me very strange. We have plenty of operator=20 discussions and I haven't seen anyone that have been committed to use=20 RSVP as it is proposed into that deployment scenario. The assumption that the admission control should be implemented in a=20 router is for me very strange. This may be of interest for som persons=20 but not as a general way of solving a problem for the infrastructure.=20 therefore a flexibillity of putting the admission contrl function=20 outside the routed infrastructure should also be considered. Was this actually aggreed on the BOF ? > > >> Please note that also the RU-PDB concept (presented >> during the tsvwg meeting) could be seen as an >> "Application based deployment model". >> Please see some discussion on the tsvwg mailing >> list on this (that took place during the IETF meeting >> in San Diego). > > > 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 Nov 30 09:42:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn6w-000774-I0; Thu, 30 Nov 2006 09:42:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn6w-00076z-2h for pcn@ietf.org; Thu, 30 Nov 2006 09:42:02 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpn6u-0007HQ-Kf for pcn@ietf.org; Thu, 30 Nov 2006 09:42:02 -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 kAUEfoTr021871; Thu, 30 Nov 2006 15:41:58 +0100 (MET) From: "Georgios Karagiannis" To: , , Subject: RE: [PCN] PCN updated charter Date: Thu, 30 Nov 2006 15:41:45 +0100 Message-ID: <003b01c7148d$ae4c78e0$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.2962 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CED6@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AccUgbxpzaDEi4NaSFGwvxlIZWY1VgABI0XQAAFyPiA= X-Spam-Score: 0.116 () 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]); Thu, 30 Nov 2006 15:41:58 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: pcn@ietf.org, attila.bader@ericsson.com X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil It is important to note that when only one=20 deployment model is used then the assumptions/goals=20 that affect the PCN activities will be=20 too limited. Meaning that we might find other PCN=20 solutions when we consider two deployment models=20 instead of one. Best Regards, Georgios =20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: donderdag 30 november 2006 14:52 > To: Lars.westberg@ericsson.com; lars.eggert@netlab.nec.de > Cc: pcn@ietf.org; attila.bader@ericsson.com > Subject: RE: [PCN] PCN updated charter >=20 > I don't think the RSVP /signalling aspects of the deployment=20 > model are the important bits - what matters is the impact on=20 > the assumptions/goals as they affect PCN.=20 > phil >=20 > -----Original Message----- > From: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: 30 November 2006 07:18 > To: Lars Eggert > Cc: pcn@ietf.org; "Attila B=E1der (IJ/ETH)" > Subject: Re: [PCN] PCN updated charter >=20 > commenst inline >=20 > Lars Eggert wrote: >=20 > > Hi, > > > > On Nov 29, 2006, at 8:58, Georgios Karagiannis wrote: > > > >> During the PCN BOF, concerns have been expressed on the "SIP based=20 > >> deployment model", but several opinions were in favour of=20 > including=20 > >> in the PCN charter instead of the "SIP based deployment model" an=20 > >> "Application based deployment model". > >> Thus the (b) deployment model has to be redefined and presented as=20 > >> the "Application based deployment model", where SIP could=20 > be seen as=20 > >> an example. > > > > > > I fail to see how broadening this deployment model from=20 > "SIP only" to=20 > > "arbitrary applications, SIP one example" is making it=20 > easier to make=20 > > progress. The general problem will be harder to solve, and=20 > with SIP as=20 > > an example the SIP details still would need to be gotten right. >=20 > I have the opposite problem. By limitating the deoplyment=20 > model, the applicabillity will be so narrow so the the=20 > working group may not consider deployment scenarios that are=20 > more general applicable that just a single one. >=20 > A deployment scenarion that assume that the whole world will=20 > use RSVP-signalling seems for me very strange. We have plenty=20 > of operator discussions and I haven't seen anyone that have=20 > been committed to use RSVP as it is proposed into that=20 > deployment scenario. >=20 > The assumption that the admission control should be=20 > implemented in a router is for me very strange. This may be=20 > of interest for som persons but not as a general way of=20 > solving a problem for the infrastructure.=20 > therefore a flexibillity of putting the admission contrl=20 > function outside the routed infrastructure should also be considered. >=20 > Was this actually aggreed on the BOF ? >=20 >=20 > > > > > >> Please note that also the RU-PDB concept (presented during=20 > the tsvwg=20 > >> meeting) could be seen as an "Application based deployment model". > >> Please see some discussion on the tsvwg mailing list on this (that=20 > >> took place during the IETF meeting in San Diego). > > > > > > Lars > > >=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 Thu Nov 30 11:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GposQ-0006Ss-Q6; Thu, 30 Nov 2006 11:35:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GposO-0006MT-Py for pcn@ietf.org; Thu, 30 Nov 2006 11:35:08 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GposN-0004LD-EJ for pcn@ietf.org; Thu, 30 Nov 2006 11:35:08 -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 kAUGYwT16607; Thu, 30 Nov 2006 11:34:59 -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, 30 Nov 2006 11:34:53 -0500 Message-Id: <6.2.5.6.0.20061130111407.05752a10@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Nov 2006 11:34:50 -0500 To: Lars Eggert From: "Kwok-Ho Chan" Subject: Re: [PCN] PCN updated charter In-Reply-To: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> References: <3A2FA085-09BF-490C-8631-5F7B7D4A801A@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Nov 2006 16:34:53.0243 (UTC) FILETIME=[766A08B0:01C7149D] X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars: Please see my comments on your (1) in-line below. With the bottom line at the top: I am proposing TO KEEP the Application/SIP Deployment Model in the charter. Thanks! -- Kwok -- At 09:17 PM 11/28/2006, Lars Eggert wrote: >Hi, > >I think feedback on PCN in San Diego was overall mostly positive, and >a large reason was that the BOF was really well prepared and chaired. >Nice job! > >However, some discussions in and after San Diego brought up valid >points that a revised charter should reflect. Let me briefly outline >them below, so we can start discussing them here: > >(1) Both the SIP- and PWE3-related deployment models have been >questioned by the respective communities, and will require non- >trivial coordination to align with the existing work in those areas. >I'd therefore like to propose to exclude them from the initial scope >of PCN at this time, and limit PCN to the "IntServ over DiffServ" >case at this time. From the Minutes of the BOF: "Dave Oran: If it requires SIP to change, we have problems, but I doubt it does. It has a dependency on SDP, which has the QoS pre-conditions." The Application/SIP/SDP Deployment Model currently does NOT indicate any changes required of SIP/SDP. Hence I agree with Dave Oran on his point of "I doubt it (the Application/SIP/SDP Deployment Model) does (requires SIP to change). It has a dependency on SDP, which has the QoS pre-conditions." With this point, the Application (SIP) usage of PCN mechanisms Deployment Model will be using the SIP/SDP QoS pre-conditions. Without changes to existing work in the (SIP, SDP) area. Hence does not see the point of "will require non-trivial coordination to align with the existing work in those areas". With this, I am proposing TO KEEP the Application/SIP Deployment Model in the charter. >(2) The different options of encoding markings in packets require >further investigation. This is an important component, because the >deployability of PCN hinges on well-defined marking mechanisms. I'd >therefore like to propose that PCN in the first phase should focus >its energies on working on the problem statement, deployment model >and marking mechanisms only. Work on the actual admission and >preemption mechanisms should kick off only after these initial work >items are stable. > >Comments? > >Thanks, >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 Nov 30 12:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppST-00038Y-9o; Thu, 30 Nov 2006 12:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppSS-00038D-Lx for pcn@ietf.org; Thu, 30 Nov 2006 12:12:24 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppSQ-0000wk-7x for pcn@ietf.org; Thu, 30 Nov 2006 12:12:24 -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 kAUHCJR17599; Thu, 30 Nov 2006 12:12:19 -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 updated charter Date: Thu, 30 Nov 2006 12:12:10 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650D7719D5@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CECA@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccT/4+UymL8PT7DTgq3/m9pfto2/AAY6jsQAA9YqQA= From: "Jozef Babiarz" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Lars wrote: "But that wasn't my point. Without even going into the semantics of various markings, a number of issues have been brought up with regards to _encoding_ this information using the ECN bits, DSCPs, IP options, etc. This should be worked out first, because the encoding choices may limit what marking semantics can be defined later, which in turn affects what edge behaviors are possible." [Joe]I think that it would be appropriate for the WG to reach agreement on what bits could be used for PCN before finalizing on the marking behavior in the routers or edge/host behavior. However, there are some dependences between, marking behavior in routers, reaction by edge nodes and the encoding. 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: Thursday, November 30, 2006 4:47 AM To: lars.eggert@netlab.nec.de; pcn@ietf.org Subject: RE: [PCN] PCN updated charter >>This [=3D the encoding choice] should be worked out first, because the encoding choices may limit what marking semantics can be defined later, which in turn affects what edge behaviors are possible. >> I'm not sure the encoding choices do limit the marking semantics that much. I think the main impact of the encoding choice is on non-PCN things like compatibility with RFC3168 & DSCP usage.=20 phil -----Original Message----- From: Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 Sent: 29 November 2006 21:44 To: pcn@ietf.org Subject: Re: [PCN] PCN updated charter On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote: > Perhaps stressing in the charter that the WG will consider the > implications of the lower levels of ingress-egress aggregation on the > marking mechanisms may address this issue? Maybe. I think I need to digest this issue a bit more. > With respect to your discussion with Ken on the problem statement =20 > draft, > I do not see any problem with combining it with the architecture > document. A large portion of the work has been already done in =20 > this in > the various individual drafts, so this particular deliverable does not > appear to be terribly limiting to me either way. Right. The existing documents may have much of the required material =20 already. Whether there will be one vs. a number of documents that =20 convey this content is mostly a matter of presentation. > I interpret he above to mean that you propose to work on the encoding > and the actual marking decisions at the internal PCN router (as =20 > well as > one deployment model and prob statement), but that the edge behavior > should come later (after re-chartering). Is that a correct > interpretation? Right. > I worry about taking the consideration of edge behaviors out of the > charter. > The primary cause of this worry is that edge behaviors depend on the > meaning of the marking. For example, if the marking is "red-=20 > like" (e.g. > virtual-queue based) its meaning is quite different than if the =20 > marking > is excess-rate based (e.g. token-bucket based", and the appropriate =20 > edge > behavior, to do "the right thing", needs to reflect the meaning of =20 > the > marking. I just cannot see how you can completely divorce one from =20 > the > other meaningfully. I agree that the meaning of the markings is important for the edge =20 algorithm and that the two are difficult to separate. But that wasn't my point. Without even going into the semantics of =20 various markings, a number of issues have been brought up with =20 regards to _encoding_ this information using the ECN bits, DSCPs, IP =20 options, etc. This should be worked out first, because the encoding =20 choices may limit what marking semantics can be defined later, which =20 in turn affects what edge behaviors are possible. > Another point is that if the first phase of the work does only the > marking behavior, and does not get re-chartered, than the product =20 > of the > WG might not result in a standard that allows interoperability (as > different edge devices may do things incompatible with the meaning of > the marking and/or with each other). If this first phase of work completes successfully, I fully expect a =20 rechartering to occur, and the initial charter should probably =20 contain an explicit rechartering milestone together with a brief =20 paragraph about what the goal of the rechartering should be. If for some reason the WG runs aground in the first phase or decides =20 not to recharter, yes, the set of RFCs it has produced won't be =20 terribly useful. Frankly, that isn't the worst possible outcome in =20 such a case. (But I don't think there is a real danger of this here.) > So I would argue against taking the consideration of edge behaviors =20 > out > of the charter, even in the first phase. 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 Nov 30 12:17:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppXk-0005We-CD; Thu, 30 Nov 2006 12:17:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppXi-0005W3-93 for pcn@ietf.org; Thu, 30 Nov 2006 12:17:50 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppXh-0001UK-QE for pcn@ietf.org; Thu, 30 Nov 2006 12:17:50 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUHHkR18730; Thu, 30 Nov 2006 12:17:46 -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, 30 Nov 2006 12:17:27 -0500 Message-Id: <6.2.5.6.0.20061130114149.03280b98@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Nov 2006 12:17:26 -0500 To: "Anna Charny \(acharny\)" From: "Kwok-Ho Chan" Subject: RE: [PCN] PCN updated charter In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Nov 2006 17:17:27.0461 (UTC) FILETIME=[68D8C550:01C714A3] X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Lars Eggert , 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 Anna, Lars, all: Please see my comments indicated by and below. Thanks! -- Kwok -- At 04:19 PM 11/29/2006, Anna Charny \(acharny\) wrote: >Hi Lars, > >Please see below (marked Anna): > >Anna > >-----Original Message----- >From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] >Sent: Tuesday, November 28, 2006 9:17 PM >To: pcn@ietf.org >Subject: Re: [PCN] PCN updated charter > >Hi, > >I think feedback on PCN in San Diego was overall mostly positive, and a >large reason was that the BOF was really well prepared and chaired. >Nice job! > >However, some discussions in and after San Diego brought up valid points >that a revised charter should reflect. Let me briefly outline them >below, so we can start discussing them here: > >(1) Both the SIP- and PWE3-related deployment models have been >questioned by the respective communities, and will require non- trivial >coordination to align with the existing work in those areas. >I'd therefore like to propose to exclude them from the initial scope of >PCN at this time, and limit PCN to the "IntServ over DiffServ" >case at this time. > >Anna begin> > >PWE3-related deployment model has already been taken out of the updated >charter, based on the BOF input. > >As to SIP-related one - there is one aspect of it that actually >potentially affects the marking at the ingress node, namely the >aggregation assumptions, and especially aggregation level on a >per-ingress-egress aggregate. This specific model is likely to assume >both lower levels of aggregation on the PCN internal links, but >especially on a per-ingress-egress pair basis. From the work available >by now it seems relatively clear that if the core marking is to >accommodate this, the decision on *when* to mark packes may be >affected, and that additional flexibility in the marking at the internal >node may be potentially needed. So in the very least this needs to be >"kept in mind" even if the SIP (or application-related) deployment is >taken out of the charter. Anna, I disagree with you on your points of: "This specific model is likely to assume both lower levels of aggregation on the PCN internal links, but especially on a per-ingress-egress pair basis." There are no strict requirements that Application (SIP) based usage of PCN must use lower levels of aggregation on the PCN internal links. Nor requirements that Application (SIP) based usage must use lower levels of aggregation on a per-ingress-egress pair basis. I believe we should try to push the envelop of applicability as much as we can. We've indicated in our earlier work (for example, showing you our simulation work so we can cover different aspects of the problem space) the usage of lower levels of aggregation (at different parts of the PCN region) because there are deployment scenarios (with interested users) that will benefit from such work. Further more, as you know, there are encouraging simulation results on lower levels of aggregation on a per-ingress-egress pair basis. The degree of "how low" will be details that can be indicated in the work of the PCN (to-be)WG. And there should be Applicability indications in the Deployment Model documents. Which should cover these points in more detail. On you point of " "From the work available by now it seems relatively clear that if the core marking is to accommodate this, the decision on *when* to mark packets may be affected, and that additional flexibility in the marking at the internal node may be potentially needed. So in the very least this needs to be "kept in mind" even if the SIP (or application-related) deployment is taken out of the charter." IMHO, it should NOT be the goal of the WG to change the Standards Track work (the internal mode when to mark packets, marking syntax, the marking semantics) between the different (re-chartering) phases of the (to-be) WG. Hence the WG should keep the Application (SIP) Deployment Model document as part of its Charter to EXPLICITLY indicate this space instead of just IMPLICITLY "kept in mind" this work. >Perhaps stressing in the charter that the WG will consider the >implications of the lower levels of ingress-egress aggregation on the >marking mechanisms may address this issue? > > > >(2) The different options of encoding markings in packets require >further investigation. This is an important component, because the >deployability of PCN hinges on well-defined marking mechanisms. I'd >therefore like to propose that PCN in the first phase should focus its >energies on working on the problem statement, deployment model and >marking mechanisms only. > > > >With respect to your discussion with Ken on the problem statement draft, >I do not see any problem with combining it with the architecture >document. A large portion of the work has been already done in this in >the various individual drafts, so this particular deliverable does not >appear to be terribly limiting to me either way. > > > > >Work on the actual admission and preemption mechanisms should kick off >only after these initial work items are stable. > > > >I interpret he above to mean that you propose to work on the encoding >and the actual marking decisions at the internal PCN router (as well as >one deployment model and prob statement), but that the edge behavior >should come later (after re-chartering). Is that a correct >interpretation? > >I worry about taking the consideration of edge behaviors out of the >charter. >The primary cause of this worry is that edge behaviors depend on the >meaning of the marking. For example, if the marking is "red-like" (e.g. >virtual-queue based) its meaning is quite different than if the marking >is excess-rate based (e.g. token-bucket based", and the appropriate edge >behavior, to do "the right thing", needs to reflect the meaning of the >marking. I just cannot see how you can completely divorce one from the >other meaningfully. > >Also, in any further evaluation of performance issues needs to be done, >such work must necessarily assume some edge behavior. My understanding >from the BOF was that further evaluation work was desirable (e.g. for >larger scale networks). Such evaluation would not be possible unless at >least some constraints on the edge behavior are specified. > >Another point is that if the first phase of the work does only the >marking behavior, and does not get re-chartered, than the product of the >WG might not result in a standard that allows interoperability (as >different edge devices may do things incompatible with the meaning of >the marking and/or with each other). > >So I would argue against taking the consideration of edge behaviors out >of the charter, even in the first phase. > > > >Comments? > >Thanks, >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 Nov 30 12:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gppfk-00059K-97; Thu, 30 Nov 2006 12:26:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gppfj-00059E-L5 for pcn@ietf.org; Thu, 30 Nov 2006 12:26:07 -0500 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gppfh-0002Di-8h for pcn@ietf.org; Thu, 30 Nov 2006 12:26:07 -0500 Received: (qmail 31077 invoked by uid 0); 30 Nov 2006 17:23:32 -0000 Received: by simscan 1.2.0 ppid: 31013, pid: 31072, t: 0.3995s scanners: clamav: 0.88.4/m:40/d:1991 spam: 3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on hiltonsmtp.worldspice.net X-Spam-Level: * X-Spam-Status: No, score=1.0 required=3.9 tests=BAYES_60 autolearn=disabled version=3.1.7 Received: from unknown (HELO lars.local) (nec-smtp@67.99.198.2) by hiltonsmtp.worldspice.net with ESMTPA; 30 Nov 2006 17:23:32 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id C146329C01C for ; Thu, 30 Nov 2006 09:25:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) To: pcn@ietf.org Message-Id: <7E7A8DE9-2C7B-4938-8F45-7DE13453F5BB@netlab.nec.de> From: Lars Eggert Date: Thu, 30 Nov 2006 09:25:51 -0800 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [PCN] quotation style 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="===============0740067467==" Errors-To: pcn-bounces@ietf.org --===============0740067467== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-43--230725187; protocol="application/pkcs7-signature" --Apple-Mail-43--230725187 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, please follow the convention of indenting quoted text in email replies with ">". I don't want to be pedantic, but I'm finding it very hard to follow who is saying what if people simply start typing their comments into the middle of unindented quoted text. Lars --Apple-Mail-43--230725187 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTMw MTcyNTUyWjAjBgkqhkiG9w0BCQQxFgQUYJ/ur+NAl7+Nj8kGBAM0Tz9NttEwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBABzOiT40NXME1nT+allK w/ColiXlONgBKKcdW7sD7Nqft5pZccMYBMWUdIf8TixrjjAx0Dzn1HeLF0Ast33+W1gtVmPS7yq7 RrBJ+bhsW8i0cTvAKebtERFM92Hl3Dd4ldPzrjlWPWE0NOE1vSY8T5/h6JpectchRT5OBMdC96n0 Mbz092WWHQN6Jj7zaJMvoM4Effb7YZnep/m5cLLadyk4MYV/ycAtMcvNJzY/PQb62pCoECB53Lae YOUR0LJoeAnPLAYrPEoQ7mjX6Vkhy33qzOm6sZqSmGEvCxIyPi3RjLRJUAh0qYzz3CpRd+Csh4mC HSqleLbpA65NXh8hOiQAAAAAAAA= --Apple-Mail-43--230725187-- --===============0740067467== 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 --===============0740067467==-- From pcn-bounces@ietf.org Thu Nov 30 13:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqWt-0007gv-8F; Thu, 30 Nov 2006 13:21:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqWs-0007gq-6K for pcn@ietf.org; Thu, 30 Nov 2006 13:21:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqWp-00016r-SR for pcn@ietf.org; Thu, 30 Nov 2006 13:21:01 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2006 10:20:58 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAUIKvuo020755; Thu, 30 Nov 2006 13:20:57 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAUIKvYJ004527; Thu, 30 Nov 2006 13:20:57 -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, 30 Nov 2006 13:20:54 -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 updated charter Date: Thu, 30 Nov 2006 13:20:53 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN updated charter Thread-Index: AccUo3pW11QInA+tS1qTUI2gKD+XXgAAzjiQ From: "Anna Charny \(acharny\)" To: "Kwok-Ho Chan" X-OriginalArrivalTime: 30 Nov 2006 18:20:54.0857 (UTC) FILETIME=[463B4B90:01C714AC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5046; t=1164910857; x=1165774857; 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]=20PCN=20=20updated=20charter |Sender:=20 |To:=20=22Kwok-Ho=20Chan=22=20; bh=CWY5cmHtrssvvBAWjQhc0utimoWpZ4omoyMNAh72PvQ=; b=P0zYmQWZ26y0Giw2JHNWLWiOZL2Rg9zOH5QqDeuAuDEt6KbXjl37GOoswBguZo3AiVHcQRuy LjjZ3MIMMH/jbwLQ7xUcbuelYzPUio/7yz3P8Ib4iEsD1LRXCLf0xn9E; 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: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Lars Eggert , 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, =20 >>Anna begin> >> >>PWE3-related deployment model has already been taken out of the updated=20 >>charter, based on the BOF input. >> >>As to SIP-related one - there is one aspect of it that actually=20 >>potentially affects the marking at the ingress node, namely the=20 >>aggregation assumptions, and especially aggregation level on a=20 >>per-ingress-egress aggregate. This specific model is likely to assume >>both lower levels of aggregation on the PCN internal links, but=20 >>especially on a per-ingress-egress pair basis. From the work available >>by now it seems relatively clear that if the core marking is to=20 >>accommodate this, the decision on *when* to mark packes may be=20 >>affected, and that additional flexibility in the marking at the=20 >>internal >>node may be potentially needed. So in the very least this needs to be >>"kept in mind" even if the SIP (or application-related) deployment is=20 >>taken out of the charter. > >Anna, I disagree with you on your points of: >>"This specific model is likely to assume both lower levels of=20 >>aggregation on the PCN internal links, but especially on a per-ingress- >>egress pair basis." >There are no strict requirements that Application (SIP) based usage of=20 >PCN must use lower levels of aggregation on the PCN internal links. >Nor requirements that Application (SIP) based usage must use lower=20 >levels of aggregation on a per-ingress-egress pair basis. >I believe we should try to push the envelop of applicability as much as >we can. I fully agree that we should push the envelop of applicability as much as we can. With respect to the aggregation level discussion it means that we might want to look into how low hese levels of aggregation could be. I merely stated that for a SIP-based model one might expect a lower degree of aggregation than that of an Intserv-over-diffserv model. I think we are in agrrement that it would be beneficial if the WG looked into the issue of how low the level of aggregation can be, and how it affects the marking (if at all). >We've indicated in our earlier work (for example, showing you our=20 >simulation work so we can cover different aspects of the problem space > the usage of lower levels of aggregation (at different parts of the PCN >region) because there are deployment scenarios (with interested users) >that will benefit from such work. Yes. That is right. I do not think there is any disgreement on that. >Further more, as you know, there are encouraging simulation results on=20 >lower levels of aggregation on a per-ingress-egress pair basis. >The degree of "how low" will be details that can be indicated in the >work of the PCN (to-be)WG. Yes. I agree with that. In my opinion, perhaps the most important aspect of the Sip/application based deployment model is the possible limits of aggregation appropriate for that deployment model. What I was trying to say is that IF the decision is made to move the SIP-deployment model to a later phase, the exploration of the limits of aggregation appropriate for that deplyment model may nevertheless need to stay in scope of the early work of the WG, as it may affect the router behavior that needs to be standardized. >On you point of " >>"From the work available by now it seems relatively clear that if the >>core marking is to accommodate this, the decision on *when* to mark >>packets may be affected, and that additional flexibility in the marking >>at the internal node may be potentially needed. So in the very least >>this needs to be "kept in mind" even if the SIP (or application- >>related) deployment is taken out of the charter." >IMHO, it should NOT be the goal of the WG to change the Standards Track >work (the internal mode when to mark packets, marking syntax, the=20 >marking semantics) between the different (re-chartering) phases of=20 >the(to-be) WG.=20 I do agree with that. I do not think I was agruing for changing the router marking semantics between recharterings at all. In fact I was arguing for exactly the opposite. I was saying that a possible difference in the aggregation level between different deployment models *may* have impact on the marking semantics and potentially edge behavior (my understanding is that the jury is out on this yet, although there are good indications that both models may in fact use the same semantics). =20 Therefore this aspect (potential impact of appropriate level of aggregation on the marking semantics) needs to be looked at early on, if SIP/Application deployment model is to be considered at any phase on the work (now or later)at all. I was in fact arguing that it needs to be looked at before rechartering. But as to other aspects of the SIP/Application model (beyond the aggregation level and its impact on the marking semantics and edge behavior), I do not personally see a reason why they can not wait till after rechartering. =20 Anna _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 30 16:13:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDj-0004Mc-DK; Thu, 30 Nov 2006 16:13:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDL-0003T4-3t for pcn@ietf.org; Thu, 30 Nov 2006 16:13:03 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpt0A-0004B5-2S for pcn@ietf.org; Thu, 30 Nov 2006 15:59:42 -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 kAUKxML04785; Thu, 30 Nov 2006 15:59:22 -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, 30 Nov 2006 15:58:15 -0500 Message-Id: <6.2.5.6.0.20061130151750.0337a6b8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Nov 2006 15:58:15 -0500 To: "Anna Charny \(acharny\)" From: "Kwok-Ho Chan" Subject: RE: [PCN] PCN updated charter In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Nov 2006 20:58:15.0788 (UTC) FILETIME=[41770AC0:01C714C2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: Lars Eggert , 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 Anna: Thank you for the agreements. I agree with your agreements, hence the only response I have is at the bottom of the E-Mail with and . Bottom line at the Top: Keeping the Application/SIP Deployment Model document in the first phase PCN Charter is beneficial to the WG. Having it in the first phase PCN Charter will help rather then hurt the WG. And there are accountable resource in the WG to get the work done. -- Kwok -- At 01:20 PM 11/30/2006, Anna Charny \(acharny\) wrote: >Hi Kwok, > > >>Anna begin> > >> > >>PWE3-related deployment model has already been taken out of the >updated > >>charter, based on the BOF input. > >> > >>As to SIP-related one - there is one aspect of it that actually > >>potentially affects the marking at the ingress node, namely the > >>aggregation assumptions, and especially aggregation level on a > >>per-ingress-egress aggregate. This specific model is likely to assume > > >>both lower levels of aggregation on the PCN internal links, but > >>especially on a per-ingress-egress pair basis. From the work available > > >>by now it seems relatively clear that if the core marking is to > >>accommodate this, the decision on *when* to mark packes may be > >>affected, and that additional flexibility in the marking at the > >>internal > >>node may be potentially needed. So in the very least this needs to >be > >>"kept in mind" even if the SIP (or application-related) deployment is > >>taken out of the charter. > > > > >Anna, I disagree with you on your points of: > >>"This specific model is likely to assume both lower levels of > >>aggregation on the PCN internal links, but especially on a >per-ingress- > >>egress pair basis." > > >There are no strict requirements that Application (SIP) based usage of > >PCN must use lower levels of aggregation on the PCN internal links. > >Nor requirements that Application (SIP) based usage must use lower > >levels of aggregation on a per-ingress-egress pair basis. > >I believe we should try to push the envelop of applicability as much as > >we can. > >I fully agree that we should push the envelop of applicability as much >as we can. With respect to the aggregation level discussion it means >that we might want to look into how low hese levels of aggregation could >be. I merely stated that for a SIP-based model one might expect a lower >degree of aggregation than that of an Intserv-over-diffserv model. I >think we are in agrrement that it would be beneficial if the WG looked >into the issue of how low the level of aggregation can be, and how it >affects the marking (if at all). > > >We've indicated in our earlier work (for example, showing you our > >simulation work so we can cover different aspects of the problem space > > the usage of lower levels of aggregation (at different parts of the >PCN >region) because there are deployment scenarios (with interested >users) > >that will benefit from such work. > >Yes. That is right. I do not think there is any disgreement on that. > > >Further more, as you know, there are encouraging simulation results on > >lower levels of aggregation on a per-ingress-egress pair basis. > >The degree of "how low" will be details that can be indicated in the > >work of the PCN (to-be)WG. > >Yes. I agree with that. In my opinion, perhaps the most important >aspect of the Sip/application based deployment model is the possible >limits of aggregation appropriate for that deployment model. What I was >trying to say is that IF the decision is made to move the SIP-deployment >model to a later phase, the exploration of the limits of aggregation >appropriate for that deplyment model may nevertheless need to stay in >scope of the early work of the WG, as it may affect the router behavior >that needs to be standardized. > > >On you point of " > >>"From the work available by now it seems relatively clear that if the > >>core marking is to accommodate this, the decision on *when* to mark > >>packets may be affected, and that additional flexibility in the >marking > >>at the internal node may be potentially needed. So in the very least > > >>this needs to be "kept in mind" even if the SIP (or application- > >>related) deployment is taken out of the charter." > > >IMHO, it should NOT be the goal of the WG to change the Standards Track > >work (the internal mode when to mark packets, marking syntax, the > >marking semantics) between the different (re-chartering) phases of > >the(to-be) WG. > >I do agree with that. I do not think I was agruing for changing the >router marking semantics between recharterings at all. In fact I was >arguing for exactly the opposite. I was saying that a possible >difference in the aggregation level between different deployment models >*may* have impact on the marking semantics and potentially edge behavior >(my understanding is that the jury is out on this yet, although there >are good indications that both models may in fact use the same >semantics). >Therefore this aspect (potential impact of appropriate level of >aggregation on the marking semantics) needs to be looked at early on, if >SIP/Application deployment model is to be considered at any phase on >the work (now or later)at all. I was in fact arguing that it needs to be >looked at before rechartering. > >But as to other aspects of the SIP/Application model (beyond the >aggregation level and its impact on the marking semantics and edge >behavior), I do not personally see a reason why they can not wait till >after rechartering. The SIP/Application Deployment Model document will put the applicability of this work in place. It is always good to do this explicitly rather then implicitly. This will provide clarity and openness to the work done by the WG. The content for SIP/Application Deployment Model document is not really new work for the people writing it. The SIP/Application Deployment Model document will help the WG to understand one possible environment of how PCN can be used. Further more the SIP/Application Deployment Model document is there so the simulation results (for the work we agreed to above) can be understood. And there are already people doing this work that is beneficial to the WG. And we should have more than one Deployment Model for PCN. This will strengthen the Standards Track part of the work we are doing. Hence I propose to keep the SIP/Application Deployment Model document as part of the first phase Charter of PCN. >Anna _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn