From pcn-bounces@ietf.org Thu Mar 01 02:52:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMg5h-0006QM-2j; Thu, 01 Mar 2007 02:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMg5g-0006QE-Dk for pcn@ietf.org; Thu, 01 Mar 2007 02:52:40 -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 1HMg5e-0005LB-W6 for pcn@ietf.org; Thu, 01 Mar 2007 02:52:40 -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 l217o4oB029258; Thu, 1 Mar 2007 09:50:31 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 09:52:09 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 09:52:10 +0200 Received: from [172.21.34.189] (esdhcp034189.research.nokia.com [172.21.34.189]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l217nGpG019452; Thu, 1 Mar 2007 09:49:16 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0A84BD2E-6E25-4254-945C-9F6ABBE99BCA@nokia.com> From: Lars Eggert Subject: Re: [PCN] WG Action: Congestion and Pre-Congestion Notification (pcn) Date: Thu, 1 Mar 2007 09:52:05 +0200 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Mar 2007 07:52:10.0069 (UTC) FILETIME=[8418B850:01C75BD6] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070301095031-70AABBB0-1B81C95F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: pcn-chairs@tools.ietf.org, pcn-ads@tools.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="===============0106703797==" Errors-To: pcn-bounces@ietf.org --===============0106703797== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--992686654; protocol="application/pkcs7-signature" --Apple-Mail-7--992686654 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, congratulations on being chartered! Your chairs are Scott Bradner (sob@harvard.edu) Steven Blake (steven.blake@ericsson.com) which you should be able to contact under the pcn- chairs@tools.ietf.org alias. Magnus and me can be reached under pcn- ads@tools.ietf.org. Scott and Steven will contact the WG shortly to prepare for your first meeting in Prague. Lars --Apple-Mail-7--992686654 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMDEwNzUyMDVaMCMGCSqGSIb3DQEJBDEWBBQydKv4U8ZESx7+ WuDBRBiK6DYmbTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEADO3jmKtYzYYoyPu30qDz9sNR0cNjlciguh9b/x+SikYR2cm+YEi7 h8m5MqgYYckgZPqKEshBT7bGJU3dTtIyBEJPK0mRRxRfQXIKnObtG3X22OTHmODIol+WCn/BwnBM 634G75GLYDh6UfWheo9JEqj1AnWcgNW+Qgj/tMccpMhVRj6odBthZBFYvjM4BsH4dV8HqELiO1cO +OR4jddhuN9WPFlfBGM3xxE8oEKxmAym2dAptEr4EQtABzP0Y3/uLpzVgbGj5DmXitYWtDIdsYm2 QVXiPQmSIfSN+wBHqTfAXsUi9EnBYkxRIXkgbAiVty35GAn3TrLpIRQuPCQbTgAAAAAAAA== --Apple-Mail-7--992686654-- --===============0106703797== 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 --===============0106703797==-- From pcn-bounces@ietf.org Fri Mar 02 13:25:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCRi-0000Td-LP; Fri, 02 Mar 2007 13:25:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCRh-0000TS-M7 for pcn@ietf.org; Fri, 02 Mar 2007 13:25:33 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNCRb-0006u4-EG for pcn@ietf.org; Fri, 02 Mar 2007 13:25:33 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 77FF24F49 for ; Fri, 2 Mar 2007 19:25:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6AEE05C72 for ; Fri, 2 Mar 2007 19:25:22 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 57A424F49 for ; Fri, 2 Mar 2007 19:25:22 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l22IPMs05683 for ; Fri, 2 Mar 2007 19:25:22 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id B02EC6F58E for ; Fri, 2 Mar 2007 19:21:45 +0100 (CET) Message-ID: <45E86BBF.4070102@informatik.uni-wuerzburg.de> Date: Fri, 02 Mar 2007 19:23:59 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [PCN] PCN terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, I've written a paper comparing different NAC types. http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-18.pdf As the PCN terminology still differs in different Internet drafts, I've chosen a completely different nomenclature to make the paper easy to read even for people without any knowledge in PCN. Comments are welcome. I hope that this paper can stimulate the work on terminology. I'll be at the meeting in Prague for discussions. Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 05 10:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFAr-00024w-7u; Mon, 05 Mar 2007 10:32:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFAo-00023q-QE for pcn@ietf.org; Mon, 05 Mar 2007 10:32:26 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOFAj-0003kR-FF for pcn@ietf.org; Mon, 05 Mar 2007 10:32:26 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l25FuaeQ030736; Mon, 5 Mar 2007 09:56:36 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 09:32:13 -0600 Received: from ipi169165.ipi.us.am.ericsson.se ([147.117.169.165]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 09:32:13 -0600 From: Steven Blake To: pcn@ietf.org Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 05 Mar 2007 10:32:17 -0500 Message-Id: <1173108737.3583.29.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2007 15:32:13.0606 (UTC) FILETIME=[72BD3460:01C75F3B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [PCN] Agenda for IETF 68 meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steven.blake@ericsson.com List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Greetings from your co-chairs. The PCN working group will have it's first meeting at IETF68 in Prague: THURSDAY, March 22, 2007 0900-1130 Morning Session I Congress I TSV pcn Congestion and Pre-Congestion Notification WG It's time to put together an agenda for the meeting. If you are interested in presenting a draft during the meeting, please send a note ASAP to the co-chairs indicating the draft name and presentation time requested. Regards, Steve & Scott =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson Data Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 05 11:02:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFdf-0006jy-TX; Mon, 05 Mar 2007 11:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFdd-0006jr-R0 for pcn@ietf.org; Mon, 05 Mar 2007 11:02:13 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOFdb-0001ET-Dd for pcn@ietf.org; Mon, 05 Mar 2007 11:02:13 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l25Frwt08927 for ; Mon, 5 Mar 2007 10:53:58 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Mar 2007 11:02:06 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650EFEDF0B@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Explicit PCN Marking Thread-Index: AcdfP5+YdiNVDPKOSRKi5q9xRxaHXg== From: "Jozef Babiarz" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [PCN] Explicit PCN 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="===============1537449080==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1537449080== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75F3F.A01E6479" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75F3F.A01E6479 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I've submitted a draft proposing a method that can be used for marking excess real-time traffic http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking-0 0.txt . Detailed simulations results can be found at http://standards.nortel.com/pcn/Simulation_EPCN.pdf=20 * Abstract:=20 In this document, we propose to the PCN WG for review, discussion and evaluation of a method for marking real-time packets to indicate that removal (preemption) of excess real-time traffic from the network is needed. First, we define the marking behavior in the interior node followed with a brief description of how this marking would work in the edge-to-edge and application-control deployment models with simulations results for different conditions and traffic mixes. Then, we discuss the simulation results for voice, both constant rate and variable rate with silence suppression, and variable rate MPEG-4 like video traffic with large and small number of flows at the congestion point. Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com ------_=_NextPart_001_01C75F3F.A01E6479 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Explicit PCN Marking

I’ve submitted a draft proposing a method = that can be used for marking excess real-time traffic http://www.ietf.org/internet-drafts/draft-babiarz-pcn-e= xplicit-marking-00.txt . Detailed simulations = results can be found at http://standards.nortel.com/pcn/Simulation_EPCN.pdf=

·  = Abstract:
In this document, we propose to the PCN WG for review, discussion and = evaluation of a method for marking real-time packets to indicate that = removal (preemption) of excess real-time traffic from the network is = needed. First, we define the marking behavior in the interior node = followed with a brief description of how this marking would work in the = edge-to-edge and application-control deployment models with simulations = results for different conditions and traffic mixes. Then, we discuss the = simulation results for voice, both constant rate and variable rate with = silence suppression, and variable rate MPEG-4 like video traffic with = large and small number of flows at the congestion point.

Regards, Joe

Telephone: 613-763-6098 (ESN 393-6098)

Email: = babiarz@nortel.com

------_=_NextPart_001_01C75F3F.A01E6479-- --===============1537449080== 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 --===============1537449080==-- From pcn-bounces@ietf.org Mon Mar 05 13:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOHro-0005ZA-SA; Mon, 05 Mar 2007 13:25:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOHrm-0005XZ-VT for pcn@ietf.org; Mon, 05 Mar 2007 13:24:58 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOHrg-0002LZ-P0 for pcn@ietf.org; Mon, 05 Mar 2007 13:24:58 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A50975B34; Mon, 5 Mar 2007 19:24:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9746C5BDB; Mon, 5 Mar 2007 19:24:45 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 723325BC6; Mon, 5 Mar 2007 19:24:45 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l25IOjs00576; Mon, 5 Mar 2007 19:24:45 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 1D3AE6F58E; Mon, 5 Mar 2007 19:21:06 +0100 (CET) Message-ID: <45EC601F.2030301@informatik.uni-wuerzburg.de> Date: Mon, 05 Mar 2007 19:23:27 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] Explicit PCN Marking References: <9671A92C3C8B5744BC97F855F7CB64650EFEDF0B@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650EFEDF0B@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe, I read the first half of your draft. The beginning of Section 2 is hard=20 to read. I have understood the proposed marking mechanism as follows. Instead of=20 marking several consecutive packets in an intermediate router when its=20 token bucket runs empty, you just mark a single packet and put x octets=20 back into the token bucket to avoid that another x octets are going to=20 be marked. The egress collects the marked packets and calculates the=20 excess traffic rate for individual ingress-egress pairs taking into=20 account the size of marked packets plus another x octects per packet. As a result of this marking scheme is that less packets are marked. -> they belong to fewer ingress gateways -> fewer ingress gateways need to reduce their rate but by a larger amoun= t. Is that what you intend? Best wishes, Michael Jozef Babiarz wrote: > > I=92ve submitted a draft proposing a method that can be used for markin= g=20 > excess real-time traffic=20 > _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking= -00.txt_=20 > . Detailed simulations results can be found at=20 > _http://standards.nortel.com/pcn/Simulation_EPCN.pdf_ > > =B7 * Abstract:* > In this document, we propose to the PCN WG for review, discussion and=20 > evaluation of a method for marking real-time packets to indicate that=20 > removal (preemption) of excess real-time traffic from the network is=20 > needed. First, we define the marking behavior in the interior node=20 > followed with a brief description of how this marking would work in=20 > the edge-to-edge and application-control deployment models with=20 > simulations results for different conditions and traffic mixes. Then,=20 > we discuss the simulation results for voice, both constant rate and=20 > variable rate with silence suppression, and variable rate MPEG-4 like=20 > video traffic with large and small number of flows at the congestion=20 > point. > > ///Regards, Joe/ > > Telephone: 613-763-6098 (ESN 393-6098) > > Email: babiarz@nortel.com > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 05 20:15:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOOHO-0001dv-Cr; Mon, 05 Mar 2007 20:15:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOOHN-0001dX-3R for pcn@ietf.org; Mon, 05 Mar 2007 20:15:49 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOOHL-00039S-Mc for pcn@ietf.org; Mon, 05 Mar 2007 20:15:49 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2617Tw17125; Mon, 5 Mar 2007 20:07:29 -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] Explicit PCN Marking Date: Mon, 5 Mar 2007 20:15:39 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F054C8D@zcarhxm1.corp.nortel.com> In-Reply-To: <45EC601F.2030301@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking Thread-Index: AcdfU5Kz9pBt9ASsQSq+Zf+gEN3SCwANI96Q From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, =20 The intent of Explicit PCN Marking approach is that the interior router measures the excess traffic and marks a packet to indicate which flow needs to be removed (terminated). Should not that in later phase of PCN standardization a marked flow can also have its sending rate reduced (rate adapted). The interior router marks a packet every x bytes of traffic that is in excess of the supportable rate. So if it is important to measure what the excess traffic is, the gateway counts the number of marked packets received per ingress-egress aggregate over time where a marked packet equals x bytes of excess traffic. My intention is that with this marking, there is no need for the egress or ingress gateways do any rate measurements of traffic or even counting the number of marked packets received. The intent is the interior router identifies the flow or flows that need their rate reduced. In the first phase of the charter a marked flow would have its rate reduced to zero (flow is terminated) but in later phase of PCN work a market flow could have its sending rate reduced to a lower rate. The egress gateway conveys to ingress gateway what flow needs its rate reduced. Does this help? Regards, Joe Telephone: 613-763-6098=20 Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: March 5, 2007 1:23 PM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: Re: [PCN] Explicit PCN Marking Hi Joe, I read the first half of your draft. The beginning of Section 2 is hard=20 to read. I have understood the proposed marking mechanism as follows. Instead of=20 marking several consecutive packets in an intermediate router when its=20 token bucket runs empty, you just mark a single packet and put x octets=20 back into the token bucket to avoid that another x octets are going to=20 be marked. The egress collects the marked packets and calculates the=20 excess traffic rate for individual ingress-egress pairs taking into=20 account the size of marked packets plus another x octects per packet. As a result of this marking scheme is that less packets are marked. -> they belong to fewer ingress gateways -> fewer ingress gateways need to reduce their rate but by a larger amount. Is that what you intend? Best wishes, Michael Jozef Babiarz wrote: > > I've submitted a draft proposing a method that can be used for marking > excess real-time traffic=20 > _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking- 00.txt_=20 > . Detailed simulations results can be found at=20 > _http://standards.nortel.com/pcn/Simulation_EPCN.pdf_ > > * * Abstract:* > In this document, we propose to the PCN WG for review, discussion and=20 > evaluation of a method for marking real-time packets to indicate that=20 > removal (preemption) of excess real-time traffic from the network is=20 > needed. First, we define the marking behavior in the interior node=20 > followed with a brief description of how this marking would work in=20 > the edge-to-edge and application-control deployment models with=20 > simulations results for different conditions and traffic mixes. Then,=20 > we discuss the simulation results for voice, both constant rate and=20 > variable rate with silence suppression, and variable rate MPEG-4 like=20 > video traffic with large and small number of flows at the congestion=20 > point. > > ///Regards, Joe/ > > Telephone: 613-763-6098 (ESN 393-6098) > > Email: babiarz@nortel.com > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 06 02:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOToq-0007am-J3; Tue, 06 Mar 2007 02:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOTop-0007ae-DE for pcn@ietf.org; Tue, 06 Mar 2007 02:10:43 -0500 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOTon-0003cK-5i for pcn@ietf.org; Tue, 06 Mar 2007 02:10:43 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 512126915; Tue, 6 Mar 2007 08:10:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 43B667DBF; Tue, 6 Mar 2007 08:10:38 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CBF9A6915; Tue, 6 Mar 2007 08:10:37 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l267Abs05072; Tue, 6 Mar 2007 08:10:37 +0100 Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 08B706F58E; Tue, 6 Mar 2007 08:06:58 +0100 (CET) Message-ID: <45ED139E.6020109@informatik.uni-wuerzburg.de> Date: Tue, 06 Mar 2007 08:09:18 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] Explicit PCN Marking References: <9671A92C3C8B5744BC97F855F7CB64650F054C8D@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650F054C8D@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Joe, I see. The difference to the existing solution is: a single marked packet suffices that the egress signals to the ingress that the respective flow should be terminated. The marking is just used to identify flows to be terminated. The usual way, i.e., calculating the excess traffic rate for each ingress-egress aggregate at the egress, signaling it to the respective ingress such that the ingress can select the flows to be terminated, becomes a secondary option which would require egress routers to measure marked traffic again. Is that right? Best wishes, Michael Jozef Babiarz wrote: > Hi Michael, > The intent of Explicit PCN Marking approach is that the interior router > measures the excess traffic and marks a packet to indicate which flow > needs to be removed (terminated). Should not that in later phase of PCN > standardization a marked flow can also have its sending rate reduced > (rate adapted). The interior router marks a packet every x bytes of > traffic that is in excess of the supportable rate. So if it is important > to measure what the excess traffic is, the gateway counts the number of > marked packets received per ingress-egress aggregate over time where a > marked packet equals x bytes of excess traffic. > > My intention is that with this marking, there is no need for the egress > or ingress gateways do any rate measurements of traffic or even counting > the number of marked packets received. The intent is the interior router > identifies the flow or flows that need their rate reduced. In the first > phase of the charter a marked flow would have its rate reduced to zero > (flow is terminated) but in later phase of PCN work a market flow could > have its sending rate reduced to a lower rate. The egress gateway > conveys to ingress gateway what flow needs its rate reduced. > > Does this help? > > Regards, Joe > Telephone: 613-763-6098 > Email: babiarz@nortel.com > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: March 5, 2007 1:23 PM > To: Babiarz, Jozef (CAR:0S03) > Cc: pcn@ietf.org > Subject: Re: [PCN] Explicit PCN Marking > > Hi Joe, > > I read the first half of your draft. The beginning of Section 2 is hard > to read. > > I have understood the proposed marking mechanism as follows. Instead of > marking several consecutive packets in an intermediate router when its > token bucket runs empty, you just mark a single packet and put x octets > back into the token bucket to avoid that another x octets are going to > be marked. The egress collects the marked packets and calculates the > excess traffic rate for individual ingress-egress pairs taking into > account the size of marked packets plus another x octects per packet. > > As a result of this marking scheme is that less packets are marked. > -> they belong to fewer ingress gateways > -> fewer ingress gateways need to reduce their rate but by a larger > amount. > Is that what you intend? > > Best wishes, > > Michael > > > Jozef Babiarz wrote: > >> I've submitted a draft proposing a method that can be used for marking >> > > >> excess real-time traffic >> >> > _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking- > 00.txt_ > >> . Detailed simulations results can be found at >> _http://standards.nortel.com/pcn/Simulation_EPCN.pdf_ >> >> * * Abstract:* >> In this document, we propose to the PCN WG for review, discussion and >> evaluation of a method for marking real-time packets to indicate that >> removal (preemption) of excess real-time traffic from the network is >> needed. First, we define the marking behavior in the interior node >> followed with a brief description of how this marking would work in >> the edge-to-edge and application-control deployment models with >> simulations results for different conditions and traffic mixes. Then, >> we discuss the simulation results for voice, both constant rate and >> variable rate with silence suppression, and variable rate MPEG-4 like >> video traffic with large and small number of flows at the congestion >> point. >> >> ///Regards, Joe/ >> >> Telephone: 613-763-6098 (ESN 393-6098) >> >> Email: babiarz@nortel.com >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> >> > > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 06 02:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOUDL-00039v-5P; Tue, 06 Mar 2007 02:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOUDJ-00039n-Ib for pcn@ietf.org; Tue, 06 Mar 2007 02:36:01 -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 1HOUDH-00078B-Vv for pcn@ietf.org; Tue, 06 Mar 2007 02:36:01 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l267ZqO1010920; Tue, 6 Mar 2007 09:35:57 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:35:51 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:35:50 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:35:50 +0200 Received: from [172.21.34.205] (esdhcp034205.research.nokia.com [172.21.34.205]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l267Zipa016586; Tue, 6 Mar 2007 09:35:44 +0200 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650F054C8D@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650F054C8D@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1E909E4D-AEFD-46EE-BB35-5435CA82DE96@nokia.com> From: Lars Eggert Subject: Re: [PCN] Explicit PCN Marking Date: Tue, 6 Mar 2007 09:35:41 +0200 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Mar 2007 07:35:50.0885 (UTC) FILETIME=[1085D950:01C75FC2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306093557-284C1BB0-31A4467F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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="===============0586023193==" Errors-To: pcn-bounces@ietf.org --===============0586023193== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-83--561670164; protocol="application/pkcs7-signature" --Apple-Mail-83--561670164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-3-6, at 3:15, ext Jozef Babiarz wrote: > The intent of Explicit PCN Marking approach is that the interior > router > measures the excess traffic and marks a packet to indicate which flow > needs to be removed (terminated). without having read the draft yet (sorry, on my reading list for Prague), this extends at least what is my view of the chartered scope. I had been under the impression that the decision about which flows were being admitted/terminated was a function that was (logically) located at the boundary routers, based on congestion markings from the interior. The semantics of these markings indicate some level of congestion, and the boundary can infer something about the state of the network by statistically analyzing the level of marked traffic to drive the admission/termination decision. This works with multiple congested routers along a path, which will result in a higher average marking rate. In your model, at least the termination decision seems to happen at an interior router and it is only the enforcement of the decision that is delegated to the boundary. The markings have a much different semantics ("terminate this flow"). One issue I see is that the router that makes this decision has a much more limited view of the network than the boundary. Another issue is that some level of coordination between the interior routers seems to be needed, to result in a stable system. Or am I misunderstanding something? Lars --Apple-Mail-83--561670164 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMDYwNzM1NDJaMCMGCSqGSIb3DQEJBDEWBBQrw4uk5sTCs1D6 DmM9MKVg1ZnqhDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAl31a/H4GLL7pBmpo0OXlOYGpLe+hMrxjMg3FC+y3qj7n24h+5xI5 ObT5X6dF36EGuyRM4ltENxSGLWfY6mtNeHZIeKaiBL+00uVXimqMegThLnsXocpYuApXon4ohSTp 5Y274cftzJa+WRQYRFGfxhi4ZY/0RWZ8OIZF7K1K1EzOB4wm9N5y5v+CFKDWBMySbW7A8wWb+V38 OVosZIA4tmzOtgC/JNBHxeLUMQpo2s7En8gxPmTbPKeCpanAxkgtmcS7+Nb7CrbPNtmOVx6hRLhz 7hB293wisLSFIn+0G55hFWXC+xJxRl4Dc03ndUviI09m6sgU0pW6YXaU6UeUpwAAAAAAAA== --Apple-Mail-83--561670164-- --===============0586023193== 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 --===============0586023193==-- From pcn-bounces@ietf.org Tue Mar 06 08:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOa6P-0000Zt-IE; Tue, 06 Mar 2007 08:53:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOa6N-0000Zc-HU for pcn@ietf.org; Tue, 06 Mar 2007 08:53:15 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOa6L-0006F2-Ro for pcn@ietf.org; Tue, 06 Mar 2007 08:53:15 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l26Dixo02814; Tue, 6 Mar 2007 08:44:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Explicit PCN Marking Date: Tue, 6 Mar 2007 08:53:06 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F054EF7@zcarhxm1.corp.nortel.com> In-Reply-To: <45ED139E.6020109@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking Thread-Index: AcdfvpEVD7IEJze0SN6tMtbJt/9hswAOAoRw From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 Yes Michael, that is correct. Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: March 6, 2007 2:09 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: Re: [PCN] Explicit PCN Marking Dear Joe, I see. The difference to the existing solution is: a single marked=20 packet suffices that the egress signals to the ingress that the=20 respective flow should be terminated. The marking is just used to=20 identify flows to be terminated. The usual way, i.e., calculating the=20 excess traffic rate for each ingress-egress aggregate at the egress,=20 signaling it to the respective ingress such that the ingress can select=20 the flows to be terminated, becomes a secondary option which would=20 require egress routers to measure marked traffic again. Is that right? Best wishes, Michael Jozef Babiarz wrote: > Hi Michael, =20 > The intent of Explicit PCN Marking approach is that the interior router > measures the excess traffic and marks a packet to indicate which flow > needs to be removed (terminated). Should not that in later phase of PCN > standardization a marked flow can also have its sending rate reduced > (rate adapted). The interior router marks a packet every x bytes of > traffic that is in excess of the supportable rate. So if it is important > to measure what the excess traffic is, the gateway counts the number of > marked packets received per ingress-egress aggregate over time where a > marked packet equals x bytes of excess traffic. > > My intention is that with this marking, there is no need for the egress > or ingress gateways do any rate measurements of traffic or even counting > the number of marked packets received. The intent is the interior router > identifies the flow or flows that need their rate reduced. In the first > phase of the charter a marked flow would have its rate reduced to zero > (flow is terminated) but in later phase of PCN work a market flow could > have its sending rate reduced to a lower rate. The egress gateway > conveys to ingress gateway what flow needs its rate reduced. > > Does this help? > > Regards, Joe > Telephone: 613-763-6098=20 > Email: babiarz@nortel.com > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 > Sent: March 5, 2007 1:23 PM > To: Babiarz, Jozef (CAR:0S03) > Cc: pcn@ietf.org > Subject: Re: [PCN] Explicit PCN Marking > > Hi Joe, > > I read the first half of your draft. The beginning of Section 2 is hard=20 > to read. > > I have understood the proposed marking mechanism as follows. Instead of=20 > marking several consecutive packets in an intermediate router when its > token bucket runs empty, you just mark a single packet and put x octets=20 > back into the token bucket to avoid that another x octets are going to > be marked. The egress collects the marked packets and calculates the=20 > excess traffic rate for individual ingress-egress pairs taking into=20 > account the size of marked packets plus another x octects per packet. > > As a result of this marking scheme is that less packets are marked. > -> they belong to fewer ingress gateways > -> fewer ingress gateways need to reduce their rate but by a larger > amount. > Is that what you intend? > > Best wishes, > > Michael > > > Jozef Babiarz wrote: > =20 >> I've submitted a draft proposing a method that can be used for marking >> =20 > > =20 >> excess real-time traffic=20 >> >> =20 > _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-explicit-marking- > 00.txt_=20 > =20 >> . Detailed simulations results can be found at=20 >> _http://standards.nortel.com/pcn/Simulation_EPCN.pdf_ >> >> * * Abstract:* >> In this document, we propose to the PCN WG for review, discussion and >> evaluation of a method for marking real-time packets to indicate that >> removal (preemption) of excess real-time traffic from the network is=20 >> needed. First, we define the marking behavior in the interior node=20 >> followed with a brief description of how this marking would work in=20 >> the edge-to-edge and application-control deployment models with=20 >> simulations results for different conditions and traffic mixes. Then, >> we discuss the simulation results for voice, both constant rate and=20 >> variable rate with silence suppression, and variable rate MPEG-4 like >> video traffic with large and small number of flows at the congestion=20 >> point. >> >> ///Regards, Joe/ >> >> Telephone: 613-763-6098 (ESN 393-6098) >> >> Email: babiarz@nortel.com >> >> >> =20 > ------------------------------------------------------------------------ > =20 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> =20 >> =20 > > =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 06 10:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObXv-00029m-7c; Tue, 06 Mar 2007 10:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObXu-00029g-9M for pcn@ietf.org; Tue, 06 Mar 2007 10:25:46 -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 1HObXp-0005P6-97 for pcn@ietf.org; Tue, 06 Mar 2007 10:25:46 -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 l26FPReV014557; Tue, 6 Mar 2007 17:25:39 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 17:25:21 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 17:25:22 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 17:25:21 +0200 Received: from [172.21.34.205] (esdhcp034205.research.nokia.com [172.21.34.205]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26FPKR9006699; Tue, 6 Mar 2007 17:25:20 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) References: <213394AB6954BE4682E8B2A491034683437808@esebe108.NOE.Nokia.com> Message-Id: <482F820C-9798-4996-BD1F-754FBB1BC86C@nokia.com> From: Lars Eggert Subject: Fwd: [PCN] IPR disclosure on draft-charny-pcn-single-marking Date: Tue, 6 Mar 2007 17:25:18 +0200 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Mar 2007 15:25:21.0732 (UTC) FILETIME=[A7A7F840:01C76003] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306172539-35EE9BB0-38B0FF07/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pcn-chairs@tools.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="===============1591041763==" Errors-To: pcn-bounces@ietf.org --===============1591041763== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--533493476; protocol="application/pkcs7-signature" --Apple-Mail-17--533493476 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, this is a re-send of a message from January 8 about an IPR disclosure filed on a related draft. The IETF received this before the PCN WG had been chartered. Now that this has happened, the WG should be aware of the existence of this IPR claim when discussing the initial work. Begin forwarded message: > Date: January 8, 2007 16:43:21 GMT+02:00 > To: > Subject: [PCN] IPR disclosure on draft-charny-pcn-single-marking > > 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 --Apple-Mail-17--533493476 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMDYxNTI1MThaMCMGCSqGSIb3DQEJBDEWBBT5kb9c8e3PqEqj 1A1ik52V7yNjFDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAdq4xlgvogReR7THXaYaqm0ili9TJcpfOas+WfqeDlaN9Ncv9xd7I HGejvhZSfrXvJFLtfKA1g1HG9WYvnUO2GN8HAETCVuRK+NR5i6Y0J9Doxm2LT0wS41JNnhoDlQAz NmPloGKcDNGfRUZQ01o13qAqMAD0a+eBHIYXR60RlzQ8IswYwgYWwBbRLVIiFE0/SfUxl4CRqEm1 fFQgBVr4I81o7x6hCEXlrJ+GYfXrGy6xWAHCOQQA/cc2QYKBAKqzzysJY+VZQ/PcsTMZPFcZF+wS hrIeDRUWUNtIZJZjx/cvHvnG/rClK683rjAfp3q4KKczN3edst3hp/tM1akorQAAAAAAAA== --Apple-Mail-17--533493476-- --===============1591041763== 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 --===============1591041763==-- From pcn-bounces@ietf.org Tue Mar 06 10:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObY4-0002AV-Cm; Tue, 06 Mar 2007 10:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObY3-0002AQ-KQ for pcn@ietf.org; Tue, 06 Mar 2007 10:25:55 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HObXw-0005P4-8i for pcn@ietf.org; Tue, 06 Mar 2007 10:25:55 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l26FPdcN015481 for ; Tue, 6 Mar 2007 09:25:39 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:25:39 -0600 Received: from ipi169165.ipi.us.am.ericsson.se ([147.117.169.165]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 09:25:38 -0600 From: Steven Blake To: pcn@ietf.org Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 06 Mar 2007 10:25:37 -0500 Message-Id: <1173194737.3583.83.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2007 15:25:39.0124 (UTC) FILETIME=[B205C740:01C76003] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [PCN] IETF68 pcn meeting schedule change X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: steven.blake@ericsson.com List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org FYI The meeting time/venue for pcn has been changed: MONDAY, March 19, 2007 1740-1950 Afternoon Session III Athens/Barcelona/Berlin TSV pcn Congestion and Pre-Congestion Notification WG WG agendas are due tomorrow, so if you are interested in presenting please notify the chairs ASAP. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson Data Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 06 10:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObqg-0005bP-5t; Tue, 06 Mar 2007 10:45:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObqf-0005Yb-2I for pcn@ietf.org; Tue, 06 Mar 2007 10:45:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HObqd-0007rx-Oa for pcn@ietf.org; Tue, 06 Mar 2007 10:45:09 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Mar 2007 10:45:05 -0500 X-IronPort-AV: i="4.14,254,1170651600"; d="scan'208"; a="115072692:sNHT45912348" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l26Fj4Mx007062; Tue, 6 Mar 2007 10:45:04 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l26Fiva1026105; Tue, 6 Mar 2007 15:45:04 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 10:44: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] IETF68 pcn meeting schedule change Date: Tue, 6 Mar 2007 10:44:58 -0500 Message-ID: In-Reply-To: <1173194737.3583.83.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] IETF68 pcn meeting schedule change thread-index: AcdgA93LsbYGGwLZT4SS2paUmX4rSQAAiZ3w From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 06 Mar 2007 15:44:59.0722 (UTC) FILETIME=[65CAFAA0:01C76006] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1194; t=1173195904; x=1174059904; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20IETF68=20pcn=20meeting=20schedule=20change |Sender:=20 |To:=20; bh=i/vDzvtD6uxWUgmDJkTgrPDtFwWaBpAYrft2+0IH8AE=; b=X4eCCnBJlAIfw5ixKKl1Yu8lcHoxMph5qxtbz9vqnHKTbRA4J2tWrafmIHsd6m87xtrnhX+S IqFAyHhTDIG2ISnpF/g190UD9ZhiUtKmqDKLd1ca2hQHthUIc7UecD1j; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: pcn@ietf.org, "Xinyang \(Joy\) Zhang" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Steven, We have two drafts that we would like to present: draft-zhang-pcn-performance-evaluation-01 Draft-charny-pcn-single-marking-01 Please let us know if that would be possible. Thanks, Anna Charny > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com]=20 > Sent: Tuesday, March 06, 2007 10:26 AM > To: pcn@ietf.org > Subject: [PCN] IETF68 pcn meeting schedule change >=20 > FYI >=20 > The meeting time/venue for pcn has been changed: >=20 > MONDAY, March 19, 2007 > 1740-1950 Afternoon Session III > Athens/Barcelona/Berlin TSV pcn Congestion and=20 > Pre-Congestion Notification WG >=20 > WG agendas are due tomorrow, so if you are interested in=20 > presenting please notify the chairs ASAP. >=20 >=20 > Regards, > =20 > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > Steven Blake > Ericsson Data Networks +1 919-472-9913 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 06 13:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOeNS-0000q9-DE; Tue, 06 Mar 2007 13:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOeNP-0000pz-B2 for pcn@ietf.org; Tue, 06 Mar 2007 13:27:07 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOeNN-0001k6-WB for pcn@ietf.org; Tue, 06 Mar 2007 13:27:07 -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 l26IR3R25691; Tue, 6 Mar 2007 13:27:03 -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] Explicit PCN Marking Date: Tue, 6 Mar 2007 13:27:02 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F0556D8@zcarhxm1.corp.nortel.com> In-Reply-To: <1E909E4D-AEFD-46EE-BB35-5435CA82DE96@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking Thread-Index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+A From: "Jozef Babiarz" To: "Lars Eggert" 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: , Errors-To: pcn-bounces@ietf.org On March 6, 2007 2:36 AM, ext Lars Eggert wrote: >Hi, > >On 2007-3-6, at 3:15, ext Jozef Babiarz wrote: >> The intent of Explicit PCN Marking approach is that the interior =20 >> router >> measures the excess traffic and marks a packet to indicate which flow >> needs to be removed (terminated). > >without having read the draft yet (sorry, on my reading list for =20 >Prague), this extends at least what is my view of the chartered scope. >I had been under the impression that the decision about which flows =20 >were being admitted/terminated was a function that was (logically) =20 >located at the boundary routers, based on congestion markings from =20 >the interior. The semantics of these markings indicate some level of =20 >congestion, and the boundary can infer something about the state of =20 >the network by statistically analyzing the level of marked traffic to =20 >drive the admission/termination decision. This works with multiple =20 >congested routers along a path, which will result in a higher average =20 >marking rate. The marking by the interior router needs to identify traffic (flows) that are flowing through congested routers. If we assume there maybe multiple paths between ingress and egress gateways than congestion levels can also be at different levels. We do not what the ingress gateway to terminate flows that are flowing through non-congested paths. At least in my view the decision of what flows are terminated can be performed in any boundary node egress or ingress however, ingress boundary node needs to enforce the decision.=20 >In your model, at least the termination decision seems to happen at =20 >an interior router and it is only the enforcement of the decision =20 >that is delegated to the boundary. The markings have a much different =20 >semantics ("terminate this flow"). One issue I see is that the router =20 >that makes this decision has a much more limited view of the network =20 >than the boundary. Another issue is that some level of coordination =20 >between the interior routers seems to be needed, to result in a =20 >stable system. In my model an interior router marking a packet (flow) that is an indication to the edges (boundary nodes) that the marked flow is on a congested path. The boundary nodes still need to act on this information. In the original phase of the PCN work it the action is to terminate the mark flow. In later phases, could do rate-adaptation, or other action. Should not that the marking of packets continues (one marked packet every x bytes of excess traffic) until congestion condition is removed. >Or am I misunderstanding something? > >Lars Regards, Joe Telephone: 613-763-6098=20 Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: March 6, 2007 2:36 AM To: Babiarz, Jozef (CAR:0S03) Cc: menth@informatik.uni-wuerzburg.de; pcn@ietf.org Subject: Re: [PCN] Explicit PCN Marking Hi, On 2007-3-6, at 3:15, ext Jozef Babiarz wrote: > The intent of Explicit PCN Marking approach is that the interior =20 > router > measures the excess traffic and marks a packet to indicate which flow > needs to be removed (terminated). without having read the draft yet (sorry, on my reading list for =20 Prague), this extends at least what is my view of the chartered scope. I had been under the impression that the decision about which flows =20 were being admitted/terminated was a function that was (logically) =20 located at the boundary routers, based on congestion markings from =20 the interior. The semantics of these markings indicate some level of =20 congestion, and the boundary can infer something about the state of =20 the network by statistically analyzing the level of marked traffic to =20 drive the admission/termination decision. This works with multiple =20 congested routers along a path, which will result in a higher average =20 marking rate. In your model, at least the termination decision seems to happen at =20 an interior router and it is only the enforcement of the decision =20 that is delegated to the boundary. The markings have a much different =20 semantics ("terminate this flow"). One issue I see is that the router =20 that makes this decision has a much more limited view of the network =20 than the boundary. Another issue is that some level of coordination =20 between the interior routers seems to be needed, to result in a =20 stable system. Or am I misunderstanding something? Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 07 04:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsC7-0003lq-1U; Wed, 07 Mar 2007 04:12:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOqtN-000789-BS for pcn@ietf.org; Wed, 07 Mar 2007 02:48:57 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOqtL-0003Gg-L4 for pcn@ietf.org; Wed, 07 Mar 2007 02:48:57 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 7 Mar 2007 08:48:52 +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, 7 Mar 2007 08:48:33 +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] Explicit PCN Marking Date: Wed, 7 Mar 2007 08:48:33 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB93EB@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650F0556D8@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking Thread-Index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+A= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 07 Mar 2007 07:48:33.0903 (UTC) FILETIME=[01BAE7F0:01C7608D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Jozef, while your proposal indeed requires different functionalities=20 compared to the PCN functionalities as discussed up to know,=20 I must admit that it is a way to deal with backbone load=20 balancing and cases of "unsymmetric congestion". Load balancing=20 is likely to occur in backbone networks and PCN should work=20 properly if IP load balancing is active. I think PCN should=20 collect and discuss ideas like yours. Regards, Ruediger |>In your model, at least the termination decision seems to happen at =20 |>an interior router and it is only the enforcement of the decision =20 |>that is delegated to the boundary. The markings have a much different |>semantics ("terminate this flow"). One issue I see is that the router |>that makes this decision has a much more limited view of the network =20 |>than the boundary. Another issue is that some level of coordination =20 |>between the interior routers seems to be needed, to result in a =20 |>stable system. | |In my model an interior router marking a packet (flow) that is an |indication to the edges (boundary nodes) that the marked flow is on a |congested path. The boundary nodes still need to act on this |information. In the original phase of the PCN work it the action is to |terminate the mark flow. In later phases, could do rate-adaptation, or |other action. Should not that the marking of packets continues (one |marked packet every x bytes of excess traffic) until congestion |condition is removed. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 07 04:12:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsCB-0003vB-K6; Wed, 07 Mar 2007 04:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOqwo-0002an-J4 for pcn@ietf.org; Wed, 07 Mar 2007 02:52:30 -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 1HOqwm-0004ik-Vo for pcn@ietf.org; Wed, 07 Mar 2007 02:52:30 -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 l277q4fi010300; Wed, 7 Mar 2007 09:52:26 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 09:52:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 09:52:14 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 09:52:14 +0200 Received: from [172.21.34.183] (esdhcp034183.research.nokia.com [172.21.34.183]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l277qCU3018178; Wed, 7 Mar 2007 09:52:13 +0200 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650F0556D8@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB64650F0556D8@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] Explicit PCN Marking Date: Wed, 7 Mar 2007 09:52:08 +0200 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Mar 2007 07:52:14.0691 (UTC) FILETIME=[85547B30:01C7608D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070307095227-267DEBB0-655B7E70/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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="===============1146262150==" Errors-To: pcn-bounces@ietf.org --===============1146262150== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31--474283004; protocol="application/pkcs7-signature" --Apple-Mail-31--474283004 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-6, at 20:27, ext Jozef Babiarz wrote: > On March 6, 2007 2:36 AM, ext Lars Eggert wrote: >> In your model, at least the termination decision seems to happen at >> an interior router and it is only the enforcement of the decision >> that is delegated to the boundary. The markings have a much different >> semantics ("terminate this flow"). One issue I see is that the router >> that makes this decision has a much more limited view of the network >> than the boundary. Another issue is that some level of coordination >> between the interior routers seems to be needed, to result in a >> stable system. > > In my model an interior router marking a packet (flow) that is an > indication to the edges (boundary nodes) that the marked flow is on a > congested path. The boundary nodes still need to act on this > information. Agreed - the meaning of the mark when set by a router is something like "this packet (and by inference, this flow) are contributing to (pre-)congestion." In your earlier email, the meaning was "terminate this flow, please", which is quite different - it's not a (pre-) congestion mark anymore, your mark prescribes a specific reaction. This moves the decision point from the boundary into the network. > In the original phase of the PCN work it the action is to > terminate the mark flow. Not only. The boundary may also alleviate (pre-)congestion over time by not admitting new flows into the network. Especially when the marking volume establishes that the network is approaching congestion but hasn't reached that point yet, not admitting new flows into the domain may be the preferred reaction, because it doesn't interfere with established communication. I don't see how flow admission would happen based on your marking definition. Lars --Apple-Mail-31--474283004 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMDcwNzUyMDlaMCMGCSqGSIb3DQEJBDEWBBQAHqndXt3GSGLj 7Y4qEbbxJ0PcxzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEALydx154cw97abQlAkCtqPazW/L5HYwiGDf7scevbmgV/5FMiUNcm 5B7AG/EZ2wOzuDkRQ6XkelHRB3XtflBTXohVo/e4JtL37hOfSfW2nt8RgglDJD8Lutx2RNA72gvM 0SY7eKFUtcY2L+Xs6XOteswlotaQXTTWndckwaXqn5Xkbrpga5gn5Fwx4chU4x8EZvFJ9dLpytWI zL5X4MM8il+LC+Xhno9fvQ5K0fRrQ/7FxJpJA37DYDxc2tDuVHvLdkZKSQSGSZOEKIiNnyCcQ4iV gBX77F6h6SM+WNkiCuz9fWbnSGXYneethrp+TpenGy9R90XDgI8J5B0LLh8+LQAAAAAAAA== --Apple-Mail-31--474283004-- --===============1146262150== 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 --===============1146262150==-- From pcn-bounces@ietf.org Wed Mar 07 08:02:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOvn3-0001CQ-MQ; Wed, 07 Mar 2007 08:02:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOvn2-0001CL-K9 for pcn@ietf.org; Wed, 07 Mar 2007 08:02:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOvn1-0002oj-7X for pcn@ietf.org; Wed, 07 Mar 2007 08:02:44 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2007 05:02:43 -0800 X-IronPort-AV: i="4.14,258,1170662400"; d="scan'208"; a="398084022:sNHT51168068" 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 l27D2gFc028347; Wed, 7 Mar 2007 05:02:42 -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 l27D2Fxl029475; Wed, 7 Mar 2007 13:02:36 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 08:02:34 -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] Explicit PCN Marking Date: Wed, 7 Mar 2007 08:02:34 -0500 Message-ID: In-Reply-To: <6439282641581441A36F7F6F83ED2ED201DB93EB@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking thread-index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+AACq/0wA== From: "Anna Charny \(acharny\)" To: "Geib, Ruediger" , X-OriginalArrivalTime: 07 Mar 2007 13:02:34.0748 (UTC) FILETIME=[DFBFB3C0:01C760B8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3346; t=1173272562; x=1174136562; 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]=20Explicit=20PCN=20Marking |Sender:=20; bh=m4t0PaWH/tmHl36fabs8bK8ob/1uBDbfWyN7+p3GFn8=; b=IsAXLEzq1fy9MS3Yb3ReYOODbsCd3gMDTi9YsV5d8unNEg2cqIKSST8xX1ZGmuHI9AKOKDQN TU3rffxv+rL4/M/aTaXmvBzKyVi1JF7F6wbfYSMyCJZLJ81zP6olf+wV; 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: 31247fb3be228bb596db9127becad0bc Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, Jozef, Yes, the ability to address ECMP directly is indeed a very attractive point of Joe's proposal. One of the other ideas that was discussed to address the ECMP case was that PCN ingress could choose for preemption only those flows which have already been pre-emption marked (based on the "usual" marking). This would prevent from pre-empting flows on the "unaffected" ECMP paths, but potentially slow down the process of pre-empting enough flows on the affected ones in some cases (specifically the cases when pre-emption marking keeps affecting the same subset of affected flows rather than being uniformly distributed among all affected flows). This would be corrected in subsequent pre-emption round, though.=20 It was discussed that this "preempted only marked flows" decision could be a local decision at the ingress - part of selection of *which* flows to choose at the ingress for pre-emption - something that the current cl drafts leave up to the implementation. Implications may need to be studied further. Another idea that was discussed was to use additional "affected" marking that would indicate that a packet would go through a bottleneck (the idea earlier described in the context of RMD). Unfortunately needs yet another codepoint. Anna=20 > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 > Sent: Wednesday, March 07, 2007 2:49 AM > To: babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Explicit PCN Marking >=20 > Jozef, >=20 > while your proposal indeed requires different functionalities=20 > compared to the PCN functionalities as discussed up to know,=20 > I must admit that it is a way to deal with backbone load=20 > balancing and cases of "unsymmetric congestion". Load=20 > balancing is likely to occur in backbone networks and PCN=20 > should work properly if IP load balancing is active. I think=20 > PCN should collect and discuss ideas like yours. >=20 > Regards, >=20 > Ruediger >=20 >=20 > |>In your model, at least the termination decision seems to=20 > happen at an=20 > |>interior router and it is only the enforcement of the=20 > decision that is=20 > |>delegated to the boundary. The markings have a much different >=20 > |>semantics ("terminate this flow"). One issue I see is that=20 > the router >=20 > |>that makes this decision has a much more limited view of=20 > the network=20 > |>than the boundary. Another issue is that some level of coordination=20 > |>between the interior routers seems to be needed, to result=20 > in a stable=20 > |>system. > | > |In my model an interior router marking a packet (flow) that is an=20 > |indication to the edges (boundary nodes) that the marked=20 > flow is on a=20 > |congested path. The boundary nodes still need to act on this=20 > |information. In the original phase of the PCN work it the=20 > action is to=20 > |terminate the mark flow. In later phases, could do=20 > rate-adaptation, or=20 > |other action. Should not that the marking of packets continues (one=20 > |marked packet every x bytes of excess traffic) until congestion=20 > |condition is removed. >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 07 08:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwQw-00016c-Dg; Wed, 07 Mar 2007 08:43:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwQv-00016X-83 for pcn@ietf.org; Wed, 07 Mar 2007 08:43:57 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOwQt-0007Mu-NN for pcn@ietf.org; Wed, 07 Mar 2007 08:43:57 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l27DhcCJ028093; Wed, 7 Mar 2007 14:43:46 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , "'Geib, Ruediger'" , References: <6439282641581441A36F7F6F83ED2ED201DB93EB@S4DE8PSAAFQ.mitte.t-com.de> Subject: RE: [PCN] Explicit PCN Marking Date: Wed, 7 Mar 2007 14:43:33 +0100 Message-ID: <001601c760be$9ec127e0$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 In-Reply-To: thread-index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+AACq/0wAACFoJg X-Spam-Score: 0.088 () 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, 07 Mar 2007 14:43:47 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna I think it will be good if we can get some PCN-WG time slot(s) to present different possible solutions, not only associated with the ECMP issue but also on other PCN related issues, that will make sense to be considered for further investigation within the PCN WG. Best Regards, Georgios > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: woensdag 7 maart 2007 14:03 > To: Geib, Ruediger; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Explicit PCN Marking > > Hi Ruediger, Jozef, > > Yes, the ability to address ECMP directly is indeed a very > attractive point of Joe's proposal. > > One of the other ideas that was discussed to address the ECMP > case was that PCN ingress could choose for preemption only > those flows which have already been pre-emption marked (based > on the "usual" marking). This would prevent from pre-empting > flows on the "unaffected" ECMP paths, but potentially slow > down the process of pre-empting enough flows on the affected > ones in some cases (specifically the cases when pre-emption > marking keeps affecting the same subset of affected flows > rather than being uniformly distributed among all affected > flows). This would be corrected in subsequent pre-emption > round, though. > > It was discussed that this "preempted only marked flows" > decision could be a local decision at the ingress - part of > selection of *which* flows to choose at the ingress for > pre-emption - something that the current cl drafts leave up > to the implementation. Implications may need to be studied further. > > Another idea that was discussed was to use additional > "affected" marking that would indicate that a packet would go > through a bottleneck (the idea earlier described in the > context of RMD). Unfortunately needs yet another codepoint. > > Anna > > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: Wednesday, March 07, 2007 2:49 AM > > To: babiarz@nortel.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Explicit PCN Marking > > > > Jozef, > > > > while your proposal indeed requires different > functionalities compared > > to the PCN functionalities as discussed up to know, I must > admit that > > it is a way to deal with backbone load balancing and cases of > > "unsymmetric congestion". Load balancing is likely to occur in > > backbone networks and PCN should work properly if IP load > balancing is > > active. I think PCN should collect and discuss ideas like yours. > > > > Regards, > > > > Ruediger > > > > > > |>In your model, at least the termination decision seems to > > happen at an > > |>interior router and it is only the enforcement of the > > decision that is > > |>delegated to the boundary. The markings have a much different > > > > |>semantics ("terminate this flow"). One issue I see is that > > the router > > > > |>that makes this decision has a much more limited view of > > the network > > |>than the boundary. Another issue is that some level of > coordination > > |>between the interior routers seems to be needed, to result > > in a stable > > |>system. > > | > > |In my model an interior router marking a packet (flow) that is an > > |indication to the edges (boundary nodes) that the marked > > flow is on a > > |congested path. The boundary nodes still need to act on this > > |information. In the original phase of the PCN work it the > > action is to > > |terminate the mark flow. In later phases, could do > > rate-adaptation, or > > |other action. Should not that the marking of packets > continues (one > > |marked packet every x bytes of excess traffic) until congestion > > |condition is removed. > > > > _______________________________________________ > > PCN mailing 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 Mar 07 09:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwj5-0005Yo-Mm; Wed, 07 Mar 2007 09:02:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwj4-0005Yi-D2 for pcn@ietf.org; Wed, 07 Mar 2007 09:02:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOwj1-0001sH-PR for pcn@ietf.org; Wed, 07 Mar 2007 09:02:42 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2007 06:02:40 -0800 X-IronPort-AV: i="4.14,258,1170662400"; d="scan'208"; a="398113220:sNHT93273628" 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 l27E2d1s026381; Wed, 7 Mar 2007 06:02:39 -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 l27E2Zxh029237; Wed, 7 Mar 2007 14:02:38 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 09:02:34 -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] Explicit PCN Marking Date: Wed, 7 Mar 2007 09:02:32 -0500 Message-ID: In-Reply-To: <001601c760be$9ec127e0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking thread-index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+AACq/0wAACFoJgAAC2OKA= From: "Anna Charny \(acharny\)" To: "Georgios Karagiannis" , "Geib, Ruediger" , X-OriginalArrivalTime: 07 Mar 2007 14:02:34.0303 (UTC) FILETIME=[414034F0:01C760C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5077; t=1173276159; x=1174140159; 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]=20Explicit=20PCN=20Marking |Sender:=20; bh=xp4muT26kRMBAnYIdc5SEEwUzhPkGKctmmRlruZGI00=; b=XQxJZUCKPj4gsGVbUWoIzM9f7Gh1mUHMnwA4y1kqzebRCiNM9Jpd6rZmjHVqkRN+Zkcz1p9T 2h07/VdazLjC6aOnDV05dcZLD7LJLGFuYSgy63LO/tjFWsDVzICzHjSP; 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: 932cba6e0228cc603da43d861a7e09d8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Georgios, We have requested a slot for the single-marking draft. Joe has requested a slot for his draft. The cl-architercture draft lists all sorts of open issues/questions already. Do you have anything specific in addition to all of this in mind? =20 Anna=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Wednesday, March 07, 2007 8:44 AM > To: Anna Charny (acharny); 'Geib, Ruediger'; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Explicit PCN Marking >=20 > Hi Anna >=20 > I think it will be good if we can get some PCN-WG time=20 > slot(s) to present different possible solutions, not only=20 > associated with the ECMP issue but also on other PCN related=20 > issues, that will make sense to be considered for further=20 > investigation within the PCN WG. >=20 >=20 > Best Regards, > Georgios >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > Sent: woensdag 7 maart 2007 14:03 > > To: Geib, Ruediger; babiarz@nortel.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Explicit PCN Marking > >=20 > > Hi Ruediger, Jozef, > >=20 > > Yes, the ability to address ECMP directly is indeed a very=20 > attractive=20 > > point of Joe's proposal. > >=20 > > One of the other ideas that was discussed to address the=20 > ECMP case was=20 > > that PCN ingress could choose for preemption only those flows which=20 > > have already been pre-emption marked (based on the "usual"=20 > marking). =20 > > This would prevent from pre-empting flows on the "unaffected" ECMP=20 > > paths, but potentially slow down the process of pre-empting enough=20 > > flows on the affected ones in some cases (specifically the=20 > cases when=20 > > pre-emption marking keeps affecting the same subset of=20 > affected flows=20 > > rather than being uniformly distributed among all affected flows).=20 > > This would be corrected in subsequent pre-emption round, though. > >=20 > > It was discussed that this "preempted only marked flows"=20 > > decision could be a local decision at the ingress - part of=20 > selection=20 > > of *which* flows to choose at the ingress for pre-emption -=20 > something=20 > > that the current cl drafts leave up to the implementation.=20 > > Implications may need to be studied further. > >=20 > > Another idea that was discussed was to use additional "affected"=20 > > marking that would indicate that a packet would go through a=20 > > bottleneck (the idea earlier described in the context of RMD).=20 > > Unfortunately needs yet another codepoint. > >=20 > > Anna > >=20 > > > -----Original Message----- > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > Sent: Wednesday, March 07, 2007 2:49 AM > > > To: babiarz@nortel.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Explicit PCN Marking > > >=20 > > > Jozef, > > >=20 > > > while your proposal indeed requires different > > functionalities compared > > > to the PCN functionalities as discussed up to know, I must > > admit that > > > it is a way to deal with backbone load balancing and cases of=20 > > > "unsymmetric congestion". Load balancing is likely to occur in=20 > > > backbone networks and PCN should work properly if IP load > > balancing is > > > active. I think PCN should collect and discuss ideas like yours. > > >=20 > > > Regards, > > >=20 > > > Ruediger > > >=20 > > >=20 > > > |>In your model, at least the termination decision seems to > > > happen at an > > > |>interior router and it is only the enforcement of the > > > decision that is > > > |>delegated to the boundary. The markings have a much different > > >=20 > > > |>semantics ("terminate this flow"). One issue I see is that > > > the router > > >=20 > > > |>that makes this decision has a much more limited view of > > > the network > > > |>than the boundary. Another issue is that some level of > > coordination > > > |>between the interior routers seems to be needed, to result > > > in a stable > > > |>system. > > > | > > > |In my model an interior router marking a packet (flow)=20 > that is an=20 > > > |indication to the edges (boundary nodes) that the marked > > > flow is on a > > > |congested path. The boundary nodes still need to act on this=20 > > > |information. In the original phase of the PCN work it the > > > action is to > > > |terminate the mark flow. In later phases, could do > > > rate-adaptation, or > > > |other action. Should not that the marking of packets > > continues (one > > > |marked packet every x bytes of excess traffic) until congestion=20 > > > |condition is removed. > > >=20 > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 07 09:22:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx2D-0002R2-D0; Wed, 07 Mar 2007 09:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx2C-0002Qu-8n for pcn@ietf.org; Wed, 07 Mar 2007 09:22:28 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOx2A-0006WI-Nn for pcn@ietf.org; Wed, 07 Mar 2007 09:22:28 -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 l27EMGR3001193; Wed, 7 Mar 2007 15:22:24 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , "'Geib, Ruediger'" , References: <001601c760be$9ec127e0$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [PCN] Explicit PCN Marking Date: Wed, 7 Mar 2007 15:22:10 +0100 Message-ID: <001701c760c4$03e6c3a0$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 In-Reply-To: thread-index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+AACq/0wAACFoJgAAC2OKAAALbSwA== X-Spam-Score: 0.088 () 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, 07 Mar 2007 15:22:24 +0100 (MET) X-Spam-Score: 0.0 (/) 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: , Errors-To: pcn-bounces@ietf.org Hi Anna Yes, I would like to present some possible solutions (in some slides) that are probably not discussed in the current PCN drafts! Best regards, Georgios > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: woensdag 7 maart 2007 15:03 > To: Georgios Karagiannis; Geib, Ruediger; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Explicit PCN Marking > > Hi Georgios, > > We have requested a slot for the single-marking draft. Joe > has requested a slot for his draft. The cl-architercture > draft lists all sorts of open issues/questions already. Do > you have anything specific in addition to all of this in mind? > > Anna > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, March 07, 2007 8:44 AM > > To: Anna Charny (acharny); 'Geib, Ruediger'; babiarz@nortel.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Explicit PCN Marking > > > > Hi Anna > > > > I think it will be good if we can get some PCN-WG time > > slot(s) to present different possible solutions, not only > associated > > with the ECMP issue but also on other PCN related issues, that will > > make sense to be considered for further investigation > within the PCN > > WG. > > > > > > Best Regards, > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > > Sent: woensdag 7 maart 2007 14:03 > > > To: Geib, Ruediger; babiarz@nortel.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Explicit PCN Marking > > > > > > Hi Ruediger, Jozef, > > > > > > Yes, the ability to address ECMP directly is indeed a very > > attractive > > > point of Joe's proposal. > > > > > > One of the other ideas that was discussed to address the > > ECMP case was > > > that PCN ingress could choose for preemption only those > flows which > > > have already been pre-emption marked (based on the "usual" > > marking). > > > This would prevent from pre-empting flows on the > "unaffected" ECMP > > > paths, but potentially slow down the process of > pre-empting enough > > > flows on the affected ones in some cases (specifically the > > cases when > > > pre-emption marking keeps affecting the same subset of > > affected flows > > > rather than being uniformly distributed among all > affected flows). > > > This would be corrected in subsequent pre-emption round, though. > > > > > > It was discussed that this "preempted only marked flows" > > > decision could be a local decision at the ingress - part of > > selection > > > of *which* flows to choose at the ingress for pre-emption - > > something > > > that the current cl drafts leave up to the implementation. > > > Implications may need to be studied further. > > > > > > Another idea that was discussed was to use additional "affected" > > > marking that would indicate that a packet would go through a > > > bottleneck (the idea earlier described in the context of RMD). > > > Unfortunately needs yet another codepoint. > > > > > > Anna > > > > > > > -----Original Message----- > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > Sent: Wednesday, March 07, 2007 2:49 AM > > > > To: babiarz@nortel.com > > > > Cc: pcn@ietf.org > > > > Subject: RE: [PCN] Explicit PCN Marking > > > > > > > > Jozef, > > > > > > > > while your proposal indeed requires different > > > functionalities compared > > > > to the PCN functionalities as discussed up to know, I must > > > admit that > > > > it is a way to deal with backbone load balancing and cases of > > > > "unsymmetric congestion". Load balancing is likely to occur in > > > > backbone networks and PCN should work properly if IP load > > > balancing is > > > > active. I think PCN should collect and discuss ideas like yours. > > > > > > > > Regards, > > > > > > > > Ruediger > > > > > > > > > > > > |>In your model, at least the termination decision seems to > > > > happen at an > > > > |>interior router and it is only the enforcement of the > > > > decision that is > > > > |>delegated to the boundary. The markings have a much different > > > > > > > > |>semantics ("terminate this flow"). One issue I see is that > > > > the router > > > > > > > > |>that makes this decision has a much more limited view of > > > > the network > > > > |>than the boundary. Another issue is that some level of > > > coordination > > > > |>between the interior routers seems to be needed, to result > > > > in a stable > > > > |>system. > > > > | > > > > |In my model an interior router marking a packet (flow) > > that is an > > > > |indication to the edges (boundary nodes) that the marked > > > > flow is on a > > > > |congested path. The boundary nodes still need to act on this > > > > |information. In the original phase of the PCN work it the > > > > action is to > > > > |terminate the mark flow. In later phases, could do > > > > rate-adaptation, or > > > > |other action. Should not that the marking of packets > > > continues (one > > > > |marked packet every x bytes of excess traffic) until > congestion > > > > |condition is removed. > > > > > > > > _______________________________________________ > > > > PCN mailing 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 Mar 07 09:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx9d-0000wt-T1; Wed, 07 Mar 2007 09:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx9c-0000sc-5R for pcn@ietf.org; Wed, 07 Mar 2007 09:30:08 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOx9X-0008EO-Uo for pcn@ietf.org; Wed, 07 Mar 2007 09:30:08 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2007 09:30:04 -0500 X-IronPort-AV: i="4.14,259,1170651600"; d="scan'208"; a="115140187:sNHT57996760" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l27EU3FZ023117; Wed, 7 Mar 2007 09:30:03 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l27ETaaL009957; Wed, 7 Mar 2007 14:29:59 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 09:29:45 -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] Explicit PCN Marking Date: Wed, 7 Mar 2007 09:29:44 -0500 Message-ID: In-Reply-To: <001701c760c4$03e6c3a0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking thread-index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+AACq/0wAACFoJgAAC2OKAAALbSwAAATh+g From: "Anna Charny \(acharny\)" To: "Georgios Karagiannis" , "Geib, Ruediger" , X-OriginalArrivalTime: 07 Mar 2007 14:29:45.0970 (UTC) FILETIME=[0DCCD520:01C760C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6508; t=1173277803; x=1174141803; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20Explicit=20PCN=20Marking |Sender:=20 |To:=20=22Georgios=20Karagiannis=22=20, =0A=20=20= 20=20=20=20=20=20=22Geib, =20Ruediger=22=20, =2 0; bh=SOQaziVJvZVSdww8GM04MKbEXMe/ZK+YVzhTwLFHL/8=; b=ARjF7+w6ygpiEoSs9iyoXyUUdOMs3f7+1QAQXdzk77b7CWoOL9Syjvl0MtOyeKiUdJxeP7Eh 98bYEwzAidOeTc3kM/1Neca03Of8dgbUSDE4eVGcTv7NzBWNjIU+LOSQ; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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, Is there a draft on these to take a look at? Thanks, Anna =20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Wednesday, March 07, 2007 9:22 AM > To: Anna Charny (acharny); 'Geib, Ruediger'; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Explicit PCN Marking >=20 > Hi Anna >=20 > Yes, I would like to present some possible solutions (in some=20 > slides) that are probably not discussed in the current PCN drafts! >=20 > Best regards, > Georgios >=20 > =20 >=20 > > -----Original Message----- > > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > Sent: woensdag 7 maart 2007 15:03 > > To: Georgios Karagiannis; Geib, Ruediger; babiarz@nortel.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Explicit PCN Marking > >=20 > > Hi Georgios, > >=20 > > We have requested a slot for the single-marking draft. Joe has=20 > > requested a slot for his draft. The cl-architercture draft=20 > lists all=20 > > sorts of open issues/questions already. Do you have=20 > anything specific=20 > > in addition to all of this in mind? > >=20 > > Anna > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Wednesday, March 07, 2007 8:44 AM > > > To: Anna Charny (acharny); 'Geib, Ruediger'; babiarz@nortel.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Explicit PCN Marking > > >=20 > > > Hi Anna > > >=20 > > > I think it will be good if we can get some PCN-WG time > > > slot(s) to present different possible solutions, not only > > associated > > > with the ECMP issue but also on other PCN related issues,=20 > that will=20 > > > make sense to be considered for further investigation > > within the PCN > > > WG. > > >=20 > > >=20 > > > Best Regards, > > > Georgios > > >=20 > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > > > Sent: woensdag 7 maart 2007 14:03 > > > > To: Geib, Ruediger; babiarz@nortel.com > > > > Cc: pcn@ietf.org > > > > Subject: RE: [PCN] Explicit PCN Marking > > > >=20 > > > > Hi Ruediger, Jozef, > > > >=20 > > > > Yes, the ability to address ECMP directly is indeed a very > > > attractive > > > > point of Joe's proposal. > > > >=20 > > > > One of the other ideas that was discussed to address the > > > ECMP case was > > > > that PCN ingress could choose for preemption only those > > flows which > > > > have already been pre-emption marked (based on the "usual" > > > marking). =20 > > > > This would prevent from pre-empting flows on the > > "unaffected" ECMP > > > > paths, but potentially slow down the process of > > pre-empting enough > > > > flows on the affected ones in some cases (specifically the > > > cases when > > > > pre-emption marking keeps affecting the same subset of > > > affected flows > > > > rather than being uniformly distributed among all > > affected flows).=20 > > > > This would be corrected in subsequent pre-emption round, though. > > > >=20 > > > > It was discussed that this "preempted only marked flows"=20 > > > > decision could be a local decision at the ingress - part of > > > selection > > > > of *which* flows to choose at the ingress for pre-emption - > > > something > > > > that the current cl drafts leave up to the implementation.=20 > > > > Implications may need to be studied further. > > > >=20 > > > > Another idea that was discussed was to use additional=20 > "affected"=20 > > > > marking that would indicate that a packet would go through a=20 > > > > bottleneck (the idea earlier described in the context of RMD). > > > > Unfortunately needs yet another codepoint. > > > >=20 > > > > Anna > > > >=20 > > > > > -----Original Message----- > > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > > Sent: Wednesday, March 07, 2007 2:49 AM > > > > > To: babiarz@nortel.com > > > > > Cc: pcn@ietf.org > > > > > Subject: RE: [PCN] Explicit PCN Marking > > > > >=20 > > > > > Jozef, > > > > >=20 > > > > > while your proposal indeed requires different > > > > functionalities compared > > > > > to the PCN functionalities as discussed up to know, I must > > > > admit that > > > > > it is a way to deal with backbone load balancing and cases of=20 > > > > > "unsymmetric congestion". Load balancing is likely to=20 > occur in=20 > > > > > backbone networks and PCN should work properly if IP load > > > > balancing is > > > > > active. I think PCN should collect and discuss ideas=20 > like yours. > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Ruediger > > > > >=20 > > > > >=20 > > > > > |>In your model, at least the termination decision seems to > > > > > happen at an > > > > > |>interior router and it is only the enforcement of the > > > > > decision that is > > > > > |>delegated to the boundary. The markings have a much=20 > different > > > > >=20 > > > > > |>semantics ("terminate this flow"). One issue I see is that > > > > > the router > > > > >=20 > > > > > |>that makes this decision has a much more limited view of > > > > > the network > > > > > |>than the boundary. Another issue is that some level of > > > > coordination > > > > > |>between the interior routers seems to be needed, to result > > > > > in a stable > > > > > |>system. > > > > > | > > > > > |In my model an interior router marking a packet (flow) > > > that is an > > > > > |indication to the edges (boundary nodes) that the marked > > > > > flow is on a > > > > > |congested path. The boundary nodes still need to act on this=20 > > > > > |information. In the original phase of the PCN work it the > > > > > action is to > > > > > |terminate the mark flow. In later phases, could do > > > > > rate-adaptation, or > > > > > |other action. Should not that the marking of packets > > > > continues (one > > > > > |marked packet every x bytes of excess traffic) until > > congestion > > > > > |condition is removed. > > > > >=20 > > > > > _______________________________________________ > > > > > PCN mailing list > > > > > PCN@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > PCN mailing list > > > > PCN@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pcn > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 07 09:40:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxJC-00039P-MU; Wed, 07 Mar 2007 09:40:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxJ9-00036g-0w for pcn@ietf.org; Wed, 07 Mar 2007 09:39:59 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOxJ7-0004RW-DD for pcn@ietf.org; Wed, 07 Mar 2007 09:39:58 -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 l27EdZVL002450; Wed, 7 Mar 2007 15:39:48 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , "'Geib, Ruediger'" , References: <001701c760c4$03e6c3a0$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [PCN] Explicit PCN Marking Date: Wed, 7 Mar 2007 15:39:30 +0100 Message-ID: <001801c760c6$6f99a5c0$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 In-Reply-To: thread-index: Acdfwhu8uJNLWZ1KQWWgz0yS2rgYNgAOcj+AACPDm+AACq/0wAACFoJgAAC2OKAAALbSwAAATh+gAABVf1A= X-Spam-Score: 0.088 () 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, 07 Mar 2007 15:39:49 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna Not yet, but it will come after the IETF meeting! Best regards, Georgios > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: woensdag 7 maart 2007 15:30 > To: Georgios Karagiannis; Geib, Ruediger; babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Explicit PCN Marking > > Hi georgios, > > Is there a draft on these to take a look at? > > Thanks, > Anna > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, March 07, 2007 9:22 AM > > To: Anna Charny (acharny); 'Geib, Ruediger'; babiarz@nortel.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Explicit PCN Marking > > > > Hi Anna > > > > Yes, I would like to present some possible solutions (in some > > slides) that are probably not discussed in the current PCN drafts! > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > > Sent: woensdag 7 maart 2007 15:03 > > > To: Georgios Karagiannis; Geib, Ruediger; babiarz@nortel.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Explicit PCN Marking > > > > > > Hi Georgios, > > > > > > We have requested a slot for the single-marking draft. Joe has > > > requested a slot for his draft. The cl-architercture draft > > lists all > > > sorts of open issues/questions already. Do you have > > anything specific > > > in addition to all of this in mind? > > > > > > Anna > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: Wednesday, March 07, 2007 8:44 AM > > > > To: Anna Charny (acharny); 'Geib, Ruediger'; babiarz@nortel.com > > > > Cc: pcn@ietf.org > > > > Subject: RE: [PCN] Explicit PCN Marking > > > > > > > > Hi Anna > > > > > > > > I think it will be good if we can get some PCN-WG time > > > > slot(s) to present different possible solutions, not only > > > associated > > > > with the ECMP issue but also on other PCN related issues, > > that will > > > > make sense to be considered for further investigation > > > within the PCN > > > > WG. > > > > > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > > > > Sent: woensdag 7 maart 2007 14:03 > > > > > To: Geib, Ruediger; babiarz@nortel.com > > > > > Cc: pcn@ietf.org > > > > > Subject: RE: [PCN] Explicit PCN Marking > > > > > > > > > > Hi Ruediger, Jozef, > > > > > > > > > > Yes, the ability to address ECMP directly is indeed a very > > > > attractive > > > > > point of Joe's proposal. > > > > > > > > > > One of the other ideas that was discussed to address the > > > > ECMP case was > > > > > that PCN ingress could choose for preemption only those > > > flows which > > > > > have already been pre-emption marked (based on the "usual" > > > > marking). > > > > > This would prevent from pre-empting flows on the > > > "unaffected" ECMP > > > > > paths, but potentially slow down the process of > > > pre-empting enough > > > > > flows on the affected ones in some cases (specifically the > > > > cases when > > > > > pre-emption marking keeps affecting the same subset of > > > > affected flows > > > > > rather than being uniformly distributed among all > > > affected flows). > > > > > This would be corrected in subsequent pre-emption > round, though. > > > > > > > > > > It was discussed that this "preempted only marked flows" > > > > > decision could be a local decision at the ingress - part of > > > > selection > > > > > of *which* flows to choose at the ingress for pre-emption - > > > > something > > > > > that the current cl drafts leave up to the implementation. > > > > > Implications may need to be studied further. > > > > > > > > > > Another idea that was discussed was to use additional > > "affected" > > > > > marking that would indicate that a packet would go through a > > > > > bottleneck (the idea earlier described in the context of RMD). > > > > > Unfortunately needs yet another codepoint. > > > > > > > > > > Anna > > > > > > > > > > > -----Original Message----- > > > > > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > > > > > Sent: Wednesday, March 07, 2007 2:49 AM > > > > > > To: babiarz@nortel.com > > > > > > Cc: pcn@ietf.org > > > > > > Subject: RE: [PCN] Explicit PCN Marking > > > > > > > > > > > > Jozef, > > > > > > > > > > > > while your proposal indeed requires different > > > > > functionalities compared > > > > > > to the PCN functionalities as discussed up to know, I must > > > > > admit that > > > > > > it is a way to deal with backbone load balancing > and cases of > > > > > > "unsymmetric congestion". Load balancing is likely to > > occur in > > > > > > backbone networks and PCN should work properly if IP load > > > > > balancing is > > > > > > active. I think PCN should collect and discuss ideas > > like yours. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Ruediger > > > > > > > > > > > > > > > > > > |>In your model, at least the termination decision seems to > > > > > > happen at an > > > > > > |>interior router and it is only the enforcement of the > > > > > > decision that is > > > > > > |>delegated to the boundary. The markings have a much > > different > > > > > > > > > > > > |>semantics ("terminate this flow"). One issue I see is that > > > > > > the router > > > > > > > > > > > > |>that makes this decision has a much more limited view of > > > > > > the network > > > > > > |>than the boundary. Another issue is that some level of > > > > > coordination > > > > > > |>between the interior routers seems to be needed, to result > > > > > > in a stable > > > > > > |>system. > > > > > > | > > > > > > |In my model an interior router marking a packet (flow) > > > > that is an > > > > > > |indication to the edges (boundary nodes) that the marked > > > > > > flow is on a > > > > > > |congested path. The boundary nodes still need to > act on this > > > > > > |information. In the original phase of the PCN work it the > > > > > > action is to > > > > > > |terminate the mark flow. In later phases, could do > > > > > > rate-adaptation, or > > > > > > |other action. Should not that the marking of packets > > > > > continues (one > > > > > > |marked packet every x bytes of excess traffic) until > > > congestion > > > > > > |condition is removed. > > > > > > > > > > > > _______________________________________________ > > > > > > PCN mailing 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 Mar 07 10:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyDN-0007rh-MH; Wed, 07 Mar 2007 10:38:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyDM-0007rW-Jo for pcn@ietf.org; Wed, 07 Mar 2007 10:38:04 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyDL-0002Nh-BX for pcn@ietf.org; Wed, 07 Mar 2007 10:38:04 -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 l27Fbt607682; Wed, 7 Mar 2007 10:37:55 -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] Explicit PCN Marking Date: Wed, 7 Mar 2007 10:37:54 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F0B8665@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Explicit PCN Marking Thread-Index: AcdgjZiz4NfGXVTpQuut9XNwHX/oMQAMbYUQ From: "Jozef Babiarz" To: "Lars Eggert" 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 Lars, The Explicit PCN Marking is intended to be used for removal of excess traffic (congestion) from the network. I agree that it is not suitable to be used for admission control (blocking of new flows being admitted into the network). For admission control, I'm currently doing simulations of a method that is similar to what is documented in draft-briscoe-tsvwg-cl-phb-03 section 2, however I'm using a token bucket approach versus virtual queue. Simulation results are encouraging for voice traffic, including controlling over admission during burst call attempts. Will share my results once I've completed the work.=20 Regards, Joe Telephone: 613-763-6098=20 Email: babiarz@nortel.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: March 7, 2007 2:52 AM To: Babiarz, Jozef (CAR:0S03) Cc: menth@informatik.uni-wuerzburg.de; pcn@ietf.org Subject: Re: [PCN] Explicit PCN Marking On 2007-3-6, at 20:27, ext Jozef Babiarz wrote: > On March 6, 2007 2:36 AM, ext Lars Eggert wrote: >> In your model, at least the termination decision seems to happen at >> an interior router and it is only the enforcement of the decision >> that is delegated to the boundary. The markings have a much different >> semantics ("terminate this flow"). One issue I see is that the router >> that makes this decision has a much more limited view of the network >> than the boundary. Another issue is that some level of coordination >> between the interior routers seems to be needed, to result in a >> stable system. > > In my model an interior router marking a packet (flow) that is an > indication to the edges (boundary nodes) that the marked flow is on a > congested path. The boundary nodes still need to act on this > information. Agreed - the meaning of the mark when set by a router is something =20 like "this packet (and by inference, this flow) are contributing to =20 (pre-)congestion." In your earlier email, the meaning was "terminate =20 this flow, please", which is quite different - it's not a (pre-)=20 congestion mark anymore, your mark prescribes a specific reaction. =20 This moves the decision point from the boundary into the network. > In the original phase of the PCN work it the action is to > terminate the mark flow. Not only. The boundary may also alleviate (pre-)congestion over time =20 by not admitting new flows into the network. Especially when the =20 marking volume establishes that the network is approaching congestion =20 but hasn't reached that point yet, not admitting new flows into the =20 domain may be the preferred reaction, because it doesn't interfere =20 with established communication. I don't see how flow admission would =20 happen based on your marking definition. Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 12 15:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQqXx-0000ta-RM; Mon, 12 Mar 2007 15:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQqXw-0000tM-0W for pcn@ietf.org; Mon, 12 Mar 2007 15:51:04 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQqXr-0000py-Cu for pcn@ietf.org; Mon, 12 Mar 2007 15:51:03 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l2CJouFG024721 for ; Mon, 12 Mar 2007 13:50:56 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 14:50:56 -0500 Received: from [147.117.169.165] ([147.117.169.165]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 14:50:56 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-riu8hj4yIuH46RZLMPUI" Organization: Ericsson IP Infrastructure Date: Mon, 12 Mar 2007 15:50:57 -0400 Message-Id: <1173729057.3423.21.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 12 Mar 2007 19:50:56.0404 (UTC) FILETIME=[BFF07540:01C764DF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [PCN] IETF68 meeting agenda and milestone revision X-BeenThere: pcn@ietf.org X-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 --=-riu8hj4yIuH46RZLMPUI Content-Type: text/plain Content-Transfer-Encoding: 7bit Greetings, The agenda for our first wg meeting is attached (also available at http://www3.ietf.org/proceedings/07mar/agenda/pcn.txt). After discussions with our ADs (Lars and Magnus), we have requested a revision to the wg charter milestones. The following changes have been requested: First milestone: replace with Nov 2007 Submit "Flow Admission and Termination Architecture within a Diffserv Domain" to the IESG for consideration as an Informational RFC Third milestone: remove This change removes one of the two overlapping milestones. We will keep you informed when/if the charter is officially updated. Regards, Steve & Scott =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson Data Networks +1 919-472-9913 --=-riu8hj4yIuH46RZLMPUI Content-Disposition: attachment; filename=pcn-ietf68-agenda.txt Content-Type: text/plain; name=pcn-ietf68-agenda.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) Monday, March 19, 2007 1740-1950 Afternoon Session III Athens/Barcelona/Berlin ==================================== CHAIRs: Scott Bradner Steven Blake AGENDA: o Administrivia chairs 10 min - Blue sheets - Scribe - Agenda bash o Charter review chairs 30 min o Overview of prior work as it applies to the Kwok-Ho Chan 30 min first three charter milestones o Performance Evaluation fo CL-PHB Admission and Anna Charny 20 min pre-emption Algorithmes draft-zhang-pcn-performance-evaluation-01 o Pre-Congestion Notification Using Single Marking Anna Charny 20 min for Admission and Pre-emption draft-charny-pcn-single-marking-01 o Explicit PCN Marking Jozef Babiarz 20 min draft-babiarz-pcn-explicit-marking-00 --=-riu8hj4yIuH46RZLMPUI 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 --=-riu8hj4yIuH46RZLMPUI-- From pcn-bounces@ietf.org Tue Mar 20 01:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTXLa-0006rm-4s; Tue, 20 Mar 2007 01:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTXLZ-0006rg-8R for pcn@ietf.org; Tue, 20 Mar 2007 01:57:25 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTXLX-0005co-V5 for pcn@ietf.org; Tue, 20 Mar 2007 01:57:25 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JF600GQTTVQPN@lhrga01-in.huawei.com> for pcn@ietf.org; Tue, 20 Mar 2007 05:57:26 +0000 (GMT) Received: from IBM4307EA0CEF3 (dhcp-4009.ietf68.org [130.129.64.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JF6002EVTVPSP@lhrga01-in.huawei.com> for pcn@ietf.org; Tue, 20 Mar 2007 05:57:26 +0000 (GMT) Date: Tue, 20 Mar 2007 06:57:10 +0100 From: Tina TSOU To: Kwok-Ho Chan Message-id: <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: pcn@ietf.org Subject: [PCN] identify an aggregation X-BeenThere: pcn@ietf.org X-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, We had a nice PCN meeting yesterday. I asked the question about how to identify an aggregation in PCN. People gave several replies. Would you like to give a summary here? B. R. Tina _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 03:43:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZ0D-0008Op-1t; Tue, 20 Mar 2007 03:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZ0A-0008NE-Sf for pcn@ietf.org; Tue, 20 Mar 2007 03:43:26 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTZ09-0008Qq-Cg for pcn@ietf.org; Tue, 20 Mar 2007 03:43:26 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8474B6BBB; Tue, 20 Mar 2007 08:43:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 76B2C6BBD; Tue, 20 Mar 2007 08:43:24 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 61C986BBB; Tue, 20 Mar 2007 08:43:24 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l2K7hOW05348; Tue, 20 Mar 2007 08:43:24 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id A9C526F58E; Tue, 20 Mar 2007 08:39:31 +0100 (CET) Message-ID: <45FF9054.1040507@informatik.uni-wuerzburg.de> Date: Tue, 20 Mar 2007 08:42:12 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [PCN] identify an aggregation References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> In-Reply-To: <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Tina, you may want to have a look at Section II of the paper referenced in the attached email. It's a short summary of how PCN basically works. The scope of the aggregation level for measured variables is expressed by mathematical dependencies. Example: * AR(l): aggregation scope is all traffic on a specific link l * ASR(Y,Z): aggregation scope is all traffic between ingress Y and egress Z Kind regards, Michael Tina TSOU wrote: > Hi Kwok, > We had a nice PCN meeting yesterday. > I asked the question about how to identify an aggregation in PCN. > People gave several replies. Would you like to give a summary here? > > B. R. > Tina > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 04:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZxv-0007oe-60; Tue, 20 Mar 2007 04:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZxt-0007nQ-GO for pcn@ietf.org; Tue, 20 Mar 2007 04:45:09 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTZxr-0005u0-4g for pcn@ietf.org; Tue, 20 Mar 2007 04:45:09 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JF7003R91NB2T@lhrga01-in.huawei.com> for pcn@ietf.org; Tue, 20 Mar 2007 08:45:12 +0000 (GMT) Received: from IBM4307EA0CEF3 (dhcp-4009.ietf68.org [130.129.64.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JF7007EL1NBP3@lhrga01-in.huawei.com> for pcn@ietf.org; Tue, 20 Mar 2007 08:45:11 +0000 (GMT) Date: Tue, 20 Mar 2007 09:44:53 +0100 From: Tina TSOU Subject: Re: [PCN] identify an aggregation To: menth@informatik.uni-wuerzburg.de Message-id: <028d01c76acc$094b4930$a201000a@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> <45FF9054.1040507@informatik.uni-wuerzburg.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Dear Michael, Where did you attach the "attached email"? ;-) As interior node in PCN domain, I might receive many packets, when packet A comes, how do I know packet A belongs to AR(1), AR(2), ASR(Y,Z), or ASR(W,X)? From the multicast destination address of Packet A? Or an identifier in the header of Packet A? B. R. Tina ----- Original Message ----- From: "Michael Menth" To: "Tina TSOU" Cc: "Kwok-Ho Chan" ; Sent: Tuesday, March 20, 2007 8:42 AM Subject: Re: [PCN] identify an aggregation > Dear Tina, > > you may want to have a look at Section II of the paper referenced in the > attached email. It's a short summary of how PCN basically works. The > scope of the aggregation level for measured variables is expressed by > mathematical dependencies. Example: > * AR(l): aggregation scope is all traffic on a specific link l > * ASR(Y,Z): aggregation scope is all traffic between ingress Y and > egress Z > > Kind regards, > > Michael > > Tina TSOU wrote: >> Hi Kwok, >> We had a nice PCN meeting yesterday. >> I asked the question about how to identify an aggregation in PCN. People >> gave several replies. Would you like to give a summary here? >> >> B. R. >> Tina >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science > Am Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 04:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTa5B-0006ED-M5; Tue, 20 Mar 2007 04:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTa5A-0006E3-As for pcn@ietf.org; Tue, 20 Mar 2007 04:52:40 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTa58-00074H-BE for pcn@ietf.org; Tue, 20 Mar 2007 04:52:40 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2K8qLM13897; Tue, 20 Mar 2007 08:52:21 GMT Received: from KCHAN-2K3.nortel.com ([47.165.248.66] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 04:52:35 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Mar 2007 09:52:33 +0100 To: Tina TSOU From: "Kwok-Ho Chan" In-Reply-To: <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2007 08:52:35.0514 (UTC) FILETIME=[1AE0F9A0:01C76ACD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: pcn@ietf.org Subject: [PCN] Re: identify an aggregation X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Tina: As the way I understand your question on the mic, the aggregation you were asking is about what happens at the Interior Nodes. At the Interior Nodes, we assume packets can be identified as PCN traffic packets, for example all PCN packets uses a specific DiffServ Code Point (DSCP). Hence we have a dependency on using a DiffServ Domain (as the scope of the current Charter). At the Interior Node, there should be a filter (diffserv classifier) that will identify the PCN packets. (see slide 5 lower left corner of my presentation). The aggregate is the traffic packets that follows the YES branch of the "PCN pkt?" going into the "PCN pkt queue". Hence the aggregate in the Interior Node includes all the PCN packets that traverse that specific Interior Node (router) link. I hope this answers your question completely. Please let me know if additional clarification is needed. Thanks! -- Kwok -- At 06:57 AM 3/20/2007, Tina TSOU wrote: >Hi Kwok, >We had a nice PCN meeting yesterday. >I asked the question about how to identify an aggregation in PCN. >People gave several replies. Would you like to give a summary here? > >B. R. >Tina _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 04:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaAX-0000Kn-Uc; Tue, 20 Mar 2007 04:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaAX-0000Ke-7x for pcn@ietf.org; Tue, 20 Mar 2007 04:58:13 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTaAO-0007jN-Nl for pcn@ietf.org; Tue, 20 Mar 2007 04:58:13 -0400 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:58:03 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Mar 2007 08:57:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] identify an aggregation Date: Tue, 20 Mar 2007 08:56:58 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA50132BF82@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] identify an aggregation Thread-Index: AcdqzC+Uzxtq1NiJSYyVHGblWsN1bgAADnGy References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl><75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net><6.2.5.6.0.20070131114845.033c4ab8@nortel.com><01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3><45FF9054.1040507@informatik.uni-wuerzburg.de> <028d01c76acc$094b4930$a201000a@IBM4307EA0CEF3> From: To: , X-OriginalArrivalTime: 20 Mar 2007 08:57:04.0802 (UTC) FILETIME=[BB631020:01C76ACD] X-Spam-Score: 0.2 (/) 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 an interior node doesnt know what AR a pkt belongs to.=20 it makes measurements for *all* PCN packets (ie all pkts in the PCN = class, ie with the DSCP that's being protected by PCN admission = control). it doesnt know anything about which particular flow (or = ingress-egress aggregate) a packet belongs to. similarly, the interior = node PCN-marks packets independently of which particular flow (or = ingress-egress aggregate) a packet belongs to.=20 the current architecture draft says things like "each router in the CL- region runs an algorithm to determine whether to Admission Mark the=20 packet. The algorithm measures the aggregate CL traffic on the link" perhaps the term "total PCN traffic" would be clearer? http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-architecture-04= .txt=20 thanks phil -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com] Sent: Tue 20/03/2007 08:44 To: menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] identify an aggregation =20 Dear Michael, Where did you attach the "attached email"? ;-) As interior node in PCN domain, I might receive many packets, when = packet A=20 comes, how do I know packet A belongs to AR(1), AR(2), ASR(Y,Z), or=20 ASR(W,X)? From the multicast destination address of Packet A? Or an=20 identifier in the header of Packet A? B. R. Tina ----- Original Message -----=20 From: "Michael Menth" To: "Tina TSOU" Cc: "Kwok-Ho Chan" ; Sent: Tuesday, March 20, 2007 8:42 AM Subject: Re: [PCN] identify an aggregation > Dear Tina, > > you may want to have a look at Section II of the paper referenced in = the > attached email. It's a short summary of how PCN basically works. The > scope of the aggregation level for measured variables is expressed by > mathematical dependencies. Example: > * AR(l): aggregation scope is all traffic on a specific link l > * ASR(Y,Z): aggregation scope is all traffic between ingress Y and > egress Z > > Kind regards, > > Michael > > Tina TSOU wrote: >> Hi Kwok, >> We had a nice PCN meeting yesterday. >> I asked the question about how to identify an aggregation in PCN. = People=20 >> gave several replies. Would you like to give a summary here? >> >> B. R. >> Tina >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn > > --=20 > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science > Am Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 04:59:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaBb-0000s9-7D; Tue, 20 Mar 2007 04:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaBZ-0000pk-Kq for pcn@ietf.org; Tue, 20 Mar 2007 04:59:17 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTaBY-0007rs-3T for pcn@ietf.org; Tue, 20 Mar 2007 04:59:17 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9018F5B0D; Tue, 20 Mar 2007 09:59:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 82AE66F82; Tue, 20 Mar 2007 09:59:15 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 64A2F5B0D; Tue, 20 Mar 2007 09:59:15 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l2K8xFW06073; Tue, 20 Mar 2007 09:59:15 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id A53006F58E; Tue, 20 Mar 2007 09:55:22 +0100 (CET) Message-ID: <45FFA21B.4020505@informatik.uni-wuerzburg.de> Date: Tue, 20 Mar 2007 09:58:03 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 Subject: Re: [PCN] identify an aggregation References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net> <6.2.5.6.0.20070131114845.033c4ab8@nortel.com> <01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3> <45FF9054.1040507@informatik.uni-wuerzburg.de> <028d01c76acc$094b4930$a201000a@IBM4307EA0CEF3> In-Reply-To: <028d01c76acc$094b4930$a201000a@IBM4307EA0CEF3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Tina, oops, i forgot the attachement. Here is the link to the paper: http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-18.pdf Regarding your question: interior routers just measure the rates of all high priority packets on the link, i.e., no difficult aggregate mapping is required. Only PCN egress routers need to map packets to ingress-egress aggregates and measure their rate. However, I don't know how this mapping is done by the routers in an efficient manner. Best wishes, Michael Tina TSOU wrote: > Dear Michael, > Where did you attach the "attached email"? ;-) > As interior node in PCN domain, I might receive many packets, when > packet A comes, how do I know packet A belongs to AR(1), AR(2), > ASR(Y,Z), or ASR(W,X)? From the multicast destination address of > Packet A? Or an identifier in the header of Packet A? > > B. R. > Tina > > ----- Original Message ----- From: "Michael Menth" > > To: "Tina TSOU" > Cc: "Kwok-Ho Chan" ; > Sent: Tuesday, March 20, 2007 8:42 AM > Subject: Re: [PCN] identify an aggregation > > >> Dear Tina, >> >> you may want to have a look at Section II of the paper referenced in the >> attached email. It's a short summary of how PCN basically works. The >> scope of the aggregation level for measured variables is expressed by >> mathematical dependencies. Example: >> * AR(l): aggregation scope is all traffic on a specific link l >> * ASR(Y,Z): aggregation scope is all traffic between ingress Y and >> egress Z >> >> Kind regards, >> >> Michael >> >> Tina TSOU wrote: >>> Hi Kwok, >>> We had a nice PCN meeting yesterday. >>> I asked the question about how to identify an aggregation in PCN. >>> People gave several replies. Would you like to give a summary here? >>> >>> B. R. >>> Tina >>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pcn >> >> -- >> Dr. Michael Menth, Assistant Professor >> University of Wuerzburg, Institute of Computer Science >> Am Hubland, D-97074 Wuerzburg, Germany, room B206 >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 05:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaXJ-0006dy-AN; Tue, 20 Mar 2007 05:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaXI-0006dh-Tg for pcn@ietf.org; Tue, 20 Mar 2007 05:21:44 -0400 Received: from egon.ietf68.org ([130.129.5.7] helo=smtp.ietf68.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTaXH-00030K-Jb for pcn@ietf.org; Tue, 20 Mar 2007 05:21:44 -0400 Received: from [130.129.18.211] (dhcp-12d3.ietf68.org [130.129.18.211]) by smtp.ietf68.org (Postfix) with ESMTP id 1FC6F5006A for ; Tue, 20 Mar 2007 10:21:43 +0100 (CET) From: Steven Blake To: pcn Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 20 Mar 2007 10:21:43 +0100 Message-Id: <1174382503.3200.11.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [PCN] IETF 68 wg presentations X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org FYI All of the presentations from yesterday's wg meeting (including Kwok's revised slides) have been uploaded to: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson Data Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 20 07:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcJT-0007NW-1B; Tue, 20 Mar 2007 07:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcJR-0007NR-RB for pcn@ietf.org; Tue, 20 Mar 2007 07:15:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTcJF-0002xc-QW for pcn@ietf.org; Tue, 20 Mar 2007 07:15:33 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2FE4B206CE; Tue, 20 Mar 2007 12:15:17 +0100 (CET) X-AuditID: c1b4fb3c-aa4eebb0000073d5-8f-45ffc245876b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 080572053A; Tue, 20 Mar 2007 12:15:17 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 12:15:16 +0100 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 12:15:16 +0100 Message-ID: <45FFC244.8070100@ericsson.com> Date: Tue, 20 Mar 2007 12:15:16 +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: menth@informatik.uni-wuerzburg.de, pcn@ietf.org Subject: Re: [PCN] identify an aggregation References: <003d01c74530$30a38cc0$4c0d5982@dynamic.ewi.utwente.nl><75A199C5D243C741BF3D3F1EBCEF9BA5019DBEBB@E03MVZ1-UKDY.domain1.systemhost.net><6.2.5.6.0.20070131114845.033c4ab8@nortel.com><01fc01c76ab4$99cc5070$a201000a@IBM4307EA0CEF3><45FF9054.1040507@informatik.uni-wuerzburg.de><028d01c76acc$094b4930$a201000a@IBM4307EA0CEF3> <45FFA21B.4020505@informatik.uni-wuerzburg.de> In-Reply-To: <45FFA21B.4020505@informatik.uni-wuerzburg.de> X-OriginalArrivalTime: 20 Mar 2007 11:15:16.0421 (UTC) FILETIME=[0993B750:01C76AE1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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: , Content-Type: multipart/mixed; boundary="===============0249548099==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0249548099== Content-Type: multipart/alternative; boundary="------------010309080804000304090708" This is a multi-part message in MIME format. --------------010309080804000304090708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think you can use this refernce into the discussions. These references is the starting point for the RMD-concept. http://www.comet.columbia.edu/~zoltan/LoadControl.pdf I do not remeber which conference it was published. I am also lacking the following reference into the discussion http://www.watersprings.org/pub/id/draft-westberg-loadcntr-01.txt We have published more work into this topic during the period of 99-02 so, if there are interest I can try to find them. regards Lasse Michael Menth wrote: > Dear Tina, > > oops, i forgot the attachement. Here is the link to the paper: > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-18.pdf > > > > Regarding your question: interior routers just measure the rates of all > high priority packets on the link, i.e., no difficult aggregate mapping > is required. Only PCN egress routers need to map packets to > ingress-egress aggregates and measure their rate. However, I don't know > how this mapping is done by the routers in an efficient manner. > > Best wishes, > > Michael > > Tina TSOU wrote: > > Dear Michael, > > Where did you attach the "attached email"? ;-) > > As interior node in PCN domain, I might receive many packets, when > > packet A comes, how do I know packet A belongs to AR(1), AR(2), > > ASR(Y,Z), or ASR(W,X)? From the multicast destination address of > > Packet A? Or an identifier in the header of Packet A? > > > > B. R. > > Tina > > > > ----- Original Message ----- From: "Michael Menth" > > > > To: "Tina TSOU" > > Cc: "Kwok-Ho Chan" ; > > Sent: Tuesday, March 20, 2007 8:42 AM > > Subject: Re: [PCN] identify an aggregation > > > > > >> Dear Tina, > >> > >> you may want to have a look at Section II of the paper referenced > in the > >> attached email. It's a short summary of how PCN basically works. The > >> scope of the aggregation level for measured variables is expressed by > >> mathematical dependencies. Example: > >> * AR(l): aggregation scope is all traffic on a specific link l > >> * ASR(Y,Z): aggregation scope is all traffic between ingress Y and > >> egress Z > >> > >> Kind regards, > >> > >> Michael > >> > >> Tina TSOU wrote: > >>> Hi Kwok, > >>> We had a nice PCN meeting yesterday. > >>> I asked the question about how to identify an aggregation in PCN. > >>> People gave several replies. Would you like to give a summary here? > >>> > >>> B. R. > >>> Tina > >>> > >>> _______________________________________________ > >>> PCN mailing list > >>> PCN@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pcn > >> > >> -- > >> Dr. Michael Menth, Assistant Professor > >> University of Wuerzburg, Institute of Computer Science > >> Am Hubland, D-97074 Wuerzburg, Germany, room B206 > >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > >> mailto:menth@informatik.uni-wuerzburg.de > >> http://www3.informatik.uni-wuerzburg.de/research/ngn > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science > Am Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > --------------010309080804000304090708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think you can use this refernce  into the discussions. These references is the starting point for the RMD-concept.
http://www.comet.columbia.edu/~zoltan/LoadControl.pdf
I do not remeber which conference it was published.
I am also  lacking the following reference into the discussion
http://www.watersprings.org/pub/id/draft-westberg-loadcntr-01.txt

We have published more work into this topic during the period of 99-02
 so, if there are interest I can try to find them.

regards Lasse

Michael Menth wrote:
Re: [PCN] identify an aggregation

Dear Tina,

oops, i forgot the attachement. Here is the link to the paper:
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-18.pdf


Regarding your question: interior routers just measure the rates of all
high priority packets on the link, i.e., no difficult aggregate mapping
is required. Only PCN egress routers need to map packets to
ingress-egress aggregates and measure their rate. However, I don't know
how this mapping is done by the routers in an efficient manner.

Best wishes,

   Michael

Tina TSOU wrote:
> Dear Michael,
> Where did you attach the "attached email"? ;-)
> As interior node in PCN domain, I might receive many packets, when
> packet A comes, how do I know packet A belongs to AR(1), AR(2),
> ASR(Y,Z), or ASR(W,X)? From the multicast destination address of
> Packet A? Or an identifier in the header of Packet A?
>
> B. R.
> Tina
>
> ----- Original Message ----- From: "Michael Menth"
> <menth@informatik.uni-wuerzburg.de>
> To: "Tina TSOU" <tena@huawei.com>
> Cc: "Kwok-Ho Chan" <khchan@nortel.com>; <pcn@ietf.org>
> Sent: Tuesday, March 20, 2007 8:42 AM
> Subject: Re: [PCN] identify an aggregation
>
>
>> Dear Tina,
>>
>> you may want to have a look at Section II of the paper referenced in the
>> attached email. It's a short summary of how PCN basically works. The
>> scope of the aggregation level for measured variables is expressed by
>> mathematical dependencies. Example:
>> * AR(l): aggregation scope is all traffic on a specific link l
>> * ASR(Y,Z): aggregation scope is all traffic between ingress Y and
>> egress Z
>>
>> Kind regards,
>>
>>    Michael
>>
>> Tina TSOU wrote:
>>> Hi Kwok,
>>> We had a nice PCN meeting yesterday.
>>> I asked the question about how to identify an aggregation in PCN.
>>> People gave several replies. Would you like to give a summary here?
>>>
>>> B. R.
>>> Tina
>>>
>>> _______________________________________________
>>> PCN mailing list
>>> PCN@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pcn
>>
>> --
>> Dr. Michael Menth, Assistant Professor
>> University of Wuerzburg, Institute of Computer Science
>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
>> mailto:menth@informatik.uni-wuerzburg.de
>> http://www3.informatik.uni-wuerzburg.de/research/ngn

--
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn


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

--------------010309080804000304090708-- --===============0249548099== 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 --===============0249548099==-- From pcn-bounces@ietf.org Tue Mar 20 10:05:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeyG-0001WB-DU; Tue, 20 Mar 2007 10:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeyD-0001UX-MF for pcn@ietf.org; Tue, 20 Mar 2007 10:05:49 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTexu-00083H-Ps for pcn@ietf.org; Tue, 20 Mar 2007 10:05:49 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 411A4210A0; Tue, 20 Mar 2007 15:05:28 +0100 (CET) X-AuditID: c1b4fb3e-af1edbb0000061ca-1a-45ffea28e1cd Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CFCE212B4; Tue, 20 Mar 2007 15:05:28 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 15:05:27 +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] identify an aggregation Date: Tue, 20 Mar 2007 15:05:26 +0100 Message-ID: <582B939025E978418C0B92DC134ADE9FA80EC1@esealmw106.eemea.ericsson.se> In-Reply-To: <45FFE7F0.8070801@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] identify an aggregation thread-index: Acdq96vql3xFPEw8QwuJUpV9I9yGGQAABM8A From: "Lars Westberg \(KI/EAB\)" To: X-OriginalArrivalTime: 20 Mar 2007 14:05:27.0409 (UTC) FILETIME=[CFCCD610:01C76AF8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 am sorry, but I am not at IETF-meeting. But, I thought that you can get some input to the discussion from the old documents. For the specific discussion of the aggregation, my suggestion is to allow different kind of models like Hose and trunks in the edge-2-edge routers. The N^2 mesh of trunk aggregates generates a scalabillity limitation within the edges. However, the trunk-aggregation fits well with MPLS in the core so that model should also be supported. All comments wellcome. -Lasse=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: den 20 mars 2007 14:56 To: Lars Westberg (KI/EAB) Subject: Re: [PCN] identify an aggregation Hello Lars, I'd like to get to know you as you are also working on pcn. I don't know your face, but you find a picture of me on my homepage:=20 http://www3.informatik.uni-wuerzburg.de/~menth/ I'll be in the Hilton today, but I am not too busy, so I am around.=20 Maybe you can say hello to me? I am leaving tomorrow morning. Best wishes, Michael Lars Westberg wrote: > I think you can use this refernce into the discussions. These=20 > references is the starting point for the RMD-concept. > http://www.comet.columbia.edu/~zoltan/LoadControl.pdf > I do not remeber which conference it was published. > I am also lacking the following reference into the discussion=20 > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-01.txt > > We have published more work into this topic during the period of 99-02 > so, if there are interest I can try to find them. > > regards Lasse > > Michael Menth wrote: >> >> Dear Tina, >> >> oops, i forgot the attachement. Here is the link to the paper: >> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-S >> ub-18.pdf=20 >> > 7-Sub-18.pdf> >> >> >> Regarding your question: interior routers just measure the rates of=20 >> all high priority packets on the link, i.e., no difficult aggregate=20 >> mapping is required. Only PCN egress routers need to map packets to=20 >> ingress-egress aggregates and measure their rate. However, I don't=20 >> know how this mapping is done by the routers in an efficient manner. >> >> Best wishes, >> >> Michael >> >> Tina TSOU wrote: >> > Dear Michael, >> > Where did you attach the "attached email"? ;-) As interior node in=20 >> > PCN domain, I might receive many packets, when packet A comes, how=20 >> > do I know packet A belongs to AR(1), AR(2), ASR(Y,Z), or ASR(W,X)?=20 >> > From the multicast destination address of Packet A? Or an=20 >> > identifier in the header of Packet A? >> > >> > B. R. >> > Tina >> > >> > ----- Original Message ----- From: "Michael Menth" >> > >> > To: "Tina TSOU" >> > Cc: "Kwok-Ho Chan" ; >> > Sent: Tuesday, March 20, 2007 8:42 AM >> > Subject: Re: [PCN] identify an aggregation >> > >> > >> >> Dear Tina, >> >> >> >> you may want to have a look at Section II of the paper referenced >> in the >> >> attached email. It's a short summary of how PCN basically works.=20 >> >> The scope of the aggregation level for measured variables is=20 >> >> expressed by mathematical dependencies. Example: >> >> * AR(l): aggregation scope is all traffic on a specific link l >> >> * ASR(Y,Z): aggregation scope is all traffic between ingress Y and >> >> egress Z >> >> >> >> Kind regards, >> >> >> >> Michael >> >> >> >> Tina TSOU wrote: >> >>> Hi Kwok, >> >>> We had a nice PCN meeting yesterday. >> >>> I asked the question about how to identify an aggregation in PCN. >> >>> People gave several replies. Would you like to give a summary here? >> >>> >> >>> B. R. >> >>> Tina >> >>> >> >>> _______________________________________________ >> >>> PCN mailing list >> >>> PCN@ietf.org >> >>> https://www1.ietf.org/mailman/listinfo/pcn >> >> >> >> -- >> >> Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 >> >> Institute of Computer Science Am Hubland, D-97074 Wuerzburg,=20 >> >> Germany, room B206 >> >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 >> >> mailto:menth@informatik.uni-wuerzburg.de >> >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> -- >> Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 >> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, >> room B206 >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 21 05:19:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwyO-0004Kt-Rb; Wed, 21 Mar 2007 05:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwyN-0004Js-Pq for pcn@ietf.org; Wed, 21 Mar 2007 05:19:11 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwxy-0000QA-P8 for pcn@ietf.org; Wed, 21 Mar 2007 05:19:11 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2L9ITW28071 for ; Wed, 21 Mar 2007 09:18:29 GMT Received: from KCHAN-2K3.nortel.com ([47.165.250.109] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 05:18:43 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 10:18:40 +0100 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2007 09:18:44.0131 (UTC) FILETIME=[EC42AF30:01C76B99] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [PCN] PCN WG work items for Nov 2007 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: Since the Monday PCN WG session at Prague IETF, couple of people have approached me informally on the hall way, during breaks, etc, indicated they would like to help in the PCN work items. I have talked to Steven (but did not get a chance to talk to Scott yet) on holding a quick meeting while most of us are at Prague, to get the work on the first couple of PCN WG work items started. Steven have given his support on this. Hence how about a quick meeting: When: Wed March 21, 2007 16:30 (20 minutes into the cookie break) Where: IETF Registration Desk This will give us half an hour to talk before Plenary starts. Notice we may overflow into the Plenary if necessary. The topic will be to get a good sense on who wants to do what and how we may divide and focus on the different pieces. For people who can not attend, please send mail to the PCN list, Chairs, or myself if you choose to, on your interest and what, how you may want to help. Thank you for all the energy and interest and hope to see you at the quick meeting indicated above. -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 21 05:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTx8S-00021r-Ns; Wed, 21 Mar 2007 05:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTx8O-0001yY-Vo for pcn@ietf.org; Wed, 21 Mar 2007 05:29:32 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTx5X-0002kK-JD for pcn@ietf.org; Wed, 21 Mar 2007 05:26:41 -0400 Received: from [130.129.22.250] by smtp.hosts.co.uk with esmtpa (Exim 4.63) (envelope-from ) id 1HTx43-0004xK-QH for pcn@ietf.org; Wed, 21 Mar 2007 09:25:04 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <812CBF72-1E98-48AD-B24A-75A4A7CB9675@g11.org.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pcn@ietf.org From: ken carlberg Date: Wed, 21 Mar 2007 10:26:36 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [PCN] simulation efforts X-BeenThere: pcn@ietf.org X-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 One thing that occurred to me after seeing the simulation presentations is that if these efforts are relying on Poisson to represent inter-arrival rates, it would be nice if they could use other representations. the journal papers of the last few years having been using other strategies (self similar, brown noise, heavy tail) and so our confidence level in the results would improve if something other than poisson is used. cheers, -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 21 08:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzbK-0007Ly-2O; Wed, 21 Mar 2007 08:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzbI-0007Jr-9z for pcn@ietf.org; Wed, 21 Mar 2007 08:07:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzaW-0001Qo-73 for pcn@ietf.org; Wed, 21 Mar 2007 08:06:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 08:06:44 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LC6hcN008177; Wed, 21 Mar 2007 08:06:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LC6aGt001332; Wed, 21 Mar 2007 12:06:43 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:06:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] simulation efforts Date: Wed, 21 Mar 2007 08:06:27 -0400 Message-ID: In-Reply-To: <812CBF72-1E98-48AD-B24A-75A4A7CB9675@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] simulation efforts thread-index: Acdrm55CA0nSkEqXQW290Olwnq1MuwACi9iw From: "Anna Charny \(acharny\)" To: "ken carlberg" , X-OriginalArrivalTime: 21 Mar 2007 12:06:41.0711 (UTC) FILETIME=[62F75BF0:01C76BB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3491; t=1174478804; x=1175342804; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20simulation=20efforts |Sender:=20 |To:=20=22ken=20carlberg=22=20,=20; bh=F07E4/eRQ85qgp9sXfxH69OswK03pe9nUKaYrNpejpk=; b=mW1oG0LVRoS31gAMoQQkX5A7+xIIO/2YUtALqG27MWRYa1C8bRqmZMf9l28xIgpPRpA1HZUT AhEqRQlVTAGrQ9ZWO9NfP/4AS12bSLEfQ09kgvCh3Jaoe6dO+pyo0dbd; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Ken, A few notes on simulation models we used. Given that the charter constrains us to non-elastic real-time traffic, we concentrated on modeling voip and video only. 1) Voip *packet* arrivals: we have simulated a subset of actual encodings and plan to simulate other encodings as well as their mix. So for *packet* arrival models for voip we seem to be in reasonable shape. There are also a few papers suggesting how to model aggregate voip traffic - but we have not done so because our interest has been in simulating specific call reaction to pcn rather than aggregate voip queuing in the core. 2) Voip *call* arrivals:=20 For voice call arrivals Poisson seems not an unreasonable assumption, based on the classic telephony experience. Of course things may change with voip, but we have not found any studies that argued for a non-Poisson *call* arrival models for voice. To be on the safe side we also tried what we called "Batch Poisson" - Poisson arrivals for some of our simulations (a burstier-than Poisson model when a batch of flows arrive near-simultaneously, but the batches arrive according to the Poisson)- and our intent is to expand the simulation study to cover a broader range of "batch sizes" traffic types. If anyone is aware of any study that suggests other voip *call* arrival distributions please do let us know.=20 3) Video *packet* arrivals: There is a vast amount of work on modeling video packet arrival models. We did not get to simulating any of those, but we did not use Poisson packet arrival assumption either. Instead, we used real video traces, and we also simulated an extremely rough on-off traffic model with an MPEG-2-like peak-to-mean ratio, with exponentially distributed on-off intervals. It is clearly not a reasonable video model, but it likely to be more challenging for the algorithms and was used as a stress-test. Our plan is to find more real video traces for simulation. 4) It is less clear what a reasonable models for video *call* arrivals are and we would appreciate any pointers on that. We used Poisson call arrivals for video simply for the lack of clarity of what a better model might be and for the lack of time to try anything else. Unlike studies of packet arrival models for video, we did not find any that studied *session/call* arrival distributions. If we just missed the relevant work, please do let us know. =20 Any specific input to simulation assumptions is very welcome. In general, this simulation effort is quite time-consuming, so more volunteers in the WG to share the work would be very welcome. Anna=20 > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk]=20 > Sent: Wednesday, March 21, 2007 5:27 AM > To: pcn@ietf.org > Subject: [PCN] simulation efforts >=20 > One thing that occurred to me after seeing the simulation=20 > presentations is that if these efforts are relying on Poisson=20 > to represent inter-arrival rates, it would be nice if they=20 > could use other representations. the journal papers of the=20 > last few years having been using other strategies (self=20 > similar, brown noise, heavy > tail) and so our confidence level in the results would=20 > improve if something other than poisson is used. >=20 > cheers, >=20 > -ken >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 21 12:08:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3ML-0000lF-Nj; Wed, 21 Mar 2007 12:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3MK-0000l2-W0 for pcn@ietf.org; Wed, 21 Mar 2007 12:08:21 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU3MJ-0007TN-JO for pcn@ietf.org; Wed, 21 Mar 2007 12:08:20 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2LG8Hm20044 for ; Wed, 21 Mar 2007 16:08:17 GMT Received: from KCHAN-2K3.nortel.com ([47.165.248.201] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 12:08:16 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 17:08:14 +0100 To: pcn@ietf.org From: "Kwok-Ho Chan" Subject: Re: [PCN] PCN WG work items for Nov 2007 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2007 16:08:16.0767 (UTC) FILETIME=[22B160F0:01C76BD3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: pcn@ietf.org X-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's Pre-BoF on Re-ECN over-ran and most of the people are in this Pre-BoF. But we also have people that need to leave. Hence we need to re-schedule our working meeting to tomorrow: When: Thur March 22, 2007 17:00 Where: IETF Registration Desk Sorry for this re-scheduling, but most of the attendees are impacted because they are in this Re-ECN Pre-BoF. Thanks! -- Kwok -- At 10:18 AM 3/21/2007, Kwok-Ho Chan wrote: >Hi all: >Since the Monday PCN WG session at Prague IETF, couple of people >have approached me informally on the hall way, during breaks, etc, >indicated they would like to help in the PCN work items. > >I have talked to Steven (but did not get a chance to talk to Scott yet) >on holding a quick meeting while most of us are at Prague, >to get the work on the first couple of PCN WG work items started. >Steven have given his support on this. > >Hence how about a quick meeting: >When: Wed March 21, 2007 16:30 (20 minutes into the cookie break) >Where: IETF Registration Desk > >This will give us half an hour to talk before Plenary starts. >Notice we may overflow into the Plenary if necessary. > >The topic will be to get a good sense on who wants to do what and >how we may divide and focus on the different pieces. > >For people who can not attend, please send mail to the PCN list, >Chairs, or myself >if you choose to, on your interest and what, how you may want to help. > >Thank you for all the energy and interest and hope to see you at the >quick meeting >indicated above. >-- Kwok -- > > > > > >_______________________________________________ >PCN mailing 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 Mar 21 13:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4f5-0007hW-Lj; Wed, 21 Mar 2007 13:31:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4f3-0007a4-Kj for pcn@ietf.org; Wed, 21 Mar 2007 13:31:45 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4f0-0006Pf-W6 for pcn@ietf.org; Wed, 21 Mar 2007 13:31:45 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1D7A16E7A; Wed, 21 Mar 2007 18:31:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0FEFD74E7; Wed, 21 Mar 2007 18:31:40 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D1CFC6E7A; Wed, 21 Mar 2007 18:31:39 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l2LHVdW21344; Wed, 21 Mar 2007 18:31:39 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 2E3696F58E; Wed, 21 Mar 2007 18:27:45 +0100 (CET) Message-ID: <46016BB3.9020207@informatik.uni-wuerzburg.de> Date: Wed, 21 Mar 2007 18:30:27 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] simulation efforts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: pcn@ietf.org, "Prof. Dr. Oliver Rose" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, my Ex-colleague Oliver Rose did quite a good on video modeling in the 1990ies. You can find his PhD thesis and a zip-file with tons of traces on the following page: http://www.iai.inf.tu-dresden.de/ms/rose/rose.html Best wishes (already from home), Michael Anna Charny (acharny) wrote: > Hello Ken, > > A few notes on simulation models we used. Given that the charter > constrains us to non-elastic real-time traffic, we concentrated on > modeling voip and video only. > > 1) Voip *packet* arrivals: we have simulated a subset of actual > encodings and plan to simulate other encodings as well as their mix. So > for *packet* arrival models for voip we seem to be in reasonable shape. > There are also a few papers suggesting how to model aggregate voip > traffic - but we have not done so because our interest has been in > simulating specific call reaction to pcn rather than aggregate voip > queuing in the core. > > 2) Voip *call* arrivals: > For voice call arrivals Poisson seems not an unreasonable assumption, > based on the classic telephony experience. Of course things may change > with voip, but we have not found any studies that argued for a > non-Poisson *call* arrival models for voice. To be on the safe side we > also tried what we called "Batch Poisson" - Poisson arrivals for some of > our simulations (a burstier-than Poisson model when a batch of flows > arrive near-simultaneously, but the batches arrive according to the > Poisson)- and our intent is to expand the simulation study to cover a > broader range of "batch sizes" traffic types. If anyone is aware of any > study that suggests other voip *call* arrival distributions please do > let us know. > > 3) Video *packet* arrivals: > There is a vast amount of work on modeling video packet arrival models. > We did not get to simulating any of those, but we did not use Poisson > packet arrival assumption either. Instead, we used real video traces, > and we also simulated an extremely rough on-off traffic model with an > MPEG-2-like peak-to-mean ratio, with exponentially distributed on-off > intervals. It is clearly not a reasonable video model, but it likely to > be more challenging for the algorithms and was used as a stress-test. > Our plan is to find more real video traces for simulation. > > 4) It is less clear what a reasonable models for video *call* arrivals > are and we would appreciate any pointers on that. We used Poisson call > arrivals for video simply for the lack of clarity of what a better model > might be and for the lack of time to try anything else. Unlike studies > of packet arrival models for video, we did not find any that studied > *session/call* arrival distributions. If we just missed the relevant > work, please do let us know. > > Any specific input to simulation assumptions is very welcome. In > general, this simulation effort is quite time-consuming, so more > volunteers in the WG to share the work would be very welcome. > > Anna > > >> -----Original Message----- >> From: ken carlberg [mailto:carlberg@g11.org.uk] >> Sent: Wednesday, March 21, 2007 5:27 AM >> To: pcn@ietf.org >> Subject: [PCN] simulation efforts >> >> One thing that occurred to me after seeing the simulation >> presentations is that if these efforts are relying on Poisson >> to represent inter-arrival rates, it would be nice if they >> could use other representations. the journal papers of the >> last few years having been using other strategies (self >> similar, brown noise, heavy >> tail) and so our confidence level in the results would >> improve if something other than poisson is used. >> >> cheers, >> >> -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 > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 21 21:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUC7o-0008H8-7d; Wed, 21 Mar 2007 21:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUC7m-0008Fk-1l for pcn@ietf.org; Wed, 21 Mar 2007 21:29:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUC6F-0001v0-9C for pcn@ietf.org; Wed, 21 Mar 2007 21:28:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 21:28:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2M1SJb5023017; Wed, 21 Mar 2007 21:28:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2M1SIlG022038; Thu, 22 Mar 2007 01:28:18 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 21:28:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] simulation efforts Date: Wed, 21 Mar 2007 21:28:16 -0400 Message-ID: In-Reply-To: <46016BB3.9020207@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] simulation efforts thread-index: Acdr3s2dJhv4bwgKS1a6lzv4FP+UsgAQXzQQ From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 22 Mar 2007 01:28:18.0156 (UTC) FILETIME=[5EAE72C0:01C76C21] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5892; t=1174526899; x=1175390899; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20\(acharny\)=22=20 |Subject:=20RE=3A=20[PCN]=20simulation=20efforts |Sender:=20 |To:=20; bh=uYJGGl2gI+M8MCn+E3JfMMSLxPLH5pil3gZzxtcmCck=; b=sKrCHtiVyhVmaQl8gWZ6oj45tt3PcljNBOS4mglHTIK86B9WICqhdaUDB3k8Bm7G0o/jBb/6 bhvWImzlIUHl19GM9pK1i5JaprRK2DljN6+Mo7+uhZ4FQ66L87TmHtq0; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: pcn@ietf.org, "Prof. Dr. Oliver Rose" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Michael, Thank you for the pointers. We do keep Oliver Rose's traces in mind for the future use - for the moment we have been using MPEG-4 traces from http://www.tkn.tu-berlin.de/research/trace/trace.html. One thing to note is that to the best of my knowledge, Oliver Rose's work is not about modelling video *flow arrivals* - rather it is about modelling traffic within a video flow. However, it is the flow arrival model that we are missing (as I mentioned, in the absense of better knowledge we have been using Poisson and plan to use Poisson burst arrival (BATCH) for video flow arrival).=20 Thank you also for the introduction to Oliver Rose. Oliver, we would appreciate any insight you might share regarding video *flow* arrival models. Thank you in advance, Anna=20 > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 > Sent: Wednesday, March 21, 2007 1:30 PM > To: Anna Charny (acharny) > Cc: ken carlberg; pcn@ietf.org; Prof. Dr. Oliver Rose > Subject: Re: [PCN] simulation efforts >=20 > Hi Anna, >=20 > my Ex-colleague Oliver Rose did quite a good on video=20 > modeling in the 1990ies. You can find his PhD thesis and a=20 > zip-file with tons of traces on the following page: > http://www.iai.inf.tu-dresden.de/ms/rose/rose.html >=20 > Best wishes (already from home), >=20 > Michael >=20 > Anna Charny (acharny) wrote: > > Hello Ken, > > > > A few notes on simulation models we used. Given that the charter=20 > > constrains us to non-elastic real-time traffic, we concentrated on=20 > > modeling voip and video only. > > > > 1) Voip *packet* arrivals: we have simulated a subset of actual=20 > > encodings and plan to simulate other encodings as well as=20 > their mix. =20 > > So for *packet* arrival models for voip we seem to be in=20 > reasonable shape. > > There are also a few papers suggesting how to model aggregate voip=20 > > traffic - but we have not done so because our interest has been in=20 > > simulating specific call reaction to pcn rather than aggregate voip=20 > > queuing in the core. > > > > 2) Voip *call* arrivals:=20 > > For voice call arrivals Poisson seems not an unreasonable=20 > assumption,=20 > > based on the classic telephony experience. Of course things=20 > may change=20 > > with voip, but we have not found any studies that argued for a=20 > > non-Poisson *call* arrival models for voice. To be on the=20 > safe side=20 > > we also tried what we called "Batch Poisson" - Poisson arrivals for=20 > > some of our simulations (a burstier-than Poisson model when=20 > a batch of=20 > > flows arrive near-simultaneously, but the batches arrive=20 > according to=20 > > the > > Poisson)- and our intent is to expand the simulation study=20 > to cover a=20 > > broader range of "batch sizes" traffic types. If anyone is=20 > aware of=20 > > any study that suggests other voip *call* arrival distributions=20 > > please do let us know. > > > > 3) Video *packet* arrivals: > > There is a vast amount of work on modeling video packet=20 > arrival models. > > We did not get to simulating any of those, but we did not=20 > use Poisson=20 > > packet arrival assumption either. Instead, we used real=20 > video traces,=20 > > and we also simulated an extremely rough on-off traffic=20 > model with an=20 > > MPEG-2-like peak-to-mean ratio, with exponentially=20 > distributed on-off=20 > > intervals. It is clearly not a reasonable video model, but=20 > it likely=20 > > to be more challenging for the algorithms and was used as a=20 > stress-test. > > Our plan is to find more real video traces for simulation. > > > > 4) It is less clear what a reasonable models for video=20 > *call* arrivals=20 > > are and we would appreciate any pointers on that. We used Poisson=20 > > call arrivals for video simply for the lack of clarity of what a=20 > > better model might be and for the lack of time to try=20 > anything else. =20 > > Unlike studies of packet arrival models for video, we did=20 > not find any=20 > > that studied > > *session/call* arrival distributions. If we just missed the=20 > relevant=20 > > work, please do let us know. > > > > Any specific input to simulation assumptions is very welcome. In=20 > > general, this simulation effort is quite time-consuming, so more=20 > > volunteers in the WG to share the work would be very welcome. > > > > Anna > > > > =20 > >> -----Original Message----- > >> From: ken carlberg [mailto:carlberg@g11.org.uk] > >> Sent: Wednesday, March 21, 2007 5:27 AM > >> To: pcn@ietf.org > >> Subject: [PCN] simulation efforts > >> > >> One thing that occurred to me after seeing the simulation=20 > >> presentations is that if these efforts are relying on Poisson to=20 > >> represent inter-arrival rates, it would be nice if they could use=20 > >> other representations. the journal papers of the last few years=20 > >> having been using other strategies (self similar, brown=20 > noise, heavy > >> tail) and so our confidence level in the results would improve if=20 > >> something other than poisson is used. > >> > >> cheers, > >> > >> -ken > >> > >> > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pcn > >> > >> =20 > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > =20 >=20 > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am=20 > Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 22 03:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUI0P-00019V-Le; Thu, 22 Mar 2007 03:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUI0O-00019Q-Ej for pcn@ietf.org; Thu, 22 Mar 2007 03:46:40 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUI0L-0004gm-Dt for pcn@ietf.org; Thu, 22 Mar 2007 03:46:40 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8FA396B1B; Thu, 22 Mar 2007 08:46:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 81F456B34; Thu, 22 Mar 2007 08:46:36 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 42EA66B1B; Thu, 22 Mar 2007 08:46:36 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l2M7kaW26413; Thu, 22 Mar 2007 08:46:36 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id D99C96F58E; Thu, 22 Mar 2007 08:42:41 +0100 (CET) Message-ID: <46023413.5040805@informatik.uni-wuerzburg.de> Date: Thu, 22 Mar 2007 08:45:23 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] simulation efforts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: pcn@ietf.org, "Prof. Dr. Oliver Rose" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Anna, Anna Charny (acharny) wrote: > Hello Michael, > > Thank you for the pointers. We do keep Oliver Rose's traces in mind for > the future use - for the moment we have been using MPEG-4 traces from > http://www.tkn.tu-berlin.de/research/trace/trace.html. > > One thing to note is that to the best of my knowledge, Oliver Rose's > work is not about modelling video *flow arrivals* - rather it is about > modelling traffic within a video flow. Yes, that's true. As far as I know Oliver developed a model to generate artificial traffic having the same statistical properties (including inter-frame correlations) as video traffic. That's nice for simulations as it avoids artifacts due to repetitions of the same video trace. > However, it is the flow arrival > model that we are missing (as I mentioned, in the absense of better > knowledge we have been using Poisson and plan to use Poisson burst > arrival (BATCH) for video flow arrival). > I think whatever we assume is not realistic. I would use an arrival process that allows a simple parameterization of the burstiness. This yields if-then-results and doesn't pretend to capture the reality by the simulation of a "typical video arrival process". So you might go either with a batch arrival process for videos (but these are already artificially strong flash crowds) or you might use a Gamma-distributed interarrival time as this allows you to control its mean and variance independently of each other without having arrivals that exactly the same time. For a suitable choice of the parameters you get Poisson arrivals. > Thank you also for the introduction to Oliver Rose. Oliver, we would > appreciate any insight you might share regarding video *flow* arrival > models. > He didn't do that. Best wishes, Michael > Thank you in advance, > Anna > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: Wednesday, March 21, 2007 1:30 PM >> To: Anna Charny (acharny) >> Cc: ken carlberg; pcn@ietf.org; Prof. Dr. Oliver Rose >> Subject: Re: [PCN] simulation efforts >> >> Hi Anna, >> >> my Ex-colleague Oliver Rose did quite a good on video >> modeling in the 1990ies. You can find his PhD thesis and a >> zip-file with tons of traces on the following page: >> http://www.iai.inf.tu-dresden.de/ms/rose/rose.html >> >> Best wishes (already from home), >> >> Michael >> >> Anna Charny (acharny) wrote: >> >>> Hello Ken, >>> >>> A few notes on simulation models we used. Given that the charter >>> constrains us to non-elastic real-time traffic, we concentrated on >>> modeling voip and video only. >>> >>> 1) Voip *packet* arrivals: we have simulated a subset of actual >>> encodings and plan to simulate other encodings as well as >>> >> their mix. >> >>> So for *packet* arrival models for voip we seem to be in >>> >> reasonable shape. >> >>> There are also a few papers suggesting how to model aggregate voip >>> traffic - but we have not done so because our interest has been in >>> simulating specific call reaction to pcn rather than aggregate voip >>> queuing in the core. >>> >>> 2) Voip *call* arrivals: >>> For voice call arrivals Poisson seems not an unreasonable >>> >> assumption, >> >>> based on the classic telephony experience. Of course things >>> >> may change >> >>> with voip, but we have not found any studies that argued for a >>> non-Poisson *call* arrival models for voice. To be on the >>> >> safe side >> >>> we also tried what we called "Batch Poisson" - Poisson arrivals for >>> some of our simulations (a burstier-than Poisson model when >>> >> a batch of >> >>> flows arrive near-simultaneously, but the batches arrive >>> >> according to >> >>> the >>> Poisson)- and our intent is to expand the simulation study >>> >> to cover a >> >>> broader range of "batch sizes" traffic types. If anyone is >>> >> aware of >> >>> any study that suggests other voip *call* arrival distributions >>> please do let us know. >>> >>> 3) Video *packet* arrivals: >>> There is a vast amount of work on modeling video packet >>> >> arrival models. >> >>> We did not get to simulating any of those, but we did not >>> >> use Poisson >> >>> packet arrival assumption either. Instead, we used real >>> >> video traces, >> >>> and we also simulated an extremely rough on-off traffic >>> >> model with an >> >>> MPEG-2-like peak-to-mean ratio, with exponentially >>> >> distributed on-off >> >>> intervals. It is clearly not a reasonable video model, but >>> >> it likely >> >>> to be more challenging for the algorithms and was used as a >>> >> stress-test. >> >>> Our plan is to find more real video traces for simulation. >>> >>> 4) It is less clear what a reasonable models for video >>> >> *call* arrivals >> >>> are and we would appreciate any pointers on that. We used Poisson >>> call arrivals for video simply for the lack of clarity of what a >>> better model might be and for the lack of time to try >>> >> anything else. >> >>> Unlike studies of packet arrival models for video, we did >>> >> not find any >> >>> that studied >>> *session/call* arrival distributions. If we just missed the >>> >> relevant >> >>> work, please do let us know. >>> >>> Any specific input to simulation assumptions is very welcome. In >>> general, this simulation effort is quite time-consuming, so more >>> volunteers in the WG to share the work would be very welcome. >>> >>> Anna >>> >>> >>> >>>> -----Original Message----- >>>> From: ken carlberg [mailto:carlberg@g11.org.uk] >>>> Sent: Wednesday, March 21, 2007 5:27 AM >>>> To: pcn@ietf.org >>>> Subject: [PCN] simulation efforts >>>> >>>> One thing that occurred to me after seeing the simulation >>>> presentations is that if these efforts are relying on Poisson to >>>> represent inter-arrival rates, it would be nice if they could use >>>> other representations. the journal papers of the last few years >>>> having been using other strategies (self similar, brown >>>> >> noise, heavy >> >>>> tail) and so our confidence level in the results would improve if >>>> something other than poisson is used. >>>> >>>> cheers, >>>> >>>> -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 >>> >>> >> -- >> Dr. Michael Menth, Assistant Professor >> University of Wuerzburg, Institute of Computer Science Am >> Hubland, D-97074 Wuerzburg, Germany, room B206 >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 22 05:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJd1-0008BX-HJ; Thu, 22 Mar 2007 05:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJd0-0008As-HB for pcn@ietf.org; Thu, 22 Mar 2007 05:30:38 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJcz-0002hC-2o for pcn@ietf.org; Thu, 22 Mar 2007 05:30:38 -0400 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l2M9UVRB011074; Thu, 22 Mar 2007 10:30:35 +0100 (MET) Received: from 130.129.20.233 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 22 Mar 2007 09:30:31 +0000 To: "Kwok-Ho Chan" , "pcn@ietf.org" Subject: Re: [PCN] PCN WG work items for Nov 2007 Date: Thu, 22 Mar 2007 09:30:30 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <5FNPs4wI.1174555830.9439340.karagian@ewi.utwente.nl> In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.06 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 22 Mar 2007 10:30:36 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Kwok Thanks, I will be there! Best regards, Georgios On 3/21/2007, "Kwok-Ho Chan" wrote: >Bob's Pre-BoF on Re-ECN over-ran and most of the people are in this Pre-BoF. >But we also have people that need to leave. >Hence we need to re-schedule our working meeting to tomorrow: >When: Thur March 22, 2007 17:00 >Where: IETF Registration Desk > >Sorry for this re-scheduling, but most of the attendees are impacted >because they are in this Re-ECN Pre-BoF. >Thanks! >-- Kwok -- > >At 10:18 AM 3/21/2007, Kwok-Ho Chan wrote: >>Hi all: >>Since the Monday PCN WG session at Prague IETF, couple of people >>have approached me informally on the hall way, during breaks, etc, >>indicated they would like to help in the PCN work items. >> >>I have talked to Steven (but did not get a chance to talk to Scott yet) >>on holding a quick meeting while most of us are at Prague, >>to get the work on the first couple of PCN WG work items started. >>Steven have given his support on this. >> >>Hence how about a quick meeting: >>When: Wed March 21, 2007 16:30 (20 minutes into the cookie break) >>Where: IETF Registration Desk >> >>This will give us half an hour to talk before Plenary starts. >>Notice we may overflow into the Plenary if necessary. >> >>The topic will be to get a good sense on who wants to do what and >>how we may divide and focus on the different pieces. >> >>For people who can not attend, please send mail to the PCN list, >>Chairs, or myself >>if you choose to, on your interest and what, how you may want to help. >> >>Thank you for all the energy and interest and hope to see you at the >>quick meeting >>indicated above. >>-- Kwok -- >> >> >> >> >> >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www1.ietf.org/mailman/listinfo/pcn > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 22 06:01:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK78-0001Ul-Cv; Thu, 22 Mar 2007 06:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK77-0001UX-Fo for pcn@ietf.org; Thu, 22 Mar 2007 06:01:45 -0400 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 1HUK6w-000416-Ee for pcn@ietf.org; Thu, 22 Mar 2007 06:01:45 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MA19Mb006546; Thu, 22 Mar 2007 12:01:32 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 12:01:15 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 12:01:15 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 12:01:15 +0200 Received: from [130.129.23.111] (essapo-nirac252166.europe.nokia.com [10.162.252.166]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MA1DMT009051; Thu, 22 Mar 2007 12:01:13 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1AAA48E0-B6D8-44BC-8754-03A9EB507805@nokia.com> From: Lars Eggert Subject: Re: [PCN] PCN WG work items for Nov 2007 Date: Thu, 22 Mar 2007 11:01:10 +0100 To: ext Kwok-Ho Chan X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Mar 2007 10:01:15.0677 (UTC) FILETIME=[078374D0:01C76C69] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070322120132-13881BB0-3639E90E/0-0/0-1 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="===============0131332899==" Errors-To: pcn-bounces@ietf.org --===============0131332899== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-104-829458996; protocol="application/pkcs7-signature" --Apple-Mail-104-829458996 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-21, at 17:08, ext Kwok-Ho Chan wrote: > Hence we need to re-schedule our working meeting to tomorrow: > When: Thur March 22, 2007 17:00 > Where: IETF Registration Desk I'd like to attend, but overlapping with the plenary is highly problematic. Lars --Apple-Mail-104-829458996 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjIxMDAxMTFaMCMGCSqGSIb3DQEJBDEWBBRb8G2LmcSKQH3l elH7B2nvlcWxjzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAY1cCF6RWwTG8ohmNw7d+NVl02xIkk6f2y4kX/e5+jtjMG4lSzTXr 6wQRiEDuSy8zaksxoieYnvB3PzDfK10cm/aNiBBSn5PPpMcusMYxLcjmYDYSnbJZvULZL6nXcgof O8ICxIZv4x344OkInJJyl7eCKPvaBaxd4VXaOsh+uUA135jnpxpC3FMR2g75VgB8xhwPwu4SkuzC xVtoa3Pcc6LnGcR0rBStxNFQR0CjidxHeq4bmaA6bKSwPriJQFeBWnl43BkzCytKNtr7Pm79LfV7 BtZhNAZU0FWerDeT5P9Ql3cKkWS/uubPrph2wVuMFArQF7g9SlcAHBak3EhUygAAAAAAAA== --Apple-Mail-104-829458996-- --===============0131332899== 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 --===============0131332899==-- From pcn-bounces@ietf.org Thu Mar 22 07:30:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULUu-0008JD-Qb; Thu, 22 Mar 2007 07:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULUs-0008It-JZ for pcn@ietf.org; Thu, 22 Mar 2007 07:30:22 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULUr-0002rL-8l for pcn@ietf.org; Thu, 22 Mar 2007 07:30:22 -0400 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 l2MBUJw11607; Thu, 22 Mar 2007 11:30:19 GMT Received: from KCHAN-2K3.nortel.com ([47.165.251.15] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 07:30:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 12:30:16 +0100 To: Lars Eggert From: "Kwok-Ho Chan" Subject: Re: [PCN] PCN WG work items for Nov 2007 In-Reply-To: <1AAA48E0-B6D8-44BC-8754-03A9EB507805@nokia.com> References: <1AAA48E0-B6D8-44BC-8754-03A9EB507805@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 22 Mar 2007 11:30:18.0708 (UTC) FILETIME=[78354940:01C76C75] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars and all: The time selection was to minimize scheduling conflict and based on suggestions I received. I think we can easily give up some cookie time and start this meeting 10 minutes after the second TSVWG session today. Hence the latest (hopefully last) re-schedule for our working meeting: When: Thur March 22, 2007 16:20 ( TODAY ) Where: IETF Registration Desk I am thinking of moving to one of the seating areas to the right of the IETF Registration desk (close to the Lower Level entrance where we boarded the bus for the social) for our discussion, so if you arrive late and don't see us at the IETF Registration Desk, come look for us there. This should give Lars 10 minutes to talk to people after TSVWG and 10 minutes for the rest of us to get cookies. (Lars, let us know if you want us to reserve a cookie or two for you). If the meeting last more than 40 minutes, Lars will at least get some overview of what is going on. Sorry for some of these last minute scheduling changes. -- Kwok -- At 11:01 AM 3/22/2007, Lars Eggert wrote: >On 2007-3-21, at 17:08, ext Kwok-Ho Chan wrote: >>Hence we need to re-schedule our working meeting to tomorrow: >>When: Thur March 22, 2007 17:00 >>Where: IETF Registration Desk > >I'd like to attend, but overlapping with the plenary is highly >problematic. > >Lars > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 22 08:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUM3U-0008Bb-NG; Thu, 22 Mar 2007 08:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUM3Q-0007yM-5C for pcn@ietf.org; Thu, 22 Mar 2007 08:06:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULz5-0002gd-IV for pcn@ietf.org; Thu, 22 Mar 2007 08:01:41 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2MC1Pg14189; Thu, 22 Mar 2007 12:01:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] simulation efforts Date: Thu, 22 Mar 2007 08:01:23 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F4FFC8E@zcarhxm1.corp.nortel.com> In-Reply-To: <46023413.5040805@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] simulation efforts Thread-Index: AcdsVlezqlIl9qhqR+2v+OUEG+LMugAGvI9A From: "Jozef Babiarz" To: , "Anna Charny \(acharny\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: Xiao-Gao Liu , pcn@ietf.org, "Prof. Dr. Oliver Rose" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Anna, Michael, The video source model we used in our simulation is based on video streaming model 1 from B. Maglaris, D. Anastassiou, P. Sen, G. Karlsson and J. Robbins, "Performance Models of Statistical Multiplexing in Packet Video Communications", IEEE Transactions on Communications, 36, pp. 834-844, July 1988. The selection of this model is for its simplicity and ability to approximate the burstness and dependence of the video source. The simulation is not required and does not attempt to model accurate video codec processing. For more details see page 53 http://standards.nortel.com/pcn/Simulation_EPCN.pdf This model assumes that the video source will generate constantly f frames per second with each frame of a fixed size of p non-compressed pixels, and the compressed bits per pixel of the frames can be modeled by a first-order autoregressive Markov process with sequence of independent Gaussian random variables with configured mean and variance. In our simulation, the original parameters from the paper are used for now, while, parameters f and p are configurable. The paper suggests that with the original parameters, a bell-like shaped distribution is produced. From simulation, it is found that the peak data rate is about 1.5 times of what is estimated using the Gaussian assumption. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: March 22, 2007 3:45 AM To: Anna Charny (acharny) Cc: pcn@ietf.org; Prof. Dr. Oliver Rose Subject: Re: [PCN] simulation efforts Hello Anna, Anna Charny (acharny) wrote: > Hello Michael, > > Thank you for the pointers. We do keep Oliver Rose's traces in mind for > the future use - for the moment we have been using MPEG-4 traces from > http://www.tkn.tu-berlin.de/research/trace/trace.html. > > One thing to note is that to the best of my knowledge, Oliver Rose's > work is not about modelling video *flow arrivals* - rather it is about > modelling traffic within a video flow. =20 Yes, that's true. As far as I know Oliver developed a model to generate=20 artificial traffic having the same statistical properties (including=20 inter-frame correlations) as video traffic. That's nice for simulations=20 as it avoids artifacts due to repetitions of the same video trace. > However, it is the flow arrival > model that we are missing (as I mentioned, in the absense of better > knowledge we have been using Poisson and plan to use Poisson burst > arrival (BATCH) for video flow arrival).=20 > =20 I think whatever we assume is not realistic. I would use an arrival=20 process that allows a simple parameterization of the burstiness. This=20 yields if-then-results and doesn't pretend to capture the reality by the simulation of a "typical video arrival process". So you might go either=20 with a batch arrival process for videos (but these are already=20 artificially strong flash crowds) or you might use a Gamma-distributed=20 interarrival time as this allows you to control its mean and variance=20 independently of each other without having arrivals that exactly the=20 same time. For a suitable choice of the parameters you get Poisson arrivals. > Thank you also for the introduction to Oliver Rose. Oliver, we would > appreciate any insight you might share regarding video *flow* arrival > models. > =20 He didn't do that. Best wishes, Michael > Thank you in advance, > Anna=20 > > =20 >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 >> Sent: Wednesday, March 21, 2007 1:30 PM >> To: Anna Charny (acharny) >> Cc: ken carlberg; pcn@ietf.org; Prof. Dr. Oliver Rose >> Subject: Re: [PCN] simulation efforts >> >> Hi Anna, >> >> my Ex-colleague Oliver Rose did quite a good on video=20 >> modeling in the 1990ies. You can find his PhD thesis and a=20 >> zip-file with tons of traces on the following page: >> http://www.iai.inf.tu-dresden.de/ms/rose/rose.html >> >> Best wishes (already from home), >> >> Michael >> >> Anna Charny (acharny) wrote: >> =20 >>> Hello Ken, >>> >>> A few notes on simulation models we used. Given that the charter=20 >>> constrains us to non-elastic real-time traffic, we concentrated on=20 >>> modeling voip and video only. >>> >>> 1) Voip *packet* arrivals: we have simulated a subset of actual=20 >>> encodings and plan to simulate other encodings as well as=20 >>> =20 >> their mix. =20 >> =20 >>> So for *packet* arrival models for voip we seem to be in=20 >>> =20 >> reasonable shape. >> =20 >>> There are also a few papers suggesting how to model aggregate voip=20 >>> traffic - but we have not done so because our interest has been in=20 >>> simulating specific call reaction to pcn rather than aggregate voip=20 >>> queuing in the core. >>> >>> 2) Voip *call* arrivals:=20 >>> For voice call arrivals Poisson seems not an unreasonable=20 >>> =20 >> assumption,=20 >> =20 >>> based on the classic telephony experience. Of course things=20 >>> =20 >> may change=20 >> =20 >>> with voip, but we have not found any studies that argued for a=20 >>> non-Poisson *call* arrival models for voice. To be on the=20 >>> =20 >> safe side=20 >> =20 >>> we also tried what we called "Batch Poisson" - Poisson arrivals for=20 >>> some of our simulations (a burstier-than Poisson model when=20 >>> =20 >> a batch of=20 >> =20 >>> flows arrive near-simultaneously, but the batches arrive=20 >>> =20 >> according to=20 >> =20 >>> the >>> Poisson)- and our intent is to expand the simulation study=20 >>> =20 >> to cover a=20 >> =20 >>> broader range of "batch sizes" traffic types. If anyone is=20 >>> =20 >> aware of=20 >> =20 >>> any study that suggests other voip *call* arrival distributions=20 >>> please do let us know. >>> >>> 3) Video *packet* arrivals: >>> There is a vast amount of work on modeling video packet=20 >>> =20 >> arrival models. >> =20 >>> We did not get to simulating any of those, but we did not=20 >>> =20 >> use Poisson=20 >> =20 >>> packet arrival assumption either. Instead, we used real=20 >>> =20 >> video traces,=20 >> =20 >>> and we also simulated an extremely rough on-off traffic=20 >>> =20 >> model with an=20 >> =20 >>> MPEG-2-like peak-to-mean ratio, with exponentially=20 >>> =20 >> distributed on-off=20 >> =20 >>> intervals. It is clearly not a reasonable video model, but=20 >>> =20 >> it likely=20 >> =20 >>> to be more challenging for the algorithms and was used as a=20 >>> =20 >> stress-test. >> =20 >>> Our plan is to find more real video traces for simulation. >>> >>> 4) It is less clear what a reasonable models for video=20 >>> =20 >> *call* arrivals=20 >> =20 >>> are and we would appreciate any pointers on that. We used Poisson=20 >>> call arrivals for video simply for the lack of clarity of what a=20 >>> better model might be and for the lack of time to try=20 >>> =20 >> anything else. =20 >> =20 >>> Unlike studies of packet arrival models for video, we did=20 >>> =20 >> not find any=20 >> =20 >>> that studied >>> *session/call* arrival distributions. If we just missed the=20 >>> =20 >> relevant=20 >> =20 >>> work, please do let us know. >>> >>> Any specific input to simulation assumptions is very welcome. In=20 >>> general, this simulation effort is quite time-consuming, so more=20 >>> volunteers in the WG to share the work would be very welcome. >>> >>> Anna >>> >>> =20 >>> =20 >>>> -----Original Message----- >>>> From: ken carlberg [mailto:carlberg@g11.org.uk] >>>> Sent: Wednesday, March 21, 2007 5:27 AM >>>> To: pcn@ietf.org >>>> Subject: [PCN] simulation efforts >>>> >>>> One thing that occurred to me after seeing the simulation=20 >>>> presentations is that if these efforts are relying on Poisson to=20 >>>> represent inter-arrival rates, it would be nice if they could use=20 >>>> other representations. the journal papers of the last few years=20 >>>> having been using other strategies (self similar, brown=20 >>>> =20 >> noise, heavy >> =20 >>>> tail) and so our confidence level in the results would improve if=20 >>>> something other than poisson is used. >>>> >>>> cheers, >>>> >>>> -ken >>>> >>>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pcn >>>> >>>> =20 >>>> =20 >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pcn >>> =20 >>> =20 >> -- >> Dr. Michael Menth, Assistant Professor >> University of Wuerzburg, Institute of Computer Science Am=20 >> Hubland, D-97074 Wuerzburg, Germany, room B206 >> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> =20 --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 29 13:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWytl-0003CT-Vy; Thu, 29 Mar 2007 13:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWytj-00032h-5O for pcn@ietf.org; Thu, 29 Mar 2007 13:58:55 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWyth-0005gj-E5 for pcn@ietf.org; Thu, 29 Mar 2007 13:58:55 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l2THwUG25296 for ; Thu, 29 Mar 2007 17:58:30 GMT Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 13:58:40 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Mar 2007 13:58:38 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Mar 2007 17:58:40.0068 (UTC) FILETIME=[E1CAE840:01C7722B] X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Subject: [PCN] Kwok's notes for Thur 03/22/07 Mtg on PCN WG Initial Work Items X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: We held the meeting mentioned (attached original E-Mail) on Thur March 22, 2007 16:30 (Prague time). We had a fruitful meeting. Please see my meeting notes below for details. Please correct/add-to/delete-from the meeting notes as I may have mis-interpreted, missed some points discussed during our meeting. Attendees: please check your names+e-mail, I may have made mistakes reading your writing on the attendees sheet. We welcome additional volunteers who want to add their name to the volunteers list. Thanks! -- Kwok -- Kwok's Notes on the PCN Work Item Meeting on Thur March 22, 2007 @ Prague Attendees: Kwok Ho Chan (khchan@nortel.com), Tina Tsou (tena@huawei.com), Ken Young (keny@gridpointsystems.com), Etsushi Ohyama (ohyama@ntt-at.ac.jp) Michael Scharf (michael.scharf@ihr.uni-stuttgart.de), Joe Babiarz (babiarz@nortel.com) Shoichi Senda (s.senda@ntt-at.co.jp), Ruediger Geib (ruediger.geib@t-systems.com) Michael Menth (menth@informatik.uni-wuerzburg.de) (not present but wanted to help) Georgios Karagiannis (karagian@cs.utwente.nl), Philip Eardley (philip.eardley@bt.com) Anna Charny (acharny@cisco.com), Bob Briscoe (bob.briscoe@bt.com) Lars Eggert (lars.eggert@nokia.com) (attended the first half) Meeting Notes: We held this quick meeting for doing a start of the initial PCN WG work items: 1. "Flow Admission and Termination Architecture within a Diffserv Domain", Informational RFC, Nov 2007. 2. "Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain", Informational RFC, Nov 2007. 3. "(Pre-)Congestion Detection within a DiffServ Domain", Proposed Standard RFC, Mar 2008. Discussion Results: For "Flow Admission and Termination Architecture within a Diffserv Domain": - We want this document to be at a high level, somewhere between the current Problem Statement draft and the CL Arch draft. - List of volunteers interested to work on this draft: Kwok Ho Chan, Tina Tsou, Ken Young, Joe Babiarz, Ruediger Geib, Micheal Menth, Philip Eardley, Anna Charny - Action Items: 1. Philip Eardley to take architectural sections from the current CL-Arch draft and Problem Statement draft to create the first cut of the new WG work item #1. This is to be at a high level and should avoid the specific deployment model from the CL-Arch draft. 2. Kwok Ho Chan to create the initial Terminology Section for the WG work item #1. During our meeting, we determined we should try to have the terminology be part of the Architecture document to start, and move it to another draft later if we need to. We should try to keep the terminology section short and try to reuse previously defined terms whenever possible. 3. The above action items should be completed in April 2007. All volunteers for WG work item #1 (and others) should review/comment/add-to the first cut version. - Goal: We should have the second version (-01) ready for WG review before Chicago (69th) IETF. For "Survey of Encoding and Transport Choices of (Pre-)Congestion Information within a DiffServ Domain": - Need to have the Chairs clarify the meaning of "Transport Choices" for this WG work item. May want to start by having a discussion of this on the WG list. - Need to work closely with Sally Floyd on this. Need to use Sally's RFC on this topic as guidance. - List of volunteers interested to work on this draft: Kwok Ho Chan, Joe Babiarz, Georgios Karagiannis, Anna Charny - Action Items: 1. Georgios Karagiannis to take the Appendix C of current CL-PHB draft and create the first cut of the new WG work item #2. 2. All volunteers for WG work item #2 (and others) should review/comment/add-to the first cut version. - Goal: We should at least have the first version (-00) ready for WG review before Chicago (69th) IETF. For "(Pre-)Congestion Detection within a DiffServ Domain": - We agreed this work item milestone is the hardest one to meet because of the technical complexity and detail work required to execute this work item correctly. - During our discussion, we have identified that we may need another draft (a new WG Work Item) for the successful execution of this work item. A draft on Criteria for Comparison of the different methods of "(Pre-)Congestion Detection". - Joe Babiarz indicated there is a (Pre)Congestion Admission Control Detection draft (companion to the Explicit Marking (for Flow Termination/Pre-emption) draft) coming. - Need to indicate/include dependencies between Detection and Encoding. - Action Items: 1. Anna Charny to create the first cut of the "Criteria for Comparing Detection Methods" draft. Each methods' authors will provide Anna with list of criteria each thinks is needed. I think someone called this the "beauty contest rules" draft. :) Goal: Have at least the first version (-00) of this new draft ready before the Chicago (69th) IETF. 2. All "(Pre-)Congestion Detection Method" authors should continue to improve on their individual drafts. 3. Geogios Karagiannis, Shoichi Senda, and others may want to consider adding other Detection Method drafts. - Goal: Get the process started early for this difficult milestone. End of Kwok's Notes on the PCN Work Item Meeting on Thur March 22, 2007 @ Prague. At 12:18 AM 3/21/2007, Kwok-Ho Chan wrote: >Hi all: >Since the Monday PCN WG session at Prague IETF, couple of people >have approached me informally on the hall way, during breaks, etc, >indicated they would like to help in the PCN work items. > >I have talked to Steven (but did not get a chance to talk to Scott yet) >on holding a quick meeting while most of us are at Prague, >to get the work on the first couple of PCN WG work items started. >Steven have given his support on this. > >Hence how about a quick meeting: >When: Wed March 21, 2007 16:30 (20 minutes into the cookie break) >Where: IETF Registration Desk > >This will give us half an hour to talk before Plenary starts. >Notice we may overflow into the Plenary if necessary. > >The topic will be to get a good sense on who wants to do what and >how we may divide and focus on the different pieces. > >For people who can not attend, please send mail to the PCN list, >Chairs, or myself >if you choose to, on your interest and what, how you may want to help. > >Thank you for all the energy and interest and hope to see you at the >quick meeting >indicated above. >-- Kwok -- > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn