From pcn-bounces@ietf.org Mon Jan 08 09:46:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vlg-0007r9-WF; Mon, 08 Jan 2007 09:46:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vlf-0007qk-FE for pcn@ietf.org; Mon, 08 Jan 2007 09:46:31 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3vij-0003nB-7H for pcn@ietf.org; Mon, 08 Jan 2007 09:43:30 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l08EfY47005149 for ; Mon, 8 Jan 2007 16:41:41 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:43:22 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:43:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Jan 2007 16:43:21 +0200 Message-ID: <213394AB6954BE4682E8B2A491034683437808@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPR disclosure on draft-charny-pcn-single-marking Thread-Index: AcczM1eZmGG1kYDFTWqtveHMjlKrfQ== From: To: X-OriginalArrivalTime: 08 Jan 2007 14:43:22.0533 (UTC) FILETIME=[588CF550:01C73333] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070108164141-13F55BB0-0013A565/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [PCN] IPR disclosure on draft-charny-pcn-single-marking 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="===============1823784221==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1823784221== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_002F_01C73344.1B2746A0" This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C73344.1B2746A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, this is to inform you that the IETF has received an IPR disclosure on the Internet-Draft entitled "Pre-Congestion Notification Using Single Marking for Admission and Pre-emption" (draft-charny-pcn-single-marking) on 2006-12-21 (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Cisco's Statement about IPR claimed in draft-charny-pcn-single-marking-00.txt." The community interested in the PCN work may want to consider the existence of this IPR during any charter discussions. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_002F_01C73344.1B2746A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTA4MTQ0MzIwWjAjBgkqhkiG 9w0BCQQxFgQUDW/lWhPwjYrWuJCki1SAWlIkzQowZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAGQhNTxyh0JAApLiwPQkcHSAU5ScXeGC8GlY8BPp 0AJM3FnmgjGTU3rD+mnubYDuYlZKrZvkEoNiHt1LJA032mFfUBvu+ixieuY5Ukdsdq4qRZJa16jT 3wrCuupwPNtFYshpr89Bik5GeK6ssLpbPd6eArTRmN13939bSe/Mou+JP4Hvupbdqpm3ltZk5uCT spv+qMQOOL1rgoFylon3vKwIGS2J0l10AdndwIEOKhcjXHDu7hIEShox9fuz8BcIuofzfvjTg0Ky u+YDfMj0Xou6sajh4IXDqN8r7w2auHGinFKLEvrG4M5KXhiwHfiTsMIfNAyI6cB34l+myRqzhfMA AAAAAAA= ------=_NextPart_000_002F_01C73344.1B2746A0-- --===============1823784221== 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 --===============1823784221==-- From pcn-bounces@ietf.org Fri Jan 12 11:36:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PNy-0003Ad-RB; Fri, 12 Jan 2007 11:36:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PNx-0003AW-Ps for pcn@ietf.org; Fri, 12 Jan 2007 11:36:09 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5PNu-0004sK-8M for pcn@ietf.org; Fri, 12 Jan 2007 11:36:09 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 12 Jan 2007 17:35:58 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 17:35:58 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] Off list: Comments on re ecn border cheat Date: Fri, 12 Jan 2007 17:35:57 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFA7E@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <5.2.1.1.2.20061222120545.01f64098@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Off list: Comments on re ecn border cheat Thread-Index: Accl8rIPJGl5g1EeQsayFQb0IvGOgwQcLo3g From: "Geib, Ruediger" To: X-OriginalArrivalTime: 12 Jan 2007 16:35:58.0500 (UTC) FILETIME=[BD12B640:01C73667] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Bob, thanks for the helpful explanations. Yes, I'd be interested in=20 working on an ID on re-ECN for PCN domains. Some more=20 comments in line. [Snip] R>To sum up, I'd prefer a deeper analysis of the scenarios |>and architectures around cheating before discussing |>solutions. Bob: |Certainly. I tried to write up both the problem and the=20 |solution, so that anyone who cared to read it all could=20 |start to satisfy themselves that PCN potentially had=20 |enough legs to go beyond just an intra-domain scenario. Yes, going beyond an intra-domain scenario and allowing=20 transits for bulk PCN service is a useful aim.=20 |I would be very happy to take a more measured approach to this=20 |whole area, if others are interested too. In that case,=20 |yes, we should start with a problem statement alone.=20 |I suggest the general problem is how to police=20 |microflow admission control at borders without per-flow=20 |processing. Or we could limit the scope of the problem=20 |to a PCN context. I got the second last sentence and agree with you. I'm not sure,=20 whether I understand what you mean by "limiting the scope=20 to a PCN context." If you want to say, let's focus on the=20 kind of service which is specified by the current PCN WG,=20 I agree too. | |Even though this isn't yet PCN chartered work, would you be=20 |interested in working on an I-D on this with me in=20 |parallel to the PCN w-g, so it's ready=20 |for when the PCN group re-charter in about a year's time? As I mentioned, I'd be willing to work on such an I-D. |Once the problem is clarified, we should see if we can dream up other=20 |solutions. However, policing of a response to network layer=20 |congestion by the transport was a very hard problem to solve elegantly. = |Solving it across an internetwork has been much much harder.=20 |So I suspect any alternative solutions are going to look pretty=20 |similar to this one, unless someone makes an innovative breakthrough. Probably my command of English is a little to weak here. By "policing"=20 you don't refer to a network functionality called "policer", you=20 rather mean "sanction" or "punish" in a more general sense?=20 There's probably more like the above, where text is worrying me.=20 Maybe trying strictly apply a terminology through=20 the document would help? The other example I just discovered is a=20 sentence of section 5.4 saying: "...the ingress gateway...will have to put twice as much congestion=20 marking into the packets...." The feature which is meant is "RE-blanking", isn't it? In 4.3.1 your=20 text says "To avoid confusion we will use the term "blanking"=20 (rather than marking)..." Looks a little like pea counting here...so don't get me wrong, I think=20 the RE-feedback and RE-blanking is a good idea and a better one is=20 instantly hard to imagine. While I think to have understood the=20 fundamental idea, some parts of the text result in making me=20 question whether I really got it. Regards, Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 12 12:23:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q86-0002Js-Ff; Fri, 12 Jan 2007 12:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q84-0002Jh-No for pcn@ietf.org; Fri, 12 Jan 2007 12:23:48 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Q83-000806-Dy for pcn@ietf.org; Fri, 12 Jan 2007 12:23:48 -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 l0CHNbZ21224; Fri, 12 Jan 2007 12:23:37 -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); Fri, 12 Jan 2007 12:23:36 -0500 Message-Id: <6.2.5.6.0.20070112121158.0332e008@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jan 2007 12:23:35 -0500 To: acharny@cisco.com, sob@harvard.edu, lars.eggert@nokia.com, magnus.westerlund@ericsson.com From: "Kwok-Ho Chan" Mime-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2007 17:23:36.0974 (UTC) FILETIME=[64DB3AE0:01C7366E] X-Spam-Score: 0.6 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: pcn@ietf.org Subject: [PCN] Requesting for a Session at 68th IETF at Prague 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="===============0153294108==" Errors-To: pcn-bounces@ietf.org --===============0153294108== Content-Type: multipart/alternative; boundary="=====================_7218439==.ALT" --=====================_7218439==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Lars, Magnus, Scott, Anna: I have just noticed on the 68th IETF @ Prague's Important Meeting Dates page: January 15, Monday - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 ET (22:00 UTC/GMT). Should we be requesting for a time slot for PCN in 68th IETF @ Prague at this time? There is also the additional date for: February 5, Monday - Cutoff date for requests to schedule BOFs at 17:00 ET (22:00 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool Sending this out because Monday Jan 15, 2007 is 3 days away. Thank you very much for your guidance. -- Kwok -- --=====================_7218439==.ALT Content-Type: text/html; charset="us-ascii" Lars, Magnus, Scott, Anna:
I have just noticed on the 68th IETF @ Prague's Important Meeting Dates page:

January 15, Monday - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 ET (22:00 UTC/GMT).

Should we be requesting for a time slot for PCN in 68th IETF @ Prague at this time?

There is also the additional date for:

February 5, Monday - Cutoff date for requests to schedule BOFs at 17:00 ET (22:00 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool

Sending this out because Monday Jan 15, 2007 is 3 days away.

Thank you very much for your guidance.
-- Kwok --

--=====================_7218439==.ALT-- --===============0153294108== 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 --===============0153294108==-- From pcn-bounces@ietf.org Sat Jan 13 10:09:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kVS-0003S2-5S; Sat, 13 Jan 2007 10:09:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kVQ-0003Rk-M4 for pcn@ietf.org; Sat, 13 Jan 2007 10:09:16 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5kVO-0004iq-RS for pcn@ietf.org; Sat, 13 Jan 2007 10:09:16 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0DF6gHa011336; Sat, 13 Jan 2007 17:07:08 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jan 2007 17:08:58 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jan 2007 17:08:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 13 Jan 2007 17:08:55 +0200 Message-ID: <213394AB6954BE4682E8B2A4910346834B1553@esebe108.NOE.Nokia.com> In-Reply-To: <6.2.5.6.0.20070112121158.0332e008@nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Requesting for a Session at 68th IETF at Prague Thread-Index: Acc2bm+X66s12xhZQ3mQyS+scb4OIQAtfl1Q From: To: , , , X-OriginalArrivalTime: 13 Jan 2007 15:08:59.0355 (UTC) FILETIME=[C0A222B0:01C73724] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070113170709-2B930BB0-777FAC73/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pcn@ietf.org Subject: [PCN] RE: Requesting for a Session at 68th IETF at Prague 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="===============0996280405==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0996280405== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_007C_01C73735.81B02EB0" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C73735.81B02EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Should we be requesting for a time slot for PCN in 68th IETF > @ Prague at this time? I've put in a session request already. As soon as my Mac is back from repair and I can get at my backup (hopefully early next week), I'll post the rewrite of the charter I did over the holidays for discussion. If we agree on a charter before Prague, we could even upgrade this to a first WG meeting; otherwise we'll use the meeting to finalize the agenda discussion. (Thanks for the reminder though!) Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_007C_01C73735.81B02EB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTEzMTUwODU1WjAjBgkqhkiG 9w0BCQQxFgQUuYsmSrahsy1BUaVdKdoX2HCC/1kwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBACTotNOCWwIIKJMAp9VxboPX7X5N2In+Bbjy6TgC RRmFWKFOgCWl1TYwf82GWJ2B2L3+tXndMRP3WZVLj/XpzcNzizHw/6w69iVyrJFv7JwY/qy9Og00 dzHzKuGa8AZ1CL4L7V7+n5HqJpK4jN2/G556berpIkXDrBwwpEooB33WJLvvs/7lwq8GaImpTDgW Vf3Jd/ShQ7iIvnCWPtPz8IkAB3gjye0Q695uDtawO+tyZTJZEYaTSRn/UMRkq5oOJNcU/NE1/6vi kjzwmqx1FbtkDnfjrpo9FBHPLlRVODhpTHAwvzSJanpjHIZC+bRMPUc6BjvRwpyEK8DvL1biAFQA AAAAAAA= ------=_NextPart_000_007C_01C73735.81B02EB0-- --===============0996280405== 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 --===============0996280405==-- From pcn-bounces@ietf.org Sat Jan 13 10:15:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kb8-00067W-Qm; Sat, 13 Jan 2007 10:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kb7-00067P-Ii for pcn@ietf.org; Sat, 13 Jan 2007 10:15:09 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5kb6-0006En-9H for pcn@ietf.org; Sat, 13 Jan 2007 10:15:09 -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 l0DFF4L21094; Sat, 13 Jan 2007 10:15:04 -0500 (EST) Received: from KCHAN-2K3.nortel.com ([47.130.17.100] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jan 2007 10:15:04 -0500 Message-Id: <6.2.5.6.0.20070113101441.033dd538@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 13 Jan 2007 10:15:02 -0500 To: From: "Kwok-Ho Chan" In-Reply-To: <213394AB6954BE4682E8B2A4910346834B1553@esebe108.NOE.Nokia. com> References: <6.2.5.6.0.20070112121158.0332e008@nortel.com> <213394AB6954BE4682E8B2A4910346834B1553@esebe108.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Jan 2007 15:15:04.0392 (UTC) FILETIME=[9A365C80:01C73725] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: pcn@ietf.org Subject: [PCN] RE: Requesting for a Session at 68th IETF at Prague X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Thanks! -- Kwok -- At 10:08 AM 1/13/2007, lars.eggert@nokia.com wrote: > > Should we be requesting for a time slot for PCN in 68th IETF > > @ Prague at this time? > >I've put in a session request already. > >As soon as my Mac is back from repair and I can get at my backup >(hopefully early next week), I'll post the rewrite of the charter I did >over the holidays for discussion. If we agree on a charter before >Prague, we could even upgrade this to a first WG meeting; otherwise >we'll use the meeting to finalize the agenda discussion. > >(Thanks for the reminder though!) > >Lars >-- >NEW EMAIL: lars.eggert@nokia.com >NEW MOBILE: +358 50 48 24461 >NEW JABBER: lars.eggert@googlemail.com > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jan 25 02:23:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yx9-0003fB-Ds; Thu, 25 Jan 2007 02:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yx8-0003f2-03 for pcn@ietf.org; Thu, 25 Jan 2007 02:23:22 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9yx6-0003yZ-C5 for pcn@ietf.org; Thu, 25 Jan 2007 02:23:21 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0P7KjNk022250 for ; Thu, 25 Jan 2007 09:20:47 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 09:23:04 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Jan 2007 09:23:04 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: pcn@ietf.org Message-Id: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> From: Lars Eggert Date: Thu, 25 Jan 2007 09:23:02 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 07:23:04.0774 (UTC) FILETIME=[A75C9660:01C74051] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070125092047-56A3BBB0-34341FCF/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Subject: [PCN] charter text update X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1588035537==" Errors-To: pcn-bounces@ietf.org --===============1588035537== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-33-276538300; protocol="application/pkcs7-signature" --Apple-Mail-33-276538300 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed (I thought I had sent this several days ago, but it apparently never made it to the list?) Hi, below is a modified version of the PCN charter posted to this list a while ago. I believe it reflects the consensus after the face-to-face and mailing list discussions in and after Montreal. Compared to the earlier version, the major changes are: - removal of SIP, application-based and PW deployment scenarios - stronger language on assumptions and scope - refactored deliverables and milestones - name change (don't feel strongly about this) Please send your comments to the list. Lars ------------------------------------------------------------------------ -- Flow Admission and Preemption (flap) Chair(s): tbd Description of Working Group: The Flow Admission and Preemption (FLAP) working group develops flow admission and flow preemption mechanisms for deployment along the edge of a network domain that protect the quality-of-service that previously-admitted flows experience within the domain during times of congestion. These mechanisms act on aggregated congestion and pre- congestion signals from routers within the network domain and control the admission of new flows into the domain or preempt previously- admitted flows. Although designed to work together, flow admission and flow preemption are independent mechanisms, and the use of one does not require the use of the other. The FLAP WG will specify the following components of an integrated flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission and preemption based on aggregated (pre-)congestion information The WG focuses on the overall architecture and specifically the signaling interfaces needed to realize it. Standards-track protocols are only developed when necessary for interoperability. When algorithms are not necessary for interoperability the WG may document examples or provide recommended solutions, however such work should not be done at the expense of normative specifications. The initial scope of the FLAP WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are FLAP-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the FLAP WG may recharter to develop solutions for scenarios where some of these restrictions are not in place. It may also recharter to consider applying the FLAP mechanisms to additional deployment scenarios (operation over concatenated DiffServ regions, FLAP-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may want to However in the initial scope this mechanism is out-of-scope with the exception that the developed solution should not, if possible, prevent a future evolution to support this. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational) --Apple-Mail-33-276538300 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjUwNzIzMDNaMCMGCSqGSIb3DQEJBDEWBBSOvCgOD983dHsi dSWuKRHuK9UjvTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAy535Fzwfwj3FZaK32EcgxdrEnL5IJK8qxThGswUH5QmKGLsC8qke s63UmLiQLGhAkuuyrT8J+hymIRO/M9F11SVgy+fxZT/KPcUzdGsCvYynVPG46+5oeMI4D38Q2b4Q z/+pyLkYjjIk8d3V9HaS4lHCbtY72i4FStJUOnG217kbyjWDbBPIMccwaeMUX+NKQV+lYqk5aQb9 5oo5iTyMmfmKhdBUAUQBytUbbKvtOB6mosxm44/w+Pw3UhbdziKgHS3OoSE90fkHY3CNJjxDJbB1 yC+OCrRaTVAUHNHgD9EnHcy5H1yPlrAA3F/1i4G9w1hDESkFHt80Xb8vdz188gAAAAAAAA== --Apple-Mail-33-276538300-- --===============1588035537== 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 --===============1588035537==-- From pcn-bounces@ietf.org Thu Jan 25 02:34:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9z8G-0001dq-7Z; Thu, 25 Jan 2007 02:34:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9z8F-0001dd-9S for pcn@ietf.org; Thu, 25 Jan 2007 02:34:51 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9z8D-00077I-LX for pcn@ietf.org; Thu, 25 Jan 2007 02:34:51 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0P7Wotq004197 for ; Thu, 25 Jan 2007 09:32:58 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 09:34:32 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Jan 2007 09:34:32 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> References: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> Message-Id: From: Lars Eggert Subject: Re: [PCN] charter text update Date: Thu, 25 Jan 2007 09:34:30 +0200 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 07:34:32.0899 (UTC) FILETIME=[41842130:01C74053] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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="===============1579582839==" Errors-To: pcn-bounces@ietf.org --===============1579582839== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-35-277226448; protocol="application/pkcs7-signature" --Apple-Mail-35-277226448 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Copy/paste error corrected below. On 2007-1-25, at 9:23, ext Lars Eggert wrote: > Flow Admission and Preemption (flap) > Chair(s): > tbd > > > Description of Working Group: > > The Flow Admission and Preemption (FLAP) working group develops > flow admission and flow preemption mechanisms for deployment along > the edge of a network domain that protect the quality-of-service > that previously-admitted flows experience within the domain during > times of congestion. These mechanisms act on aggregated congestion > and pre-congestion signals from routers within the network domain > and control the admission of new flows into the domain or preempt > previously-admitted flows. Although designed to work together, flow > admission and flow preemption are independent mechanisms, and the > use of one does not require the use of the other. > > The FLAP WG will specify the following components of an integrated > flow admission and preemption mechanism: > > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals > > (2) conditions under which interior routers generate > (pre-)congestion signals > > (3) encoding and transport of (pre-)congestion signals > to the appropriate ingress routers of the network domain > > (4) edge router control mechanisms for flow admission and > preemption based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture and specifically the > signaling interfaces needed to realize it. Standards-track > protocols are only developed when necessary for interoperability. > When algorithms are not necessary for interoperability the WG may > document examples or provide recommended solutions, however such > work should not be done at the expense of normative specifications. > > > The initial scope of the FLAP WG is restricted in the following ways: > > (A) develop these components for a single DiffServ region, > where all edge and interior routers are FLAP-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping > > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective > > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits > > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > etc.) > is out of scope > > After completion of the initial phase, the FLAP WG may recharter to > develop solutions for scenarios where some of these restrictions > are not in place. It may also recharter to consider applying the > FLAP mechanisms to additional deployment scenarios (operation over > concatenated DiffServ regions, FLAP-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion signals. One example could > be flow-rate adaptation (rather than flow admission/preemption) > during times of congestion. The details of these work items are > outside the scope of the initial phase; but the WG may want to ...consider their requirements during the design of the initial components. > However in the initial scope this mechanism is out-of-scope with > the exception that the developed solution should not, if possible, > prevent a future evolution to support this. > > > Goals and Milestones: > > Jul 2007 Flow Admission and Preemption Architecture > (Informational) > > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region > (Informational) > > Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed Standard) > > Mar 2008 Transport from Flow Egress in a DiffServ Region of > information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) > > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) --Apple-Mail-35-277226448 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjUwNzM0MzFaMCMGCSqGSIb3DQEJBDEWBBTlLPjfg0G0lfuk sRbQ9BcN6/x3FDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAlo+yT1jTPn3ROxsKqlUe7hvvDdeRfFJxArrIewwNoBs/lCSSsOP1 dUIct1eys1sTIwSJ1I7lPyPNQEDGPGuQlxwzdEAIpv82y9jI9ZxLxHl5z1aTb6e5NDSZESxMFgbO KoZse0WI3JHQ3gFNkiby4QcD7PLUQdRDx6H00ABJgXGBRg9UPHywhh6WI5Gwy1YI5h6KgHq6jT6p Ug2e008qSsock8RB9EfR9y6xHkg5SPHrBvzbE/fWzN9iGadPLkzzmc1JjUozUrcup1jELco4XUCK qZXTdUd+8szZMsUw3LTRYlm8pBPYJMMePynSmlaM2dbnX8ELEB69i1IgZqoERAAAAAAAAA== --Apple-Mail-35-277226448-- --===============1579582839== 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 --===============1579582839==-- From pcn-bounces@ietf.org Thu Jan 25 11:41:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7eu-000182-LV; Thu, 25 Jan 2007 11:41:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7es-00015G-Pr for pcn@ietf.org; Thu, 25 Jan 2007 11:41:06 -0500 Received: from smtp.hosts.co.uk ([85.233.160.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7er-0003kQ-9H for pcn@ietf.org; Thu, 25 Jan 2007 11:41:06 -0500 Received: from [200.28.197.113] by smtp.hosts.co.uk with esmtpa (Exim 4.63) (envelope-from ) id 1HA7dL-0000jV-UC; Thu, 25 Jan 2007 16:39:56 +0000 In-Reply-To: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> References: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] charter text update Date: Thu, 25 Jan 2007 13:37:19 -0300 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars, I'd have a strong preference to keep the previous name, and to soften the use of the term Preemption in the charter. if the IESG is consistent, some of the them will have a difficult time with the term preemption and will kick back the charter and ask that it be reworded. Some in the IESG had a hard time with this subject (as well as some others) in the IEPREP group -- both in the past and most recently in the IETF mailing list concerning an attempted re- chartering effort for IEPREP. A few months i brought up this topic on PCN and mentioned how under certain scenarios/circumstances, the use of preemption for VoIP is simply not allowed in certain countries. http://www1.ietf.org/mail-archive/web/pcn/current/msg00023.html http://www1.ietf.org/mail-archive/web/pcn/current/msg00037.html http://www1.ietf.org/mail-archive/web/pcn/current/msg00046.html http://www1.ietf.org/mail-archive/web/pcn/current/msg00053.html Unfortunately, the subject of what is legal/regulated is not one that technical in nature, but it is something that should be considered by the group. In my previous comments, I was trying to encourage the group to treat preemption as one of several (re)actions that can be advanced by the group. I'd like to re-encourage this line of thought and text in the Charter. regards, -ken ps, my apologies in not volunteering specific suggested text changes right now, but I'm preparing for a couple of days of travel (ugh). On Jan 25, 2007, at 4:23 AM, Lars Eggert wrote: > (I thought I had sent this several days ago, but it apparently > never made it to the list?) > > Hi, > > below is a modified version of the PCN charter posted to this list > a while ago. I believe it reflects the consensus after the face-to- > face and mailing list discussions in and after Montreal. > > Compared to the earlier version, the major changes are: > > - removal of SIP, application-based and PW deployment scenarios > - stronger language on assumptions and scope > - refactored deliverables and milestones > - name change (don't feel strongly about this) > > Please send your comments to the list. > > Lars > > ---------------------------------------------------------------------- > ---- > > Flow Admission and Preemption (flap) > Chair(s): > tbd > > > Description of Working Group: > > The Flow Admission and Preemption (FLAP) working group develops > flow admission and flow preemption mechanisms for deployment along > the edge of a network domain that protect the quality-of-service > that previously-admitted flows experience within the domain during > times of congestion. These mechanisms act on aggregated congestion > and pre-congestion signals from routers within the network domain > and control the admission of new flows into the domain or preempt > previously-admitted flows. Although designed to work together, flow > admission and flow preemption are independent mechanisms, and the > use of one does not require the use of the other. > > The FLAP WG will specify the following components of an integrated > flow admission and preemption mechanism: > > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals > > (2) conditions under which interior routers generate > (pre-)congestion signals > > (3) encoding and transport of (pre-)congestion signals > to the appropriate ingress routers of the network domain > > (4) edge router control mechanisms for flow admission and > preemption based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture and specifically the > signaling interfaces needed to realize it. Standards-track > protocols are only developed when necessary for interoperability. > When algorithms are not necessary for interoperability the WG may > document examples or provide recommended solutions, however such > work should not be done at the expense of normative specifications. > > > The initial scope of the FLAP WG is restricted in the following ways: > > (A) develop these components for a single DiffServ region, > where all edge and interior routers are FLAP-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping > > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective > > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits > > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > etc.) > is out of scope > > After completion of the initial phase, the FLAP WG may recharter to > develop solutions for scenarios where some of these restrictions > are not in place. It may also recharter to consider applying the > FLAP mechanisms to additional deployment scenarios (operation over > concatenated DiffServ regions, FLAP-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion signals. One example could > be flow-rate adaptation (rather than flow admission/preemption) > during times of congestion. The details of these work items are > outside the scope of the initial phase; but the WG may want to > > However in the initial scope this mechanism is out-of-scope with > the exception that the developed solution should not, if possible, > prevent a future evolution to support this. > > > Goals and Milestones: > > Jul 2007 Flow Admission and Preemption Architecture > (Informational) > > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region > (Informational) > > Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed Standard) > > Mar 2008 Transport from Flow Egress in a DiffServ Region of > information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) > > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jan 25 12:01:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7yg-0006fn-I3; Thu, 25 Jan 2007 12:01:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7yf-0006ff-E1 for pcn@ietf.org; Thu, 25 Jan 2007 12:01:33 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7yd-0007Yu-W9 for pcn@ietf.org; Thu, 25 Jan 2007 12:01:33 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0PGwp3N028946; Thu, 25 Jan 2007 18:58:52 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 19:01:19 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Jan 2007 19:01:20 +0200 In-Reply-To: References: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4AEC884D-CDA1-4125-83C3-F8858709F8C8@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter text update Date: Thu, 25 Jan 2007 19:01:19 +0200 To: ext ken carlberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 17:01:20.0286 (UTC) FILETIME=[6F7F93E0:01C740A2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070125185852-70D60BB0-316F3AEE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1890670450==" Errors-To: pcn-bounces@ietf.org --===============1890670450== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-74-311234574; protocol="application/pkcs7-signature" --Apple-Mail-74-311234574 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-25, at 18:37, ext ken carlberg wrote: > I'd have a strong preference to keep the previous name OK - the name change came about when the evolving charter was focused more on the admission and preemption mechanisms than it is now. I'm OK with reverting to the old name. > , and to soften the use of the term Preemption in the charter. if > the IESG is consistent, some of the them will have a difficult time > with the term preemption and will kick back the charter and ask > that it be reworded. Some in the IESG had a hard time with this > subject (as well as some others) in the IEPREP group -- both in the > past and most recently in the IETF mailing list concerning an > attempted re-chartering effort for IEPREP. It's not the term preemption, it is the concept of preemption especially in the context of emergency use. Which is why restriction (E) specifically declares this to be out-of-scope: >> (E) flows may have different precedence, but the applicability >> of these mechanisms for emergency use (911, GETS, WPS, >> MLPP, etc.) >> is out of scope > Unfortunately, the subject of what is legal/regulated is not one > that technical in nature, but it is something that should be > considered by the group. In my previous comments, I was trying to > encourage the group to treat preemption as one of several (re) > actions that can be advanced by the group. I'd like to re- > encourage this line of thought and text in the Charter. I have little hope that this group would make any better progress on this issue than the other groups that are having a hard time with it. I also haven't seen strong consensus that emergency use was a stated goal. Lars --Apple-Mail-74-311234574 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjUxNzAxMTlaMCMGCSqGSIb3DQEJBDEWBBQpu8d9V/PZqc2F 36BeBsCQgHb/6TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEASDeQupHzx7FopQo8kGQD4aFvryjUy6JZuLEWgwvV8pWGVQOk3XIZ eY7d4Z51oORefQlLdYGqtjXIEFGds/kF7PI3in+m5GGuna7inUmCj/dl9PHzdpu84TkKGNt1Ut3x HTuOOHU+b8Kcpw186K6u1X1pxFLBQ/bSEFvHTqTIZsvZJ5XNuMKs3W4ASRe8gN9NmpEz2DmVc7Ra qBwP+7KIpZFZTSSQCrLa0p2Zg1YI8qJyPx+PXDU3ZJsMJELovND7cnJNWR7muLSgNGyPD4fO+Ra6 gQJ9Ph3wokM+RMO/JEPV4+/TFkgZ3lXz/0K+sbaesAcdZaUeh6MItSX5Q1xNBAAAAAAAAA== --Apple-Mail-74-311234574-- --===============1890670450== 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 --===============1890670450==-- From pcn-bounces@ietf.org Thu Jan 25 14:34:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAN0-00013F-TK; Thu, 25 Jan 2007 14:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAMy-00011e-AQ for pcn@ietf.org; Thu, 25 Jan 2007 14:34:48 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAAJU-0006eQ-Q8 for pcn@ietf.org; Thu, 25 Jan 2007 14:31:14 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0PJUxM8001665; Thu, 25 Jan 2007 13:31:12 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 13:31:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter text update Date: Thu, 25 Jan 2007 13:31:05 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD09A564D1@ILEXC1U02.ndc.lucent.com> In-Reply-To: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdAUclKkyxAYrpfSNa+anoEahMecAAY3M+A From: "GOLDMAN, STUART O \(STUART\)" To: "Lars Eggert" , X-OriginalArrivalTime: 25 Jan 2007 19:31:07.0183 (UTC) FILETIME=[5C1B3BF0:01C740B7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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, I have several questions regarding the proposed new charter which may be because I don't have a real good understanding of pre-congestion versus actual congestion: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals Why would we want to preempt existing real sessions prior to an actual congestion? (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope By this I assume that we would not preempt or prevent these kinds of emergency calls. What does it imply about preemption of ordinary calls in favor of emergency calls? As for the name, it did seem to me at least that the ability to anticipate congestion and modify edge behavior is more palatable than focusing on when congestion exists as implied by the FLAP name (Flow Admission and Preemption (flap)). Am I misinterpreting the impression this would leave in peoples' minds? Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: Thursday, January 25, 2007 12:23 AM To: pcn@ietf.org Subject: [PCN] charter text update (I thought I had sent this several days ago, but it apparently never =20 made it to the list?) Hi, below is a modified version of the PCN charter posted to this list a =20 while ago. I believe it reflects the consensus after the face-to-face =20 and mailing list discussions in and after Montreal. Compared to the earlier version, the major changes are: - removal of SIP, application-based and PW deployment scenarios - stronger language on assumptions and scope - refactored deliverables and milestones - name change (don't feel strongly about this) Please send your comments to the list. Lars ------------------------------------------------------------------------ -- Flow Admission and Preemption (flap) Chair(s): tbd Description of Working Group: The Flow Admission and Preemption (FLAP) working group develops flow =20 admission and flow preemption mechanisms for deployment along the =20 edge of a network domain that protect the quality-of-service that =20 previously-admitted flows experience within the domain during times =20 of congestion. These mechanisms act on aggregated congestion and pre-=20 congestion signals from routers within the network domain and control =20 the admission of new flows into the domain or preempt previously-=20 admitted flows. Although designed to work together, flow admission =20 and flow preemption are independent mechanisms, and the use of one =20 does not require the use of the other. The FLAP WG will specify the following components of an integrated =20 flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission and preemption based on aggregated (pre-)congestion information The WG focuses on the overall architecture and specifically the =20 signaling interfaces needed to realize it. Standards-track protocols =20 are only developed when necessary for interoperability. When =20 algorithms are not necessary for interoperability the WG may document =20 examples or provide recommended solutions, however such work should =20 not be done at the expense of normative specifications. The initial scope of the FLAP WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are FLAP-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms =20 to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, =20 etc.) is out of scope After completion of the initial phase, the FLAP WG may recharter to =20 develop solutions for scenarios where some of these restrictions are =20 not in place. It may also recharter to consider applying the FLAP =20 mechanisms to additional deployment scenarios (operation over =20 concatenated DiffServ regions, FLAP-aware application mechanisms, =20 etc.). The WG may also consider to investigate additional response =20 mechanisms that act on (pre-)congestion signals. One example could be =20 flow-rate adaptation (rather than flow admission/preemption) during =20 times of congestion. The details of these work items are outside the =20 scope of the initial phase; but the WG may want to However in the initial scope this mechanism is out-of-scope with the =20 exception that the developed solution should not, if possible, =20 prevent a future evolution to support this. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of =20 information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational) _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 26 03:24:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMO0-0000BI-3h; Fri, 26 Jan 2007 03:24:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMNy-0000AJ-B4 for pcn@ietf.org; Fri, 26 Jan 2007 03:24:38 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAMMn-00076j-Po for pcn@ietf.org; Fri, 26 Jan 2007 03:23:27 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 26 Jan 2007 09:23:08 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 09:23:08 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter text update Date: Fri, 26 Jan 2007 09:23:07 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAD2@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdAn6g/KPvQmGuKQDeBSzHi/wh8iwAgZXNQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 26 Jan 2007 08:23:08.0178 (UTC) FILETIME=[35922720:01C74123] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars, I support Ken's view. Making "Preemption" part of a new PCN WG name=20 doesn't seem to be wise to me too. Setting such a sharp focus on=20 preemption could easily result in drawing to much attention from=20 people whose background is more "preemption" then PCN.=20 I appreciate that you at least don't object to Ken's suggestion=20 to this regard. =20 Cheers, Rudiger |-----Original Message----- |From: ken carlberg [mailto:carlberg@g11.org.uk] |Sent: Thursday, January 25, 2007 5:37 PM |To: Lars Eggert |Cc: pcn@ietf.org |Subject: Re: [PCN] charter text update | | |Lars, | |I'd have a strong preference to keep the previous name, and to soften =20 |the use of the term Preemption in the charter. if the IESG is =20 |consistent, some of the them will have a difficult time with the term =20 |preemption and will kick back the charter and ask that it be =20 |reworded. Some in the IESG had a hard time with this subject (as =20 |well as some others) in the IEPREP group -- both in the past and most =20 |recently in the IETF mailing list concerning an attempted re-=20 |chartering effort for IEPREP. | |A few months i brought up this topic on PCN and mentioned how under =20 |certain scenarios/circumstances, the use of preemption for VoIP is =20 |simply not allowed in certain countries. | |http://www1.ietf.org/mail-archive/web/pcn/current/msg00023.html |http://www1.ietf.org/mail-archive/web/pcn/current/msg00037.html |http://www1.ietf.org/mail-archive/web/pcn/current/msg00046.html |http://www1.ietf.org/mail-archive/web/pcn/current/msg00053.html | |Unfortunately, the subject of what is legal/regulated is not one that =20 |technical in nature, but it is something that should be considered by =20 |the group. In my previous comments, I was trying to encourage the =20 |group to treat preemption as one of several (re)actions that can be =20 |advanced by the group. I'd like to re-encourage this line of thought =20 |and text in the Charter. | |regards, | |-ken | |ps, my apologies in not volunteering specific suggested text changes =20 |right now, but I'm preparing for a couple of days of travel (ugh). | | |On Jan 25, 2007, at 4:23 AM, Lars Eggert wrote: | |> (I thought I had sent this several days ago, but it apparently =20 |> never made it to the list?) |> |> Hi, |> |> below is a modified version of the PCN charter posted to this list =20 |> a while ago. I believe it reflects the consensus after the face-to-=20 |> face and mailing list discussions in and after Montreal. |> |> Compared to the earlier version, the major changes are: |> |> - removal of SIP, application-based and PW deployment scenarios |> - stronger language on assumptions and scope |> - refactored deliverables and milestones |> - name change (don't feel strongly about this) |> |> Please send your comments to the list. |> |> Lars |> |>=20 |----------------------------------------------------------------------=20 |> ---- |> |> Flow Admission and Preemption (flap) |> Chair(s): |> tbd |> |> |> Description of Working Group: |> |> The Flow Admission and Preemption (FLAP) working group develops =20 |> flow admission and flow preemption mechanisms for deployment along =20 |> the edge of a network domain that protect the quality-of-service =20 |> that previously-admitted flows experience within the domain during =20 |> times of congestion. These mechanisms act on aggregated congestion =20 |> and pre-congestion signals from routers within the network domain =20 |> and control the admission of new flows into the domain or preempt =20 |> previously-admitted flows. Although designed to work together, flow =20 |> admission and flow preemption are independent mechanisms, and the =20 |> use of one does not require the use of the other. |> |> The FLAP WG will specify the following components of an integrated =20 |> flow admission and preemption mechanism: |> |> (1) a general architecture for flow admission and preemption based |> on aggregated (pre-)congestion signals |> |> (2) conditions under which interior routers generate |> (pre-)congestion signals |> |> (3) encoding and transport of (pre-)congestion signals |> to the appropriate ingress routers of the network domain |> |> (4) edge router control mechanisms for flow admission and |> preemption based on aggregated (pre-)congestion information |> |> The WG focuses on the overall architecture and specifically the =20 |> signaling interfaces needed to realize it. Standards-track =20 |> protocols are only developed when necessary for interoperability. =20 |> When algorithms are not necessary for interoperability the WG may =20 |> document examples or provide recommended solutions, however such =20 |> work should not be done at the expense of normative specifications. |> |> |> The initial scope of the FLAP WG is restricted in the following ways: |> |> (A) develop these components for a single DiffServ region, |> where all edge and interior routers are FLAP-enabled |> and mutually trust each other |> |> (B) all flows handled by these mechanisms are inelastic and |> constrained to a known maximum rate through policing=20 |or shaping |> |> (C) the number of flows across any potential aggregation=20 |bottleneck |> is sufficiently large for stateless, statistical mechanisms =20 |> to be |> effective |> |> (D) aggregation occurs either on links or ingress/egress pairs; |> mechanisms must further define relevant limits |> |> (E) flows may have different precedence, but the applicability |> of these mechanisms for emergency use (911, GETS, WPS, MLPP, =20 |> etc.) |> is out of scope |> |> After completion of the initial phase, the FLAP WG may recharter to =20 |> develop solutions for scenarios where some of these restrictions =20 |> are not in place. It may also recharter to consider applying the =20 |> FLAP mechanisms to additional deployment scenarios (operation over =20 |> concatenated DiffServ regions, FLAP-aware application mechanisms, =20 |> etc.). The WG may also consider to investigate additional response =20 |> mechanisms that act on (pre-)congestion signals. One example could =20 |> be flow-rate adaptation (rather than flow admission/preemption) =20 |> during times of congestion. The details of these work items are =20 |> outside the scope of the initial phase; but the WG may want to |> |> However in the initial scope this mechanism is out-of-scope with =20 |> the exception that the developed solution should not, if possible, =20 |> prevent a future evolution to support this. |> |> |> Goals and Milestones: |> |> Jul 2007 Flow Admission and Preemption Architecture |> (Informational) |> |> Jul 2007 Survey of Encoding and Transport Choices of |> (Pre-)Congestion Signals within a DiffServ Region |> (Informational) |> |> Nov 2007 Flow Admission and Preemption within a DiffServ |> Region (Informational) |> |> Nov 2007 (Pre-)Congestion Detection within a DiffServ Region |> (Proposed Standard) |> |> Mar 2008 Encoding and Transport of (Pre-)Congestion Signals |> within a DiffServ Region to Flow Egress (Proposed=20 |Standard) |> |> Mar 2008 Transport from Flow Egress in a DiffServ Region of =20 |> information |> (possibly aggregated) or Admission/Preemption Signals to |> DiffServ edge devices. (Proposed Standard) |> |> Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms |> (Informational) |> |> |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 26 04:17:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAND5-0005aw-9q; Fri, 26 Jan 2007 04:17:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAND3-0005ao-Jl for pcn@ietf.org; Fri, 26 Jan 2007 04:17:25 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAND2-000251-5e for pcn@ietf.org; Fri, 26 Jan 2007 04:17:25 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0Q9EHIx020931; Fri, 26 Jan 2007 11:14:44 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:17:04 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Jan 2007 11:17:04 +0200 In-Reply-To: <7D096A439A3D0D48A3D10872022CFD09A564D1@ILEXC1U02.ndc.lucent.com> References: <7D096A439A3D0D48A3D10872022CFD09A564D1@ILEXC1U02.ndc.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36AF84F3-3F6C-4114-8AE3-1BA76D0B06BA@nokia.com> Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [PCN] charter text update Date: Fri, 26 Jan 2007 11:16:59 +0200 To: "ext GOLDMAN, STUART O (STUART)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 09:17:04.0683 (UTC) FILETIME=[BEAD9FB0:01C7412A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, On 2007-1-25, at 21:31, ext GOLDMAN, STUART O (STUART) wrote: > I have several questions regarding the proposed new charter which > may be > because I don't have a real good understanding of pre-congestion > versus > actual congestion: > > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals > > Why would we want to preempt existing real sessions prior to an actual > congestion? First, "(pre-)congestion signals" expands to "pre-congestion and congestion signals." (I"m not too happy with this abbreviation, but using the expanded version everywhere is also not good - suggestions?) So maybe the edge reacts to pre-congestion signals with admission decisions, but to congestion signals (due to equipment failure, etc.) with preemption decisions. But allowing an edge to preempt flows based on pre-congestion signals might also make sense, and I wouldn't want to exclude this option. Note that the edge policies will be described in Informational documents only, and maybe the WG wants to describe multiple edge policies that establish different behaviors. > (E) flows may have different precedence, but the applicability of > these > mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of > scope > > By this I assume that we would not preempt or prevent these kinds of > emergency calls. What does it imply about preemption of ordinary calls > in favor of emergency calls? This is supposed to express that whereas the edge is free to treat flows differently when it comes to deciding whether to admit or preempt some, use of the admission/preemption mechanisms for emergency use - with all the policy and legal implications that entails - is out of scope. I'm open for suggestions on how to phrase this more clearly. > As for the name, it did seem to me at least that the ability to > anticipate congestion and modify edge behavior is more palatable than > focusing on when congestion exists as implied by the FLAP name (Flow > Admission and Preemption (flap)). Am I misinterpreting the impression > this would leave in peoples' minds? People have convinced me that sticking to the original PCN name is better. I will make that change in the next revision. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 26 04:17:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANDS-0006GE-G9; Fri, 26 Jan 2007 04:17:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANDQ-00065F-Q8 for pcn@ietf.org; Fri, 26 Jan 2007 04:17:48 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HANDP-00027q-CS for pcn@ietf.org; Fri, 26 Jan 2007 04:17:48 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0Q9F1Ur021179; Fri, 26 Jan 2007 11:15:10 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:17:45 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Jan 2007 11:17:45 +0200 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFAD2@S4DE8PSAAFQ.mitte.t-com.de> References: <6439282641581441A36F7F6F83ED2ED2CBFAD2@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [PCN] charter text update Date: Fri, 26 Jan 2007 11:17:41 +0200 To: "ext Geib, Ruediger" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 09:17:45.0230 (UTC) FILETIME=[D6D89AE0:01C7412A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On 2007-1-26, at 10:23, ext Geib, Ruediger wrote: > I support Ken's view. Making "Preemption" part of a new PCN WG name > doesn't seem to be wise to me too. Setting such a sharp focus on > preemption could easily result in drawing to much attention from > people whose background is more "preemption" then PCN. > > I appreciate that you at least don't object to Ken's suggestion > to this regard. I'll change the name back to PCN in the next revision. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jan 26 04:48:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANhL-0006F7-Hz; Fri, 26 Jan 2007 04:48:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANhK-0006Ew-Nu; Fri, 26 Jan 2007 04:48:42 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HANhJ-0007V2-8v; Fri, 26 Jan 2007 04:48:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0Q9jjER030256; Fri, 26 Jan 2007 11:46:05 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:49:12 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Jan 2007 11:48:25 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <895DE7DB-FAB3-463D-9E1F-0177087BC607@nokia.com> From: Lars Eggert Date: Fri, 26 Jan 2007 11:48:22 +0200 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 09:48:25.0011 (UTC) FILETIME=[1F70E830:01C7412F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tsv-area@ietf.org, tsvwg Subject: [PCN] HEADS UP: looking for co-chairs for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg-ads@tools.ietf.org List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359018100==" Errors-To: pcn-bounces@ietf.org --===============0359018100== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-80-371657636; protocol="application/pkcs7-signature" --Apple-Mail-80-371657636 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, we're looking for volunteers interested in co-chairing the Pre- Congestion Notification (PCN) WG. Note that a final chartering decision has not yet been made, and depends on the outcome of the ongoing discussion. This will be a new WG with a moderately busy initial charter, so we're looking for two chairs with sufficient weekly cycles to actively see this WG off to a good start. Experience with DiffServ/ IntServ, signaling and/or congestion control is a plus. Although we'd like chairs with a technical background that fits the scope of the WG, we'd also like them to not become major technical contributors. The current charter revision is at http://www1.ietf.org/mail-archive/ web/pcn/current/msg00261.html, but likely to change. Note: We're trying to train new chairs for the TSV area, so there is *no* requirement to having had prior chairing experience. If you are interested in co-chairing PCN, please respond to tsvwg- ads@tools.ietf.org with your name, affiliation and a brief summary of your IETF experience by February 9, 2006. Thanks, Lars --Apple-Mail-80-371657636 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjYwOTQ4MjJaMCMGCSqGSIb3DQEJBDEWBBTRGW/FDyuE4q+R Hwk6MZSIS3tNYzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAsC1e+UxWAkaXmydOEnMP8n+2D3lCuhEBvs1SY2dF8f2XG0YUk+Yg 1x/GSEd6tRIDRYdkbKspDgT8LQU1pXktG2NuxBK5pj0UAFYpotkUN1Zr3oW6nP3GztlBTtMOad7S 0kq15IfGCJWMji6DX7nnkGbYRRvF1bVOMHTPkRTtn0W/eYymEWnH/fcQmlYEo85QUpdND00PPQx6 V7P9qf8vY5W+sar5zLczs+ulOdU07zb+oj+ak3MICpUiGBWRjoIl0l5xggnL3u8z3LmSLmFItJFI aZHR3gc1n71+7x5cwTZaYQU9LotR8SgFaQnskxrFmY4xxrnwjEEO6dtaoM1d0AAAAAAAAA== --Apple-Mail-80-371657636-- --===============0359018100== 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 --===============0359018100==-- From pcn-bounces@ietf.org Sun Jan 28 21:00:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBLor-0001Kn-Il; Sun, 28 Jan 2007 21:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBLoq-0001Ki-MV for pcn@ietf.org; Sun, 28 Jan 2007 21:00:28 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBLoq-00083y-8K for pcn@ietf.org; Sun, 28 Jan 2007 21:00:28 -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 l0T20Nb10066; Sun, 28 Jan 2007 21:00:23 -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] charter proposed text changes Date: Sun, 28 Jan 2007 21:00:21 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E5622F0@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter proposed text changes Thread-Index: AcdAU1h3H4lWcEkUS9+4xdyQtU+DngC88MAg From: "Jozef Babiarz" To: "Lars Eggert" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 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 and all, I also prefer PCN (Pre-Congestion Notification) as the name of the workgroup. Secondly, I also think that it is a good idea to soften the term "preemption" or possibly do not use the preemption term as it has a different function to what I believe the main focus of this work should be. Below is my attempt at rewording the PCN charter without changing the scope. Hope it's helpful. I will send a separate email on adding additional items to the scope. Description of Working Group: The (Pre-)Congestion Notification (PCN) working group will develop procedures and mechanisms for congestion control of inelastic flows to protect the quality-of-service to previously-admitted traffic. The WG will develop mechanism by which network node in DiffServ domain can signal the onset of congestion and whereas nodes at the edges monitor and react to the signaled (pre-)congestion information. The WG will define procedure for admission control, the blocking of new flows being added in to the network as the first step to congestion control for inelastic traffic. As in some situation admission control may not be sufficient, the WG will also define procedures for removal of excess inelastic traffic should network nodes become congested. The removal of excess traffic may consist of define methods for flow termination and/or flow-rate adaptation. The PCN WG will specify the following components of an integrated flow admission and congestion relief mechanism: (1) a general architecture for congestion control of inelastic=20 flows through the use of (pre-)congestion signals (2) conditions under which network nodes generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals in the network =20 (4) edge nodes control procedures for flow admission and congestion relief based on (pre-)congestion information The WG focuses on the overall architecture, (pre-)congestion marking behavior and specifically the signaling interfaces needed to realize it. Standards-track protocols are only developed when necessary for interoperability. When algorithms are not necessary for interoperability the WG may document examples or provide recommended solutions, however such work should not be done at the expense of normative specifications. The initial scope of the PCN WG is restricted in the following ways: (A) develop flow admission and removal of excess traffic mechanisms for a single DiffServ region, where all edge and interior routers are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for statistical mechanisms to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may recharter to develop solutions for scenarios where some of these restrictions are not in place. It may also recharter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ regions, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/flow termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG will need to consider their requirements during the design of the initial components. However in the initial scope these mechanisms are out-of-scope with the exception that the developed solution should not, if possible, prevent a future evolution to support this. Goals and Milestones: Jul 2007 Congestion Control Architecture for Inelastic Flows (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection and Encoding within a DiffServ Region (Proposed Standard) Mar 2008 Behavioral definition for Ingress and Egress Network Nodes for Flow Admission and Removal of Excess Traffic within a DiffServ Region (Informational) Mar 2008 Requirements for Signalling of (Pre-)Congestion information from Egress Nodes to Ingress Nodes in a DiffServ Region (Informational) Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: January 25, 2007 2:35 AM To: pcn@ietf.org Subject: Re: [PCN] charter text update Copy/paste error corrected below. On 2007-1-25, at 9:23, ext Lars Eggert wrote: > Flow Admission and Preemption (flap) > Chair(s): > tbd > > > Description of Working Group: > > The Flow Admission and Preemption (FLAP) working group develops =20 > flow admission and flow preemption mechanisms for deployment along =20 > the edge of a network domain that protect the quality-of-service =20 > that previously-admitted flows experience within the domain during =20 > times of congestion. These mechanisms act on aggregated congestion =20 > and pre-congestion signals from routers within the network domain =20 > and control the admission of new flows into the domain or preempt =20 > previously-admitted flows. Although designed to work together, flow =20 > admission and flow preemption are independent mechanisms, and the =20 > use of one does not require the use of the other. > > The FLAP WG will specify the following components of an integrated =20 > flow admission and preemption mechanism: > > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals > > (2) conditions under which interior routers generate > (pre-)congestion signals > > (3) encoding and transport of (pre-)congestion signals > to the appropriate ingress routers of the network domain > > (4) edge router control mechanisms for flow admission and > preemption based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture and specifically the =20 > signaling interfaces needed to realize it. Standards-track =20 > protocols are only developed when necessary for interoperability. =20 > When algorithms are not necessary for interoperability the WG may =20 > document examples or provide recommended solutions, however such =20 > work should not be done at the expense of normative specifications. > > > The initial scope of the FLAP WG is restricted in the following ways: > > (A) develop these components for a single DiffServ region, > where all edge and interior routers are FLAP-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping > > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms =20 > to be > effective > > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits > > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, =20 > etc.) > is out of scope > > After completion of the initial phase, the FLAP WG may recharter to =20 > develop solutions for scenarios where some of these restrictions =20 > are not in place. It may also recharter to consider applying the =20 > FLAP mechanisms to additional deployment scenarios (operation over =20 > concatenated DiffServ regions, FLAP-aware application mechanisms, =20 > etc.). The WG may also consider to investigate additional response =20 > mechanisms that act on (pre-)congestion signals. One example could =20 > be flow-rate adaptation (rather than flow admission/preemption) =20 > during times of congestion. The details of these work items are =20 > outside the scope of the initial phase; but the WG may want to ...consider their requirements during the design of the initial =20 components. > However in the initial scope this mechanism is out-of-scope with =20 > the exception that the developed solution should not, if possible, =20 > prevent a future evolution to support this. > > > Goals and Milestones: > > Jul 2007 Flow Admission and Preemption Architecture > (Informational) > > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region > (Informational) > > Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed Standard) > > Mar 2008 Transport from Flow Egress in a DiffServ Region of =20 > information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) > > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Jan 28 21:47:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBMY2-0003a0-Cl; Sun, 28 Jan 2007 21:47:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBMY0-0003Zo-K8 for pcn@ietf.org; Sun, 28 Jan 2007 21:47:08 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBMXz-0004lV-Cy for pcn@ietf.org; Sun, 28 Jan 2007 21:47: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 l0T2l4P09007; Sun, 28 Jan 2007 21:47:04 -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] charter, addition to scope Date: Sun, 28 Jan 2007 21:47:03 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E562300@zcarhxm1.corp.nortel.com> In-Reply-To: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdAUc0vwsHQ1a70Qz6/ObSb1A/8SQC/UQRw From: "Jozef Babiarz" To: "Lars Eggert" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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, Do not understand why application aware (pre-)congestion is out of scope? At the BOF in San Diego and on the PCN mailing list there was support for it with people will to work on it. Specifically what I would like to add to scope in the PCN charter is that "the PCN WG will define requirements for conveying (pre-)congestion information from the receiver to the sender and the actions that both the receiving host and sending host should perform." Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: January 25, 2007 2:23 AM To: pcn@ietf.org Subject: [PCN] charter text update (I thought I had sent this several days ago, but it apparently never =20 made it to the list?) Hi, below is a modified version of the PCN charter posted to this list a =20 while ago. I believe it reflects the consensus after the face-to-face =20 and mailing list discussions in and after Montreal. Compared to the earlier version, the major changes are: - removal of SIP, application-based and PW deployment scenarios - stronger language on assumptions and scope - refactored deliverables and milestones - name change (don't feel strongly about this) Please send your comments to the list. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 04:08:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSUr-0003Fa-Cy; Mon, 29 Jan 2007 04:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSUq-0003Ee-6U for pcn@ietf.org; Mon, 29 Jan 2007 04:08:16 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBSUo-0004K2-NQ for pcn@ietf.org; Mon, 29 Jan 2007 04:08:16 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0T96FL3031780; Mon, 29 Jan 2007 11:06:18 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 11:07:44 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 11:07:43 +0200 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E562300@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650E562300@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <89E5E0B8-1F9D-43DB-926A-E9720188B5E8@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 11:07:54 +0200 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 09:07:43.0935 (UTC) FILETIME=[EFAF84F0:01C74384] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026573104==" Errors-To: pcn-bounces@ietf.org --===============1026573104== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-628430300; protocol="application/pkcs7-signature" --Apple-Mail-7-628430300 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-1-29, at 4:47, ext Jozef Babiarz wrote: > Do not understand why application aware (pre-)congestion is out of > scope? At the BOF in San Diego and on the PCN mailing list there was > support for it with people will to work on it. there was _some_ support for it, but there was also significant pushback against it, for example, from the SIP folks, who argued that the presented model for SIP-based deployment had significant issues. Consequently, at least from what I observed, we had rough consensus on not including it in the initial charter. > Specifically what I would > like to add to scope in the PCN charter is that "the PCN WG will > define > requirements for conveying (pre-)congestion information from the > receiver to the sender and the actions that both the receiving host > and > sending host should perform." The "host-to-host" deployment model is significantly different from the "edge-to-edge" one that the majority of the current discussion has focused on, with the latter one being somewhat simpler. Hence the approach is to deal with this first, while trying to ensure that the individual mechanisms (marking behavior, encoding, etc.) are sufficiently general to support both. Thank you for the other suggested changes to the charter in your other email. I incorporated some of them into a revision of the charter text, which I'll email separately. I didn't change "flow admission and preemption" to "congestion control", as that doesn't convey quite the same meaning and is also less specific. About the term "preemption", would people be OK with changing it to "termination?" (Preemption sounds like the flow can resume.) But this is a minor change IMO. Lars --Apple-Mail-7-628430300 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkwOTA3NTVaMCMGCSqGSIb3DQEJBDEWBBTiFQkn2DA+R+hc CP1AjXkzuZsCVjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAOD/bJO+2+4i+c41u+k05Lt4z6vnTZDPuUB/PqIlOnTFc5ybJY6KR Vuso8KvkDwCpwvqDZuwNAw3U3O3lYvmRBQZhrU84RPEbo0onTOfozxl9co2Gfr3O9tHhwHr/w3h2 7voXP0X7XJ++mY4buaiOFfN/EKO9C3oiK2I2FqBIrYn0ClMYjatPPK84aajchLAoAB8M+A7bdpvT rhL0Yk5Im8ye6kfzqzhgDMbFY5NYrxiR+APbzmn87nd78/XvNO6qCpYa/4ce2vUfT0T/m+kDoUv8 JbupSCY6X5nQ4r4qc/9auEp4hKsjiiguxXHuXoVFOPN50aYbkr3giOAOXLkKZgAAAAAAAA== --Apple-Mail-7-628430300-- --===============1026573104== 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 --===============1026573104==-- From pcn-bounces@ietf.org Mon Jan 29 04:08:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSVN-0003qY-1b; Mon, 29 Jan 2007 04:08:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSVL-0003qT-3P for pcn@ietf.org; Mon, 29 Jan 2007 04:08:47 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBSVH-0004O0-DM for pcn@ietf.org; Mon, 29 Jan 2007 04:08:47 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0T96QAb005492 for ; Mon, 29 Jan 2007 11:06:38 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 11:08:27 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 11:08:26 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: pcn@ietf.org Message-Id: From: ext Lars Eggert Date: Mon, 29 Jan 2007 11:08:37 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 09:08:26.0826 (UTC) FILETIME=[09402AA0:01C74385] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Subject: [PCN] 2nd charter text update X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0150269091==" Errors-To: pcn-bounces@ietf.org --===============0150269091== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-628473066; protocol="application/pkcs7-signature" --Apple-Mail-8-628473066 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Congestion and Pre-Congestion Notification (PCN) Chair(s): tbd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established flows within a network domain when congestion is imminent or existing. These mechanisms operate at the domain edge, based on aggregated congestion and pre-congestion signals from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior routers and the encoding of the congestion signals. Reaction mechanisms at the edge include flow admission and flow preemption. The WG may produce informational documents that describe how specific quality-of-service policies can be implemented using a combination of these mechanisms. The PCN WG will specify the following components of an integrated flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission, preemption or rate adaption, based on aggregated (pre-)congestion information The WG focuses on the overall architecture and the marking behavior and signaling interface needed to realize it. Standards-track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The initial scope of the PCN WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are PCN-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ regions, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG should consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational) --Apple-Mail-8-628473066 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkwOTA4MzhaMCMGCSqGSIb3DQEJBDEWBBQoO2UEyEdodi/G 0y5b48SmUXDUzDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAbshh9KzEtaEy0EAat1FjacS0dgL9H+aInc+W28jtBaOExsC+7G46 o9hNRknoci/F+J3z+JL2ViTYQybcrllX+GQ9W3InnwoDHyGe7fQ7o3fXb5mWfsL4sj/i32G4qRZX gvmDM6zGKoNDsfT6g/kEIQUZeEREnOY8WVbur4zMkqp6O+gu/8eGCnclk/MiNX37nbfbZMHooICN FFBP7DVp2nj1G5ndxV2E3cUyuWlhyYIh6DnvzQxh1ba5WGWwpJAHRTMZBW9YMTzRXniPKH0nYsI8 Up/H7Q2bzbanmyBgr3kl/rToc7fDhC56qrl7LfPj5EvVn9lvr6JG2czOCLp7zQAAAAAAAA== --Apple-Mail-8-628473066-- --===============0150269091== 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 --===============0150269091==-- From pcn-bounces@ietf.org Mon Jan 29 04:37:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSxW-0007uU-16; Mon, 29 Jan 2007 04:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSxU-0007uJ-QF for pcn@ietf.org; Mon, 29 Jan 2007 04:37:52 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBSxS-0008S8-9V for pcn@ietf.org; Mon, 29 Jan 2007 04:37:52 -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 l0T9bBWD010551; Mon, 29 Jan 2007 10:37:23 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" , References: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> <9671A92C3C8B5744BC97F855F7CB64650E562300@zcarhxm1.corp.nortel.com> Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 10:37:23 +0100 Message-ID: <000c01c74389$1a6314b0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdAUc0vwsHQ1a70Qz6/ObSb1A/8SQC/UQRwAA3Z8TA= In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E562300@zcarhxm1.corp.nortel.com> X-Spam-Score: 0.094 () 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]); Mon, 29 Jan 2007 10:37:24 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 I agree with Jozef. In my opinion, during the IETF in San Diego one could find a consensus to consider the application aware (pre-)congestion as being in the scope of this WG. Furthermore, also in the e-mail discussions, I did not encounter a severe objection on introducing the application aware (pre-)congestion as being in the scope of this WG. I would very much appreciate if you at least could include the following (modified proposal) of Jozef: "the PCN WG will define requirements for conveying (pre-)congestion information from the receiver to the sender and the actions that both the receiving end host or gateway and sending end host or gateway should perform." In addition to this I have another comment on the charter description. Regarding the following paragraph: "After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ regions, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG should consider their requirements to design components that are sufficiently general to support such extensions in the future." First you mention: "The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion." And then you say: "The details of these work items are outside the scope of the initial phase; but the WG should consider their requirements to design components that are sufficiently general to support such extensions in the future." I think that the two above sentences contradict each other some how. What you actually say in the second sentence is that the requirements of the flow-rate adaptation during times of congestion should be considered to design components that are sufficiently general to support such extensions in the future. However, in the first paragraph you mention that flow-rate adaptation during times of congestion might be considered, but it is not sure that this will happen. I will very much appreciate if you could change the following sentence: Please change from: "The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion." INTO: "The WG should consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example is the flow-rate adaptation (rather than flow admission/preemption) during times of congestion." Best Regards, Georgios > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: maandag 29 januari 2007 3:47 > To: Lars Eggert; pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope > > Lars, > Do not understand why application aware (pre-)congestion is > out of scope? At the BOF in San Diego and on the PCN mailing > list there was support for it with people will to work on it. > Specifically what I would like to add to scope in the PCN > charter is that "the PCN WG will define requirements for > conveying (pre-)congestion information from the receiver to > the sender and the actions that both the receiving host and > sending host should perform." > > Regards, Joe > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: January 25, 2007 2:23 AM > To: pcn@ietf.org > Subject: [PCN] charter text update > > (I thought I had sent this several days ago, but it > apparently never made it to the list?) > > Hi, > > below is a modified version of the PCN charter posted to this > list a while ago. I believe it reflects the consensus after > the face-to-face and mailing list discussions in and after Montreal. > > Compared to the earlier version, the major changes are: > > - removal of SIP, application-based and PW deployment scenarios > - stronger language on assumptions and scope > - refactored deliverables and milestones > - name change (don't feel strongly about this) > > Please send your comments to the list. > > 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 Mon Jan 29 05:09:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTS6-0003vq-8z; Mon, 29 Jan 2007 05:09:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTS5-0003tA-8B for pcn@ietf.org; Mon, 29 Jan 2007 05:09:29 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBTS3-0004zk-Rg for pcn@ietf.org; Mon, 29 Jan 2007 05:09:29 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TA9NYk026343 for ; Mon, 29 Jan 2007 05:09:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] 2nd charter text update Date: Mon, 29 Jan 2007 12:09:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 2nd charter text update Thread-Index: AcdDhTKAk2dD4l2TSB63mPrz6GYVuQACALqA References: From: "Romascanu, Dan \(Dan\)" To: "ext Lars Eggert" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 previous version of the charter proposal included:=20 7. an analysis of the manageability issues of a PCN region As well as July 2007 initial manageability issues document Internet Draft ... Nov 2007 submit manageability issues document to IESG for approval as informational RFC=20 When and why did those disappear?=20 Dan =20 =20 > -----Original Message----- > From: ext Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Monday, January 29, 2007 11:09 AM > To: pcn@ietf.org > Subject: [PCN] 2nd charter text update >=20 > Congestion and Pre-Congestion Notification (PCN) >=20 > Chair(s): > tbd >=20 > Transport Area Director(s): > Magnus Westerlund > Lars Eggert >=20 > Transport Area Advisor: > Lars Eggert >=20 > Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html >=20 >=20 > Description of Working Group: >=20 > The Congestion and Pre-Congestion Notification (PCN) working=20 > group develops mechanisms to protect the quality-of-service=20 > of established flows within a network domain when congestion=20 > is imminent or existing. These mechanisms operate at the=20 > domain edge, based on aggregated congestion and=20 > pre-congestion signals from within the domain. The focus of=20 > the WG is on developing standards for the marking behavior of=20 > the interior routers and the encoding of the congestion=20 > signals. Reaction mechanisms at the edge include flow=20 > admission and flow preemption. The WG may produce=20 > informational documents that describe how specific=20 > quality-of-service policies can be implemented using a=20 > combination of these mechanisms. >=20 > The PCN WG will specify the following components of an=20 > integrated flow admission and preemption mechanism: >=20 > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals >=20 > (2) conditions under which interior routers generate > (pre-)congestion signals >=20 > (3) encoding and transport of (pre-)congestion signals > to the appropriate ingress routers of the network domain >=20 > (4) edge router control mechanisms for flow admission,=20 > preemption or > rate adaption, based on aggregated (pre-)congestion=20 > information >=20 > The WG focuses on the overall architecture and the marking=20 > behavior and signaling interface needed to realize it.=20 > Standards-track protocols and mechanisms are only developed=20 > where necessary for interoperability. For other components of=20 > the architecture, the WG may document examples or provide=20 > recommended solutions in informational documents. >=20 >=20 > The initial scope of the PCN WG is restricted in the following ways: >=20 > (A) develop these components for a single DiffServ region, > where all edge and interior routers are PCN-enabled > and mutually trust each other >=20 > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing=20 > or shaping >=20 > (C) the number of flows across any potential aggregation=20 > bottleneck > is sufficiently large for stateless, statistical=20 > mechanisms to be > effective >=20 > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits >=20 > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > etc.) > is out of scope >=20 > After completion of the initial phase, the PCN WG may=20 > re-charter to develop solutions for scenarios where some of=20 > these restrictions are not in place. It may also re-charter=20 > to consider applying the PCN mechanisms to additional=20 > deployment scenarios (operation over concatenated DiffServ=20 > regions, PCN-aware application mechanisms, etc.). The WG may=20 > also consider to investigate additional response mechanisms=20 > that act on (pre-)congestion signals. One example could be=20 > flow-rate adaptation (rather than flow admission/preemption)=20 > during times of congestion. The details of these work items=20 > are outside the scope of the initial phase; but the WG should=20 > consider their requirements to design components that are=20 > sufficiently general to support such extensions in the future. >=20 >=20 > Goals and Milestones: >=20 > Jul 2007 Flow Admission and Preemption Architecture > (Informational) >=20 > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region > (Informational) >=20 > Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) >=20 > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) >=20 > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed=20 > Standard) >=20 > Mar 2008 Transport from Flow Egress in a DiffServ Region of =20 > information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) >=20 > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) >=20 >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 05:38:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTtl-00078m-Tv; Mon, 29 Jan 2007 05:38:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTtk-00078c-Mm for pcn@ietf.org; Mon, 29 Jan 2007 05:38:04 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBTtb-0001lB-8r for pcn@ietf.org; Mon, 29 Jan 2007 05:38:04 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9331220625; Mon, 29 Jan 2007 11:37:50 +0100 (CET) X-AuditID: c1b4fb3c-af7c7bb0000007de-34-45bdce7e0847 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A6A72086B; Mon, 29 Jan 2007 11:37:50 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 11:37:50 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 11:37:49 +0100 Message-ID: <45BDCE7D.8010208@ericsson.com> Date: Mon, 29 Jan 2007 11:37:49 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [PCN] charter, addition to scope References: <63C04CB2-176D-46D5-BEE8-792B3B2E60B4@nokia.com> <9671A92C3C8B5744BC97F855F7CB64650E562300@zcarhxm1.corp.nortel.com> <000c01c74389$1a6314b0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <000c01c74389$1a6314b0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2007 10:37:50.0058 (UTC) FILETIME=[85FC6CA0:01C74391] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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, Georgios and Jozef, another reason for this charters look is that we ADs don't want the WG to try to boil the ocean. That is why we try to constrain the initial problem to solve to the most fundamental central parts of the problem. We do want the WG to be able to complete its initial milestones within a reasonable timeframe. If that is achieved and there still are interest and energy, I at least are very positive to a rechartering. I know that this produce some issues when trying to draw up requirements for possible extension which hasn't been worked through. However to be realistic, we rather see a product that works for at least one set a problem then having no solution for many problems. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 05:49:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBU4q-0003uv-BJ; Mon, 29 Jan 2007 05:49:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBU4p-0003uq-IL for pcn@ietf.org; Mon, 29 Jan 2007 05:49:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBU4k-0003Ww-2Z for pcn@ietf.org; Mon, 29 Jan 2007 05:49:31 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1BD68214EA; Mon, 29 Jan 2007 11:46:58 +0100 (CET) X-AuditID: c1b4fb3e-aeed1bb0000007e1-46-45bdd0a215af Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C75B214E2; Mon, 29 Jan 2007 11:46:58 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 11:46:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 11:46:57 +0100 Message-ID: <582B939025E978418C0B92DC134ADE9F5E2B05@esealmw106.eemea.ericsson.se> In-Reply-To: <45BDCE7D.8010208@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDkZsYOJ5IgDsNTQ6/uYsh0Yi+zAAABRKg From: "Lars Westberg \(KI/EAB\)" To: "Magnus Westerlund \(KI/EAB\)" , "Georgios Karagiannis" X-OriginalArrivalTime: 29 Jan 2007 10:46:57.0766 (UTC) FILETIME=[CC720860:01C74392] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org My suggestion is to concentrate on describing the three involved functions:=20 1) traffic measurement function 2) protocol marking 3) triggering on admission control and the "communication" between them. We could in principle do that without any implementation constraints My suggestion is that all of the algorithmic stuff are excluded from the basic protocol specification as we have made in RMD. Algorithm is targetted the implementation space. I think that the protocol should be support any algorithm. The only difference will become the perfomance of them. I am very worried that we will get into discussion about the favourite algorithm.=20 I therefore suggest that the charter should have an explicit statement that algorithms for marking should be excluded from the working group documents Regards Lasse =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: den 29 januari 2007 11:38 To: Georgios Karagiannis Cc: pcn@ietf.org Subject: Re: [PCN] charter, addition to scope Hi, Georgios and Jozef, another reason for this charters look is that we ADs don't want the WG to try to boil the ocean. That is why we try to constrain the initial problem to solve to the most fundamental central parts of the problem. We do want the WG to be able to complete its initial milestones within a reasonable timeframe. If that is achieved and there still are interest and energy, I at least are very positive to a rechartering. I know that this produce some issues when trying to draw up requirements for possible extension which hasn't been worked through. However to be realistic, we rather see a product that works for at least one set a problem then having no solution for many problems. 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 Mon Jan 29 05:52:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBU7E-0004LC-31; Mon, 29 Jan 2007 05:52:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBU7C-0004L6-Tf for pcn@ietf.org; Mon, 29 Jan 2007 05:51:58 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBU7B-0003qd-Gl for pcn@ietf.org; Mon, 29 Jan 2007 05:51:58 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0TAnZc2003705; Mon, 29 Jan 2007 12:49:58 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 12:51:34 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 12:51:47 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8806A59C-6D27-4902-B452-DA75D270998D@nokia.com> From: Lars Eggert Subject: Re: [PCN] 2nd charter text update Date: Mon, 29 Jan 2007 12:51:45 +0200 To: "ext Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 10:51:47.0349 (UTC) FILETIME=[790CE450:01C74393] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0754649519==" Errors-To: pcn-bounces@ietf.org --===============0754649519== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-634661204; protocol="application/pkcs7-signature" --Apple-Mail-13-634661204 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-29, at 12:09, ext Romascanu, Dan (Dan) wrote: > When and why did those disappear? Good point. I had sort of assumed that these were part of the architecture document. Do you see a specific need for a standalone document, or should I simply make it a bit clearer in the text where those considerations are to be addressed? Lars --Apple-Mail-13-634661204 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkxMDUxNDZaMCMGCSqGSIb3DQEJBDEWBBRwzeRxknU0ffz2 O8jnpf4mj18rizCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAwJ1WWpNCjeyQL3hiGFZtSuFqgz9CzCqUKGmM0CksJXYj27DmHrbb gpPfTAPrn5+7PTj0+lVL5cdPoSilGsOrObAxlhBmoy+d7GMZo894s7cxY6gL4AjdnD8YRpBSrTLO JgnETyxOvtP1Tq0HaaoOAHsSKnkbFSW3Ip6c9bukIjgnWp0XKSgexaGBicU8Fgq2HuvM/3+USYoi 8gvkTZjdgCL+0nMVySAv2fG5uapae1rLOwoF7cXXLwMKKJY3VK8y+3EOmIvus/gS5ccjUUKqvq9u oInmHSTrBhmWUSv6Kj4bt1ammYc/Hk3Q86/FCAUCtVmt6Z6FBF18M16X0b17jAAAAAAAAA== --Apple-Mail-13-634661204-- --===============0754649519== 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 --===============0754649519==-- From pcn-bounces@ietf.org Mon Jan 29 05:55:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUAt-0005wN-8S; Mon, 29 Jan 2007 05:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUAs-0005wI-DX for pcn@ietf.org; Mon, 29 Jan 2007 05:55:46 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBUAo-0004Nb-Vu for pcn@ietf.org; Mon, 29 Jan 2007 05:55:46 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0TArMr8012485; Mon, 29 Jan 2007 12:53:34 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 12:55:17 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 12:55:18 +0200 In-Reply-To: <582B939025E978418C0B92DC134ADE9F5E2B05@esealmw106.eemea.ericsson.se> References: <582B939025E978418C0B92DC134ADE9F5E2B05@esealmw106.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 12:55:16 +0200 To: "ext Lars Westberg (KI/EAB)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 10:55:18.0068 (UTC) FILETIME=[F6A60F40:01C74393] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070129125334-3024DBB0-744C03E0/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589267226==" Errors-To: pcn-bounces@ietf.org --===============1589267226== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-634871797; protocol="application/pkcs7-signature" --Apple-Mail-14-634871797 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > I therefore suggest that the charter should have an explicit statement > that algorithms for marking should be excluded from the working group > documents I don't see how interior routers that implement different marking algorithms within one PCN region result in a system where the edge can know how to react. Or am I missing something? Lars --Apple-Mail-14-634871797 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkxMDU1MTZaMCMGCSqGSIb3DQEJBDEWBBRRvH/L/x5Mpwc3 X7T74uKHkcZQNzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAteyUaf4nlseJYAoX6h65cGaEkSMnKimrhFI9I4eYtuA93mtgbfIv RbVkGJvW/r5Dv20QOZuPM7Yqj/07C/DGLeQvita8WCF6hKS+hQSNz8+pIyIuHHreoRulBmfwFl3i +etmd0Wl8bvbJ6+3BBjpF0PWcY82evNf/LjsxLgCzatV/buxY7L81E+ucmukCtLJj1rVd8odYBFG fVKIyXFt6C3JMdTjXBpfDbpELckH8nnUAILFav4XK13dEXpZORuwiCm/lDaWrcKJTX1+HE6TtWFN aCJ2leSvDEwN4TP54DhLNZa2iP1QxTshfjLhSejocIgKSvPS1YTQWk3GtjnW6wAAAAAAAA== --Apple-Mail-14-634871797-- --===============1589267226== 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 --===============1589267226==-- From pcn-bounces@ietf.org Mon Jan 29 06:18:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUX3-00070q-Jw; Mon, 29 Jan 2007 06:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUX1-00070g-TB for pcn@ietf.org; Mon, 29 Jan 2007 06:18:39 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBUX0-0008Ut-KS for pcn@ietf.org; Mon, 29 Jan 2007 06:18:39 -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 l0TBIa1b020512 for ; Mon, 29 Jan 2007 06:18:37 -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] 2nd charter text update Date: Mon, 29 Jan 2007 13:18:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 2nd charter text update Thread-Index: AcdDk4RfLcaqUW0XQgawhyD5p0JcugAApoag References: <8806A59C-6D27-4902-B452-DA75D270998D@nokia.com> From: "Romascanu, Dan \(Dan\)" To: "Lars Eggert" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org It's up to the working group to decide whether they want to make out of the manageability considerations a separate document or include them in the architecture or other document. The main point right now is to say specifically in the charter what they decided to do.=20 Dan =20 =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Monday, January 29, 2007 12:52 PM > To: Romascanu, Dan (Dan) > Cc: pcn@ietf.org > Subject: Re: [PCN] 2nd charter text update >=20 > On 2007-1-29, at 12:09, ext Romascanu, Dan (Dan) wrote: > > When and why did those disappear? >=20 > Good point. I had sort of assumed that these were part of the=20 > architecture document. Do you see a specific need for a=20 > standalone document, or should I simply make it a bit clearer=20 > in the text where those considerations are to be addressed? >=20 > Lars >=20 >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 07:04:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVFE-0007lA-2E; Mon, 29 Jan 2007 07:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVFD-0007l4-Hg for pcn@ietf.org; Mon, 29 Jan 2007 07:04:19 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBVF4-0001ic-LU for pcn@ietf.org; Mon, 29 Jan 2007 07:04:19 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B5742056B; Mon, 29 Jan 2007 13:03:30 +0100 (CET) X-AuditID: c1b4fb3e-afed3bb0000007e1-44-45bde2923918 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 78EDA2146C; Mon, 29 Jan 2007 13:03:30 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 13:03:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 13:02:59 +0100 Message-ID: <582B939025E978418C0B92DC134ADE9F5E2CE5@esealmw106.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDlAaRvN995WtcRM+Jnm/ktClkVgABZrEg From: "Lars Westberg \(KI/EAB\)" To: "Lars Eggert" X-OriginalArrivalTime: 29 Jan 2007 12:03:02.0102 (UTC) FILETIME=[6D006F60:01C7439D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1097311668==" Errors-To: pcn-bounces@ietf.org --===============1097311668== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="--=_NextPart_DJD_35683592.130259374" ----=_NextPart_DJD_35683592.130259374 Content-Type: multipart/alternative; boundary="--=_NextPart_DJD_35683592.130259274" ----=_NextPart_DJD_35683592.130259274 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Some more explanation As I understand, the purpose with marking is to generate blocking or rejection of resou= rces. There are a few basic pronciple to to it i.e. rate-based marking. Exaclty how admi= ssion control function is measuring the marking is a implementation issue and when and= exactly how the admission control react is is not needed to be described. Only some basi= c marking charactistics are needed.=20 Many algorithms can be used even of the marking method is defined. One example is =22how= you measure the marking?=22 i.e weighted avereraging, fixed window, token bucket...= =2E=20 All of these methods is just an implementation of an measurement algorithm. The main co= nsequence of different algorithms is the level of =22overprovisioning=22 that is nee= ded to cope with the wrong admission control decisions are different. In general, the main problem is depednet of the following parameters:=20 1)rate of admission control request. The rate of admission control request are differ= ent for different scenario:=20 -admission control for trunks=20 -per flow -the sources for admission control (MGW,,,,,) internal functionality and reaso= n for triggereing of a resource request. 2) expectation of utilization. If high utlization is expected,=20 an algorithm with high percision and increased complexity is required 3)what expected fault conditions should be covered by PCN?=20 - should it handle single fault or multiple faults.=20 a) spare capacity for single faults so PCN only=20 cover blocking of new resource request. b) high utlization networks so PCN also must reject ongoing admitted resource= s ? We have done similar things for RMD and I think it is very important to avoid algoritmic d= escription into the specifications.=20 Regards Lasse -----Original Message----- From: Lars Eggert =5Bmailto:lars.eggert=40nokia.com=5D=20 Sent: den 29 januari 2007 11:55 To: Lars Westberg (KI/EAB) Cc: Magnus Westerlund (KI/EAB); Georgios Karagiannis; pcn=40ietf.org Subject: Re: =5BPCN=5D charter, addition to scope On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > I therefore suggest that the charter should have an explicit statement=20 > that algorithms for marking should be excluded from the working group=20 > documents I don't see how interior routers that implement different marking algorithms within o= ne PCN region result in a system where the edge can know how to react. Or am I missing somet= hing? Lars ----=_NextPart_DJD_35683592.130259274 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 3.2//EN=22> RE: =5BPCN=5D charter, addition to scope <=21-- Converted from text/plain format -->

Some more explanation

As I understand, the purpose with marking is to generate blocking o= r rejection of resources. There are a few basic pronciple to to it i.e. rate-based marki= ng. Exaclty how admission control function is measuring the marking is a implementati= on issue and when and exactly how the admission control react is is not needed to be descr= ibed. Only some basic marking charactistics are needed.

Many algorithms can be used even of the marking method is defined. O= ne example is "how you measure the marking?" i.e weighted avereraging, fix= ed window, token bucket....

All of these methods is just an implementation of an measurement al= gorithm. The main consequence of different algorithms is the level of "overprov= isioning" that is needed to cope with the wrong admission control decisions are d= ifferent.

In general, the main problem is depednet of the following paramete= rs:
1)rate of admission control request. The rate of admission contr= ol request are different for different scenario:
        -admission con= trol for trunks
        -per flow
        -the sources fo= r admission control (MGW,,,,,) internal       &n= bsp;    functionality and reason for triggereing of a resource request.

2) expectation of utilization. If high utlization is expected,
        an algorithm wi= th high percision and increased complexity is    required

3)what expected fault conditions should be covered by PCN?
            &nb= sp;   - should it handle single fault or multiple faults. <= /FONT>
            &nb= sp;   a) spare capacity for single faults so PCN only
            &nb= sp;      cover blocking of new resource reques= t.
            &nb= sp;   b) high utlization networks so PCN also must reject o= ngoing              &= nbsp;  admitted resources ?

We have done similar things for RMD and I think it is very important t= o avoid algoritmic description into the specifications.

Regards Lasse

-----Original Message-----
From: Lars Eggert =5Bmailto:lars.eggert=40nokia.com=5D
Sent: den 29 januari 2007 11:55
To: Lars Westberg (KI/EAB)
Cc: Magnus Westerlund (KI/EAB); Georgios Karagiannis; pcn=40i= etf.org
Subject: Re: =5BPCN=5D charter, addition to scope

On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote:=
> I therefore suggest that the charter should have an explicit= statement
> that algorithms for marking should be excluded from the work= ing group
> documents

I don't see how interior routers that implement different marking= algorithms within one PCN region result in a system where the edge can know how to react.= Or am I missing something?

Lars

----=_NextPart_DJD_35683592.130259274 Content-Type: application/rtf Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJs DQp7XGYwXGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7 fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZj aGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xjb2xvcnRibFxyZWQwXGdyZWVuMFxi bHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBhcmRccGxhaW5cZGVm dGFiMzYwIFxmMFxmczIwIFNvbWUgbW9yZSBleHBsYW5hdGlvblxwYXINClxwYXIN CkFzIEkgdW5kZXJzdGFuZCwgdGhlIHB1cnBvc2Ugd2l0aCBtYXJraW5nIGlzIHRv IGdlbmVyYXRlIGJsb2NraW5nIG9yIHJlamVjdGlvbiBvZiByZXNvdXJjZXMuIFRo ZXJlIGFyZSBhIGZldyBiYXNpYyBwcm9uY2lwbGUgdG8gdG8gaXQgaS5lLiByYXRl LWJhc2VkIG1hcmtpbmcuIEV4YWNsdHkgaG93IGFkbWlzc2lvbiBjb250cm9sIGZ1 bmN0aW9uIGlzIG1lYXN1cmluZyB0aGUgbWFya2luZyBpcyBhIGltcGxlbWVudGF0 aW9uIGlzc3VlIGFuZCB3aGVuIGFuZCBleGFjdGx5IGhvdyB0aGUgYWRtaXNzaW9u IGNvbnRyb2wgcmVhY3QgaXMgaXMgbm90IG5lZWRlZCB0byBiZSBkZXNjcmliZWQu IE9ubHkgc29tZSBiYXNpYyBtYXJraW5nIGNoYXJhY3Rpc3RpY3MgYXJlIG5lZWRl ZC4gXHBhcg0KXHBhcg0KTWFueSBhbGdvcml0aG1zIGNhbiBiZSB1c2VkIGV2ZW4g b2YgdGhlIG1hcmtpbmcgbWV0aG9kIGlzIGRlZmluZWQuIE9uZSBleGFtcGxlIGlz ICJob3cgeW91IG1lYXN1cmUgdGhlIG1hcmtpbmc/IiBpLmUgd2VpZ2h0ZWQgYXZl cmVyYWdpbmcsIGZpeGVkIHdpbmRvdywgdG9rZW4gYnVja2V0Li4uLiBccGFyDQpB bGwgb2YgdGhlc2UgbWV0aG9kcyBpcyBqdXN0IGFuIGltcGxlbWVudGF0aW9uIG9m IGFuIG1lYXN1cmVtZW50IGFsZ29yaXRobS4gVGhlIG1haW4gY29uc2VxdWVuY2Ug b2YgZGlmZmVyZW50IGFsZ29yaXRobXMgaXMgdGhlIGxldmVsIG9mICJvdmVycHJv dmlzaW9uaW5nIiB0aGF0IGlzIG5lZWRlZCB0byBjb3BlIHdpdGggdGhlIHdyb25n IGFkbWlzc2lvbiBjb250cm9sIGRlY2lzaW9ucyBhcmUgZGlmZmVyZW50LlxwYXIN ClxwYXINCkluIGdlbmVyYWwsIHRoZSBtYWluIHByb2JsZW0gaXMgZGVwZWRuZXQg b2YgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOiBccGFyDQoxKXJhdGUgb2YgYWRt aXNzaW9uIGNvbnRyb2wgcmVxdWVzdC4gVGhlIHJhdGUgb2YgYWRtaXNzaW9uIGNv bnRyb2wgcmVxdWVzdCBhcmUgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgc2NlbmFy aW86IFxwYXINClx0YWIgLWFkbWlzc2lvbiBjb250cm9sIGZvciB0cnVua3MgXHBh cg0KXHRhYiAtcGVyIGZsb3dccGFyDQpcdGFiIC10aGUgc291cmNlcyBmb3IgYWRt aXNzaW9uIGNvbnRyb2wgKE1HVywsLCwsKSBpbnRlcm5hbCBcdGFiIFx0YWIgICBm dW5jdGlvbmFsaXR5IGFuZCByZWFzb24gZm9yIHRyaWdnZXJlaW5nIG9mIGEgcmVz b3VyY2UgcmVxdWVzdC5ccGFyDQoyKSBleHBlY3RhdGlvbiBvZiB1dGlsaXphdGlv bi4gSWYgaGlnaCB1dGxpemF0aW9uIGlzIGV4cGVjdGVkLCBccGFyDQpcdGFiIGFu IGFsZ29yaXRobSB3aXRoIGhpZ2ggcGVyY2lzaW9uIGFuZCBpbmNyZWFzZWQgY29t cGxleGl0eSBpcyBcdGFiIHJlcXVpcmVkXHBhcg0KXHBhcg0KMyl3aGF0IGV4cGVj dGVkIGZhdWx0IGNvbmRpdGlvbnMgc2hvdWxkIGJlIGNvdmVyZWQgYnkgUENOPyBc cGFyDQpcdGFiIFx0YWIgLSBzaG91bGQgaXQgaGFuZGxlIHNpbmdsZSBmYXVsdCBv ciBtdWx0aXBsZSBmYXVsdHMuIFxwYXINClx0YWIgXHRhYiBhKSBzcGFyZSBjYXBh Y2l0eSBmb3Igc2luZ2xlIGZhdWx0cyBzbyBQQ04gb25seSBccGFyDQpcdGFiIFx0 YWIgICAgY292ZXIgYmxvY2tpbmcgb2YgbmV3IHJlc291cmNlIHJlcXVlc3QuXHBh cg0KXHRhYiBcdGFiIGIpIGhpZ2ggdXRsaXphdGlvbiBuZXR3b3JrcyBzbyBQQ04g YWxzbyBtdXN0IHJlamVjdCBvbmdvaW5nIFx0YWIgXHRhYiAgICAgYWRtaXR0ZWQg cmVzb3VyY2VzID9ccGFyDQpccGFyDQpXZSBoYXZlIGRvbmUgc2ltaWxhciB0aGlu Z3MgZm9yIFJNRCBhbmQgSSB0aGluayBpdCBpcyB2ZXJ5IGltcG9ydGFudCB0byBh dm9pZCBhbGdvcml0bWljIGRlc2NyaXB0aW9uIGludG8gdGhlIHNwZWNpZmljYXRp b25zLiBccGFyDQpccGFyDQpSZWdhcmRzIExhc3NlXHBhcg0KXHBhcg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS1ccGFyDQpGcm9tOiBMYXJzIEVnZ2VydCBbbWFp bHRvOmxhcnMuZWdnZXJ0QG5va2lhLmNvbV0gXHBhcg0KU2VudDogZGVuIDI5IGph bnVhcmkgMjAwNyAxMTo1NVxwYXINClRvOiBMYXJzIFdlc3RiZXJnIChLSS9FQUIp XHBhcg0KQ2M6IE1hZ251cyBXZXN0ZXJsdW5kIChLSS9FQUIpOyBHZW9yZ2lvcyBL YXJhZ2lhbm5pczsgcGNuQGlldGYub3JnXHBhcg0KU3ViamVjdDogUmU6IFtQQ05d IGNoYXJ0ZXIsIGFkZGl0aW9uIHRvIHNjb3BlXHBhcg0KXHBhcg0KT24gMjAwNy0x LTI5LCBhdCAxMjo0NiwgZXh0IExhcnMgV2VzdGJlcmcgKEtJL0VBQikgd3JvdGU6 XHBhcg0KPiBJIHRoZXJlZm9yZSBzdWdnZXN0IHRoYXQgdGhlIGNoYXJ0ZXIgc2hv dWxkIGhhdmUgYW4gZXhwbGljaXQgc3RhdGVtZW50IFxwYXINCj4gdGhhdCBhbGdv cml0aG1zIGZvciBtYXJraW5nIHNob3VsZCBiZSBleGNsdWRlZCBmcm9tIHRoZSB3 b3JraW5nIGdyb3VwIFxwYXINCj4gZG9jdW1lbnRzXHBhcg0KXHBhcg0KSSBkb24n dCBzZWUgaG93IGludGVyaW9yIHJvdXRlcnMgdGhhdCBpbXBsZW1lbnQgZGlmZmVy ZW50IG1hcmtpbmcgYWxnb3JpdGhtcyB3aXRoaW4gb25lIFBDTiByZWdpb24gcmVz dWx0IGluIGEgc3lzdGVtIHdoZXJlIHRoZSBlZGdlIGNhbiBrbm93IGhvdyB0byBy ZWFjdC4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz9ccGFyDQpccGFyDQpMYXJz XHBhcg0KXHBhcg0KfQ== ----=_NextPart_DJD_35683592.130259274-- ----=_NextPart_DJD_35683592.130259374 Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIIMhAYJKoZIhvcNAQcCoIIMdTCCDHECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCCb0wggOlMIICjaADAgECAgRD2XAfMA0GCSqGSIb3DQEBBQUAMBMxETAP BgNVBAoTCEVyaWNzc29uMB4XDTA2MTAyNTA2MzUwNFoXDTExMTAyNTA3MDUwNFow JDERMA8GA1UEChMIRXJpY3Nzb24xDzANBgNVBAMTBkVSQUxHVzCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA3/duHnIjoajZGQgcGeO5iLx40PX0inZzL1c4vn3V WrdJqiEc+pR+x+sJB5OG6wjvHdkADFpZ+JBPW43zbKPurj0Yu2mxN7g1XULEe5yI o99FYWBpM5kg0kUoeRJk3/KXk1znKnfXqbVAbVvJ8hfXuvQ8ub/Xs+XDMesWuUq1 hh8CAwEAAaOCAXIwggFuMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDA2MTAy NTA2MzUwNFqBDzIwMTAwNDI1MTEwNTA0WjBYBglghkgBhvprHgEESwxJVGhlIHBy aXZhdGUga2V5IGNvcnJlc3BvbmRpbmcgdG8gdGhpcyBjZXJ0aWZpY2F0ZSBtYXkg aGF2ZSBiZWVuIGV4cG9ydGVkLjATBgNVHSAEDDAKMAgGBiqFcBcKAjAlBgNVHREE HjAcgRpsYXJzLndlc3RiZXJnQGVyaWNzc29uLmNvbTA2BgNVHR8ELzAtMCugKaAn pCUwIzERMA8GA1UEChMIRXJpY3Nzb24xDjAMBgNVBAMTBUNSTDYzMB8GA1UdIwQY MBaAFMQofJlEh2JceRLZdW6TS8BPJsilMB0GA1UdDgQWBBRyHnz8ifch14OJqgWJ rXW7MinfwDAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjEDAgSwMA0G CSqGSIb3DQEBBQUAA4IBAQB1bEjsgeG69ZPF4jk6HEDFQoqAKPPLSMnbkA8u6CIJ cOf5RheEc+OiRr27182FK/zqbtmgjscgk5R8I836SdPtSFR4N2usj/rzNKsjIRmo yG3nNATLP9GwEOAGfXpSh5hRsgHgw1ie3C8hRbK7bkldp1CstN2KIVUROt9Yk5Er ChAIl+Jca22G2Yg1Jdik8jSjYc+vrufmOEIrgt2DkYTq0nNGQpw57SaLsp6jRpLu 29nG1RZIj15LxSSutpokXHTYZzmp9ZDqGs4T86rhJgAYPZJJohN7gC7hLnNK+TI+ /n5SG+0X8F7KSesQanDadT+KALPW6yxG3Lh+Ksw7GQQnMIIDeDCCAmCgAwIBAgIE Q9lwIDANBgkqhkiG9w0BAQUFADATMREwDwYDVQQKEwhFcmljc3NvbjAeFw0wNjEw MjUwNjM1MDRaFw0xMTEwMjUwNzA1MDRaMCQxETAPBgNVBAoTCEVyaWNzc29uMQ8w DQYDVQQDEwZFUkFMR1cwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKabIUh2 kvn4qMow9vETSxqvLHWOVsKM+gya85ERqHEG1CdmSv2Er0GxpzEsXWAgETlit7C4 RdqCGHfOXneqO5MSSQinRjF1i4NQpYg8mlhamANunBdb5Iv2rOsSKAygdgjazkK8 kaiposNxxKt2qlMVR1sRuNbPyF13e9albBNZAgMBAAGjggFFMIIBQTALBgNVHQ8E BAMCBSAwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3JyZXNwb25k aW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w EwYDVR0gBAwwCjAIBgYqhXAXCgIwJQYDVR0RBB4wHIEabGFycy53ZXN0YmVyZ0Bl cmljc3Nvbi5jb20wNgYDVR0fBC8wLTAroCmgJ6QlMCMxETAPBgNVBAoTCEVyaWNz c29uMQ4wDAYDVQQDEwVDUkw2MzAfBgNVHSMEGDAWgBTEKHyZRIdiXHkS2XVuk0vA TybIpTAdBgNVHQ4EFgQUDohOak6kLaSGA1oyDdxFIbHVCU8wCQYDVR0TBAIwADAZ BgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEA1gc9 3M5sartSDIRVTHfV+jBQEF0u/bLj8lp7ahR+Vrv6lxfaKI+mV6OtOzQIiOk5FSar 1dytBtRVS+jOgjoPPQU+gvuXTHEJGMw8Jx2Z/msi0Lv8RvO3y8b2qRn9HcsWlHNE ythzX+zQeKOaUsHyTi8UC5XdJ2AD7Ss+hldQ7s5pPcE0h+DRVP+ertobRD6XB/op 5N3tO6HhPY0b0HdGsk4lT+sS9hN535JzRciJCnpD6pAYXQO17gWRpfYfVti+hbJe LqSfjgTvqyz9BuIopfvOeltg4fKAsY5pAorq8Ovjdacxx3Axm3YoKzrHOC/RVS0n 5Ztm5Ohh2n2nHpCDaDCCApQwggH9oAMCAQICBEV6t44wDQYJKoZIhvcNAQEFBQAw EzERMA8GA1UEChMIRXJpY3Nzb24wHhcNMDYxMjA5MTUxMDQ5WhcNMjYxMjA5MTU0 MDQ5WjATMREwDwYDVQQKEwhFcmljc3NvbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAy8Lb0C3v4ddAPc+xSrdKOcvPim69a2YF9ICxH97d4Qw/5ssyA2/wF2Xh q4FVE43il3PoCWccyiyIejVUJaypSnzX4rB0oh+0e+WaG58bKRByz+jflxq+TZ+8 9ddj62vBiOIZFZrb1HJYxoLP0VLrQ4gvX4bbSxgXHuhWFhZkAAUCAwEAAaOB9DCB 8TARBglghkgBhvhCAQEEBAMCAAcwNQYDVR0fBC4wLDAqoCigJqQkMCIxETAPBgNV BAoTCEVyaWNzc29uMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQkMCKADzIwMDYxMjA5 MTUxMDQ5WoEPMjAyNjEyMDkxNTQwNDlaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAW gBTN7XMIkIHZL+2izGRK0mEp20NxLjAdBgNVHQ4EFgQUze1zCJCB2S/tosxkStJh KdtDcS4wDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNy4xOjQuMAMC BJAwDQYJKoZIhvcNAQEFBQADgYEAANG/DJ/RSWdIeS187y7BJ88xVdCvOI9Y5aZ9 ozOmy476TbTchE691m8UrWyddCS5s5VCLmmcf38HST+H+Bk7d0TmQuSs1a7K/skg kwPSAZP3qXKhLg1wFXcIcf22fXz8enuN6++SeYIlvOAtZGlAkgCkXhGAORlChQgA LnGXjw0xggKPMIICiwIBATAbMBMxETAPBgNVBAoTCEVyaWNzc29uAgRD2XAfMAkG BSsOAwIaBQCgggHKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA3MDEyOTEyMDI1OVowIwYJKoZIhvcNAQkEMRYEFBw1rWArg7C9KF9G FUsRyDu8+FlAMCwGCyqGSIb3DQEJEAILMR2gGzATMREwDwYDVQQKEwhFcmljc3Nv bgIEQ9lwIDCCATsGCSqGSIb3DQEJDzGCASwwggEoMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEARYwCwYJYIZIAWUDBAECMA8GCSqGSIb2fQdCCgICAIAwDgYIKoZIhvcN AwICAgCAMAoGCCqGSIb3DQMHMA0GCysGAQQBgTwHAQECMA4GCSqGSIb2fQdCCgIB KDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAHBgUrDgMCGjAKBggqhkiG9w0CBTAL BglghkgBZQMEAgEwCwYJKoZIhvcNAQEBMAsGCSqGSIb3DQEBBzAJBgcqhkjOOAQB MAkGByqGSM49AgEwCwYJKoZIhvcNAQEFMAsGCSqGSIb3DQEBBDAJBgcqhkjOOAQD MAkGByqGSM49BAEwCwYJKoZIhvcNAQELMAwGCiqGSIb3DQEJDwEwDQYJKoZIhvcN AQEBBQAEgYC9LYKoZPOUlNJs080qnavl5NDl66kHMSF2gGFp4VFQSQrULPFveKxy HnzJRKFFTkXPKx4II3u1G0uAFvYsr9AazSSoEdJ2Nfwbgek9rlnInyuVqgkrwiQY Ga/lIDBJEWJDUK/Pvfq++ARvB/rJ3W2AOn5L92iJZh4t0Mp/WXeSQg== ----=_NextPart_DJD_35683592.130259374-- --===============1097311668== 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 --===============1097311668==-- From pcn-bounces@ietf.org Mon Jan 29 09:21:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXNa-000323-09; Mon, 29 Jan 2007 09:21:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXNY-00031s-NY for pcn@ietf.org; Mon, 29 Jan 2007 09:21:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXNW-0001gW-D6 for pcn@ietf.org; Mon, 29 Jan 2007 09:21:04 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 Jan 2007 06:21:01 -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 l0TEL1Af019930; Mon, 29 Jan 2007 06:21:01 -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 l0TEKqnX002380; Mon, 29 Jan 2007 06:21:01 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 09:20:59 -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] charter, addition to scope Date: Mon, 29 Jan 2007 09:20:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDlBM8m0/kfX38RbedQeklqUXwcQAG8Dgw From: "Anna Charny \(acharny\)" To: "Lars Eggert" , "ext Lars Westberg \(KI/EAB\)" X-OriginalArrivalTime: 29 Jan 2007 14:20:59.0474 (UTC) FILETIME=[B2B32B20:01C743B0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1320; t=1170080461; x=1170944461; c=relaxed/simple; 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]=20charter,=20addition=20to=20scope |Sender:=20; bh=dVi4l3lCKAUAv1YDEQMxwK2FXLjojXIu/9jzjFS3mF0=; b=JsK40XGgUH/ejc/bxhJxTfaI1OWBVv8jNsUXZAUxPOmyD2ISnKRNRF7kD7hrWSlUByGtQdS0 1VpszxEm37U+RyyiW6Fo3GKVI8crIvvEXNqarXG4urrwllCMhR3sW4PJ; 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars and Lars, It seems to me that we should neither say that the algorithms are explicitly excluded, not try to standardize anything in the algorithms beyond what is needed for interoperability. The interoperability requirements should in my opinion reflect the meaning/semantics of the marking and hence the appropriate reaction of the edge devices to this marking, and that in turn may restrict the range of flexibility of the implementation/detailed algorithm. One of the tasks of the WG would be to decide exactly what that means. Sorry if this is stating the obvious. Anna=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Monday, January 29, 2007 5:55 AM > To: ext Lars Westberg (KI/EAB) > Cc: pcn@ietf.org > Subject: Re: [PCN] charter, addition to scope >=20 > On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > > I therefore suggest that the charter should have an=20 > explicit statement=20 > > that algorithms for marking should be excluded from the=20 > working group=20 > > documents >=20 > I don't see how interior routers that implement different=20 > marking algorithms within one PCN region result in a system=20 > where the edge can know how to react. Or am I missing something? >=20 > Lars >=20 >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 09:32:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXZ2-0007b0-L2; Mon, 29 Jan 2007 09:32:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXZ0-0007ZX-NT for pcn@ietf.org; Mon, 29 Jan 2007 09:32:54 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXYu-0003CN-5t for pcn@ietf.org; Mon, 29 Jan 2007 09:32:54 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C206F21580; Mon, 29 Jan 2007 15:32:03 +0100 (CET) X-AuditID: c1b4fb3e-aeed1bb0000007e1-02-45be05633f9f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B276C21571; Mon, 29 Jan 2007 15:32:03 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 15:32:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 15:32:02 +0100 Message-ID: <582B939025E978418C0B92DC134ADE9F5E2F9F@esealmw106.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDlBM8m0/kfX38RbedQeklqUXwcQAG8DgwAAA/V5A= From: "Lars Westberg \(KI/EAB\)" To: "Anna Charny \(acharny\)" , "Lars Eggert" X-OriginalArrivalTime: 29 Jan 2007 14:32:03.0132 (UTC) FILETIME=[3E4557C0:01C743B2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Overprovisioning is a solution that can be solved with all different algorithmic solution, so the gain with PCN (as far I can see) is mainly bandwidth efficiency. So I 100%-agreee that we should only standardize things that are neccessary and visible on the interface between different routers. I though of characteristics like: rate-based marking i.e that the marking is perform with a certin average rate given a certain average overload. Regards Lasse -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: den 29 januari 2007 15:21 To: Lars Eggert; Lars Westberg (KI/EAB) Cc: pcn@ietf.org Subject: RE: [PCN] charter, addition to scope Hi Lars and Lars, It seems to me that we should neither say that the algorithms are explicitly excluded, not try to standardize anything in the algorithms beyond what is needed for interoperability. The interoperability requirements should in my opinion reflect the meaning/semantics of the marking and hence the appropriate reaction of the edge devices to this marking, and that in turn may restrict the range of flexibility of the implementation/detailed algorithm. One of the tasks of the WG would be to decide exactly what that means. Sorry if this is stating the obvious. Anna=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Monday, January 29, 2007 5:55 AM > To: ext Lars Westberg (KI/EAB) > Cc: pcn@ietf.org > Subject: Re: [PCN] charter, addition to scope >=20 > On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > > I therefore suggest that the charter should have an > explicit statement > > that algorithms for marking should be excluded from the > working group > > documents >=20 > I don't see how interior routers that implement different marking=20 > algorithms within one PCN region result in a system where the edge can > know how to react. Or am I missing something? >=20 > Lars >=20 >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 10:05:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBY4D-0002KA-04; Mon, 29 Jan 2007 10:05:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBY4C-0002K5-Fu for pcn@ietf.org; Mon, 29 Jan 2007 10:05:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBY4A-000829-42 for pcn@ietf.org; Mon, 29 Jan 2007 10:05:08 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2007 07:05:04 -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 l0TF54dc009099; Mon, 29 Jan 2007 07:05:04 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0TF4pnX022313; Mon, 29 Jan 2007 07:05:03 -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); Mon, 29 Jan 2007 10:04: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] charter, addition to scope Date: Mon, 29 Jan 2007 10:04:52 -0500 Message-ID: In-Reply-To: <582B939025E978418C0B92DC134ADE9F5E2F9F@esealmw106.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDlBM8m0/kfX38RbedQeklqUXwcQAG8DgwAAA/V5AAARdDUA== From: "Anna Charny \(acharny\)" To: "Lars Westberg \(KI/EAB\)" , "Lars Eggert" X-OriginalArrivalTime: 29 Jan 2007 15:04:54.0077 (UTC) FILETIME=[D50BAED0:01C743B6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3096; t=1170083104; x=1170947104; 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]=20charter,=20addition=20to=20scope |Sender:=20; bh=EUOFTFrcM77gZSQIB3vbdW8y+Nz6jWFQOjxPOR6RXAg=; b=ZEipnbQyCbq5a4dDWfW6umvO0z9tLghIleC+H3/PAMXx5fB6NSo376tOFYf+scqDCz4mM7mN f/B2OttNy6Qc21zyvUjpg4QI5riRmTxQ58Ewtea5EKuPRK9kCO0V+cve; 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: d185fa790257f526fedfd5d01ed9c976 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 Lasse, I wonder if we may end up needed somewhat more that what (I think) you are proposing. A decision to make marking a function of the overload (which is I think what your suggestion means) is an important one. Note the semantics of the admission/pre-congestion marking proposed in current CL- drafts is not proportional to the overload - it would result in a 100% marking for consistent overload. It is not clear how the system would work if some devices do CL-style marking and some do, for example, overload-proportional marking. So one of the decisions the WG would need to make is which way to go on this. Anna=20 > -----Original Message----- > From: Lars Westberg (KI/EAB) [mailto:lars.westberg@ericsson.com]=20 > Sent: Monday, January 29, 2007 9:32 AM > To: Anna Charny (acharny); Lars Eggert > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Overprovisioning is a solution that can be solved with all=20 > different algorithmic solution, so the gain with PCN (as far=20 > I can see) is mainly bandwidth efficiency. >=20 > So I 100%-agreee that we should only standardize things that=20 > are neccessary and visible on the interface between different routers. >=20 > I though of characteristics like: rate-based marking i.e that=20 > the marking is perform with a certin average rate given a=20 > certain average overload. >=20 > Regards Lasse >=20 > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: den 29 januari 2007 15:21 > To: Lars Eggert; Lars Westberg (KI/EAB) > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Hi Lars and Lars, >=20 > It seems to me that we should neither say that the algorithms=20 > are explicitly excluded, not try to standardize anything in=20 > the algorithms beyond what is needed for interoperability. =20 > The interoperability requirements should in my opinion=20 > reflect the meaning/semantics of the marking and hence the=20 > appropriate reaction of the edge devices to this marking, and=20 > that in turn may restrict the range of flexibility of the=20 > implementation/detailed algorithm. One of the tasks of the=20 > WG would be to decide exactly what that means. Sorry if this=20 > is stating the obvious. >=20 > Anna=20 >=20 > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: Monday, January 29, 2007 5:55 AM > > To: ext Lars Westberg (KI/EAB) > > Cc: pcn@ietf.org > > Subject: Re: [PCN] charter, addition to scope > >=20 > > On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > > > I therefore suggest that the charter should have an > > explicit statement > > > that algorithms for marking should be excluded from the > > working group > > > documents > >=20 > > I don't see how interior routers that implement different marking=20 > > algorithms within one PCN region result in a system where=20 > the edge can >=20 > > know how to react. Or am I missing something? > >=20 > > Lars > >=20 > >=20 > >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 10:06:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBY57-0003BI-50; Mon, 29 Jan 2007 10:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBY53-0003Al-FC for pcn@ietf.org; Mon, 29 Jan 2007 10:06:03 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBY4x-00085h-2P for pcn@ietf.org; Mon, 29 Jan 2007 10:06:01 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0TF5rqC018991; Mon, 29 Jan 2007 09:05:53 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 09:05:53 -0600 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] 2nd charter text update Date: Mon, 29 Jan 2007 09:05:51 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD09A951BC@ILEXC1U02.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] 2nd charter text update Thread-Index: AcdDk4RfLcaqUW0XQgawhyD5p0JcugAApoagAAgQWjA= References: <8806A59C-6D27-4902-B452-DA75D270998D@nokia.com> From: "GOLDMAN, STUART O \(STUART\)" To: "Romascanu, Dan \(Dan\)" , "Lars Eggert" X-OriginalArrivalTime: 29 Jan 2007 15:05:53.0105 (UTC) FILETIME=[F83AA410:01C743B6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Folks, While it is up to the working group if an additional document is the way to go, my initial reaction is that things would be more clear if it all can be covered in the architecture document. The fewer documents to have to manage, the better. Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, January 29, 2007 4:19 AM To: Lars Eggert Cc: pcn@ietf.org Subject: RE: [PCN] 2nd charter text update It's up to the working group to decide whether they want to make out of the manageability considerations a separate document or include them in the architecture or other document. The main point right now is to say specifically in the charter what they decided to do.=20 Dan =20 =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Monday, January 29, 2007 12:52 PM > To: Romascanu, Dan (Dan) > Cc: pcn@ietf.org > Subject: Re: [PCN] 2nd charter text update >=20 > On 2007-1-29, at 12:09, ext Romascanu, Dan (Dan) wrote: > > When and why did those disappear? >=20 > Good point. I had sort of assumed that these were part of the=20 > architecture document. Do you see a specific need for a=20 > standalone document, or should I simply make it a bit clearer=20 > in the text where those considerations are to be addressed? >=20 > Lars >=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 Jan 29 10:12:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYAw-0005eF-8k; Mon, 29 Jan 2007 10:12:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYAv-0005cp-0x for pcn@ietf.org; Mon, 29 Jan 2007 10:12:05 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYAp-0000YO-4l for pcn@ietf.org; Mon, 29 Jan 2007 10:12:04 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0TFBs7B006913; Mon, 29 Jan 2007 09:11:54 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 09:11:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 09:11:48 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD09A951CC@ILEXC1U02.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDlBM8m0/kfX38RbedQeklqUXwcQAG8DgwAAA/V5AAARdDUAAAhgJg References: <582B939025E978418C0B92DC134ADE9F5E2F9F@esealmw106.eemea.ericsson.se> From: "GOLDMAN, STUART O \(STUART\)" To: "Anna Charny \(acharny\)" , "Lars Westberg \(KI/EAB\)" , "Lars Eggert" X-OriginalArrivalTime: 29 Jan 2007 15:11:50.0380 (UTC) FILETIME=[CD2E7AC0:01C743B7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Folks, Would it make sense to borrow a page from the legacy TDN network management controls? There you can signal the percentage of new attempts that should be discarded and the percentage can thus be adjusted up or down to fine tune the load to match the capacity at the core. There is also a gapping scheme where you don't specify the degree that blocking should occur, but rather an admittance rate of X calls per unit time Y.=20 Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: Monday, January 29, 2007 8:05 AM To: Lars Westberg (KI/EAB); Lars Eggert Cc: pcn@ietf.org Subject: RE: [PCN] charter, addition to scope Hi Lasse, I wonder if we may end up needed somewhat more that what (I think) you are proposing. A decision to make marking a function of the overload (which is I think what your suggestion means) is an important one. Note the semantics of the admission/pre-congestion marking proposed in current CL- drafts is not proportional to the overload - it would result in a 100% marking for consistent overload. It is not clear how the system would work if some devices do CL-style marking and some do, for example, overload-proportional marking. So one of the decisions the WG would need to make is which way to go on this. Anna=20 > -----Original Message----- > From: Lars Westberg (KI/EAB) [mailto:lars.westberg@ericsson.com]=20 > Sent: Monday, January 29, 2007 9:32 AM > To: Anna Charny (acharny); Lars Eggert > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Overprovisioning is a solution that can be solved with all=20 > different algorithmic solution, so the gain with PCN (as far=20 > I can see) is mainly bandwidth efficiency. >=20 > So I 100%-agreee that we should only standardize things that=20 > are neccessary and visible on the interface between different routers. >=20 > I though of characteristics like: rate-based marking i.e that=20 > the marking is perform with a certin average rate given a=20 > certain average overload. >=20 > Regards Lasse >=20 > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: den 29 januari 2007 15:21 > To: Lars Eggert; Lars Westberg (KI/EAB) > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Hi Lars and Lars, >=20 > It seems to me that we should neither say that the algorithms=20 > are explicitly excluded, not try to standardize anything in=20 > the algorithms beyond what is needed for interoperability. =20 > The interoperability requirements should in my opinion=20 > reflect the meaning/semantics of the marking and hence the=20 > appropriate reaction of the edge devices to this marking, and=20 > that in turn may restrict the range of flexibility of the=20 > implementation/detailed algorithm. One of the tasks of the=20 > WG would be to decide exactly what that means. Sorry if this=20 > is stating the obvious. >=20 > Anna=20 >=20 > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: Monday, January 29, 2007 5:55 AM > > To: ext Lars Westberg (KI/EAB) > > Cc: pcn@ietf.org > > Subject: Re: [PCN] charter, addition to scope > >=20 > > On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > > > I therefore suggest that the charter should have an > > explicit statement > > > that algorithms for marking should be excluded from the > > working group > > > documents > >=20 > > I don't see how interior routers that implement different marking=20 > > algorithms within one PCN region result in a system where=20 > the edge can >=20 > > know how to react. Or am I missing something? > >=20 > > Lars > >=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 Jan 29 10:17:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYGX-0008BD-B4; Mon, 29 Jan 2007 10:17:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYGW-0008B0-Ns for pcn@ietf.org; Mon, 29 Jan 2007 10:17:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYGT-0001Hw-4B for pcn@ietf.org; Mon, 29 Jan 2007 10:17:52 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0TFHalc013771; Mon, 29 Jan 2007 09:17:42 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 09:17:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 09:17:35 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDlBM8m0/kfX38RbedQeklqUXwcQAG8DgwAAIJ/NA= References: From: "GOLDMAN, STUART O \(STUART\)" To: "Anna Charny \(acharny\)" , "Lars Eggert" , "ext Lars Westberg \(KI/EAB\)" X-OriginalArrivalTime: 29 Jan 2007 15:17:37.0722 (UTC) FILETIME=[9C36A9A0:01C743B8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Folks, I am a bit confused about one item in this scheme. As I understand the principle, when the core senses that it is approaching congestion, the edge nodes are requested to reduce their offerings. What is the motivation for a given edge node to do so? It seems that if the other edge nodes do reduce their offerings then a "renegade" edge node could take advantage of the reduction in traffic at the core to continue to send his traffic. Such behavior would logically lead the others to follow unless there was some sort of policing. Am I missing something? Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: Monday, January 29, 2007 7:21 AM To: Lars Eggert; ext Lars Westberg (KI/EAB) Cc: pcn@ietf.org Subject: RE: [PCN] charter, addition to scope Hi Lars and Lars, It seems to me that we should neither say that the algorithms are explicitly excluded, not try to standardize anything in the algorithms beyond what is needed for interoperability. The interoperability requirements should in my opinion reflect the meaning/semantics of the marking and hence the appropriate reaction of the edge devices to this marking, and that in turn may restrict the range of flexibility of the implementation/detailed algorithm. One of the tasks of the WG would be to decide exactly what that means. Sorry if this is stating the obvious. Anna=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Monday, January 29, 2007 5:55 AM > To: ext Lars Westberg (KI/EAB) > Cc: pcn@ietf.org > Subject: Re: [PCN] charter, addition to scope >=20 > On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: > > I therefore suggest that the charter should have an=20 > explicit statement=20 > > that algorithms for marking should be excluded from the=20 > working group=20 > > documents >=20 > I don't see how interior routers that implement different=20 > marking algorithms within one PCN region result in a system=20 > where the edge can know how to react. Or am I missing something? >=20 > Lars >=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 Jan 29 10:26:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYOy-0002xK-Qs; Mon, 29 Jan 2007 10:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYOu-0002vU-4G for pcn@ietf.org; Mon, 29 Jan 2007 10:26:32 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYOr-00026r-7Z for pcn@ietf.org; Mon, 29 Jan 2007 10:26:31 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0TFO76J004880; Mon, 29 Jan 2007 17:24:18 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 17:26:09 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 17:26:09 +0200 In-Reply-To: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com> References: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 17:26:20 +0200 To: "ext GOLDMAN, STUART O (STUART)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 15:26:09.0566 (UTC) FILETIME=[CD4BDBE0:01C743B9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070129172418-12FC5BB0-13731576/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279311690==" Errors-To: pcn-bounces@ietf.org --===============0279311690== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-28-651135958; protocol="application/pkcs7-signature" --Apple-Mail-28-651135958 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > I am a bit confused about one item in this scheme. As I understand the > principle, when the core senses that it is approaching congestion, the > edge nodes are requested to reduce their offerings. Under the initial model, it is the edge *routers* that are acting on the signal from the interior. Which is why all routers need to trust each other. > What is the > motivation for a given edge node to do so? It seems that if the other > edge nodes do reduce their offerings then a "renegade" edge node could > take advantage of the reduction in traffic at the core to continue to > send his traffic. Such behavior would logically lead the others to > follow unless there was some sort of policing. Right, all these issues (and others) exist with the host-to-host deployment scenario, which is why we're declaring this to be out-of- scope initially. Lars --Apple-Mail-28-651135958 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkxNTI2MjBaMCMGCSqGSIb3DQEJBDEWBBSJh8l176wQxEjD pSwF8SIgCm2XbDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAuwQ32ajdM7A2fsTNzLGLmZ8avDOv/gvE2Prd6R6UpMEWfYNQgLVu c5kYhwrRyo8FvqbW8GHHYM888vw9PdpbF5AKBOLI1SGAj+PHVaXYGHpYIUo6WnfF6NKbGkJqqy8t 6Wp4tIjcd+dlxIkfDevaNwYgNTErVJLrXtKe8Gz9hECdMrCaxoG+tZEP0JQC2wjsdMHNpcrAFYrl oegqh+l0kNxR37xFh322rL1jdZs2csr3TeogRmA8/hsstuP4WzAsQAtIyBzjMRgOIURA5incrfou Yhw++9QYGzvwebSn5SibLS9JzvoxwLpN1tDTSMmuLm8u3cF6aHOlWG3xvXFXawAAAAAAAA== --Apple-Mail-28-651135958-- --===============0279311690== 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 --===============0279311690==-- From pcn-bounces@ietf.org Mon Jan 29 19:39:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBh1y-0002Ni-AX; Mon, 29 Jan 2007 19:39:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBh1x-0002Nd-4g for pcn@ietf.org; Mon, 29 Jan 2007 19:39:25 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBh1v-0007Wh-Sj for pcn@ietf.org; Mon, 29 Jan 2007 19:39:25 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0U0dLm07189; Mon, 29 Jan 2007 19:39:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 19:39:19 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> In-Reply-To: <6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDueYA1p52i+q1Q8KIg7JkInhopgANO6kg From: "Jozef Babiarz" To: "Lars Eggert" , "ext GOLDMAN, STUART O \(STUART\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 wrote: >Right, all these issues (and others) exist with the host-to-host =20 >deployment scenario, which is why we're declaring this to be out-of-=20 >scope initially. I have slightly different view. In the first phase of PCN work to reduce the list of issues it was proposed that the WG focus on network deployment scenario where all nodes can be trusted and delay work on deployment scenarios where some of the nodes are not trusted. I have no issue with delaying work on cheater detection and enforcement. I believe there are methods that can be used to detect, discourage or even stop devices from cheating with the PCN mechanism.=20 On comment host-to-host: Currently, there are examples of scenarios where hosts are trusted by the network. Some examples are, 3G wireless terminal, media gateways, IP telephone sets connected in enterprise networks, enterprises run "plug-in modules" that verifies/enforces hardware and software the employees can run on their personal computers when they connect to their network. So I do not agree that so called host-to-host deployment has a trust that is non starter for PCN workgroup to address. The trust issue will need to be address if PCN mechanism is to be used in open networks like the Internet, where an ingress router can not trust its neighbor ingress router or an egress routers or any other node that connects to the network (e.g., media gateway, wireless access point, IP telephone sets, personal computers, servers, etc.) that my be associated with the PCN mechanism. =20 Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: January 29, 2007 10:26 AM To: ext GOLDMAN, STUART O (STUART) Cc: pcn@ietf.org Subject: Re: [PCN] charter, addition to scope On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > I am a bit confused about one item in this scheme. As I understand the > principle, when the core senses that it is approaching congestion, the > edge nodes are requested to reduce their offerings. Under the initial model, it is the edge *routers* that are acting on =20 the signal from the interior. Which is why all routers need to trust =20 each other. > What is the > motivation for a given edge node to do so? It seems that if the other > edge nodes do reduce their offerings then a "renegade" edge node could > take advantage of the reduction in traffic at the core to continue to > send his traffic. Such behavior would logically lead the others to > follow unless there was some sort of policing. Right, all these issues (and others) exist with the host-to-host =20 deployment scenario, which is why we're declaring this to be out-of-=20 scope initially. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jan 29 20:21:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhgt-0004S2-Fp; Mon, 29 Jan 2007 20:21:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhgs-0004Rs-R7 for pcn@ietf.org; Mon, 29 Jan 2007 20:21:42 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhgr-0006sI-DH for pcn@ietf.org; Mon, 29 Jan 2007 20:21:42 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0U1LeHw006195; Mon, 29 Jan 2007 19:21:40 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.5]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 19:21:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Mon, 29 Jan 2007 19:21:39 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD09A95621@ILEXC1U02.ndc.lucent.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdDueYA1p52i+q1Q8KIg7JkInhopgANO6kgAAd4yeA= References: <6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> From: "GOLDMAN, STUART O \(STUART\)" To: "Jozef Babiarz" , "Lars Eggert" X-OriginalArrivalTime: 30 Jan 2007 01:21:40.0739 (UTC) FILETIME=[FEBC2D30:01C7440C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, Thanks for the input. While I am still concerned about not addressing the trust concern until a later phase, I accept your belief that it can be successfully resolved. I will wait patently until we get to that phase. Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Monday, January 29, 2007 5:39 PM To: Lars Eggert; GOLDMAN, STUART O (STUART) Cc: pcn@ietf.org Subject: RE: [PCN] charter, addition to scope Lars wrote: >Right, all these issues (and others) exist with the host-to-host =20 >deployment scenario, which is why we're declaring this to be out-of-=20 >scope initially. I have slightly different view. In the first phase of PCN work to reduce the list of issues it was proposed that the WG focus on network deployment scenario where all nodes can be trusted and delay work on deployment scenarios where some of the nodes are not trusted. I have no issue with delaying work on cheater detection and enforcement. I believe there are methods that can be used to detect, discourage or even stop devices from cheating with the PCN mechanism.=20 On comment host-to-host: Currently, there are examples of scenarios where hosts are trusted by the network. Some examples are, 3G wireless terminal, media gateways, IP telephone sets connected in enterprise networks, enterprises run "plug-in modules" that verifies/enforces hardware and software the employees can run on their personal computers when they connect to their network. So I do not agree that so called host-to-host deployment has a trust that is non starter for PCN workgroup to address. The trust issue will need to be address if PCN mechanism is to be used in open networks like the Internet, where an ingress router can not trust its neighbor ingress router or an egress routers or any other node that connects to the network (e.g., media gateway, wireless access point, IP telephone sets, personal computers, servers, etc.) that my be associated with the PCN mechanism. =20 Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: January 29, 2007 10:26 AM To: ext GOLDMAN, STUART O (STUART) Cc: pcn@ietf.org Subject: Re: [PCN] charter, addition to scope On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > I am a bit confused about one item in this scheme. As I understand the > principle, when the core senses that it is approaching congestion, the > edge nodes are requested to reduce their offerings. Under the initial model, it is the edge *routers* that are acting on =20 the signal from the interior. Which is why all routers need to trust =20 each other. > What is the > motivation for a given edge node to do so? It seems that if the other > edge nodes do reduce their offerings then a "renegade" edge node could > take advantage of the reduction in traffic at the core to continue to > send his traffic. Such behavior would logically lead the others to > follow unless there was some sort of policing. Right, all these issues (and others) exist with the host-to-host =20 deployment scenario, which is why we're declaring this to be out-of-=20 scope initially. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 30 02:33:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnUj-0006Zu-TM; Tue, 30 Jan 2007 02:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnUh-0006YH-V9 for pcn@ietf.org; Tue, 30 Jan 2007 02:33:31 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBnUg-0001Pc-GC for pcn@ietf.org; Tue, 30 Jan 2007 02:33:31 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 30 Jan 2007 08:33:28 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 08:33:28 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter, addition to scope Date: Tue, 30 Jan 2007 08:33:28 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAD9@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope thread-index: AcdDlBM8m0/kfX38RbedQeklqUXwcQAG8DgwAAIJ/NAAIfRMgA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Jan 2007 07:33:28.0580 (UTC) FILETIME=[EF3E9440:01C74440] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Stuart, the issue you raise is currently not a chartered work item. Bob=20 Briscoe already started thinking about counter measures. His =20 draft-briscoe-tsvwg-re-ecn-border-cheat-01 recently expired. Regards, Ruediger |-----Original Message----- |From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@alcatel-lucent.com] |Sent: Monday, January 29, 2007 4:18 PM |To: Anna Charny (acharny); Lars Eggert; ext Lars Westberg (KI/EAB) |Cc: pcn@ietf.org |Subject: RE: [PCN] charter, addition to scope | | |Folks, | |I am a bit confused about one item in this scheme. As I understand the |principle, when the core senses that it is approaching congestion, the |edge nodes are requested to reduce their offerings. What is the |motivation for a given edge node to do so? It seems that if the other |edge nodes do reduce their offerings then a "renegade" edge node could |take advantage of the reduction in traffic at the core to continue to |send his traffic. Such behavior would logically lead the others to |follow unless there was some sort of policing. | |Am I missing something? | |Stuart Goldman |Alcatel-Lucent=20 |sgoldman@alcatel-lucent.com |602 493 8438 | | | |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 |Sent: Monday, January 29, 2007 7:21 AM |To: Lars Eggert; ext Lars Westberg (KI/EAB) |Cc: pcn@ietf.org |Subject: RE: [PCN] charter, addition to scope | |Hi Lars and Lars, | |It seems to me that we should neither say that the algorithms are |explicitly excluded, not try to standardize anything in the algorithms |beyond what is needed for interoperability. The interoperability |requirements should in my opinion reflect the meaning/semantics of the |marking and hence the appropriate reaction of the edge devices to this |marking, and that in turn may restrict the range of flexibility of the |implementation/detailed algorithm. One of the tasks of the WG would be |to decide exactly what that means. Sorry if this is stating=20 |the obvious. | |Anna=20 | |> -----Original Message----- |> From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 |> Sent: Monday, January 29, 2007 5:55 AM |> To: ext Lars Westberg (KI/EAB) |> Cc: pcn@ietf.org |> Subject: Re: [PCN] charter, addition to scope |>=20 |> On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote: |> > I therefore suggest that the charter should have an=20 |> explicit statement=20 |> > that algorithms for marking should be excluded from the=20 |> working group=20 |> > documents |>=20 |> I don't see how interior routers that implement different=20 |> marking algorithms within one PCN region result in a system=20 |> where the edge can know how to react. Or am I missing something? |>=20 |> Lars |>=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 Jan 30 11:51:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwCd-0001y5-0C; Tue, 30 Jan 2007 11:51:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwCb-0001xe-NO for pcn@ietf.org; Tue, 30 Jan 2007 11:51:25 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwCY-00072p-4L for pcn@ietf.org; Tue, 30 Jan 2007 11:51:25 -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 l0UGpJB19482; Tue, 30 Jan 2007 11:51:19 -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); Tue, 30 Jan 2007 11:51:18 -0500 Message-Id: <6.2.5.6.0.20070130100927.056e6750@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Jan 2007 11:51:17 -0500 To: ext Lars Eggert From: "Kwok-Ho Chan" Subject: Re: [PCN] 2nd charter text update In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Jan 2007 16:51:18.0127 (UTC) FILETIME=[DCA627F0:01C7448E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 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 and all: Please see my comments embedded below indicated/delimited by KHC_START> KHC_END> Thanks! -- Kwok -- At 04:08 AM 1/29/2007, ext Lars Eggert wrote: >Congestion and Pre-Congestion Notification (PCN) > >Chair(s): > tbd > >Transport Area Director(s): > Magnus Westerlund > Lars Eggert KHC_START> Lars: E-Mail address update needed? KHC_END> >Transport Area Advisor: > Lars Eggert KHC_START> Lars: E-Mail address update needed? KHC_END> >Mailing Lists: > General Discussion: pcn@ietf.org > To Subscribe: pcn-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/pcn/index.html > > >Description of Working Group: > >The Congestion and Pre-Congestion Notification (PCN) working group >develops mechanisms to protect the quality-of-service of established >flows within a network domain when congestion is imminent or >existing. KHC_START> IMHO, The following text needs to be improved. To allow the text to be more concise and standardize what are needed for inter-operability without shutting out innovations and possible better ways of implementation. KHC_END> >These mechanisms operate at the domain edge, based on >aggregated congestion and pre-congestion signals from within the >domain. The focus of the WG is on developing standards for the >marking behavior of the interior routers and the encoding of the >congestion signals. Reaction mechanisms at the edge include flow >admission and flow preemption. The WG may produce informational >documents that describe how specific quality-of-service policies can >be implemented using a combination of these mechanisms. KHC_START> Suggested new text: These mechanisms operate on the IP packet data path, with network nodes: 1. At the middle of the IP packet data path domain (interior nodes) performing measurement, detection, and indication of congestion and pre-congestion conditions. 2. At the edge of the IP packet data path domain (edge nodes) performing control of the IP packets that affect the congestion and pre-congestion conditions at the middle of the IP packet data path domain The focus of the WG is on developing standards for specifying the detection and indication behaviors at the interior nodes that is required for inter-operability. The WG will use flow admission and flow preemption at the edge nodes as the mechanism for controlling the IP packets that affect the congestion and pre-congestion conditions at the middle of the IP packet data path domain. The description of the behavior at the edge nodes may be a standards track document if it is needed for inter-operability. The WG may produce additional informational documents that describe some possible methods for providing the required behaviors at the interior nodes and edge nodes that supports the inter-operability of the standards developed here. The WG may produce additional informational documents on how specific quality-of-service polices can be implemented using a combination of these mechanisms. KHC_END> >The PCN WG will specify the following components of an integrated >flow admission and preemption mechanism: > > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals KHC_START> Suggest to replace: "on aggregated (pre-)congestion signals" by "on aggregated (pre-)congestion information" KHC_END> > (2) conditions under which interior routers generate > (pre-)congestion signals KHC_START> Suggest to replace: "(pre-)congestion signals" by "(pre-)congestion information" KHC_END> > (3) encoding and transport of (pre-)congestion signals KHC_START> Suggest to replace: "encoding and transport of (pre-)congestion signals" by "encoding and transport of aggregated (pre-)congestion information" KHC_END> > to the appropriate ingress routers of the network domain KHC_START> Suggest to delete: "to the appropriate ingress routers of the network domain" The reasoning is we want to standardize how the (pre-)congestion information is conveyed by the interior nodes to the edge nodes. The deleted part of the sentence will confuse this point. Hence I suggest to delete it. KHC_END> > (4) edge router control mechanisms for flow admission, preemption or > rate adaption, based on aggregated (pre-)congestion information KHC_START> Suggest to replace: "edge router control mechanisms ..." by: "behaviors of edge node control mechanisms ..." or: "edge node control behaviors ..." KHC_END> >The WG focuses on the overall architecture and the marking behavior >and signaling interface needed to realize it. KHC_START> Suggest to replace: "The WG focuses on the overall architecture and the marking behavior and signaling interface needed to realize it." by "The WG focuses on the overall architecture and the marking behavior and possible required external interfaces (e.g. to management, to signaling) needed to realize it." KHC_END> >Standards-track >protocols and mechanisms are only developed where necessary for >interoperability. For other components of the architecture, the WG >may document examples or provide recommended solutions in >informational documents. KHC_START> Suggest to replace: "Standards-track protocols and mechanisms ..." by "Standards-track behaviors and mechanisms ..." KHC_END> >The initial scope of the PCN WG is restricted in the following ways: > > (A) develop these components for a single DiffServ region, > where all edge and interior routers are PCN-enabled KHC_START> Suggest to replace: "where all edge and interior routers ..." by: "where all edge and interior nodes ..." KHC_END> > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping > > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms >to be > effective > > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits > > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, >etc.) > is out of scope > >After completion of the initial phase, the PCN WG may re-charter to >develop solutions for scenarios where some of these restrictions are >not in place. It may also re-charter to consider applying the PCN >mechanisms to additional deployment scenarios (operation over >concatenated DiffServ regions, PCN-aware application mechanisms, KHC_START> Suggest to replace: "concatenated DiffServ regions, PCN-aware application mechanisms," by: "concatenated DiffServ regions, end-to-end deployment of PCN mechanisms," KHC_END> >etc.). The WG may also consider to investigate additional response >mechanisms that act on (pre-)congestion signals. One example could be KHC_START> Suggest to replace: "mechanisms that act on (pre-)congestion signals." by: "mechanisms that act on (pre-)congestion information." KHC_END> >flow-rate adaptation (rather than flow admission/preemption) during >times of congestion. The details of these work items are outside the >scope of the initial phase; but the WG should consider their >requirements to design components that are sufficiently general to >support such extensions in the future. > > >Goals and Milestones: > >Jul 2007 Flow Admission and Preemption Architecture > (Informational) > >Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region KHC_START> Suggest to replace: "(Pre-)Congestion Signals ..." by: "(Pre-)Congestion Information ..." KHC_END> > (Informational) > >Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) > >Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) > >Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed Standard) KHC_START> Suggest to replace: "Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard)" by "Encoding and Transport of (Pre-)Congestion Information within a DiffServ Region (Proposed Standard)" KHC_END> >Mar 2008 Transport from Flow Egress in a DiffServ Region of >information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) KHC_START> Suggest to delete: "Mar 2008 Transport from Flow Egress in a DiffServ Region of information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard)" KHC_END> >Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jan 30 12:16:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwbA-0007mX-GK; Tue, 30 Jan 2007 12:16:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwb9-0007mL-Is for pcn@ietf.org; Tue, 30 Jan 2007 12:16:47 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwb8-0005Ue-9f for pcn@ietf.org; Tue, 30 Jan 2007 12:16:47 -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 l0UHGhJ22048; Tue, 30 Jan 2007 12:16:43 -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); Tue, 30 Jan 2007 12:16:43 -0500 Message-Id: <6.2.5.6.0.20070130120548.056e6b28@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Jan 2007 12:16:42 -0500 To: Lars Eggert From: "Kwok-Ho Chan" Subject: Re: [PCN] charter, addition to scope In-Reply-To: <6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> References: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com> <6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Jan 2007 17:16:43.0382 (UTC) FILETIME=[69C59960:01C74492] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: By the last sentence of your E-Mail, I think you are equating "Application Control Deployment" with "host-to-host". Which may be your reasoning for excluding "Application Control Deployment". "Application Control Deployment" can be "edge-to-edge", which will very much use the same behaviors and mechanisms that we can standardize in PCN. Hence IMHO, the "Application Control Deployment" for "edge-to-edge" fits very well within the work being done in the first phase of PCN and should be included as a work item (informational track) for the first phase of PCN. Please separate the notion of "host-to-host" from "Application Control Deployment". Thanks! -- Kwok -- At 10:26 AM 1/29/2007, Lars Eggert wrote: >On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: >>I am a bit confused about one item in this scheme. As I understand the >>principle, when the core senses that it is approaching congestion, the >>edge nodes are requested to reduce their offerings. > >Under the initial model, it is the edge *routers* that are acting on >the signal from the interior. Which is why all routers need to trust >each other. > >>What is the >>motivation for a given edge node to do so? It seems that if the other >>edge nodes do reduce their offerings then a "renegade" edge node could >>take advantage of the reduction in traffic at the core to continue to >>send his traffic. Such behavior would logically lead the others to >>follow unless there was some sort of policing. > >Right, all these issues (and others) exist with the host-to-host >deployment scenario, which is why we're declaring this to be out-of- >scope initially. > >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 Wed Jan 31 03:41:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCB1u-0006pu-5L; Wed, 31 Jan 2007 03:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCB1s-0006pl-Gn for pcn@ietf.org; Wed, 31 Jan 2007 03:41:20 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCB1o-0006Bq-8c for pcn@ietf.org; Wed, 31 Jan 2007 03:41:20 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0V8YtIk023277; Wed, 31 Jan 2007 10:35:09 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 10:37:10 +0200 Received: from [192.168.1.33] ([10.162.253.201]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 10:37:24 +0200 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 10:37:06 +0200 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 08:37:24.0557 (UTC) FILETIME=[0813F7D0:01C74513] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070131103509-5A84BBB0-5E0BC24C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0293335192==" Errors-To: pcn-bounces@ietf.org --===============0293335192== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-82-799381569; protocol="application/pkcs7-signature" --Apple-Mail-82-799381569 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > In the first phase of PCN work to reduce the list of issues it was > proposed that the WG focus on network deployment scenario where all > nodes can be trusted and delay work on deployment scenarios where some > of the nodes are not trusted. If by "nodes" you mean routers, then yes, I agree. If "nodes" include end systems, proxies or other entities, then I don't agree we had agreement on that. > Currently, there are examples of scenarios where hosts are trusted by > the network. Some examples are, 3G wireless terminal, media > gateways, IP > telephone sets connected in enterprise networks, enterprises run > "plug-in modules" that verifies/enforces hardware and software the > employees can run on their personal computers when they connect to > their > network. So I do not agree that so called host-to-host deployment > has a > trust that is non starter for PCN workgroup to address. I don't dispute that examples exists where mutual trust exists among the routers, hosts and other boxes in the network. But there are clearly many cases where such trust doesn't exist. At and after the BOF, there was agreement that the case where such trust exists between the routers of a single network domain had been described in sufficient detail to be solvable by the IETF. When the trust extended to other nodes, that agreement wasn't there. > The trust issue will need to be address if PCN mechanism is to be used > in open networks like the Internet, where an ingress router can not > trust its neighbor ingress router or an egress routers or any other > node > that connects to the network (e.g., media gateway, wireless access > point, IP telephone sets, personal computers, servers, etc.) that > my be > associated with the PCN mechanism. Completely agree. Which is why we're limiting the scope of the initial problem to a single network domain. How PCN operates when some or even most of the routers or other nodes aren't trusted is an open problem. Lars --Apple-Mail-82-799381569 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzEwODM3MDZaMCMGCSqGSIb3DQEJBDEWBBSkhqypRRgeKAgz qBj7QH/IgpCMZjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEADfZJam5XZf1zlAKS34HLZt3lzh+8E0Ivsto9sb2Xagqx83MnPnGg l9HARaZxKIawwzJI5aX4EZ8jPXO7h89K5+9ieIrrSjPImV0nIB+zF7wXp0y0oxpucoB9HvGEIVbW j9w213uPnnZ4inbupwdbZn4yeZy4LuAwYrKs6e+T/GpbfzhaA2yxg35VGB1Yz6lTqfaT25LQqVYL IEe7WXvawQAx7hpuMAcwuoT/LGQcCp0Piohh+w4l1TYgnZAF5ZQ8p5SvMEk7s7wwDnErWvkLqSiX LGzNpkwvI7RU5V16li6dE1Dr5faMmWqXc8enwtMdKcGIDh6W418fDhY3Y4ESdgAAAAAAAA== --Apple-Mail-82-799381569-- --===============0293335192== 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 --===============0293335192==-- From pcn-bounces@ietf.org Wed Jan 31 03:59:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBJV-0006s1-QQ; Wed, 31 Jan 2007 03:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBJT-0006rj-Nu for pcn@ietf.org; Wed, 31 Jan 2007 03:59:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBJI-00024x-Qm for pcn@ietf.org; Wed, 31 Jan 2007 03:59:31 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31F8121275; Wed, 31 Jan 2007 09:59:12 +0100 (CET) X-AuditID: c1b4fb3e-b16d6bb0000007e1-27-45c05a60d2a3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 05CC4200CE; Wed, 31 Jan 2007 09:59:12 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:58:41 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:58:40 +0100 Message-ID: <45C05A40.300@ericsson.com> Date: Wed, 31 Jan 2007 09:58:40 +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] charter, addition to scope References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> In-Reply-To: <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> X-OriginalArrivalTime: 31 Jan 2007 08:58:40.0888 (UTC) FILETIME=[00D49F80:01C74516] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114964111==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2114964111== Content-Type: multipart/alternative; boundary="------------080103050709070402060908" This is a multi-part message in MIME format. --------------080103050709070402060908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If I interprete you correctly, examples are lacking, for trust to other nodes ? What do we needed to proof that it exists ? Examples from telecom networks ? or, are telecom networks out-of-scope from IETF-perspective ? regards Lasse Lars Eggert wrote: > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > In the first phase of PCN work to reduce the list of issues it was > > proposed that the WG focus on network deployment scenario where all > > nodes can be trusted and delay work on deployment scenarios where some > > of the nodes are not trusted. > > If by "nodes" you mean routers, then yes, I agree. If "nodes" include > end systems, proxies or other entities, then I don't agree we had > agreement on that. > > > Currently, there are examples of scenarios where hosts are trusted by > > the network. Some examples are, 3G wireless terminal, media > > gateways, IP > > telephone sets connected in enterprise networks, enterprises run > > "plug-in modules" that verifies/enforces hardware and software the > > employees can run on their personal computers when they connect to > > their > > network. So I do not agree that so called host-to-host deployment > > has a > > trust that is non starter for PCN workgroup to address. > > I don't dispute that examples exists where mutual trust exists among > the routers, hosts and other boxes in the network. But there are > clearly many cases where such trust doesn't exist. At and after the > BOF, there was agreement that the case where such trust exists > between the routers of a single network domain had been described in > sufficient detail to be solvable by the IETF. When the trust extended > to other nodes, that agreement wasn't there. > > > The trust issue will need to be address if PCN mechanism is to be used > > in open networks like the Internet, where an ingress router can not > > trust its neighbor ingress router or an egress routers or any other > > node > > that connects to the network (e.g., media gateway, wireless access > > point, IP telephone sets, personal computers, servers, etc.) that > > my be > > associated with the PCN mechanism. > > Completely agree. Which is why we're limiting the scope of the > initial problem to a single network domain. How PCN operates when > some or even most of the routers or other nodes aren't trusted is an > open problem. > > Lars > > >------------------------------------------------------------------------ > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn > > --------------080103050709070402060908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
If I interprete you correctly, examples are lacking, for trust to other nodes ?

What do we needed to proof that it exists ?
Examples from telecom networks ?

or, are  telecom networks out-of-scope from IETF-perspective ?

regards Lasse

Lars Eggert wrote:
Re: [PCN] charter, addition to scope

On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
> In the first phase of PCN work to reduce the list of issues it was
> proposed that the WG focus on network deployment scenario where all
> nodes can be trusted and delay work on deployment scenarios where some
> of the nodes are not trusted.

If by "nodes" you mean routers, then yes, I agree. If "nodes" include 
end systems, proxies or other entities, then I don't agree we had 
agreement on that.

> Currently, there are examples of scenarios where hosts are trusted by
> the network. Some examples are, 3G wireless terminal, media 
> gateways, IP
> telephone sets connected in enterprise networks, enterprises run
> "plug-in modules" that verifies/enforces hardware and software the
> employees can run on their personal computers when they connect to 
> their
> network. So I do not agree that so called host-to-host deployment 
> has a
> trust that is non starter for PCN workgroup to address.

I don't dispute that examples exists where mutual trust exists among 
the routers, hosts and other boxes in the network. But there are 
clearly many cases where such trust doesn't exist. At and after the 
BOF, there was agreement that the case where such trust exists 
between the routers of a single network domain had been described in 
sufficient detail to be solvable by the IETF. When the trust extended 
to other nodes, that agreement wasn't there.

> The trust issue will need to be address if PCN mechanism is to be used
> in open networks like the Internet, where an ingress router can not
> trust its neighbor ingress router or an egress routers or any other 
> node
> that connects to the network (e.g., media gateway, wireless access
> point, IP telephone sets, personal computers, servers, etc.) that 
> my be
> associated with the PCN mechanism.

Completely agree. Which is why we're limiting the scope of the 
initial problem to a single network domain. How PCN operates when 
some or even most of the routers or other nodes aren't trusted is an 
open problem.

Lars


 


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--------------080103050709070402060908-- --===============2114964111== 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 --===============2114964111==-- From pcn-bounces@ietf.org Wed Jan 31 04:02:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBMh-0007zH-RH; Wed, 31 Jan 2007 04:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBMh-0007z8-6l for pcn@ietf.org; Wed, 31 Jan 2007 04:02:51 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBMe-0003Y1-Pa for pcn@ietf.org; Wed, 31 Jan 2007 04:02:51 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0V90cv0022713; Wed, 31 Jan 2007 11:00:44 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:02:41 +0200 Received: from [192.168.1.33] ([10.162.253.32]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 11:02:41 +0200 In-Reply-To: <45C05A40.300@ericsson.com> References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> <45C05A40.300@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 11:02:38 +0200 To: "ext Lars Westberg" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 09:02:41.0120 (UTC) FILETIME=[90051E00:01C74516] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070131110044-586B0BB0-70659389/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1848447111==" Errors-To: pcn-bounces@ietf.org --===============1848447111== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-84-800913574; protocol="application/pkcs7-signature" --Apple-Mail-84-800913574 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-31, at 10:58, ext Lars Westberg wrote: > If I interprete you correctly, examples are lacking, for trust to > other nodes ? Read again. I said I _don't_ dispute that such examples exist. Lars --Apple-Mail-84-800913574 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzEwOTAyMzhaMCMGCSqGSIb3DQEJBDEWBBQ7EQvMO0PSU8FS 2TtcyPWRlciHpjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAHJxXP5KfdswmZtWcXLikKBqdSkmmWC9vdhPTLHAUyVGMNrcCc5Mb DNw2KfdGyLUudKfFP74xpa6KWRcbT3+8GJcUFkyeZFa2CdgdaCfI5LscpUSREyzshOBbtaWX7wnK ax87EjwpyXGsB4QmIIgk3jVHXzZIBdQGCTVJmQmd3894UAAaM71QSMIPLX0JbshrDG+e5IWRyA6I Q4jqpzPHA54Q5F7b4UFAKnNeNzwk5iMQazhHn1MldsysCaoqM8zcXYXLmo5CmGvv5IXASYgme3xq 2IOOYXn1xOQpaVaftex+I8dROdhT7oxbguTA9PvqjOMQPJdz/66kQNng7aV/UAAAAAAAAA== --Apple-Mail-84-800913574-- --===============1848447111== 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 --===============1848447111==-- From pcn-bounces@ietf.org Wed Jan 31 04:12:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBW1-0003u1-OV; Wed, 31 Jan 2007 04:12:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBW0-0003tw-8p for pcn@ietf.org; Wed, 31 Jan 2007 04:12:28 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBVk-0006hO-2e for pcn@ietf.org; Wed, 31 Jan 2007 04:12:28 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6884F212B0; Wed, 31 Jan 2007 10:12:09 +0100 (CET) X-AuditID: c1b4fb3e-ae6d0bb0000007e1-dc-45c05d695817 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3161A2125A; Wed, 31 Jan 2007 10:12:09 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 10:12:06 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 10:12:06 +0100 Message-ID: <45C05D66.2070806@ericsson.com> Date: Wed, 31 Jan 2007 10:12:06 +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] charter, addition to scope References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> <45C05A40.300@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 09:12:06.0298 (UTC) FILETIME=[E0E46FA0:01C74517] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 is the problem? Is trust between routers more common than the other scenario? One problem I forsee it that the architecture for routers may include limitations for thw other scenario. What is the way forward? wait to the next re-charter 3-year ahead ? regards Lasse Lars Eggert wrote: > On 2007-1-31, at 10:58, ext Lars Westberg wrote: > >> If I interprete you correctly, examples are lacking, for trust to >> other nodes ? > > > Read again. I said I _don't_ dispute that such examples exist. > > Lars > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 04:24:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBhO-00006p-77; Wed, 31 Jan 2007 04:24:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBhM-00006W-BI for pcn@ietf.org; Wed, 31 Jan 2007 04:24:12 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBhK-0002N5-Gd for pcn@ietf.org; Wed, 31 Jan 2007 04:24:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0V9JMi1020267; Wed, 31 Jan 2007 11:21:21 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:23:27 +0200 Received: from [192.168.1.33] ([10.162.253.32]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 11:23:41 +0200 In-Reply-To: <6.2.5.6.0.20070130100927.056e6750@nortel.com> References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> From: Lars Eggert Subject: Re: [PCN] 2nd charter text update Date: Wed, 31 Jan 2007 11:23:38 +0200 To: ext Kwok-Ho Chan X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 09:23:41.0510 (UTC) FILETIME=[7F455E60:01C74519] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0860829405==" Errors-To: pcn-bounces@ietf.org --===============0860829405== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-85-802174040; protocol="application/pkcs7-signature" --Apple-Mail-85-802174040 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-30, at 18:51, ext Kwok-Ho Chan wrote: > Lars: E-Mail address update needed? Yes. Oops. >> These mechanisms operate at the domain edge, based on >> aggregated congestion and pre-congestion signals from within the >> domain. The focus of the WG is on developing standards for the >> marking behavior of the interior routers and the encoding of the >> congestion signals. Reaction mechanisms at the edge include flow >> admission and flow preemption. The WG may produce informational >> documents that describe how specific quality-of-service policies can >> be implemented using a combination of these mechanisms. > > Suggested new text: > These mechanisms operate on the IP packet data path, with network > nodes: > 1. At the middle of the IP packet data path domain (interior nodes) > performing > measurement, detection, and indication of congestion and pre- > congestion > conditions. > 2. At the edge of the IP packet data path domain (edge nodes) > performing > control of the IP packets that affect the congestion and pre- > congestion > conditions at the middle of the IP packet data path domain > > The focus of the WG is on developing standards for specifying the > detection > and indication behaviors at the interior nodes that is required for > inter-operability. > The WG will use flow admission and flow preemption at the edge > nodes as the > mechanism for controlling the IP packets that affect the congestion > and > pre-congestion conditions at the middle of the IP packet data path > domain. Talking about "nodes" and "paths" leaves the door open for other work than the routers-within-a-single-DiffServ-domain model that we want to focus the work on initially. > The description of the behavior at the edge nodes may be a > standards track > document if it is needed for inter-operability. Do you see a specific need for this to become standards track? > The WG may produce additional informational documents that describe > some > possible methods for providing the required behaviors at the > interior nodes and > edge nodes that supports the inter-operability of the standards > developed here. > The WG may produce additional informational documents on how specific > quality-of-service polices can be implemented using a combination > of these > mechanisms. I'd rather not give the WG too many options to do additional Informational documents in the beginning. The focus should be on the standards track specifications. > Suggest to replace: > "on aggregated (pre-)congestion signals" > by > "on aggregated (pre-)congestion information" OK (also elsewhere) >> to the appropriate ingress routers of the network domain > Suggest to delete: > "to the appropriate ingress routers of the network domain" > The reasoning is we want to standardize how the (pre-)congestion > information is conveyed by the interior nodes to the edge nodes. > The deleted part of the sentence will confuse this point. Hence I > suggest to delete it. How will it confuse this point? It clarifies that we're not looking at transporting this information elsewhere, such as outside of the domain. Lars --Apple-Mail-85-802174040 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzEwOTIzMzlaMCMGCSqGSIb3DQEJBDEWBBSdpkCtRTYnjsOH qTzatE9QRUH4NjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAgzDVmrPM7vhu3i+Mgyb308xvNTGRNoXuk6HPLSxRtZQRK2UeKGR7 rYVELdOOWYJ2rD6awfsqkUk55FF7W/7Mj6Bon0fmfs/948FVcsbCZnc8DPNKXrKT+xyk0alFcS0e OLj5wMLeDhmmZWMvt/cA59QLOw6rDQmmrzokVvLhM3Ik6DHoLBceDKjgtO9+99g93t8ibiLQdrTA rmtucW7u/+XZJiS83ltQU3jOfYnkTGMh53mwdnPWcA7s+MRKuJEJWfi3jO/5nZFGGnzCleok7yoy RFZ9aGRX7nmASKD9OMCYcS9EIw3Gs6Q6YrIxWjEI3CJoEn9aht3aROGlhGayXwAAAAAAAA== --Apple-Mail-85-802174040-- --===============0860829405== 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 --===============0860829405==-- From pcn-bounces@ietf.org Wed Jan 31 06:37:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCDmG-0001jX-CI; Wed, 31 Jan 2007 06:37:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCDmF-0001jS-BY for pcn@ietf.org; Wed, 31 Jan 2007 06:37:23 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCDmD-00078I-TN for pcn@ietf.org; Wed, 31 Jan 2007 06:37:23 -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 l0VBarLW002954; Wed, 31 Jan 2007 12:37:00 +0100 (MET) From: "Georgios Karagiannis" To: "'Lars Eggert'" , "'ext Jozef Babiarz'" References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 12:37:08 +0100 Message-ID: <002001c7452c$291184c0$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: <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+ig X-Spam-Score: 0.083 () 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, 31 Jan 2007 12:37:01 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars Please see in line! > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > In the first phase of PCN work to reduce the list of issues it was > > proposed that the WG focus on network deployment scenario where all > > nodes can be trusted and delay work on deployment scenarios > where some > > of the nodes are not trusted. > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If "nodes" > include end systems, proxies or other entities, then I don't > agree we had agreement on that. Georgios: This imposes an additional restriction on the scope of the charter, which has been not discussed yet. >From what I remember before, during and after the PCN BOF there was no objection on using the term edge node, that could mean something different than a edge router. Please note that this is something different than a scenario covered by an application based deployment model. Note that we have used this term in the first version of the PCN BOF charter and also the draft: http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01.txt Is it okay with you if end nodes could be gateways/routers? > > Currently, there are examples of scenarios where hosts are > trusted by > > the network. Some examples are, 3G wireless terminal, media > gateways, > > IP telephone sets connected in enterprise networks, enterprises run > > "plug-in modules" that verifies/enforces hardware and software the > > employees can run on their personal computers when they connect to > > their network. So I do not agree that so called host-to-host > > deployment has a trust that is non starter for PCN workgroup to > > address. > > (by Lars: ) I don't dispute that examples exists where mutual trust > exists among the routers, hosts and other boxes in the > network. But there are clearly many cases where such trust > doesn't exist. At and after the BOF, there was agreement that > the case where such trust exists between the routers of a > single network domain had been described in sufficient detail > to be solvable by the IETF. When the trust extended to other > nodes, that agreement wasn't there. Georgios: From the point of security vulnerabilities I am not sure if there are main differences between the scenario that one trusted domain is used or the scenario where two or more concateneted trusted domains are used. Note that the two or more concateneted trusted domains can be seen as one trusted domain (from the point of security vulnerabilities) > > > The trust issue will need to be address if PCN mechanism is > to be used > > in open networks like the Internet, where an ingress router can not > > trust its neighbor ingress router or an egress routers or any other > > node that connects to the network (e.g., media gateway, wireless > > access point, IP telephone sets, personal computers, servers, etc.) > > that my be associated with the PCN mechanism. > > Completely agree. Which is why we're limiting the scope of > the initial problem to a single network domain. How PCN > operates when some or even most of the routers or other nodes > aren't trusted is an open problem. > > Lars Best Regards, Georgios > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 06:58:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCE6o-0001nu-9W; Wed, 31 Jan 2007 06:58:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCE6n-0001no-5h for pcn@ietf.org; Wed, 31 Jan 2007 06:58:37 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCE6h-0004aC-N7 for pcn@ietf.org; Wed, 31 Jan 2007 06:58:37 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:53:52 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Jan 2007 11:53:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter text update Date: Wed, 31 Jan 2007 11:53:49 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEB4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <36AF84F3-3F6C-4114-8AE3-1BA76D0B06BA@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdBKtkVY9CC9Q0BTkqdeeSXy6AdXwEAWXHA From: To: , X-OriginalArrivalTime: 31 Jan 2007 11:53:50.0426 (UTC) FILETIME=[7900DBA0:01C7452E] X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 26 January 2007 09:17 > To: ext GOLDMAN, STUART O (STUART) > Cc: pcn@ietf.org > Subject: Re: [PCN] charter text update >=20 > Hi, >=20 > On 2007-1-25, at 21:31, ext GOLDMAN, STUART O (STUART) wrote: > > I have several questions regarding the proposed new charter which > > may be > > because I don't have a real good understanding of pre-congestion > > versus > > actual congestion: > > > > (1) a general architecture for flow admission and preemption based > > on aggregated (pre-)congestion signals > > > > Why would we want to preempt existing real sessions prior to an actual > > congestion? >=20 > First, "(pre-)congestion signals" expands to "pre-congestion and > congestion signals." (I"m not too happy with this abbreviation, but > using the expanded version everywhere is also not good - > suggestions?) So maybe the edge reacts to pre-congestion signals with > admission decisions, but to congestion signals (due to equipment > failure, etc.) with preemption decisions. >=20 also, once actual congestion is occurring then the QoS of all flows is degraded. Rather than risk this happening, some may prefer to protect the QoS of (most) existing flows by pre-empting a (few) flows. > But allowing an edge to preempt flows based on pre-congestion signals > might also make sense, and I wouldn't want to exclude this option. > Note that the edge policies will be described in Informational > documents only, and maybe the WG wants to describe multiple edge > policies that establish different behaviors. >=20 >=20 > > (E) flows may have different precedence, but the applicability of > > these > > mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of > > scope > > > > By this I assume that we would not preempt or prevent these kinds of > > emergency calls. What does it imply about preemption of ordinary calls > > in favor of emergency calls? >=20 > This is supposed to express that whereas the edge is free to treat > flows differently when it comes to deciding whether to admit or > preempt some, use of the admission/preemption mechanisms for > emergency use - with all the policy and legal implications that > entails - is out of scope. >=20 > I'm open for suggestions on how to phrase this more clearly. >=20 > > As for the name, it did seem to me at least that the ability to > > anticipate congestion and modify edge behavior is more palatable than > > focusing on when congestion exists as implied by the FLAP name (Flow > > Admission and Preemption (flap)). Am I misinterpreting the impression > > this would leave in peoples' minds? >=20 > People have convinced me that sticking to the original PCN name is > better. I will make that change in the next revision. >=20 > Lars >=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 Wed Jan 31 06:59:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCE7y-0002fl-Uz; Wed, 31 Jan 2007 06:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCE7x-0002ff-7z for pcn@ietf.org; Wed, 31 Jan 2007 06:59:49 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCE7v-000510-Kd for pcn@ietf.org; Wed, 31 Jan 2007 06:59:49 -0500 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:59:46 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Jan 2007 11:59:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 11:59:44 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEB5@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000c01c74389$1a6314b0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdAUc0vwsHQ1a70Qz6/ObSb1A/8SQC/UQRwAA3Z8TAAagiO0A== From: To: , , X-OriginalArrivalTime: 31 Jan 2007 11:59:46.0214 (UTC) FILETIME=[4D11CC60:01C7452F] X-Spam-Score: 0.2 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 29 January 2007 09:37 > To: 'Lars Eggert'; pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Hi Lars >=20 > I agree with Jozef. In my opinion, > during the IETF in San Diego one could find a consensus to > consider the application aware (pre-)congestion as being in > the scope of this WG. > Furthermore, also in the e-mail discussions, I did not > encounter a severe objection on introducing the application aware > (pre-)congestion as being in the scope of this WG. >=20 > I would very much appreciate if you at least could include the following > (modified proposal) of Jozef: > "the PCN WG will define requirements for > conveying (pre-)congestion information from the receiver to > the sender and the actions that both the receiving end host or gateway and > sending end host or gateway should perform." >=20 >=20 > In addition to this I have another comment on the charter description. > Regarding the following paragraph: >=20 > "After completion of the initial phase, the PCN WG may re-charter to > develop > solutions for scenarios where some of these restrictions are not in place. > It may also re-charter to consider applying the PCN mechanisms to > additional > deployment scenarios (operation over concatenated DiffServ regions, > PCN-aware application mechanisms, etc.). The WG may also consider to > investigate additional response mechanisms that act on (pre-)congestion > signals. One example could be flow-rate adaptation (rather than flow > admission/preemption) during times of congestion. The details of these > work > items are outside the scope of the initial phase; but the WG should > consider > their requirements to design components that are sufficiently general to > support such extensions in the future." >=20 > First you mention: > "The WG may also consider to investigate additional response mechanisms > that > act on (pre-)congestion signals. One example could be flow-rate adaptation > (rather than flow admission/preemption) during times of congestion." >=20 > And then you say: > "The details of these work items are outside the scope of the initial > phase; > but the WG should consider their requirements to design components that > are > sufficiently general to support such extensions in the future." >=20 > I think that the two above sentences contradict each other some how. > What you actually say in the second sentence is that the requirements of > the > flow-rate adaptation during times of congestion should be considered to > design components that are sufficiently general to support such extensions > in the future. However, in the first paragraph you mention that flow-rate > adaptation during times of congestion might be considered, but it is not > sure that this will happen. > I will very much appreciate if you could change the following sentence: >=20 > Please change from: > "The WG may also consider to investigate additional response mechanisms > that > act on (pre-)congestion signals. One example could be flow-rate adaptation > (rather than flow admission/preemption) during times of congestion." >=20 > INTO: > "The WG should consider to investigate additional response mechanisms that > act on (pre-)congestion signals. One example is the flow-rate adaptation > (rather than flow admission/preemption) during times of congestion." I think you're suggesting saying now what will definitely be in a re-charter. This doesn't sound possible to me.=20 (incidentally, personally I think the case of flow-rate adaptation based on pre-congestion marks is rather different - eg will be hard to translate lessons from the work from simulations/ performance analysis during the work of the initial charter.) >=20 > Best Regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: Jozef Babiarz [mailto:babiarz@nortel.com] > > Sent: maandag 29 januari 2007 3:47 > > To: Lars Eggert; pcn@ietf.org > > Subject: RE: [PCN] charter, addition to scope > > > > Lars, > > Do not understand why application aware (pre-)congestion is > > out of scope? At the BOF in San Diego and on the PCN mailing > > list there was support for it with people will to work on it. > > Specifically what I would like to add to scope in the PCN > > charter is that "the PCN WG will define requirements for > > conveying (pre-)congestion information from the receiver to > > the sender and the actions that both the receiving host and > > sending host should perform." > > > > Regards, Joe > > Telephone: 613-763-6098 (ESN 393-6098) > > Email: babiarz@nortel.com > > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: January 25, 2007 2:23 AM > > To: pcn@ietf.org > > Subject: [PCN] charter text update > > > > (I thought I had sent this several days ago, but it > > apparently never made it to the list?) > > > > Hi, > > > > below is a modified version of the PCN charter posted to this > > list a while ago. I believe it reflects the consensus after > > the face-to-face and mailing list discussions in and after Montreal. > > > > Compared to the earlier version, the major changes are: > > > > - removal of SIP, application-based and PW deployment scenarios > > - stronger language on assumptions and scope > > - refactored deliverables and milestones > > - name change (don't feel strongly about this) > > > > Please send your comments to the list. > > > > Lars > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 07:02:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEA2-0003mi-U8; Wed, 31 Jan 2007 07:01:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEA2-0003iM-5Q for pcn@ietf.org; Wed, 31 Jan 2007 07:01:58 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCE9s-0005Xw-NS for pcn@ietf.org; Wed, 31 Jan 2007 07:01:58 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08D41207A2; Wed, 31 Jan 2007 13:01:44 +0100 (CET) X-AuditID: c1b4fb3c-affc8bb0000007de-8e-45c0852761c4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EAFA22075B; Wed, 31 Jan 2007 13:01:43 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 13:01:43 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 13:01:43 +0100 Message-ID: <45C08527.5050607@ericsson.com> Date: Wed, 31 Jan 2007 13:01:43 +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 Westberg Subject: Re: [PCN] charter, addition to scope References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com> <010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> <45C05A40.300@ericsson.com> <45C05D66.2070806@ericsson.com> In-Reply-To: <45C05D66.2070806@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 12:01:43.0396 (UTC) FILETIME=[92EA5A40:01C7452F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 may I do not have the background for the decissions and I haven't got any reply on my questions yet. I have gotten simillar respone two times and I think that we have two choices: 1) discuss it somewhere else in another standardization body. 2) initiate a new BOF for this task. I don't understand the decision. Admission control function is typical function i n MGW not in backbone routers. regards Lasse Lars Westberg wrote: > what is the problem? > Is trust between routers more common than the other scenario? > One problem I forsee it that the architecture for routers may include > limitations for thw other scenario. > > What is the way forward? > wait to the next re-charter 3-year ahead ? > > regards Lasse > > Lars Eggert wrote: > >> On 2007-1-31, at 10:58, ext Lars Westberg wrote: >> >>> If I interprete you correctly, examples are lacking, for trust to >>> other nodes ? >> >> >> >> Read again. I said I _don't_ dispute that such examples exist. >> >> Lars >> >> > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 07:06:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEED-0005uD-5S; Wed, 31 Jan 2007 07:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEEC-0005u8-Bj for pcn@ietf.org; Wed, 31 Jan 2007 07:06:16 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCEEA-00075D-Iq for pcn@ietf.org; Wed, 31 Jan 2007 07:06:16 -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 l0VC5l3Z004333; Wed, 31 Jan 2007 13:05:53 +0100 (MET) From: "Georgios Karagiannis" To: "'Kwok-Ho Chan'" , "'Lars Eggert'" References: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com><6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> <6.2.5.6.0.20070130120548.056e6b28@nortel.com> Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 13:06:02 +0100 Message-ID: <003d01c74530$30a38cc0$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: <6.2.5.6.0.20070130120548.056e6b28@nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdEkmcoHhPZdDWJTBWw8rwPJCixugAnUUJQ X-Spam-Score: 0.083 () 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, 31 Jan 2007 13:05:54 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Kwok You are very right the "Application Control Deployment" can be "edge-to-edge" and not host-to-host. I think that this is a matter of right terminology. Best Regards, Georgios > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: dinsdag 30 januari 2007 18:17 > To: Lars Eggert > Cc: pcn@ietf.org > Subject: Re: [PCN] charter, addition to scope > > Lars: > By the last sentence of your E-Mail, > I think you are equating "Application Control Deployment" > with "host-to-host". > Which may be your reasoning for excluding "Application > Control Deployment". > > "Application Control Deployment" can be "edge-to-edge", which > will very much use the same behaviors and mechanisms that we > can standardize in PCN. > > Hence IMHO, the "Application Control Deployment" for "edge-to-edge" > fits very well > within the work being done in the first phase of PCN and > should be included as a work item (informational track) for > the first phase of PCN. > > Please separate the notion of "host-to-host" from > "Application Control Deployment". > Thanks! > -- Kwok -- > > > At 10:26 AM 1/29/2007, Lars Eggert wrote: > >On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > >>I am a bit confused about one item in this scheme. As I > understand the > >>principle, when the core senses that it is approaching > congestion, the > >>edge nodes are requested to reduce their offerings. > > > >Under the initial model, it is the edge *routers* that are acting on > >the signal from the interior. Which is why all routers need to trust > >each other. > > > >>What is the > >>motivation for a given edge node to do so? It seems that if > the other > >>edge nodes do reduce their offerings then a "renegade" edge > node could > >>take advantage of the reduction in traffic at the core to > continue to > >>send his traffic. Such behavior would logically lead the others to > >>follow unless there was some sort of policing. > > > >Right, all these issues (and others) exist with the host-to-host > >deployment scenario, which is why we're declaring this to be out-of- > >scope initially. > > > >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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 07:45:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEq9-0006uL-2Y; Wed, 31 Jan 2007 07:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEq8-0006uF-6b for pcn@ietf.org; Wed, 31 Jan 2007 07:45:28 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCEq0-0001pd-DQ for pcn@ietf.org; Wed, 31 Jan 2007 07:45:28 -0500 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 12:45:11 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Jan 2007 12:45:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 12:45:07 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEB9@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <002001c7452c$291184c0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igAANZLOA= From: To: , , X-OriginalArrivalTime: 31 Jan 2007 12:45:09.0366 (UTC) FILETIME=[A431D160:01C74535] X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 31 January 2007 11:37 > To: 'Lars Eggert'; 'ext Jozef Babiarz' > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Hi Lars >=20 > Please see in line! >=20 > > > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > > In the first phase of PCN work to reduce the list of issues it was > > > proposed that the WG focus on network deployment scenario where all > > > nodes can be trusted and delay work on deployment scenarios > > where some > > > of the nodes are not trusted. > > > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If "nodes" > > include end systems, proxies or other entities, then I don't > > agree we had agreement on that. >=20 >=20 > Georgios: This imposes an additional restriction on the scope > of the charter, which has been not discussed yet. > >From what I remember before, during and after the PCN BOF > there was no objection on using > the term edge node, that could mean something different than a edge > router. > Please note that this is something different than a scenario covered by > an application based deployment model. >=20 > Note that we have used this term in the first version of the > PCN BOF charter and also > the draft: > http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement- > 01.txt >=20 > Is it okay with you if end nodes could be gateways/routers? >=20 >=20 > > > Currently, there are examples of scenarios where hosts are > > trusted by > > > the network. Some examples are, 3G wireless terminal, media > > gateways, > > > IP telephone sets connected in enterprise networks, enterprises run > > > "plug-in modules" that verifies/enforces hardware and software the > > > employees can run on their personal computers when they connect to > > > their network. So I do not agree that so called host-to-host > > > deployment has a trust that is non starter for PCN workgroup to > > > address. > > > > (by Lars: ) I don't dispute that examples exists where mutual trust > > exists among the routers, hosts and other boxes in the > > network. But there are clearly many cases where such trust > > doesn't exist. At and after the BOF, there was agreement that > > the case where such trust exists between the routers of a > > single network domain had been described in sufficient detail > > to be solvable by the IETF. When the trust extended to other > > nodes, that agreement wasn't there. >=20 > Georgios: From the point of security vulnerabilities I am not sure > if there are main differences between the scenario that one trusted domain > is used > or the scenario where two or more concateneted > trusted domains are used. Note that the two or more concateneted trusted > domains can be seen as one trusted domain (from the point of security > vulnerabilities) the charter says a "single Diffserv region". DS region [rfc2475] " a set of contiguous DS domains which can offer differentiated services over paths across those DS domains." >=20 >=20 > > > > > The trust issue will need to be address if PCN mechanism is > > to be used > > > in open networks like the Internet, where an ingress router can not > > > trust its neighbor ingress router or an egress routers or any other > > > node that connects to the network (e.g., media gateway, wireless > > > access point, IP telephone sets, personal computers, servers, etc.) > > > that my be associated with the PCN mechanism. > > > > Completely agree. Which is why we're limiting the scope of > > the initial problem to a single network domain. How PCN > > operates when some or even most of the routers or other nodes > > aren't trusted is an open problem. > > > > Lars >=20 >=20 > Best Regards, > Georgios >=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 Wed Jan 31 07:54:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEyx-0001lc-JE; Wed, 31 Jan 2007 07:54:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEyw-0001lN-Cc for pcn@ietf.org; Wed, 31 Jan 2007 07:54:34 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCEyb-00048I-53 for pcn@ietf.org; Wed, 31 Jan 2007 07:54:34 -0500 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 12:54:12 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Jan 2007 12:54:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter text update Date: Wed, 31 Jan 2007 12:54:11 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdAn/FfTVCky36NTfubwjzA1opfgAEj9lVA From: To: , X-OriginalArrivalTime: 31 Jan 2007 12:54:11.0876 (UTC) FILETIME=[E78E4640:01C74536] X-Spam-Score: 0.2 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: 25 January 2007 16:37 > To: Lars Eggert > Cc: pcn@ietf.org > Subject: Re: [PCN] charter text update >=20 > Lars, >=20 > I'd have a strong preference to keep the previous name, and to soften > the use of the term Preemption in the charter. if the IESG is > consistent, some of the them will have a difficult time with the term > preemption and will kick back the charter and ask that it be > reworded. Some in the IESG had a hard time with this subject (as > well as some others) in the IEPREP group -- both in the past and most > recently in the IETF mailing list concerning an attempted re- > chartering effort for IEPREP. >=20 > A few months i brought up this topic on PCN and mentioned how under > certain scenarios/circumstances, the use of preemption for VoIP is > simply not allowed in certain countries. >=20 > http://www1.ietf.org/mail-archive/web/pcn/current/msg00023.html > http://www1.ietf.org/mail-archive/web/pcn/current/msg00037.html > http://www1.ietf.org/mail-archive/web/pcn/current/msg00046.html > http://www1.ietf.org/mail-archive/web/pcn/current/msg00053.html >=20 > Unfortunately, the subject of what is legal/regulated is not one that > technical in nature, but it is something that should be considered by > the group. In my previous comments, I was trying to encourage the > group to treat preemption as one of several (re)actions that can be > advanced by the group. I'd like to re-encourage this line of thought > and text in the Charter. Ken, I remember thinking about this before the BoF, when we were experimenting with wordings for the BoF. It proved (to my surprise) difficult to find a wording that worked.=20 For example, saying something like "the WG will specify a mechanism to determine how much excess traffic is; the WG will not specify a required reaction to this information, but it will write an Info on flow pre-emption as one possible reaction (which may not be allowed for legal /regulatory reasons)" The problem is that this assumes the mechanism will work by measuring the excess traffic. Although this is the way described in the CL-drafts, others have in mind a different method. So instead we went back to saying that the WG will standardise how the edge makes a pre-emption decision, but ruling handling of emergency calls as out of scope. so as to rule out thinking about nasty legal/regulatory issues. But hopefully you can find a better phrasing! However, I think I disagree with you when you say "preemption as one of several (re)actions that can be advanced by the group". I think that in the initial charter that the WG should advance only one "(re)action" ie flow pre-emption (as well as adm ctrl). Other possible reactions (say adapting rate of flows) should be after re-chartering.=20 >=20 > regards, >=20 > -ken >=20 > ps, my apologies in not volunteering specific suggested text changes > right now, but I'm preparing for a couple of days of travel (ugh). >=20 >=20 > On Jan 25, 2007, at 4:23 AM, Lars Eggert wrote: >=20 > > (I thought I had sent this several days ago, but it apparently > > never made it to the list?) > > > > Hi, > > > > below is a modified version of the PCN charter posted to this list > > a while ago. I believe it reflects the consensus after the face-to- > > face and mailing list discussions in and after Montreal. > > > > Compared to the earlier version, the major changes are: > > > > - removal of SIP, application-based and PW deployment scenarios > > - stronger language on assumptions and scope > > - refactored deliverables and milestones > > - name change (don't feel strongly about this) > > > > Please send your comments to the list. > > > > Lars > > > > ---------------------------------------------------------------------- > > ---- > > > > Flow Admission and Preemption (flap) > > Chair(s): > > tbd > > > > > > Description of Working Group: > > > > The Flow Admission and Preemption (FLAP) working group develops > > flow admission and flow preemption mechanisms for deployment along > > the edge of a network domain that protect the quality-of-service > > that previously-admitted flows experience within the domain during > > times of congestion. These mechanisms act on aggregated congestion > > and pre-congestion signals from routers within the network domain > > and control the admission of new flows into the domain or preempt > > previously-admitted flows. Although designed to work together, flow > > admission and flow preemption are independent mechanisms, and the > > use of one does not require the use of the other. > > > > The FLAP WG will specify the following components of an integrated > > flow admission and preemption mechanism: > > > > (1) a general architecture for flow admission and preemption based > > on aggregated (pre-)congestion signals > > > > (2) conditions under which interior routers generate > > (pre-)congestion signals > > > > (3) encoding and transport of (pre-)congestion signals > > to the appropriate ingress routers of the network domain > > > > (4) edge router control mechanisms for flow admission and > > preemption based on aggregated (pre-)congestion information > > > > The WG focuses on the overall architecture and specifically the > > signaling interfaces needed to realize it. Standards-track > > protocols are only developed when necessary for interoperability. > > When algorithms are not necessary for interoperability the WG may > > document examples or provide recommended solutions, however such > > work should not be done at the expense of normative specifications. > > > > > > The initial scope of the FLAP WG is restricted in the following ways: > > > > (A) develop these components for a single DiffServ region, > > where all edge and interior routers are FLAP-enabled > > and mutually trust each other > > > > (B) all flows handled by these mechanisms are inelastic and > > constrained to a known maximum rate through policing or shaping > > > > (C) the number of flows across any potential aggregation bottleneck > > is sufficiently large for stateless, statistical mechanisms > > to be > > effective > > > > (D) aggregation occurs either on links or ingress/egress pairs; > > mechanisms must further define relevant limits > > > > (E) flows may have different precedence, but the applicability > > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > > etc.) > > is out of scope > > > > After completion of the initial phase, the FLAP WG may recharter to > > develop solutions for scenarios where some of these restrictions > > are not in place. It may also recharter to consider applying the > > FLAP mechanisms to additional deployment scenarios (operation over > > concatenated DiffServ regions, FLAP-aware application mechanisms, > > etc.). The WG may also consider to investigate additional response > > mechanisms that act on (pre-)congestion signals. One example could > > be flow-rate adaptation (rather than flow admission/preemption) > > during times of congestion. The details of these work items are > > outside the scope of the initial phase; but the WG may want to > > > > However in the initial scope this mechanism is out-of-scope with > > the exception that the developed solution should not, if possible, > > prevent a future evolution to support this. > > > > > > Goals and Milestones: > > > > Jul 2007 Flow Admission and Preemption Architecture > > (Informational) > > > > Jul 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Signals within a DiffServ Region > > (Informational) > > > > Nov 2007 Flow Admission and Preemption within a DiffServ > > Region (Informational) > > > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > > (Proposed Standard) > > > > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > > within a DiffServ Region to Flow Egress (Proposed Standard) > > > > Mar 2008 Transport from Flow Egress in a DiffServ Region of > > information > > (possibly aggregated) or Admission/Preemption Signals to > > DiffServ edge devices. (Proposed Standard) > > > > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > > (Informational) > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 08:02:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCF6R-0005HY-Hr; Wed, 31 Jan 2007 08:02:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCF6Q-0005HK-IH for pcn@ietf.org; Wed, 31 Jan 2007 08:02:18 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCF6G-00062A-0j for pcn@ietf.org; Wed, 31 Jan 2007 08:02:18 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6185520246; Wed, 31 Jan 2007 14:02:05 +0100 (CET) X-AuditID: c1b4fb3e-ae6d0bb0000007e1-4a-45c0934dc6d4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 460E02010F; Wed, 31 Jan 2007 14:02:05 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:02:04 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:01:53 +0100 Message-ID: <45C09341.3040503@ericsson.com> Date: Wed, 31 Jan 2007 14:01:53 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [PCN] charter, addition to scope References: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com><6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> <6.2.5.6.0.20070130120548.056e6b28@nortel.com> <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 13:01:53.0530 (UTC) FILETIME=[FAB915A0:01C74537] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Georgios Karagiannis skrev: > Hi Kwok > > You are very right the "Application Control Deployment" > can be "edge-to-edge" and not host-to-host. > I think that this is a matter of right terminology. Independent of that, there is no good description of what this would mean. draft-babiarz-pcn-sip-cap-00 seems to only talk about end-to-end cases. Or at least where the PCN aware equipment would reside outside a PCN domain. The problem from Lars Eggert and my perspective is that there is no consensus on what application control means in this scenario while it is reasonably simple to understand using RSVP towards a PCN domain, and using PCN information to determine if the reservation is acceptable or not. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 08:49:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFqW-0002su-Ea; Wed, 31 Jan 2007 08:49:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFqU-0002sY-UD for pcn@ietf.org; Wed, 31 Jan 2007 08:49:54 -0500 Received: from smtp.hosts.co.uk ([85.233.160.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFqR-0003Nw-Ob for pcn@ietf.org; Wed, 31 Jan 2007 08:49:54 -0500 Received: from [69.255.82.176] (helo=[192.168.1.3]) by smtp.hosts.co.uk with esmtpa (Exim 4.63) (envelope-from ) id 1HCFqQ-0002dz-0u; Wed, 31 Jan 2007 13:49:50 +0000 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBA@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBA@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] charter text update Date: Wed, 31 Jan 2007 08:49:47 -0500 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, > So instead we went back to saying that the WG will standardise how the > edge makes a pre-emption decision, but ruling handling of emergency > calls as out of scope. so as to rule out thinking about nasty > legal/regulatory issues. But hopefully you can find a better phrasing! I debated whether to respond to something similar stated by Lars E., but since you are touching on the same thing I'll speak up now. The subjects of pre-emption and emergency calls/services are some what tangential to each other. I understand the position that how emergency calls are handled (the protocols/mechanisms) is out of scope. No problem. However, put simply, preemption involving the PSTN in some countries (eg, USA and Germany) is simply not allowed under *any* conditions....regardless if there are emergency calls or not. And given that those VoIP providers that bridge to the PSTN tend to be subject to the same regulations as the PSTN (eg, required support for 911), then I _think_ its a safe bet that this restriction of preemption applies as well. So all I'm advocating for is making sure the group doesn't paint itself into a corner. Until other (re)actions are defined, or regulations are changed, deployment would seem to be limited for preemption as a (re)action. > However, I think I disagree with you when you say "preemption as > one of > several (re)actions that can be advanced by the group". I think > that in > the initial charter that the WG should advance only one "(re) > action" ie > flow pre-emption (as well as adm ctrl). Other possible reactions (say > adapting rate of flows) should be after re-chartering. I have no issues in advancing one (re)action in the first iteration of the WG. I just think its important that the WG makes it clear in the proposed charter that other (re)actions can exist, and in its work agrees on the hooks to allow this to happen. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 08:51:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFsR-0003bi-TQ; Wed, 31 Jan 2007 08:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFsQ-0003ZN-T2 for pcn@ietf.org; Wed, 31 Jan 2007 08:51:54 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFsM-0003mo-4F for pcn@ietf.org; Wed, 31 Jan 2007 08:51:54 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 13:46:48 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Jan 2007 13:46:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 13:46:28 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdEkmcoHhPZdDWJTBWw8rwPJCixugAnUUJQAAH+TyA= From: To: , , X-OriginalArrivalTime: 31 Jan 2007 13:46:28.0848 (UTC) FILETIME=[35563700:01C7453E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I'm not sure, but I think there may be violent agreement. Thinking only about PCN mechanisms running edge-to-edge, which is what's in scope in Lars's charter. In terms of how new flows are requested: - we have what is described in draft-briscoe-tsvwg-cl-architecture-04.txt. RSVP from end host reaches PCN-region ingress gateway, which checks the current Congestion-Level-Estimate for the relevant ingress-egress-aggregate, and hence decides whether to admit the new flow request.=20 - I can imagine an alternative (which I think is "Application Control Deployment" or Lars W's MGW case) where some signalling from the end host (not RSVP) reaches an 'admission controller', which is in the PCN-region but is not (necessarily) on the data path (if the flow is admitted). The 'admission controller' would work out what the PCN-ingress & PCN-egress would be (eg if the call is admitted, the data will enter the PCN-region via this ingress). It would then discover what the current Congestion-Level-Estimate for the relevant ingress-egress-aggregate, and hence decides whether to admit the new flow request. - case 2 sounds reasonable to me, but is not really described anywhere at the moment (draft-babiarz-pcn-sip-cap-00.txt touches it, but that draft is really about the host-to-host case) - case 2 isn't explicitly in or out of the current draft charter=20 - what would including case 2 impact? (in terms of the Charter work items). I think it's only the architecture doc that would change (get an extra section), and even that is mainly in terms of operation outside the PCN-region. technical arguments about the right encoding, marking behaviour etc won't be altered. To me this suggests it's easier to exclude it, just so there's less to write, but I don't really mind. However, if I'm wrong and it will change the technical arguments then it probably should be included (but please hint why/how now!) =20 best wishes, phil > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 31 January 2007 12:06 > To: 'Kwok-Ho Chan'; 'Lars Eggert' > Cc: pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope >=20 > Hi Kwok >=20 > You are very right the "Application Control Deployment" > can be "edge-to-edge" and not host-to-host. > I think that this is a matter of right terminology. >=20 > Best Regards, > Georgios >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > Sent: dinsdag 30 januari 2007 18:17 > > To: Lars Eggert > > Cc: pcn@ietf.org > > Subject: Re: [PCN] charter, addition to scope > > > > Lars: > > By the last sentence of your E-Mail, > > I think you are equating "Application Control Deployment" > > with "host-to-host". > > Which may be your reasoning for excluding "Application > > Control Deployment". > > > > "Application Control Deployment" can be "edge-to-edge", which > > will very much use the same behaviors and mechanisms that we > > can standardize in PCN. > > > > Hence IMHO, the "Application Control Deployment" for "edge-to-edge" > > fits very well > > within the work being done in the first phase of PCN and > > should be included as a work item (informational track) for > > the first phase of PCN. > > > > Please separate the notion of "host-to-host" from > > "Application Control Deployment". > > Thanks! > > -- Kwok -- > > > > > > At 10:26 AM 1/29/2007, Lars Eggert wrote: > > >On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > > >>I am a bit confused about one item in this scheme. As I > > understand the > > >>principle, when the core senses that it is approaching > > congestion, the > > >>edge nodes are requested to reduce their offerings. > > > > > >Under the initial model, it is the edge *routers* that are acting on > > >the signal from the interior. Which is why all routers need to trust > > >each other. > > > > > >>What is the > > >>motivation for a given edge node to do so? It seems that if > > the other > > >>edge nodes do reduce their offerings then a "renegade" edge > > node could > > >>take advantage of the reduction in traffic at the core to > > continue to > > >>send his traffic. Such behavior would logically lead the others to > > >>follow unless there was some sort of policing. > > > > > >Right, all these issues (and others) exist with the host-to-host > > >deployment scenario, which is why we're declaring this to be out-of- > > >scope initially. > > > > > >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 > > >=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 Wed Jan 31 09:12:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGC1-0005XL-QM; Wed, 31 Jan 2007 09:12:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGC0-0005X8-2d for pcn@ietf.org; Wed, 31 Jan 2007 09:12:08 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGBy-0002MT-KU for pcn@ietf.org; Wed, 31 Jan 2007 09:12:08 -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 l0VEBZuw010478; Wed, 31 Jan 2007 15:11:43 +0100 (MET) From: "Georgios Karagiannis" To: "'Magnus Westerlund'" References: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com><6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> <6.2.5.6.0.20070130120548.056e6b28@nortel.com> <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <45C09341.3040503@ericsson.com> Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 15:11:49 +0100 Message-ID: <004701c74541$c5a4c850$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: <45C09341.3040503@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdFN/Y8KQGpZgI5RJa2zr5P8Iev9AACLsSA X-Spam-Score: 0.083 () 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, 31 Jan 2007 15:11:43 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Magnus In the following draft we have tried to somehow explain what a PCN regios is and which nodes it has to use: http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01.txt In order to satisfy your concerns I have changed a bit the used terms, see below. Please note that I have changed the term PCN End Node to PCN Edge Node. Furthermore, I removed the term end hosts: PCN-Region: A DiffServ region of the Internet running PCN, that is the PCN- based mechanisms are used to decide whether to admit a new flow to the DiffServ region and whether to pre-empt an existing flow. All traffic enters/leaves the PCN-Region through a PCN Edge Node. Please note that the PCN-Region is also defined by the Diffserv Service Class [18] that is subject to the PCN mechanisms. PCN Interior Node (PIN) (function): The PCN Interior Node is an "on-path" function. It performs traffic metering and PCN-marking: the function that enables a network element to give an early warning of its own incipient congestion ("pre-congestion") on one of its interfaces, ie traffic is above a certain level, by marking, e.g. changing the header of packet(s). PCN Edge Node (PEN) (function): The PCN Edge Node is an "on-path" function. The PCN Edge Node is where the PCN Region ends. It indicates the significance of the PCN packet marking which terminates at this functional node. This functional description does not imply which physical device will implement this function (e.g., edge router, media gateway). This "on-path" function performs the detection of PCN-marks: the function that monitors PCN-marking to obtain on-path congestion information as signaled through PCN-marking by PCN-enabled Interior Nodes. Best Regards, Georgios > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: woensdag 31 januari 2007 14:02 > To: Georgios Karagiannis > Cc: 'Kwok-Ho Chan'; 'Lars Eggert'; pcn@ietf.org > Subject: Re: [PCN] charter, addition to scope > > Georgios Karagiannis skrev: > > Hi Kwok > > > > You are very right the "Application Control Deployment" > > can be "edge-to-edge" and not host-to-host. > > I think that this is a matter of right terminology. > > Independent of that, there is no good description of what > this would mean. draft-babiarz-pcn-sip-cap-00 seems to only > talk about end-to-end cases. Or at least where the PCN aware > equipment would reside outside a PCN domain. > > The problem from Lars Eggert and my perspective is that there > is no consensus on what application control means in this > scenario while it is reasonably simple to understand using > RSVP towards a PCN domain, and using PCN information to > determine if the reservation is acceptable or not. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 09:39:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGce-0002d5-Ma; Wed, 31 Jan 2007 09:39:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGcd-0002d0-Rk for pcn@ietf.org; Wed, 31 Jan 2007 09:39:39 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGcb-0002sc-C1 for pcn@ietf.org; Wed, 31 Jan 2007 09:39:39 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 31 Jan 2007 15:39:36 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:39:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PCN] charter text update Date: Wed, 31 Jan 2007 15:39:35 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBFAE7@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update thread-index: AcdFPwbHLU1P7gx3SWyQEMKnOi0LEAAALJYw From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 31 Jan 2007 14:39:35.0803 (UTC) FILETIME=[A0E8F4B0:01C74545] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ken, Phil what you say is that "preemption" must not be the only reaction=20 specified by PCN once an ingress edge router determines that=20 the path to a particular egress router reached=20 congestion/preemption state?=20 If yes, I agree. Would the charter have to say so or should=20 this be a design constraint to be kept in mind when drafting=20 standards? The minimum requirement may be to demand that the deactivation=20 of a preemption mechanism must be possible (the PCN domain=20 would then always interpret congestion marks in the same way as=20 pre-congestion marks ). In the trusted inter domain case, both=20 ends may follow different implementations. PCN should ensure=20 interoperability then. I now also understand Jozef Babiarz proposal to change=20 "preemption" to "congestion" in the charter. The behaviour=20 "Preemption" would then be one option how to react on congestion. And the PCN WG must work on the preemption behaviour, but also=20 must allow for operation without it. Jozefs proposed new charter simply replaced "preemption" by=20 "congestion", if I recall right. May be doing so but adding a=20 statement on using the state "congestion" to trigger=20 preemption (as one possible reaction) could help to clarify=20 the charter?=20 =20 Regards, Ruediger |-----Original Message----- |From: ken carlberg [mailto:carlberg@g11.org.uk] |Sent: Wednesday, January 31, 2007 2:50 PM |To: philip.eardley@bt.com |Cc: pcn@ietf.org |Subject: Re: [PCN] charter text update | | |Phil, | |> So instead we went back to saying that the WG will standardise how the |> edge makes a pre-emption decision, but ruling handling of emergency |> calls as out of scope. so as to rule out thinking about nasty |> legal/regulatory issues. But hopefully you can find a better phrasing! | |I debated whether to respond to something similar stated by Lars E., =20 |but since you are touching on the same thing I'll speak up now. The =20 |subjects of pre-emption and emergency calls/services are some what =20 |tangential to each other. I understand the position that how =20 |emergency calls are handled (the protocols/mechanisms) is out of =20 |scope. No problem. | |However, put simply, preemption involving the PSTN in some countries =20 |(eg, USA and Germany) is simply not allowed under *any* =20 |conditions....regardless if there are emergency calls or not. And =20 |given that those VoIP providers that bridge to the PSTN tend to be =20 |subject to the same regulations as the PSTN (eg, required support for =20 |911), then I _think_ its a safe bet that this restriction of =20 |preemption applies as well. | |So all I'm advocating for is making sure the group doesn't paint =20 |itself into a corner. Until other (re)actions are defined, or =20 |regulations are changed, deployment would seem to be limited for =20 |preemption as a (re)action. | |> However, I think I disagree with you when you say "preemption as =20 |> one of |> several (re)actions that can be advanced by the group". I think =20 |> that in |> the initial charter that the WG should advance only one "(re)=20 |> action" ie |> flow pre-emption (as well as adm ctrl). Other possible reactions (say |> adapting rate of flows) should be after re-chartering. | |I have no issues in advancing one (re)action in the first iteration =20 |of the WG. I just think its important that the WG makes it clear in =20 |the proposed charter that other (re)actions can exist, and in its =20 |work agrees on the hooks to allow this to happen. | |-ken | | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 09:59:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGw9-0004gQ-Nc; Wed, 31 Jan 2007 09:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGw8-0004en-9d for pcn@ietf.org; Wed, 31 Jan 2007 09:59:48 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGvz-0000SD-GT for pcn@ietf.org; Wed, 31 Jan 2007 09:59:48 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CF06A548044; Wed, 31 Jan 2007 15:59:32 +0100 (CET) X-AuditID: c1b4fb3c-affc8bb0000007de-ae-45c0aed4becc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AF4B3520001; Wed, 31 Jan 2007 15:59:32 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:59:32 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:59:32 +0100 Message-ID: <45C0AED4.1060404@ericsson.com> Date: Wed, 31 Jan 2007 15:59:32 +0100 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [PCN] charter, addition to scope References: <7D096A439A3D0D48A3D10872022CFD09A951D5@ILEXC1U02.ndc.lucent.com><6654A6BA-6D09-4B26-B020-8B65FB5347F5@nokia.com> <6.2.5.6.0.20070130120548.056e6b28@nortel.com><003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <45C09341.3040503@ericsson.com> In-Reply-To: <45C09341.3040503@ericsson.com> X-OriginalArrivalTime: 31 Jan 2007 14:59:32.0233 (UTC) FILETIME=[6A09AF90:01C74548] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0252750555==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0252750555== Content-Type: multipart/alternative; boundary="------------000108060101050305000309" This is a multi-part message in MIME format. --------------000108060101050305000309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think it is some mis-understanding. I am not refering to end-p2-end scenarios. I am refering telecom scenario where MGWs are connected to an IP-backbone. In these scenarios, the admission control function is a part of the MGW and not the routers. The IP-backbone is provisioned by a network managmenent systen. We are refering to a scenario when bandwidth (in the network) are shared among a number of entities that are connected to the same multi-service backbone. In some way, the notification has to be sent to the MGW. The MGW can block calls (reduce the traffic vlume) and the edge-router can dropping packet. However, packet drops is not recommended for the sensitive traffic. Therefore, some interation has to be there and I do not understand why we only limit the scenario to admission control in a edge-routers. Some vendors might be interested in this sceario, but I am worried that this will put restriction of the architecture. so, once again, give a summary of the reasons not to include Admission control into other entities than routers. Magnus Westerlund wrote: > Georgios Karagiannis skrev: > > Hi Kwok > > > > You are very right the "Application Control Deployment" > > can be "edge-to-edge" and not host-to-host. > > I think that this is a matter of right terminology. > > Independent of that, there is no good description of what this would > mean. draft-babiarz-pcn-sip-cap-00 seems to only talk about end-to-end > cases. Or at least where the PCN aware equipment would reside outside a > PCN domain. > > The problem from Lars Eggert and my perspective is that there is no > consensus on what application control means in this scenario while it is > reasonably simple to understand using RSVP towards a PCN domain, and > using PCN information to determine if the reservation is acceptable or > not. > > 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 > --------------000108060101050305000309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think it is some mis-understanding.
I am not refering to end-p2-end scenarios. I am refering telecom scenario where MGWs are connected to an IP-backbone. In these scenarios, the admission control function is a part of the MGW and not the routers. The IP-backbone is provisioned by a network managmenent systen.
We are refering to a scenario when bandwidth (in the network) are shared among a number of entities that are connected to the same multi-service backbone.

In some way, the notification has to be sent to the MGW. The MGW can block calls (reduce the traffic vlume) and the edge-router can dropping packet. However, packet drops is not recommended for the sensitive traffic.

Therefore, some interation has to be there and I do not understand why we only limit the scenario to admission control in a edge-routers. Some vendors might be interested in this sceario, but I am worried that this will put restriction of the architecture.

so, once again, give a summary of the reasons not to include Admission control into other entities than  routers.







Magnus Westerlund wrote:
Re: [PCN] charter, addition to scope

Georgios Karagiannis skrev:
> Hi Kwok
>
> You are very right the "Application Control Deployment"
> can be "edge-to-edge" and not host-to-host.
> I think that this is a matter of right terminology.

Independent of that, there is no good description of what this would
mean. draft-babiarz-pcn-sip-cap-00 seems to only talk about end-to-end
cases. Or at least where the PCN aware equipment would reside outside a
PCN domain.

The problem from Lars Eggert and my perspective is that there is no
consensus on what application control means in this scenario while it is
reasonably simple to understand using RSVP towards a PCN domain, and
using PCN information to determine if the reservation is acceptable or not.

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

--------------000108060101050305000309-- --===============0252750555== 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 --===============0252750555==-- From pcn-bounces@ietf.org Wed Jan 31 10:32:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHRu-0005Yn-0k; Wed, 31 Jan 2007 10:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHRs-0005YF-U0 for pcn@ietf.org; Wed, 31 Jan 2007 10:32:36 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHRq-0002Mp-Aj for pcn@ietf.org; Wed, 31 Jan 2007 10:32:36 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VFTZ4G031017; Wed, 31 Jan 2007 17:29:37 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:32:01 +0200 Received: from [192.168.1.33] ([10.162.252.246]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 17:32:02 +0200 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBFAE7@S4DE8PSAAFQ.mitte.t-com.de> References: <6439282641581441A36F7F6F83ED2ED2CBFAE7@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <9048D4F2-7965-4722-BD29-3D9F573193E5@nokia.com> From: Lars Eggert Subject: Re: [PCN] charter text update Date: Wed, 31 Jan 2007 17:31:59 +0200 To: "ext Geib, Ruediger" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 15:32:02.0276 (UTC) FILETIME=[F45AA240:01C7454C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070131172937-78C1FBB0-1763736B/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2012380034==" Errors-To: pcn-bounces@ietf.org --===============2012380034== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-107-824274953; protocol="application/pkcs7-signature" --Apple-Mail-107-824274953 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, the recent emails by Ken, Phil and you helped a lot. I think we actually may be in agreement. On 2007-1-31, at 16:39, ext Geib, Ruediger wrote: > what you say is that "preemption" must not be the only reaction > specified by PCN once an ingress edge router determines that > the path to a particular egress router reached > congestion/preemption state? > > If yes, I agree. Would the charter have to say so or should > this be a design constraint to be kept in mind when drafting > standards? The charter already allows a reaction other than preemption, namely, to prevent admission of new flows. Additionally, there was some discussion around having a rate-adaptation reaction function. Would a slightly-reworded statement taken from an earlier version of the charter help: Although designed to work together, flow admission and flow preemption are independent mechanisms, and the use of one does not require or prevent the use of the other. > The minimum requirement may be to demand that the deactivation > of a preemption mechanism must be possible (the PCN domain > would then always interpret congestion marks in the same way as > pre-congestion marks ). There seems to be an unstated assumption here that congestion marks will always lead to preemption, while pre-congestion marks will lead to admission decisions. This is not so - the current charter allows different policies, i.e., meaning decision algorithms that take congestion and pre-congestion markers as input and produce preemption and admission decisions on the set of flows as an output. A policy that would only ever issue admission decisions is certainly possible. > I now also understand Jozef Babiarz proposal to change > "preemption" to "congestion" in the charter. The behaviour > "Preemption" would then be one option how to react on congestion. > And the PCN WG must work on the preemption behaviour, but also > must allow for operation without it. Right. Admission decisions are the other reaction mechanism. > Jozefs proposed new charter simply replaced "preemption" by > "congestion", if I recall right. May be doing so but adding a > statement on using the state "congestion" to trigger > preemption (as one possible reaction) could help to clarify > the charter? I don't see how making this replacement and then explaining what it means by using the replaced term is making anything more clear. Lars --Apple-Mail-107-824274953 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzExNTMxNTlaMCMGCSqGSIb3DQEJBDEWBBTCBZBBbeFT5tl+ UL5EXYtUuEIxazCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEATCVxXVGuy+Qm6ZjmGhHXzqtgFVuL5ltphZURji+M9xorsd0Zrk2O Js1WGfLh0Fipkhv8mMSZGvE8vZtk1d9KubYZ6oaBj+fVoCZvK/Ai9msjauRT02VSQ6nGust3hAgS jjNFf0Qc12gDb6BkdTVrkiJA5ElgSNnNDD3uzEP748XJMcQ17hpWKP5EwMHoxNdPkZKnqB9pfEyA 9ybtsIKpv6BMwsQMHFDV+HxCrvzm6/RdqE9TfbR/CVe+6rMrxH73/CPY73PIoK4FK0e+cnv5pNJ0 iVsbLlHW9dExeXQUMjHMjARGobrhFgcl+Ues+Fxs5AJgK3hKf9t2/2I88w0LmwAAAAAAAA== --Apple-Mail-107-824274953-- --===============2012380034== 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 --===============2012380034==-- From pcn-bounces@ietf.org Wed Jan 31 12:03:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIrz-0001wf-8x; Wed, 31 Jan 2007 12:03:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIrx-0001wQ-QT for pcn@ietf.org; Wed, 31 Jan 2007 12:03:37 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIrv-00085F-8g for pcn@ietf.org; Wed, 31 Jan 2007 12:03:37 -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 l0VH3Qn12792; Wed, 31 Jan 2007 12:03:27 -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] charter text update Date: Wed, 31 Jan 2007 12:03:26 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650E697391@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBA@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter text update Thread-Index: AcdAn/FfTVCky36NTfubwjzA1opfgAEj9lVAAAmxdyA= From: "Jozef Babiarz" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 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 Philip and all, To some people *preemption*, "means the removal of a call to make room for a new call to be admitted". In the PCN work we have modified the meaning of preemption to "the removal of excess (that causes congestion) traffic at flow granularity level". I think we should think about using a different word or term so that people directly not involved with PCN WG do not get confused, just a suggestion. Personally, I like preemption, but if it will make the charter approval process go faster by using a different term, I'm for the changing it.=20 Regards, Joe 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: January 31, 2007 7:54 AM To: carlberg@g11.org.uk; lars.eggert@nokia.com Cc: pcn@ietf.org Subject: RE: [PCN] charter text update > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: 25 January 2007 16:37 > To: Lars Eggert > Cc: pcn@ietf.org > Subject: Re: [PCN] charter text update >=20 > Lars, >=20 > I'd have a strong preference to keep the previous name, and to soften > the use of the term Preemption in the charter. if the IESG is > consistent, some of the them will have a difficult time with the term > preemption and will kick back the charter and ask that it be > reworded. Some in the IESG had a hard time with this subject (as > well as some others) in the IEPREP group -- both in the past and most > recently in the IETF mailing list concerning an attempted re- > chartering effort for IEPREP. >=20 > A few months i brought up this topic on PCN and mentioned how under > certain scenarios/circumstances, the use of preemption for VoIP is > simply not allowed in certain countries. >=20 > http://www1.ietf.org/mail-archive/web/pcn/current/msg00023.html > http://www1.ietf.org/mail-archive/web/pcn/current/msg00037.html > http://www1.ietf.org/mail-archive/web/pcn/current/msg00046.html > http://www1.ietf.org/mail-archive/web/pcn/current/msg00053.html >=20 > Unfortunately, the subject of what is legal/regulated is not one that > technical in nature, but it is something that should be considered by > the group. In my previous comments, I was trying to encourage the > group to treat preemption as one of several (re)actions that can be > advanced by the group. I'd like to re-encourage this line of thought > and text in the Charter. Ken, I remember thinking about this before the BoF, when we were experimenting with wordings for the BoF. It proved (to my surprise) difficult to find a wording that worked.=20 For example, saying something like "the WG will specify a mechanism to determine how much excess traffic is; the WG will not specify a required reaction to this information, but it will write an Info on flow pre-emption as one possible reaction (which may not be allowed for legal /regulatory reasons)" The problem is that this assumes the mechanism will work by measuring the excess traffic. Although this is the way described in the CL-drafts, others have in mind a different method. So instead we went back to saying that the WG will standardise how the edge makes a pre-emption decision, but ruling handling of emergency calls as out of scope. so as to rule out thinking about nasty legal/regulatory issues. But hopefully you can find a better phrasing! However, I think I disagree with you when you say "preemption as one of several (re)actions that can be advanced by the group". I think that in the initial charter that the WG should advance only one "(re)action" ie flow pre-emption (as well as adm ctrl). Other possible reactions (say adapting rate of flows) should be after re-chartering.=20 >=20 > regards, >=20 > -ken >=20 > ps, my apologies in not volunteering specific suggested text changes > right now, but I'm preparing for a couple of days of travel (ugh). >=20 >=20 > On Jan 25, 2007, at 4:23 AM, Lars Eggert wrote: >=20 > > (I thought I had sent this several days ago, but it apparently > > never made it to the list?) > > > > Hi, > > > > below is a modified version of the PCN charter posted to this list > > a while ago. I believe it reflects the consensus after the face-to- > > face and mailing list discussions in and after Montreal. > > > > Compared to the earlier version, the major changes are: > > > > - removal of SIP, application-based and PW deployment scenarios > > - stronger language on assumptions and scope > > - refactored deliverables and milestones > > - name change (don't feel strongly about this) > > > > Please send your comments to the list. > > > > Lars > > > > ---------------------------------------------------------------------- > > ---- > > > > Flow Admission and Preemption (flap) > > Chair(s): > > tbd > > > > > > Description of Working Group: > > > > The Flow Admission and Preemption (FLAP) working group develops > > flow admission and flow preemption mechanisms for deployment along > > the edge of a network domain that protect the quality-of-service > > that previously-admitted flows experience within the domain during > > times of congestion. These mechanisms act on aggregated congestion > > and pre-congestion signals from routers within the network domain > > and control the admission of new flows into the domain or preempt > > previously-admitted flows. Although designed to work together, flow > > admission and flow preemption are independent mechanisms, and the > > use of one does not require the use of the other. > > > > The FLAP WG will specify the following components of an integrated > > flow admission and preemption mechanism: > > > > (1) a general architecture for flow admission and preemption based > > on aggregated (pre-)congestion signals > > > > (2) conditions under which interior routers generate > > (pre-)congestion signals > > > > (3) encoding and transport of (pre-)congestion signals > > to the appropriate ingress routers of the network domain > > > > (4) edge router control mechanisms for flow admission and > > preemption based on aggregated (pre-)congestion information > > > > The WG focuses on the overall architecture and specifically the > > signaling interfaces needed to realize it. Standards-track > > protocols are only developed when necessary for interoperability. > > When algorithms are not necessary for interoperability the WG may > > document examples or provide recommended solutions, however such > > work should not be done at the expense of normative specifications. > > > > > > The initial scope of the FLAP WG is restricted in the following ways: > > > > (A) develop these components for a single DiffServ region, > > where all edge and interior routers are FLAP-enabled > > and mutually trust each other > > > > (B) all flows handled by these mechanisms are inelastic and > > constrained to a known maximum rate through policing or shaping > > > > (C) the number of flows across any potential aggregation bottleneck > > is sufficiently large for stateless, statistical mechanisms > > to be > > effective > > > > (D) aggregation occurs either on links or ingress/egress pairs; > > mechanisms must further define relevant limits > > > > (E) flows may have different precedence, but the applicability > > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > > etc.) > > is out of scope > > > > After completion of the initial phase, the FLAP WG may recharter to > > develop solutions for scenarios where some of these restrictions > > are not in place. It may also recharter to consider applying the > > FLAP mechanisms to additional deployment scenarios (operation over > > concatenated DiffServ regions, FLAP-aware application mechanisms, > > etc.). The WG may also consider to investigate additional response > > mechanisms that act on (pre-)congestion signals. One example could > > be flow-rate adaptation (rather than flow admission/preemption) > > during times of congestion. The details of these work items are > > outside the scope of the initial phase; but the WG may want to > > > > However in the initial scope this mechanism is out-of-scope with > > the exception that the developed solution should not, if possible, > > prevent a future evolution to support this. > > > > > > Goals and Milestones: > > > > Jul 2007 Flow Admission and Preemption Architecture > > (Informational) > > > > Jul 2007 Survey of Encoding and Transport Choices of > > (Pre-)Congestion Signals within a DiffServ Region > > (Informational) > > > > Nov 2007 Flow Admission and Preemption within a DiffServ > > Region (Informational) > > > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > > (Proposed Standard) > > > > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > > within a DiffServ Region to Flow Egress (Proposed Standard) > > > > Mar 2008 Transport from Flow Egress in a DiffServ Region of > > information > > (possibly aggregated) or Admission/Preemption Signals to > > DiffServ edge devices. (Proposed Standard) > > > > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > > (Informational) > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 12:11:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIzT-00055A-2o; Wed, 31 Jan 2007 12:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIzR-00053I-At for pcn@ietf.org; Wed, 31 Jan 2007 12:11:21 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIwJ-00016T-Jc for pcn@ietf.org; Wed, 31 Jan 2007 12:08:09 -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 l0VH7f44019416; Wed, 31 Jan 2007 18:07:46 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <000c01c74389$1a6314b0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEB5@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 18:07:55 +0100 Message-ID: <006801c7455a$5cfc72d0$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: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEB5@E03MVZ1-UKDY.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdAUc0vwsHQ1a70Qz6/ObSb1A/8SQC/UQRwAA3Z8TAAagiO0AAKwr6w X-Spam-Score: 0.083 () 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, 31 Jan 2007 18:07:46 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil Please see in line! > > In addition to this I have another comment on the charter > description. > > Regarding the following paragraph: > > > > "After completion of the initial phase, the PCN WG may > re-charter to > > develop solutions for scenarios where some of these > restrictions are > > not in > place. > > It may also re-charter to consider applying the PCN mechanisms to > > additional deployment scenarios (operation over > concatenated DiffServ > > regions, PCN-aware application mechanisms, etc.). The WG may also > > consider to investigate additional response mechanisms that act on > (pre-)congestion > > signals. One example could be flow-rate adaptation (rather than flow > > admission/preemption) during times of congestion. The > details of these > > work items are outside the scope of the initial phase; but the WG > > should consider their requirements to design components that are > > sufficiently general > to > > support such extensions in the future." > > > > First you mention: > > "The WG may also consider to investigate additional response > mechanisms > > that > > act on (pre-)congestion signals. One example could be flow-rate > adaptation > > (rather than flow admission/preemption) during times of congestion." > > > > And then you say: > > "The details of these work items are outside the scope of > the initial > > phase; but the WG should consider their requirements to design > > components > that > > are > > sufficiently general to support such extensions in the future." > > > > I think that the two above sentences contradict each other some how. > > What you actually say in the second sentence is that the > requirements > of > > the > > flow-rate adaptation during times of congestion should be considered > to > > design components that are sufficiently general to support such > extensions > > in the future. However, in the first paragraph you mention that > flow-rate > > adaptation during times of congestion might be considered, but it is > not > > sure that this will happen. > > I will very much appreciate if you could change the following > sentence: > > > > Please change from: > > "The WG may also consider to investigate additional response > mechanisms > > that > > act on (pre-)congestion signals. One example could be flow-rate > adaptation > > (rather than flow admission/preemption) during times of congestion." > > > > INTO: > > "The WG should consider to investigate additional response > mechanisms > that > > act on (pre-)congestion signals. One example is the flow-rate > adaptation > > (rather than flow admission/preemption) during times of congestion." > > I think you're suggesting saying now what will definitely be > in a re-charter. This doesn't sound possible to me. > (incidentally, personally I think the case of flow-rate > adaptation based on pre-congestion marks is rather different > - eg will be hard to translate lessons from the work from > simulations/ performance analysis during the work of the > initial charter.) No, what I am saying here is that the flow rate adaptaion scenario can be considered after rechartering, but the requirements imposed by a flow-rate adaptation scenario should be considered already in the first phase. Best Regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 12:14:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ2j-0005lt-Rw; Wed, 31 Jan 2007 12:14:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ2j-0005lO-Eo for pcn@ietf.org; Wed, 31 Jan 2007 12:14:45 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJ2g-00037z-V9 for pcn@ietf.org; Wed, 31 Jan 2007 12:14:45 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0VH6Q228964; Wed, 31 Jan 2007 12:06:27 -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); Wed, 31 Jan 2007 12:14:11 -0500 Message-Id: <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 31 Jan 2007 12:14:10 -0500 To: From: "Kwok-Ho Chan" Subject: RE: [PCN] charter, addition to scope In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.doma in1.systemhost.net> References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jan 2007 17:14:11.0299 (UTC) FILETIME=[39895330:01C7455B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, LarsE, All: Please see my comments enclosed with KHC_START> and KHC_END>. Thanks! -- Kwok -- At 08:46 AM 1/31/2007, philip.eardley@bt.com wrote: >I'm not sure, but I think there may be violent agreement. > >Thinking only about PCN mechanisms running edge-to-edge, which is what's >in scope in Lars's charter. In terms of how new flows are requested: > >- we have what is described in >draft-briscoe-tsvwg-cl-architecture-04.txt. RSVP from end host reaches >PCN-region ingress gateway, which checks the current >Congestion-Level-Estimate for the relevant ingress-egress-aggregate, and >hence decides whether to admit the new flow request. > >- I can imagine an alternative (which I think is "Application Control >Deployment" or Lars W's MGW case) where some signalling from the end >host (not RSVP) reaches an 'admission controller', which is in the >PCN-region but is not (necessarily) on the data path (if the flow is >admitted). The 'admission controller' would work out what the >PCN-ingress & PCN-egress would be (eg if the call is admitted, the data >will enter the PCN-region via this ingress). It would then discover what >the current Congestion-Level-Estimate for the relevant >ingress-egress-aggregate, and hence decides whether to admit the new >flow request. > >- case 2 sounds reasonable to me, but is not really described anywhere >at the moment (draft-babiarz-pcn-sip-cap-00.txt touches it, but that >draft is really about the host-to-host case) > >- case 2 isn't explicitly in or out of the current draft charter KHC_START> IMHO, case 2 should be explicitly INCLUDED in the current draft charter. And I will be happy to give it a try on adding a sentence or two for it. KHC_END> > > >- what would including case 2 impact? (in terms of the Charter work >items). I think it's only the architecture doc that would change (get an >extra section), and even that is mainly in terms of operation outside >the PCN-region. technical arguments about the right encoding, marking >behaviour etc won't be altered. To me this suggests it's easier to >exclude it, just so there's less to write, but I don't really mind. >However, if I'm wrong and it will change the technical arguments then it >probably should be included (but please hint why/how now!) KHC_START> When I looked at the 2nd charter text update, I found the standardization work will pretty much be the same for both case 1 and case 2 you indicated above. With the additional work of providing an Information document that will describe the deployment scenario when Application Control is used Edge-to-Edge, which we have a good handful of people volunteering to do the work. Hence my suggestion of making "Application Control for Edge-to-Edge Deployment" be included by the proposed charter and possibly adding such a deliverable in the milestone part of the charter. KHC_END> >best wishes, >phil > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 31 January 2007 12:06 > > To: 'Kwok-Ho Chan'; 'Lars Eggert' > > Cc: pcn@ietf.org > > Subject: RE: [PCN] charter, addition to scope > > > > Hi Kwok > > > > You are very right the "Application Control Deployment" > > can be "edge-to-edge" and not host-to-host. > > I think that this is a matter of right terminology. > > > > Best Regards, > > Georgios > > > > > > > > > > > -----Original Message----- > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > Sent: dinsdag 30 januari 2007 18:17 > > > To: Lars Eggert > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] charter, addition to scope > > > > > > Lars: > > > By the last sentence of your E-Mail, > > > I think you are equating "Application Control Deployment" > > > with "host-to-host". > > > Which may be your reasoning for excluding "Application > > > Control Deployment". > > > > > > "Application Control Deployment" can be "edge-to-edge", which > > > will very much use the same behaviors and mechanisms that we > > > can standardize in PCN. > > > > > > Hence IMHO, the "Application Control Deployment" for "edge-to-edge" > > > fits very well > > > within the work being done in the first phase of PCN and > > > should be included as a work item (informational track) for > > > the first phase of PCN. > > > > > > Please separate the notion of "host-to-host" from > > > "Application Control Deployment". > > > Thanks! > > > -- Kwok -- > > > > > > > > > At 10:26 AM 1/29/2007, Lars Eggert wrote: > > > >On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > > > >>I am a bit confused about one item in this scheme. As I > > > understand the > > > >>principle, when the core senses that it is approaching > > > congestion, the > > > >>edge nodes are requested to reduce their offerings. > > > > > > > >Under the initial model, it is the edge *routers* that are acting >on > > > >the signal from the interior. Which is why all routers need to >trust > > > >each other. > > > > > > > >>What is the > > > >>motivation for a given edge node to do so? It seems that if > > > the other > > > >>edge nodes do reduce their offerings then a "renegade" edge > > > node could > > > >>take advantage of the reduction in traffic at the core to > > > continue to > > > >>send his traffic. Such behavior would logically lead the others >to > > > >>follow unless there was some sort of policing. > > > > > > > >Right, all these issues (and others) exist with the host-to-host > > > >deployment scenario, which is why we're declaring this to be >out-of- > > > >scope initially. > > > > > > > >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 > > > > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 12:20:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ7y-00006G-Db; Wed, 31 Jan 2007 12:20:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ7x-000067-Qf for pcn@ietf.org; Wed, 31 Jan 2007 12:20:09 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCJ7w-0006oP-6j for pcn@ietf.org; Wed, 31 Jan 2007 12:20:09 -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 l0VHJb1L019961; Wed, 31 Jan 2007 18:19:44 +0100 (MET) From: "Georgios Karagiannis" To: "'Kwok-Ho Chan'" , References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 18:19:52 +0100 Message-ID: <006901c7455c$08226c90$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: <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdFWzeRvfQQG1XiQvCC4RaFBp8jEQAAIkUw X-Spam-Score: 0.083 () 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, 31 Jan 2007 18:19:45 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Kwok I agree with your below suggestion. > Hence my suggestion of making "Application Control for > Edge-to-Edge Deployment" > be included by the proposed charter and possibly adding such > a deliverable in the milestone part of the charter. Best Regards, Georgios > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: woensdag 31 januari 2007 18:14 > To: philip.eardley@bt.com > Cc: karagian@cs.utwente.nl; Kwok-Ho Chan; > lars.eggert@nokia.com; pcn@ietf.org > Subject: RE: [PCN] charter, addition to scope > > Phil, LarsE, All: > Please see my comments enclosed with KHC_START> and KHC_END>. > Thanks! > -- Kwok -- > > At 08:46 AM 1/31/2007, philip.eardley@bt.com wrote: > >I'm not sure, but I think there may be violent agreement. > > > >Thinking only about PCN mechanisms running edge-to-edge, which is > >what's in scope in Lars's charter. In terms of how new flows > are requested: > > > >- we have what is described in > >draft-briscoe-tsvwg-cl-architecture-04.txt. RSVP from end > host reaches > >PCN-region ingress gateway, which checks the current > >Congestion-Level-Estimate for the relevant ingress-egress-aggregate, > >and hence decides whether to admit the new flow request. > > > >- I can imagine an alternative (which I think is > "Application Control > >Deployment" or Lars W's MGW case) where some signalling from the end > >host (not RSVP) reaches an 'admission controller', which is in the > >PCN-region but is not (necessarily) on the data path (if the flow is > >admitted). The 'admission controller' would work out what the > >PCN-ingress & PCN-egress would be (eg if the call is > admitted, the data > >will enter the PCN-region via this ingress). It would then discover > >what the current Congestion-Level-Estimate for the relevant > >ingress-egress-aggregate, and hence decides whether to admit the new > >flow request. > > > >- case 2 sounds reasonable to me, but is not really > described anywhere > >at the moment (draft-babiarz-pcn-sip-cap-00.txt touches it, but that > >draft is really about the host-to-host case) > > > >- case 2 isn't explicitly in or out of the current draft charter > > KHC_START> > IMHO, case 2 should be explicitly INCLUDED in the current > draft charter. > And I will be happy to give it a try on adding a sentence or > two for it. > KHC_END> > > > > > > >- what would including case 2 impact? (in terms of the Charter work > >items). I think it's only the architecture doc that would > change (get > >an extra section), and even that is mainly in terms of operation > >outside the PCN-region. technical arguments about the right > encoding, > >marking behaviour etc won't be altered. To me this suggests > it's easier > >to exclude it, just so there's less to write, but I don't > really mind. > >However, if I'm wrong and it will change the technical > arguments then > >it probably should be included (but please hint why/how now!) > > KHC_START> > When I looked at the 2nd charter text update, I found the > standardization work will pretty much be the same for both > case 1 and case 2 you indicated above. > With the additional work of providing an Information document > that will describe the deployment scenario when Application > Control is used Edge-to-Edge, which we have a good handful of > people volunteering to do the work. > Hence my suggestion of making "Application Control for > Edge-to-Edge Deployment" > be included by the proposed charter and possibly adding such > a deliverable in the milestone part of the charter. > KHC_END> > > > >best wishes, > >phil > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 31 January 2007 12:06 > > > To: 'Kwok-Ho Chan'; 'Lars Eggert' > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] charter, addition to scope > > > > > > Hi Kwok > > > > > > You are very right the "Application Control Deployment" > > > can be "edge-to-edge" and not host-to-host. > > > I think that this is a matter of right terminology. > > > > > > Best Regards, > > > Georgios > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > > Sent: dinsdag 30 januari 2007 18:17 > > > > To: Lars Eggert > > > > Cc: pcn@ietf.org > > > > Subject: Re: [PCN] charter, addition to scope > > > > > > > > Lars: > > > > By the last sentence of your E-Mail, > > > > I think you are equating "Application Control Deployment" > > > > with "host-to-host". > > > > Which may be your reasoning for excluding "Application > > > > Control Deployment". > > > > > > > > "Application Control Deployment" can be "edge-to-edge", which > > > > will very much use the same behaviors and mechanisms that we > > > > can standardize in PCN. > > > > > > > > Hence IMHO, the "Application Control Deployment" for > "edge-to-edge" > > > > fits very well > > > > within the work being done in the first phase of PCN and > > > > should be included as a work item (informational track) for > > > > the first phase of PCN. > > > > > > > > Please separate the notion of "host-to-host" from > > > > "Application Control Deployment". > > > > Thanks! > > > > -- Kwok -- > > > > > > > > > > > > At 10:26 AM 1/29/2007, Lars Eggert wrote: > > > > >On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote: > > > > >>I am a bit confused about one item in this scheme. As I > > > > understand the > > > > >>principle, when the core senses that it is approaching > > > > congestion, the > > > > >>edge nodes are requested to reduce their offerings. > > > > > > > > > >Under the initial model, it is the edge *routers* that > are acting > >on > > > > >the signal from the interior. Which is why all routers need to > >trust > > > > >each other. > > > > > > > > > >>What is the > > > > >>motivation for a given edge node to do so? It seems that if > > > > the other > > > > >>edge nodes do reduce their offerings then a "renegade" edge > > > > node could > > > > >>take advantage of the reduction in traffic at the core to > > > > continue to > > > > >>send his traffic. Such behavior would logically lead > the others > >to > > > > >>follow unless there was some sort of policing. > > > > > > > > > >Right, all these issues (and others) exist with the > host-to-host > > > > >deployment scenario, which is why we're declaring this to be > >out-of- > > > > >scope initially. > > > > > > > > > >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 > > > > > > > > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 14:31:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLAw-0003sv-8X; Wed, 31 Jan 2007 14:31:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLAu-0003sl-AV for pcn@ietf.org; Wed, 31 Jan 2007 14:31:20 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLAr-0002zE-0A for pcn@ietf.org; Wed, 31 Jan 2007 14:31:20 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0VJV3bA014215; Wed, 31 Jan 2007 14:31:04 -0500 (EST) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0VJUn2s005460; Wed, 31 Jan 2007 14:31:00 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:30:07 -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] charter, addition to scope Date: Wed, 31 Jan 2007 14:30:07 -0500 Message-ID: In-reply-to: <002001c7452c$291184c0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igABFlM0A= References: <9671A92C3C8B5744BC97F855F7CB64650E5E93D1@zcarhxm1.corp.nortel.com><010AA8A4-BF53-44DA-9234-3E2DAAF8026F@nokia.com> <002001c7452c$291184c0$4c0d5982@dynamic.ewi.utwente.nl> To: X-OriginalArrivalTime: 31 Jan 2007 19:30:07.0681 (UTC) FILETIME=[371E7310:01C7456E] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.31.110933 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 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 Georgios wrote: > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > > In the first phase of PCN work to reduce the list of issues it was > > > proposed that the WG focus on network deployment scenario where all=20 > > > nodes can be trusted and delay work on deployment scenarios where some=20 > > > of the nodes are not trusted. > >=20 > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If "nodes"=20 > > include end systems, proxies or other entities, then I don't=20 > > agree we had agreement on that. >=20 > Georgios: This imposes an additional restriction on the scope=20 > of the charter, which has been not discussed yet. > >From what I remember before, during and after the PCN BOF=20 > there was no objection on using > the term edge node, that could mean something different than a edge router. > Please note that this is something different than a scenario covered by=20 > an application based deployment model. It's certainly not a new restriction based on the discussion in the BOF engendered about whether a SIP telephone (used on some of the slides) was a good example. I believe the BOF conclusion was that a SIP telephone was a bad example. IMHO, a SIP telephone causes two sets of issues wrt the proposed work: (1) It speaks SIP, and=20 (2) It's a telephone ;-) The first set of issues has already been discussed extensively - my understanding is that the SIP scenario is currently out of scope, and I don't care to reopen that discussion. The "telephone" issues come up in two ways: (2a) Small number of flows may make relatively fine-grained adjustment on the link to the phone impossible. The PCN work prior to the BOF relied on the ability to make such adjustments. (2b) While other sorts of phones may be trusted, a SIP phone (which may be software-only) is definitely not trustable in general. I would observe that Lars Westerberg's suggestion of a Media Gateway: > I am referring telecom scenario where MGWs are connected to an IP-backbone. > In these scenarios, the admission control function is a part of the MGW > and not the routers. The IP-backbone is provisioned by a network > management system. could avoid all of these issues: (1) The media gateway could speak RSVP to the network management system, avoiding any need to deal with SIP here. (2a) A media gateway is likely to handle enough flows to be consistent with the fine-grained adjustment assumed by the work done to date. (2b) One can plausibly assume/require that media gateways be trusted with respect to the IP network. To the extent that one can vest "edge" functionality in a trusted media gateway, I see no reason to exclude that scenario. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 16:28:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMzt-0004Cd-Pz; Wed, 31 Jan 2007 16:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMzs-0004CV-5m for pcn@ietf.org; Wed, 31 Jan 2007 16:28:04 -0500 Received: from maillnx-us111.fmr.com ([192.223.198.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCMzp-0005nT-IG for pcn@ietf.org; Wed, 31 Jan 2007 16:28:04 -0500 Received: from MSGMROSM01WIN.dmn1.fmr.com (MSGMROSM01WIN.dmn1.fmr.com [172.26.7.127]) by maillnx-us111.fmr.com (Switch-3.1.0/Switch-3.1.0) with SMTP id l0VLM5i1005620 for ; Wed, 31 Jan 2007 16:22:06 -0500 Received: from MSGMROIV01WIN.DMN1.FMR.COM (172.26.31.106) by MSGMROSM01WIN.dmn1.fmr.com (Sigaba Gateway v4.0) with ESMTP id 119174908; Wed, 31 Jan 2007 16:27:59 -0500 Received: from MSGMMKIM02WIN.DMN1.FMR.COM ([172.25.108.84]) by MSGMROIV01WIN.DMN1.FMR.COM with SMTP_server; Wed, 31 Jan 2007 16:27:58 -0500 Received: from msgmmkclp2win.FMR.COM ([10.33.182.27]) by MSGMMKIM02WIN.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Jan 2007 16:27:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] charter, addition to scope Date: Wed, 31 Jan 2007 16:27:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter, addition to scope Thread-Index: AcdFE6lGuZLDcmPvSLSHeooVBStRWAAEn+igABFlM0AAALDecAAAtiiA From: "Lee, Richard FTC" To: , X-OriginalArrivalTime: 31 Jan 2007 21:27:58.0708 (UTC) FILETIME=[ADC78B40:01C7457E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org To all, I agree that there must be a prioritization of flows from the aggregation devices However, it's not just the media gateway that should speak RSVP, but the edge proxy (or firewall "proxy") as well - it is the signaling proxy at the edge that reserves the media path. The reservation protocol request to the network from the VoIP proxy/gateway must reserve resources to the destination in the network.=20 The resource reservation request to the network by the edge proxy/media gateway, must at the very minimum, meet the following conditions: 1. it needs to specify the resources required for the IP & ports (RTP/RTCP & bandwidth) for example, G.711 and G.729 voice and various MPEG-4 video codecs all have very different requirements 2. it must be mapped to the signaling request for SIP, it must map the SDP for media with the reservation flow - for example something along the lines of RFC 3524 while not the answer, the mapping of the media flows is a necessary component It should be noted that the edge proxies/media gateways may have a large number of flows (and ports for each =20 RTP/RTCP flow) from the same source IP. The request is made for each flow or conversation 3. it must be honored by the edge network device.=20 The trust boundary must be extended to the edge proxy/media gateway for each new flow. This brings up the issue of security authentication of the edge proxy/media gateway to the network Does this happen in EAP, NAC, or just interoperability and certification among vendors If the resources are not available, then the signaling indicates the session is not completed. For example a SIP CANCEL from the edge proxy In addition, the network device must have priority queuing enabled for input queues from the edge device. The media flows must not be subject to input buffers being filled prior to classification Thanks, Richard Lee Fidelity Investments Enterprise Technology and Architecture 617-563-3278 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Wednesday, January 31, 2007 2:30 PM To: karagian@cs.utwente.nl Cc: pcn@ietf.org Subject: RE: [PCN] charter, addition to scope Georgios wrote: > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote: > > > In the first phase of PCN work to reduce the list of issues it was > > > proposed that the WG focus on network deployment scenario where all=20 > > > nodes can be trusted and delay work on deployment scenarios where some=20 > > > of the nodes are not trusted. > >=20 > > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If "nodes"=20 > > include end systems, proxies or other entities, then I don't=20 > > agree we had agreement on that. >=20 > Georgios: This imposes an additional restriction on the scope=20 > of the charter, which has been not discussed yet. > >From what I remember before, during and after the PCN BOF=20 > there was no objection on using > the term edge node, that could mean something different than a edge router. > Please note that this is something different than a scenario covered by=20 > an application based deployment model. It's certainly not a new restriction based on the discussion in the BOF engendered about whether a SIP telephone (used on some of the slides) was a good example. I believe the BOF conclusion was that a SIP telephone was a bad example. IMHO, a SIP telephone causes two sets of issues wrt the proposed work: (1) It speaks SIP, and=20 (2) It's a telephone ;-) The first set of issues has already been discussed extensively - my understanding is that the SIP scenario is currently out of scope, and I don't care to reopen that discussion. The "telephone" issues come up in two ways: (2a) Small number of flows may make relatively fine-grained adjustment on the link to the phone impossible. The PCN work prior to the BOF relied on the ability to make such adjustments. (2b) While other sorts of phones may be trusted, a SIP phone (which may be software-only) is definitely not trustable in general. I would observe that Lars Westerberg's suggestion of a Media Gateway: > I am referring telecom scenario where MGWs are connected to an IP-backbone. > In these scenarios, the admission control function is a part of the MGW > and not the routers. The IP-backbone is provisioned by a network > management system. could avoid all of these issues: (1) The media gateway could speak RSVP to the network management system, avoiding any need to deal with SIP here. (2a) A media gateway is likely to handle enough flows to be consistent with the fine-grained adjustment assumed by the work done to date. (2b) One can plausibly assume/require that media gateways be trusted with respect to the IP network. To the extent that one can vest "edge" functionality in a trusted media gateway, I see no reason to exclude that scenario. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jan 31 18:50:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCPDi-000819-Gn; Wed, 31 Jan 2007 18:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCPDh-000814-TS for pcn@ietf.org; Wed, 31 Jan 2007 18:50:29 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCPDg-0000Xm-Hj for pcn@ietf.org; Wed, 31 Jan 2007 18:50:29 -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 l0VNoQJ00521; Wed, 31 Jan 2007 18:50:26 -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); Wed, 31 Jan 2007 18:50:25 -0500 Message-Id: <6.2.5.6.0.20070131163950.03af6318@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 31 Jan 2007 18:50:25 -0500 To: Lars Eggert From: "Kwok-Ho Chan" Subject: Re: [PCN] 2nd charter text update In-Reply-To: <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> References: <6.2.5.6.0.20070130100927.056e6750@nortel.com> <425F643F-F15D-4E63-B96D-738487C5DDF1@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jan 2007 23:50:25.0995 (UTC) FILETIME=[945C09B0:01C74592] X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org LarsE, all: Please see my response embedded below enclosed by KHC_START> and KHC_END>. Thanks! -- Kwok -- At 04:23 AM 1/31/2007, Lars Eggert wrote: >On 2007-1-30, at 18:51, ext Kwok-Ho Chan wrote: >>Lars: E-Mail address update needed? > >Yes. Oops. > >>>These mechanisms operate at the domain edge, based on >>>aggregated congestion and pre-congestion signals from within the >>>domain. The focus of the WG is on developing standards for the >>>marking behavior of the interior routers and the encoding of the >>>congestion signals. Reaction mechanisms at the edge include flow >>>admission and flow preemption. The WG may produce informational >>>documents that describe how specific quality-of-service policies can >>>be implemented using a combination of these mechanisms. >> >>Suggested new text: >>These mechanisms operate on the IP packet data path, with network >>nodes: >>1. At the middle of the IP packet data path domain (interior nodes) >>performing >> measurement, detection, and indication of congestion and pre- congestion >> conditions. >>2. At the edge of the IP packet data path domain (edge nodes) >>performing >> control of the IP packets that affect the congestion and pre- congestion >> conditions at the middle of the IP packet data path domain >> >>The focus of the WG is on developing standards for specifying the >>detection >>and indication behaviors at the interior nodes that is required for >>inter-operability. >>The WG will use flow admission and flow preemption at the edge >>nodes as the >>mechanism for controlling the IP packets that affect the congestion >>and >>pre-congestion conditions at the middle of the IP packet data path >>domain. > >Talking about "nodes" and "paths" leaves the door open for other work >than the routers-within-a-single-DiffServ-domain model that we want >to focus the work on initially. KHC_START> The use of "IP packet data path" is just to make the proposed charter more concise. May be it becomes too wordy in the itemized sentences, hence it will be OK for me if they are removed from the itemized sentences. But I think "These mechanisms operate on the IP packet data path" at the top is helpful to make the propose charter more clear and concise. On the topic of using the words "nodes" and/or "routers". I don't have a good understanding of why the word "router" must be there. Many of today's "routers" perform "switching" instead of "routing". And many of today's "routers" does more than just "routing". Is a "blade-center" a "router"? Part of it is a "router"? And does the output (behavior, mechanism documentations) of this WG need to be implemented on a specific hardware implementation? On a specific physical box? IMHO, the proposed-standards documents produced by this WG should indicate behaviors and functionality. To promote and assure inter-operability. IMHO, the proposed-standards documents produced by this WG should NOT dictate how the implementation is done, or where (which and what kind of square/round physical box) the implementation must be done at. I totally agree that we should focus on "within-a-single-DiffServ-domain" in the first phase. IMHO, the usage of the word "nodes" does NOT "leaves the door open for other work" that will be for NOT "within-a-single-DiffServ-domain". Also, the usage of the word "routers" will NOT guarantee that we will just focus on "within-a-single-DiffServ-domain". (There are routers outside of DiffServ domains.) IMHO, the propose charter is sufficiently clear that we are focusing on "within-a-single-DiffServ-domain" for the initial phase. Please accept my apology for being wordy here. KHC_END> >>The description of the behavior at the edge nodes may be a >>standards track >>document if it is needed for inter-operability. > >Do you see a specific need for this to become standards track? KHC_START> I think the required behavior (but NOT how it is implemented and NOT the exact algorithm used) may need to be standards track for inter-operability reasons. For example, the edge nodes may need to have the required behaviors of not allowing more traffic be added to the (pre-)congested path(s) when (pre-)congestion condition is indicated. KHC_END> >>The WG may produce additional informational documents that describe >>some >>possible methods for providing the required behaviors at the >>interior nodes and >>edge nodes that supports the inter-operability of the standards >>developed here. >>The WG may produce additional informational documents on how specific >>quality-of-service polices can be implemented using a combination >>of these >>mechanisms. > >I'd rather not give the WG too many options to do additional >Informational documents in the beginning. The focus should be on the >standards track specifications. KHC_START> How about we indicate ONE additional informational document that multiple people in the BOF have indicated they will work on, that uses the standards track specifications developed by this WG in the first phase? KHC_END> >>Suggest to replace: >>"on aggregated (pre-)congestion signals" >>by >>"on aggregated (pre-)congestion information" > >OK (also elsewhere) > >>> to the appropriate ingress routers of the network domain >>Suggest to delete: >>"to the appropriate ingress routers of the network domain" >>The reasoning is we want to standardize how the (pre-)congestion >>information is conveyed by the interior nodes to the edge nodes. >>The deleted part of the sentence will confuse this point. Hence I >>suggest to delete it. > >How will it confuse this point? It clarifies that we're not looking >at transporting this information elsewhere, such as outside of the >domain. KHC_START> Lars: I believe you are talking about my comments to the itemized (3) in the 2nd charter text update. I found the statement: "(3) encoding and transport of (pre-)congestion signals (replaced with information) to the appropriate ingress routers of the network domain" confusing because I believe we want to specify in a standards track document how the (pre-)congestion information is encoded (the bits and bytes detail) in some IP header field (ECN, DSCP, etc). Based on my above interpretation, I see the mentioning of "ingress router" confuses the purpose of (3). I agree with the notion of "within-the-domain". But it is pretty clear that is the scope of our first phase. Maybe (3) can be: "(3) Encoding and transporting of (pre-)congestion information within the DiffServ domain". KHC_END> >Lars > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn