From fqhuang@huawei.com Tue Nov 3 01:45:16 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915473A687D for ; Tue, 3 Nov 2009 01:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIkOYEMsLCx4 for ; Tue, 3 Nov 2009 01:45:15 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7B5E73A6821 for ; Tue, 3 Nov 2009 01:45:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSJ00HNS1J2J8@szxga04-in.huawei.com> for pcn@ietf.org; Tue, 03 Nov 2009 17:40:14 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSJ00E231J2M3@szxga04-in.huawei.com> for pcn@ietf.org; Tue, 03 Nov 2009 17:40:14 +0800 (CST) Received: from WWWE99ECC189FD (120.89.60.58.broad.sz.gd.dynamic.163data.com.cn [58.60.89.120]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSJ00MWW1IX3S@szxml01-in.huawei.com>; Tue, 03 Nov 2009 17:40:14 +0800 (CST) Date: Tue, 03 Nov 2009 17:42:24 +0800 From: Fortune HUANG In-reply-to: <003b01ca5256$af8bcbc0$810c5982@dynamic.ewi.utwente.nl> To: 'Georgios Karagiannis' , pcn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpN0Z/r453Zm4BjRm2Ch1wDOVl4ewEg3UeAAoUi/XA= References: <003b01ca5256$af8bcbc0$810c5982@dynamic.ewi.utwente.nl> Subject: Re: [PCN] New edge behaviour: draft-karagiannis-pcn-hose-edge-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:45:16 -0000 Hi Georgios, Basically, I think the HOSE model has its great advantage to solve the ECMP issue, which is well described in this draft. But I still have a comment that it should be the decision node that makes the decision to admit/block/terminate a flow. According to the PCN architecture, neither PCN-ingress-node nor PCN-egress-node contains the function of making decision. So I think the role of decision node is missing and the behaviour of making decision is misplaced in this draft. Best regards, Fortune -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Wednesday, October 21, 2009 9:59 PM To: pcn@ietf.org Subject: [PCN] New edge behaviour: draft-karagiannis-pcn-hose-edge-behaviour-00 Hi all During the last two IETF meetings I had promissed to publish the HOSE edge behaviour draft. Via the following URL you can find this draft: http://www.ietf.org/id/draft-karagiannis-pcn-hose-edge-behaviour-00.txt If you have any comments please let me know! -------------------------------------------------------- Abstract ++ Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is denoted as the HOSE model. In this document the term HOSE is referring to the aggregation of incoming traffic from all ingress edges, which is associated with one traffic class, i.e., PHB, towards one egress edge. This type of HOSE model is equivalent to the Multiple Point to Point (MP2P) type of aggregation. The HOSE model ensures bandwidth limits without the need of maintaining per each ingress and egress pair ingress-egress- aggregated states. In this case all edges maintain one aggregated state per each traffic class, i.e., PHB (Per Hop Behaviour), used in the PCN domain. Moreover, the HOSE model is able to provide solutions for the ECMP (Equal Cost Multi Path) problem for both admission control and flow termination procedures. ------------------------------------- Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Tue Nov 3 02:04:08 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFF73A698E for ; Tue, 3 Nov 2009 02:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH64NykujTIa for ; Tue, 3 Nov 2009 02:04:07 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 292133A68C6 for ; Tue, 3 Nov 2009 02:04:07 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nA3A4EaT006884; Tue, 3 Nov 2009 11:04:18 +0100 (MET) From: "Georgios Karagiannis" To: "'Fortune HUANG'" , References: <003b01ca5256$af8bcbc0$810c5982@dynamic.ewi.utwente.nl> Date: Tue, 3 Nov 2009 11:04:07 +0100 Message-ID: <001801ca5c6c$ff1a7db0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpN0Z/r453Zm4BjRm2Ch1wDOVl4ewEg3UeAAoUi/XAAAKt0oA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 03 Nov 2009 11:04:20 +0100 (MET) Subject: Re: [PCN] New edge behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 10:04:08 -0000 Hi Fortune Thank you very much for the comments! Please see in line! > -----Original Message----- > From: Fortune HUANG [mailto:fqhuang@huawei.com] > Sent: dinsdag 3 november 2009 10:42 > To: 'Georgios Karagiannis'; pcn@ietf.org > Subject: RE: [PCN] New edge > behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 > > Hi Georgios, > > Basically, I think the HOSE model has its great advantage to > solve the ECMP issue, which is well described in this draft. > > But I still have a comment that it should be the decision > node that makes the decision to admit/block/terminate a flow. > According to the PCN architecture, neither PCN-ingress-node > nor PCN-egress-node contains the function of making decision. > So I think the role of decision node is missing and the > behaviour of making decision is misplaced in this draft. Georgios: You are right, we are not emphasizing which entity is the decision point. Please note that the decision point can be either the ingress, the egress or a centralized decision point. Please note that in a future version of the draft we can clarify this, by explicitly using the notion of the decission point. Best regards, Georgios > > Best regards, > Fortune > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Wednesday, October 21, 2009 9:59 PM > To: pcn@ietf.org > Subject: [PCN] New edge behaviour: > draft-karagiannis-pcn-hose-edge-behaviour-00 > > Hi all > > During the last two IETF meetings I had promissed to publish > the HOSE edge behaviour draft. > > Via the following URL you can find this draft: > > http://www.ietf.org/id/draft-karagiannis-pcn-hose-edge-behavio ur-00.txt > > If you have any comments please let me know! > > -------------------------------------------------------- > > Abstract ++ > > Precongestion notification (PCN) is a means for protecting > quality of > service for inelastic traffic admitted to a Diffserv domain. The > overall PCN architecture is described in RFC 5559. This > memo is one > of a series describing possible boundary node behaviours for a PCN > domain. The behaviour described here is denoted as the HOSE model. > In this document the term HOSE is referring to the > aggregation of incoming traffic from all ingress edges, which is > associated with one traffic class, i.e., PHB, towards one egress > edge. This type of HOSE model is equivalent to the > Multiple Point to > Point (MP2P) type of aggregation. > > The HOSE model ensures bandwidth limits without the need of > maintaining per each ingress and egress pair ingress-egress- > aggregated states. In this case all edges maintain one aggregated > state per each traffic class, i.e., PHB (Per Hop > Behaviour), used in > the PCN domain. Moreover, the HOSE model is able to > provide solutions > for the ECMP (Equal Cost Multi Path) problem for both admission > control and flow termination procedures. > > > ------------------------------------- > > > > Best regards, > Georgios > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From slblake@petri-meat.com Wed Nov 4 06:05:55 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FE03A6923 for ; Wed, 4 Nov 2009 06:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puqn7f5IE5pK for ; Wed, 4 Nov 2009 06:05:54 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id A66E93A68F7 for ; Wed, 4 Nov 2009 06:05:54 -0800 (PST) Received: from cpe-024-211-225-123.nc.res.rr.com ([24.211.225.123]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N5gV1-0002Kx-PT for pcn@ietf.org; Wed, 04 Nov 2009 09:06:12 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-Kqkrl/3+126MdRGLXCPW" Date: Wed, 04 Nov 2009 09:06:14 -0500 Message-Id: <1257343574.4122.14.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] [Fwd: Fwd: Pre-posting of slides in Hiroshima] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:05:55 -0000 --=-Kqkrl/3+126MdRGLXCPW Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI. Please try to get me your presentation slides as early as possible (pdf preferred). Regards, // Steve --=-Kqkrl/3+126MdRGLXCPW Content-Disposition: inline Content-Description: Forwarded message - Fwd: Pre-posting of slides in Hiroshima Content-Type: message/rfc822 Return-path: Envelope-to: slblake@petri-meat.com Delivery-date: Tue, 03 Nov 2009 17:51:34 -0500 Received: from zinfandel.tools.ietf.org ([64.170.98.42]) by elom.tchmachines.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1N5SDu-00007d-MO for slblake@petri-meat.com; Tue, 03 Nov 2009 17:51:34 -0500 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N5SDR-0008MB-8U for tsv-chairs@tools.ietf.org; Tue, 03 Nov 2009 14:51:05 -0800 Received: by core3.amsl.com (Postfix, from userid 65534) id AF9A33A68F3; Tue, 3 Nov 2009 14:50:43 -0800 (PST) X-Original-To: tools-tsv-chairs@core3.amsl.com Delivered-To: tools-tsv-chairs@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9568C3A6897 for ; Tue, 3 Nov 2009 14:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP2u9VutrpbS for ; Tue, 3 Nov 2009 14:50:41 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 6F3773A63EB for ; Tue, 3 Nov 2009 14:50:41 -0800 (PST) Received: from [192.168.1.47] ([12.162.0.169]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA3MoQnK067837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 00:50:33 +0200 (EET) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Content-Type: multipart/signed; boundary=Apple-Mail-18--191458499; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 3 Nov 2009 14:50:15 -0800 References: <4B6BC7B560444DC8A96331A90B07E686@your029b8cecfe> To: tsv-chairs@ietf.org, Yoshifumi Nishida , Leslie Daigle , David Oran , Jason Livingood , Gonzalo Camarillo , yunfei zhang Message-Id: <4CC560D0-B91F-4AC8-8232-8779F8F8477C@nokia.com> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Wed, 04 Nov 2009 00:50:47 +0200 (EET) X-SA-Exim-Connect-IP: 2001:1890:1112:1::20 X-SA-Exim-Rcpt-To: tsv-chairs@tools.ietf.org X-SA-Exim-Mail-From: lars.eggert@nokia.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on zinfandel.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no version=3.2.5 Subject: Fwd: Pre-posting of slides in Hiroshima X-SA-Exim-Version: 4.2.1 (built Sat, 01 Aug 2009 12:09:26 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) --Apple-Mail-18--191458499 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, please try to do this as much as possible. Lars Begin forwarded message: > From: Adrian Farrel > Date: October 31, 2009 13:25:16 PDT > To: "wgchairs@ietf.org" > Subject: Pre-posting of slides in Hiroshima > Reply-To: Adrian Farrel > > Hi, > > We can expect a higher than normal number of people at our WG > meetings in > Hiroshima for whom English is not the first language. > > In discussions in Stockholm, the thing that Asian participants said > would be > most useful was pre-posting of the slides. This allows them to look > up any > difficult words, make notes, and follow along at their own speed. > > I know many working groups have a good record of posting slides > before their > meetings. Can I ask you all to make a special effort to get the > material > onto the IETF site ahead of your meetings (preferably at least a day > ahead) > as an act of courtesy and to ensure better discussions within your > working > groups. > > Thanks, > Adrian > --Apple-Mail-18--191458499 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzIyNTAxNlowIwYJKoZIhvcNAQkEMRYEFCRnCsGiALZhMHvT7A4LcnQcBo9fMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBraSOSh/r6ljyQUAC4YBCe9mX7iZny0Bsvw2dd07NkcixGMA0krnikw2UOujHpNxyyo2+2 Crdl4Jk5WrBer69iCvwcDAuxbaOFMd23s4H7zesksJ4IcUJxbQKBNmj1wZ9Wm2cpbTWbO0sWaasj ZUvmTSCoEnIA9tgWEZiWumfgQ41P6biuyTQSrT2uGNCe60+6MELTuV65hjjhQUZC+xGESV8yJs88 nBlOgutMfpfB+rsdN14BBhUy5RvJWo5uLnZ4IXw7dYAenQj36WCQk8LH0rcw7zjh7gApX+DyNMHm uRAQwPvlyXVDI9QkG6NqtV2nrunVADAk2cjNfT6mHEcwAAAAAAAA --Apple-Mail-18--191458499-- --=-Kqkrl/3+126MdRGLXCPW-- From arjen.holtzer@tno.nl Fri Nov 6 06:02:31 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2CC3A698C for ; Fri, 6 Nov 2009 06:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.494 X-Spam-Level: X-Spam-Status: No, score=0.494 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j8k+ZeDWcaW for ; Fri, 6 Nov 2009 06:02:30 -0800 (PST) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 69AB73A6863 for ; Fri, 6 Nov 2009 06:02:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,693,1249250400"; d="scan'208";a="26849996" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 06 Nov 2009 15:02:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Nov 2009 15:02:45 +0100 Message-ID: In-Reply-To: <003b01ca5256$af8bcbc0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New edge behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 Thread-Index: AcpN0Z/r453Zm4BjRm2Ch1wDOVl4ewEg3UeAAyT2yKA= References: <003b01ca5256$af8bcbc0$810c5982@dynamic.ewi.utwente.nl> From: "Holtzer, A.C.G. (Arjen)" To: "Georgios Karagiannis" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: PCN@ietf.org Subject: Re: [PCN] New edge behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:02:31 -0000 Hello Georgios, I think that the proposed combination of signalling and PCN-marking really has advantages for solving the ECMP issue and am interested in seeing how it would perform (in both the trunk and HOSE model). I think the draft clearly explains the proposed mechanisms. I have two minor remarks: 1) Maybe the addition of a short description of the actual ECMP problem that is solved here would make the draft more complete. 2) Section 2, bullet 5a says: =09 "the interior SHOULD preferentially drop unmarked packets instead of marked packets".=20 Shouldn't this be changed into: "the interior node SHOULD preferentially drop unmarked or Threshold marked packets instead of Excess marked packets"? Best regards, Arjen=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On=20 > Behalf Of Georgios Karagiannis > Sent: woensdag 21 oktober 2009 15:59 > To: pcn@ietf.org > Subject: [PCN] New edge=20 > behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 >=20 >=20 > Hi all >=20 > During the last two IETF meetings I had promissed to publish=20 > the HOSE edge behaviour draft. >=20 > Via the following URL you can find this draft: >=20 > http://www.ietf.org/id/draft-karagiannis-pcn-hose-edge-behavio > ur-00.txt >=20 > If you have any comments please let me know! >=20 > -------------------------------------------------------- >=20 > Abstract ++ >=20 > Precongestion notification (PCN) is a means for protecting=20 > quality of > service for inelastic traffic admitted to a Diffserv domain. The > overall PCN architecture is described in RFC 5559. This=20 > memo is one > of a series describing possible boundary node behaviours for a PCN > domain. The behaviour described here is denoted as the HOSE model. > In this document the term HOSE is referring to the > aggregation of incoming traffic from all ingress edges, which is > associated with one traffic class, i.e., PHB, towards one egress > edge. This type of HOSE model is equivalent to the=20 > Multiple Point to > Point (MP2P) type of aggregation. >=20 > The HOSE model ensures bandwidth limits without the need of > maintaining per each ingress and egress pair ingress-egress- > aggregated states. In this case all edges maintain one aggregated > state per each traffic class, i.e., PHB (Per Hop=20 > Behaviour), used in > the PCN domain. Moreover, the HOSE model is able to=20 > provide solutions > for the ECMP (Equal Cost Multi Path) problem for both admission > control and flow termination procedures. >=20 >=20 > ------------------------------------- >=20 >=20 >=20 > Best regards, > Georgios >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn >=20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From karagian@cs.utwente.nl Fri Nov 6 09:06:37 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0012B28C177 for ; Fri, 6 Nov 2009 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFwYGBroPaC1 for ; Fri, 6 Nov 2009 09:06:36 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id ABCD328C176 for ; Fri, 6 Nov 2009 09:06:35 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nA6H6p3v018265; Fri, 6 Nov 2009 18:06:54 +0100 (MET) From: "Georgios Karagiannis" To: "'Holtzer, A.C.G. \(Arjen\)'" References: <003b01ca5256$af8bcbc0$810c5982@dynamic.ewi.utwente.nl> Date: Fri, 6 Nov 2009 18:06:48 +0100 Message-ID: <003501ca5f03$89a1bfa0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpN0Z/r453Zm4BjRm2Ch1wDOVl4ewEg3UeAAyT2yKAABoXMkA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 06 Nov 2009 18:06:56 +0100 (MET) Cc: PCN@ietf.org Subject: Re: [PCN] New edge behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:06:37 -0000 Hi Arjen Thank you very much for your comments! Please see in line! > -----Original Message----- > From: Holtzer, A.C.G. (Arjen) [mailto:arjen.holtzer@tno.nl] > Sent: vrijdag 6 november 2009 15:03 > To: Georgios Karagiannis > Cc: PCN@ietf.org > Subject: RE: [PCN] New edge > behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 > > Hello Georgios, > > I think that the proposed combination of signalling and > PCN-marking really has advantages for solving the ECMP issue > and am interested in seeing how it would perform (in both the > trunk and HOSE model). I think the draft clearly explains the > proposed mechanisms. I have two minor > remarks: > > 1) Maybe the addition of a short description of the actual > ECMP problem that is solved here would make the draft more complete. Georgios: yes that is a good idea. The next version of the draft will include this description. > > 2) Section 2, bullet 5a says: > > "the interior SHOULD preferentially drop unmarked packets > instead of marked packets". > > Shouldn't this be changed into: > > "the interior node SHOULD preferentially drop unmarked or > Threshold marked packets instead of Excess marked packets"? Georgios: Yes you are right! This is actually what we were willing to say, but is written in a wrong way! We will correct it in the next version of the draft! Best regards, Georgios > > Best regards, > Arjen > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: woensdag 21 oktober 2009 15:59 > > To: pcn@ietf.org > > Subject: [PCN] New edge > > behaviour:draft-karagiannis-pcn-hose-edge-behaviour-00 > > > > > > Hi all > > > > During the last two IETF meetings I had promissed to > publish the HOSE > > edge behaviour draft. > > > > Via the following URL you can find this draft: > > > > http://www.ietf.org/id/draft-karagiannis-pcn-hose-edge-behavio > > ur-00.txt > > > > If you have any comments please let me know! > > > > -------------------------------------------------------- > > > > Abstract ++ > > > > Precongestion notification (PCN) is a means for > protecting quality > > of > > service for inelastic traffic admitted to a Diffserv domain. The > > overall PCN architecture is described in RFC 5559. This memo is > > one > > of a series describing possible boundary node behaviours > for a PCN > > domain. The behaviour described here is denoted as the > HOSE model. > > In this document the term HOSE is referring to the > > aggregation of incoming traffic from all ingress edges, which is > > associated with one traffic class, i.e., PHB, towards one egress > > edge. This type of HOSE model is equivalent to the > Multiple Point > > to > > Point (MP2P) type of aggregation. > > > > The HOSE model ensures bandwidth limits without the need of > > maintaining per each ingress and egress pair ingress-egress- > > aggregated states. In this case all edges maintain one > aggregated > > state per each traffic class, i.e., PHB (Per Hop > Behaviour), used > > in > > the PCN domain. Moreover, the HOSE model is able to provide > > solutions > > for the ECMP (Equal Cost Multi Path) problem for both admission > > control and flow termination procedures. > > > > > > ------------------------------------- > > > > > > > > Best regards, > > Georgios > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > From slblake@petri-meat.com Sun Nov 8 17:03:53 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C843A6909 for ; Sun, 8 Nov 2009 17:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TyCaqOdwTPA for ; Sun, 8 Nov 2009 17:03:52 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 910B23A635F for ; Sun, 8 Nov 2009 17:03:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7Ify-0003sM-QV for pcn@ietf.org; Sun, 08 Nov 2009 20:04:10 -0500 MIME-Version: 1.0 Date: Sun, 08 Nov 2009 20:04:10 -0500 From: To: pcn@ietf.org Message-ID: <36045076bd4a96f5e1aaa7a9546ceb83@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] Meeting presentations X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:03:53 -0000 If you are presenting tomorrow, please send me you slides as soon as possible. The meeting will not commence until all of the presentations are uploaded to the meeting materials site. We need volunteers for minute taker and jabber scribe. Regards, // Steve From fqhuang@huawei.com Mon Nov 9 17:20:29 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBF83A68E0 for ; Mon, 9 Nov 2009 17:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjHpu5+2F1nz for ; Mon, 9 Nov 2009 17:20:24 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B120A3A6809 for ; Mon, 9 Nov 2009 17:20:23 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV001IDD2F47@szxga03-in.huawei.com> for pcn@ietf.org; Tue, 10 Nov 2009 09:20:40 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV00BBZD2FLU@szxga03-in.huawei.com> for pcn@ietf.org; Tue, 10 Nov 2009 09:20:39 +0800 (CST) Received: from WWWE99ECC189FD (host-19-105.meeting.ietf.org [133.93.19.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSV00FJ6D2AKZ@szxml02-in.huawei.com> for pcn@ietf.org; Tue, 10 Nov 2009 09:20:39 +0800 (CST) Date: Tue, 10 Nov 2009 10:22:35 +0900 From: Fortune HUANG To: pcn@ietf.org Message-id: <36802C0A84CC486991D69F28E52FF011@WWWE99ECC189FD> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Fkie0ziFmDQhFRMFuXmI2A)" Thread-index: AcphpEhx/cIqvAiMSISRsXRakRLObg== Subject: [PCN] about the signalling draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:20:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Fkie0ziFmDQhFRMFuXmI2A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, As pointed out by Lars just now in the meeting room, the signalling requirement draft should be generized to be applied to all deployment scenarios or implementations. I think what we actually need to standardize in the signalling draft is two logical interfaces: 1) the interface between the PCN-ingress-node and the decision node; 2) the interface between the PCN-egress-node and the decision node. We could also mention the common deployment scenarios in the draft (but please note that this is not the intention of the draft and this could even be put into the appendix), e.g.: 1) Scenario 1, the decision node co-locates with the PCN-ingress-node: the interface between the PCN-ingress-node and the decision node is an internal interface which can be implemented privately within a vendor; the interface between the PCN-egress-node and the decision node is an external interface which must follow the standardized interface. 2) Scenario 2, the decision node co-locates with the PCN-egress-node: the interface between the PCN-ingress-node and the decision node is an external interface which must follow the standardized interface; the interface between the PCN-egress-node and the decision node is an internal interface which can be implemented privately within a vendor. 3) Scenario 3, the decision node co-locates with neither the PCN-egress-node nor the PCN-ingress-node: both the interface between the PCN-ingress-node and the decision node, and the interface the PCN-egress-node and the decision node are external interfaces and must follow the standardized interfaces. There was an argument whether the admit/block state or the raw data could be sent from the egress to the ingress. From my understanding, this argument relates to two deployment scenarios: when reporting the admit/block state, we are refering to the interface between the decision node and the PCN-ingress-node, where the decision node is co-located with the PCN-egress-node; when reporting the raw data, we are refering to the interface between the PCN-egress-node and the decsion node, where the decision node is co-located with the PCN-ingress-node. So both reportings could co-exist since they belong to different interfaces. Since both scenarios are valid, we don't need to make a choice at least in the signalling draft. Best regards, Fortune --Boundary_(ID_Fkie0ziFmDQhFRMFuXmI2A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

As pointed out by Lars just now in the meeting room, the signalling requirement draft should be generized to be applied to all deployment scenarios or implementations. I think what we actually need to standardize in the signalling draft is two logical interfaces: 1) the interface between the PCN-ingress-node and the decision node; 2) the interface between the PCN-egress-node and the decision node.

 

We could also mention the common deployment scenarios in the draft (but please note that this is not the intention of the draft and this could even be put into the appendix), e.g.:

1) Scenario 1, the decision node co-locates with the PCN-ingress-node:  the interface between the PCN-ingress-node and the decision node is an internal interface which can be implemented privately within a vendor; the interface between the PCN-egress-node and the decision node is an external interface which must follow the standardized interface.

2) Scenario 2, the decision node co-locates with the PCN-egress-node: the interface between the PCN-ingress-node and the decision node is an external interface which must follow the standardized interface; the interface between the PCN-egress-node and the decision node is an internal interface which can be implemented privately within a vendor.

3) Scenario 3, the decision node co-locates with neither the PCN-egress-node nor the PCN-ingress-node: both the interface between the PCN-ingress-node and the decision node, and the interface the PCN-egress-node and the decision node are external interfaces and must follow the standardized interfaces.

 

There was an argument whether the admit/block state or the raw data could be sent from the egress to the ingress. From my understanding, this argument relates to two deployment scenarios: when reporting the admit/block state, we are refering to the interface between the decision node and the PCN-ingress-node, where the decision node is co-located with the PCN-egress-node; when reporting the raw data, we are refering to the interface between the  PCN-egress-node and the decsion node, where the decision node is co-located with the PCN-ingress-node. So both reportings could co-exist since they belong to different interfaces. Since both scenarios are valid, we don’t need to make a choice at least in the signalling draft.

 

Best regards,

Fortune

 

--Boundary_(ID_Fkie0ziFmDQhFRMFuXmI2A)-- From lars.eggert@nokia.com Mon Nov 9 17:37:28 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3053A69DA for ; Mon, 9 Nov 2009 17:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfA5K7oBFSBR for ; Mon, 9 Nov 2009 17:37:27 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 1854228C197 for ; Mon, 9 Nov 2009 17:37:26 -0800 (PST) Received: from host-24-27.meeting.ietf.org (host-24-27.meeting.ietf.org [133.93.24.27]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nAA1bZ2S004613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Nov 2009 03:37:38 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-13-336978961; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <36802C0A84CC486991D69F28E52FF011@WWWE99ECC189FD> Date: Tue, 10 Nov 2009 10:37:33 +0900 Message-Id: References: <36802C0A84CC486991D69F28E52FF011@WWWE99ECC189FD> To: Fortune HUANG X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 10 Nov 2009 03:37:40 +0200 (EET) Cc: "pcn@ietf.org" Subject: Re: [PCN] about the signalling draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:37:28 -0000 --Apple-Mail-13-336978961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 2009-11-10, at 10:22, Fortune HUANG wrote: > As pointed out by Lars just now in the meeting room, the signalling = requirement draft should be generized to be applied to all deployment = scenarios or implementations. > I think what we actually need to standardize in the signalling draft = is two logical interfaces: 1) the interface between the PCN-ingress-node = and the decision node; 2) the interface between the PCN-egress-node and = the decision node. to be clear: I was taking about capturing *requirements* for PCN = signaling protocols, which is what the ID tries to do. I was *not* arguing that we should standardize any specific signaling = protocols, for either 1 or 2 or cases with no central decision node. Lars > We could also mention the common deployment scenarios in the draft = (but please note that this is not the intention of the draft and this = could even be put into the appendix), e.g.: > 1) Scenario 1, the decision node co-locates with the PCN-ingress-node: = the interface between the PCN-ingress-node and the decision node is an = internal interface which can be implemented privately within a vendor; = the interface between the PCN-egress-node and the decision node is an = external interface which must follow the standardized interface. > 2) Scenario 2, the decision node co-locates with the PCN-egress-node: = the interface between the PCN-ingress-node and the decision node is an = external interface which must follow the standardized interface; the = interface between the PCN-egress-node and the decision node is an = internal interface which can be implemented privately within a vendor. > 3) Scenario 3, the decision node co-locates with neither the = PCN-egress-node nor the PCN-ingress-node: both the interface between the = PCN-ingress-node and the decision node, and the interface the = PCN-egress-node and the decision node are external interfaces and must = follow the standardized interfaces. >=20 > There was an argument whether the admit/block state or the raw data = could be sent from the egress to the ingress. =46rom my understanding, = this argument relates to two deployment scenarios: when reporting the = admit/block state, we are refering to the interface between the decision = node and the PCN-ingress-node, where the decision node is co-located = with the PCN-egress-node; when reporting the raw data, we are refering = to the interface between the PCN-egress-node and the decsion node, = where the decision node is co-located with the PCN-ingress-node. So both = reportings could co-exist since they belong to different interfaces. = Since both scenarios are valid, we don=92t need to make a choice at = least in the signalling draft. >=20 > Best regards, > Fortune >=20 > --Apple-Mail-13-336978961 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTExMDAxMzczM1owIwYJKoZIhvcNAQkEMRYEFIbkKTXOmDCnEgR53BSL1sInHS9WMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAX2r4PlJ0yH8BcdxGs6YbY4DXeBRbNXEX9Q/l64dh0fKlPaR6A8fW8c+zFB1rK1/LLrL4t cmwMRUnLcg9+igIMTCP8iM4OEQH/iOfc6KiEc4SHquLeVlWIr4kejN20KsQwVpkXwoyV6u9JOLpL El1DwVKdrvYvMfEfgK/U5Wd+bimLHQ1ggbGrdJbNV/x3k+kAxbb7irpWZcLSy6dichMp6GgMbmty Rt+SoHaL0q2RecjWQtbwx71vDXLGOGTPy685+NBy3sYC6a+tSM/31bDOuGcBzUeN+xciRBD7J7V1 YiCxMXRAZyjMrN15BctIgmCSAqG9OTJuvRqi5S/+Qq49AAAAAAAA --Apple-Mail-13-336978961-- From fqhuang@huawei.com Mon Nov 9 17:47:12 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825923A68C2 for ; Mon, 9 Nov 2009 17:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=2.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPXO2awwoBCC for ; Mon, 9 Nov 2009 17:47:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8AAEC3A67AF for ; Mon, 9 Nov 2009 17:47:11 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV008ADEBCV3@szxga04-in.huawei.com> for pcn@ietf.org; Tue, 10 Nov 2009 09:47:37 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV00GU2EBCD9@szxga04-in.huawei.com> for pcn@ietf.org; Tue, 10 Nov 2009 09:47:36 +0800 (CST) Received: from WWWE99ECC189FD (host-19-105.meeting.ietf.org [133.93.19.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSV00CPIEB7FF@szxml01-in.huawei.com>; Tue, 10 Nov 2009 09:47:36 +0800 (CST) Date: Tue, 10 Nov 2009 10:49:55 +0900 From: Fortune HUANG In-reply-to: To: 'Lars Eggert' Message-id: <7E428F0915F84628BF9DCECE2340973F@WWWE99ECC189FD> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcphpmwgsHxsys0MTkO5fCgpiKAaNAAAUhIg References: <36802C0A84CC486991D69F28E52FF011@WWWE99ECC189FD> Cc: pcn@ietf.org Subject: Re: [PCN] about the signalling draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:47:12 -0000 Hi Lars, I was not suggesting specifying any specific signalling protocols, either. What I meant is the signalling requirements for the two logical interfaces. Best regards, Fortune -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Tuesday, November 10, 2009 10:38 AM To: Fortune HUANG Cc: pcn@ietf.org Subject: Re: [PCN] about the signalling draft Hi, On 2009-11-10, at 10:22, Fortune HUANG wrote: > As pointed out by Lars just now in the meeting room, the signalling requirement draft should be generized to be applied to all deployment scenarios or implementations. > I think what we actually need to standardize in the signalling draft is two logical interfaces: 1) the interface between the PCN-ingress-node and the decision node; 2) the interface between the PCN-egress-node and the decision node. to be clear: I was taking about capturing *requirements* for PCN signaling protocols, which is what the ID tries to do. I was *not* arguing that we should standardize any specific signaling protocols, for either 1 or 2 or cases with no central decision node. Lars > We could also mention the common deployment scenarios in the draft (but please note that this is not the intention of the draft and this could even be put into the appendix), e.g.: > 1) Scenario 1, the decision node co-locates with the PCN-ingress-node: the interface between the PCN-ingress-node and the decision node is an internal interface which can be implemented privately within a vendor; the interface between the PCN-egress-node and the decision node is an external interface which must follow the standardized interface. > 2) Scenario 2, the decision node co-locates with the PCN-egress-node: the interface between the PCN-ingress-node and the decision node is an external interface which must follow the standardized interface; the interface between the PCN-egress-node and the decision node is an internal interface which can be implemented privately within a vendor. > 3) Scenario 3, the decision node co-locates with neither the PCN-egress-node nor the PCN-ingress-node: both the interface between the PCN-ingress-node and the decision node, and the interface the PCN-egress-node and the decision node are external interfaces and must follow the standardized interfaces. > > There was an argument whether the admit/block state or the raw data could be sent from the egress to the ingress. From my understanding, this argument relates to two deployment scenarios: when reporting the admit/block state, we are refering to the interface between the decision node and the PCN-ingress-node, where the decision node is co-located with the PCN-egress-node; when reporting the raw data, we are refering to the interface between the PCN-egress-node and the decsion node, where the decision node is co-located with the PCN-ingress-node. So both reportings could co-exist since they belong to different interfaces. Since both scenarios are valid, we don't need to make a choice at least in the signalling draft. > > Best regards, > Fortune > > From tom111.taylor@bell.net Tue Nov 10 15:29:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D739D28C212 for ; Tue, 10 Nov 2009 15:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DijqyHcfkMv for ; Tue, 10 Nov 2009 15:29:06 -0800 (PST) Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by core3.amsl.com (Postfix) with ESMTP id 1646628C1F9 for ; Tue, 10 Nov 2009 15:29:06 -0800 (PST) Received: from BLU0-SMTP98 ([65.55.116.8]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:29:33 -0800 X-Originating-IP: [222.151.136.142] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [172.30.240.1] ([222.151.136.142]) by BLU0-SMTP98.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:29:32 -0800 Date: Wed, 11 Nov 2009 08:29:29 +0900 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2009 23:29:32.0256 (UTC) FILETIME=[A7F12600:01CA625D] Subject: [PCN] Key results from PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:29:06 -0000 This is a small report in advance of the official notes, written from my point of view. The key outcomes I noted from the PCN meeting were these: 1) The egress node will always report the measured rates of unmarked, excess-traffic-marked, and, if applicable, threshold-marked traffic. This is for two reasons: flexibility in the application of policy at the decision point, and flexibility in future applications in general. 2) Two remarks apply to the signalling requirements draft. One has to do with the current division into ingress vs. centralized control. Fortune has sent notes on that topic. Probably more importantly, the draft has to talk about how each end knows that the other end is alive, and how long it is permissible for the system to proceed without some assurance that the peer is still alive. Steven was going to write a note on this, since he raised it. 3) The piggybacking behaviour draft needs fixing to match how RSVP and NSIS actually work. I have to do some studying. Francois LeFaucheur gave me a reference that should serve as a tutorial. 4) I don't think we came to a conclusion on how much memory/lag is desirable in the measurements. Accumulating over an interval introduces some lag. Exponential smoothing or moving averages introduce some lag. These are both means to reducing very short-term oscillations in system behaviour. I'm personally indifferent to the means used, but believe that some damping is desirable. 4) The final point is, I think, the most important one for us to resolve going forward. That is the question of when reports are issued. It could be at the end of fixed intervals, or it could be when something significant has changed. The question is tied up with whether reliable transport is needed and also with the liveness question described in 2) above. Tom Taylor From tom111.taylor@bell.net Tue Nov 10 15:33:16 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA3628C188 for ; Tue, 10 Nov 2009 15:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 909gjEcjMK5O for ; Tue, 10 Nov 2009 15:33:15 -0800 (PST) Received: from blu0-omc1-s19.blu0.hotmail.com (blu0-omc1-s19.blu0.hotmail.com [65.55.116.30]) by core3.amsl.com (Postfix) with ESMTP id 3CD213A6887 for ; Tue, 10 Nov 2009 15:33:15 -0800 (PST) Received: from BLU0-SMTP99 ([65.55.116.9]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:33:42 -0800 X-Originating-IP: [222.151.136.142] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [172.30.240.1] ([222.151.136.142]) by BLU0-SMTP99.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:33:42 -0800 Date: Wed, 11 Nov 2009 08:33:39 +0900 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pcn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2009 23:33:42.0523 (UTC) FILETIME=[3D1CDCB0:01CA625E] Subject: Re: [PCN] Key results from PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:33:16 -0000 Something I missed on point 2): what does one end do if it decides that the other end is dead? Particularly, what does the decision point do if it gets no reports for a "long" time. Tom Taylor wrote: > This is a small report in advance of the official notes, written from my > point of view. The key outcomes I noted from the PCN meeting were these: > > 1) The egress node will always report the measured rates of unmarked, > excess-traffic-marked, and, if applicable, threshold-marked traffic. > This is for two reasons: flexibility in the application of policy at the > decision point, and flexibility in future applications in general. > > 2) Two remarks apply to the signalling requirements draft. One has to do > with the current division into ingress vs. centralized control. Fortune > has sent notes on that topic. Probably more importantly, the draft has > to talk about how each end knows that the other end is alive, and how > long it is permissible for the system to proceed without some assurance > that the peer is still alive. Steven was going to write a note on this, > since he raised it. > > 3) The piggybacking behaviour draft needs fixing to match how RSVP and > NSIS actually work. I have to do some studying. Francois LeFaucheur gave > me a reference that should serve as a tutorial. > > 4) I don't think we came to a conclusion on how much memory/lag is > desirable in the measurements. Accumulating over an interval introduces > some lag. Exponential smoothing or moving averages introduce some lag. > These are both means to reducing very short-term oscillations in system > behaviour. I'm personally indifferent to the means used, but believe > that some damping is desirable. > > 4) The final point is, I think, the most important one for us to resolve > going forward. That is the question of when reports are issued. It could > be at the end of fixed intervals, or it could be when something > significant has changed. The question is tied up with whether reliable > transport is needed and also with the liveness question described in 2) > above. > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From slblake@petri-meat.com Thu Nov 12 02:45:16 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF573A6875 for ; Thu, 12 Nov 2009 02:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77R9BciUg4VC for ; Thu, 12 Nov 2009 02:45:16 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 0123D3A6920 for ; Thu, 12 Nov 2009 02:45:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8XBN-0001bZ-I3; Thu, 12 Nov 2009 05:45:41 -0500 MIME-Version: 1.0 Date: Thu, 12 Nov 2009 05:45:41 -0500 From: Steven Blake To: Tom Taylor In-Reply-To: References: Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn Subject: Re: [PCN] Key results from PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 10:45:17 -0000 On Wed, 11 Nov 2009 08:33:39 +0900, Tom Taylor wrote: > Something I missed on point 2): what does one end do if it decides that the > other end is dead? Particularly, what does the decision point do if it gets > no reports for a "long" time. That is my point, which is why I brought up the issue of signaling channel liveness. Suppose the decision point is at the ingress. The ingress knows it is sending PCN traffic to a particular egress, and it stops getting reports from that egress for some extended time period. What should it do? If the answer is nothing, then signaling channel liveness is not an issue. My guess is that at some point the ingress should stop admitting new flows. Whatever the desired response, that will help drive the requirements for tracking the state of the signaling channel. > Tom Taylor wrote: >> This is a small report in advance of the official notes, written from my >> point of view. The key outcomes I noted from the PCN meeting were these: >> >> 1) The egress node will always report the measured rates of unmarked, >> excess-traffic-marked, and, if applicable, threshold-marked traffic. >> This is for two reasons: flexibility in the application of policy at the >> decision point, and flexibility in future applications in general. >> >> 2) Two remarks apply to the signalling requirements draft. One has to do >> with the current division into ingress vs. centralized control. Fortune >> has sent notes on that topic. Probably more importantly, the draft has >> to talk about how each end knows that the other end is alive, and how >> long it is permissible for the system to proceed without some assurance >> that the peer is still alive. Steven was going to write a note on this, >> since he raised it. >> >> 3) The piggybacking behaviour draft needs fixing to match how RSVP and >> NSIS actually work. I have to do some studying. Francois LeFaucheur gave >> me a reference that should serve as a tutorial. >> >> 4) I don't think we came to a conclusion on how much memory/lag is >> desirable in the measurements. Accumulating over an interval introduces >> some lag. Exponential smoothing or moving averages introduce some lag. >> These are both means to reducing very short-term oscillations in system >> behaviour. I'm personally indifferent to the means used, but believe >> that some damping is desirable. Whatever is decided, recommending exponential smoothing and then saying that the parameter values are completely irrelevant doesn't make any sense to me. It would be better to say that parameters within some range seem to work fine. >> 4) The final point is, I think, the most important one for us to resolve >> going forward. That is the question of when reports are issued. It could >> be at the end of fixed intervals, or it could be when something >> significant has changed. The question is tied up with whether reliable >> transport is needed and also with the liveness question described in 2) >> above. The closer CLE at an egress gets to the blocking threshold, the more frequently you might want to send reports. Regards, // Steve From slblake@petri-meat.com Thu Nov 12 02:52:53 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB493A6921 for ; Thu, 12 Nov 2009 02:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkbq6wRv5p4B for ; Thu, 12 Nov 2009 02:52:51 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id A87263A687E for ; Thu, 12 Nov 2009 02:52:51 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8XIj-0003HM-Kx; Thu, 12 Nov 2009 05:53:17 -0500 MIME-Version: 1.0 Date: Thu, 12 Nov 2009 05:53:17 -0500 From: Steven Blake To: pcn@ietf.org Message-ID: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Type: multipart/mixed; boundary="=_b10f48f81409aa5dd217671f0c6262c9" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] **DRAFT** IETF 76 PCN meeting minutes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 10:52:53 -0000 --=_b10f48f81409aa5dd217671f0c6262c9 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Howdy. The draft meeting minutes from Tuesday are attached. Thanks to Philip for taking them! Please send comments/corrections to the list within the next week. Regards, // Steve --=_b10f48f81409aa5dd217671f0c6262c9 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8"; name="pcn-ietf76-minutes.draft.txt"; Content-Disposition: attachment; filename="pcn-ietf76-minutes.draft.txt"; 77u/Q29uZ2VzdGlvbiBhbmQgUHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFdHIChwY24pCklF VEYgNzYgTWVldGluZyBNaW51dGVzCgpDSEFJUlM6IFNjb3R0IEJyYWRuZXIgPHNvYkBoYXJ2YXJk LmVkdT4gIChub3QgcHJlc2VudCkKICAgICAgICBTdGV2ZW4gQmxha2UgIDxzYmxha2VAZXh0cmVt ZW5ldHdvcmtzLmNvbT4KCk1pbnV0ZSB0YWtlcjogUGhpbGlwIEVhcmRsZXkgPHBoaWxpcC5lYXJk bGV5QGJ0LmNvbT4KClR1ZXNkYXksIE5vdmVtYmVyIDEwLCAyMDA5CjA5MDAgLSAxMTMwIE1vcm5p bmcgU2Vzc2lvbiBJCkNhdHRsZXlhIFdlc3QKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpBR0VOREE6 CgpvIEFkbWluaXN0cml2aWEKICBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA5bm92 L3NsaWRlcy9wY24tMC5wZGYgIAoKU3RldmVuIEJsYWtlIHByZXNlbnRlZCB0aGUgYWdlbmRhIHNs aWRlcywgd2hpY2ggd2VyZSBhY2NlcHRlZCB3aXRob3V0Cm9iamVjdGlvbi4gIEhlIGFsc28gcmV2 aWV3ZWQgdGhlIGN1cnJlbnQgbWlsZXN0b25lIHN0YXR1cy4KCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KbyBFbmNvZGluZyBDb21wYXJpc29uCiAgZHJhZnQtaWV0Zi1wY24tZW5jb2RpbmctY29tcGFy aXNvbi0wMQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDlub3Yvc2xpZGVzL3Bj bi01LnBkZgoKU3RldmVuIEJsYWtlIHByZXNlbnRlZCB0aGUgc2xpZGVzIG9uIGJlaGFsZiBvZiBL d29rIEhvIENoYW4sIHdobyB3YXMgbm90CmFibGUgdG8gYXR0ZW5kLiAgVGhhbmtzIHRvIEt3b2sg Zm9yIGhpcyB3b3JrIG9uIGl0LiAgU3RldmVuIHBvbGxlZCB0aGUgcm9vbQp0byBzZWUgaG93IG1h bnkgaGFkIHJlYWQgdGhlIGRyYWZ0OyBmZXcgaGFkLgoKTGFycyBFZ2dlcnQ6IEl0IGdvdCBhZGRl ZCB0byB0aGUgY2hhcnRlciDigJMgc28gdGhlIHBlb3BsZSB3aG8gd2FudGVkIGl0IGFkZGVkIHRv IGNoYXJ0ZXIgYXJlIGV4cGVjdGVkL29ibGlnZWQgdG8gcmV2aWV3IGl0LgoKU3RldmVuIEJsYWtl OiBXYW50IHRvIGdvIHRvIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGJlZm9yZSB0aGUgZW5kIG9m IHllYXIuCgpQaGlsaXAgRWFyZGxleTogSSBoYXZlIDIgY29tbWVudHMgdGhhdCBJIHRoaW5rIG5l ZWQgdG8gYmUgc29sdmVkIGJlZm9yZSBpdCBpcwpyZWFkeSBmb3IgTEM6Ci0gSXQgZG9lc27igJl0 IGdpdmUgYSBnb29kIHNlbnNlIG9mIHdoeSBiYXNlbGluZSB3YXMgY2hvc2VuCi0gSXQgZG9lc27i gJl0IGdpdmUgZ29vZCBzZW5zZSBvZiB0aGUgcHJvcyAmIGNvbnMgb2YgdmFyaW91cyB3b3JraW5n LWdyb3VwIAogIHByb3Bvc2VkIGV4dGVuc2lvbiBlbmNvZGluZ3MuCgpTdGV2ZW4gQmxha2UgYXNr ZWQgZm9yIHRoZSBzdGF0dXMgb2YgZHJhZnQtaWV0Zi1wY24tMy1zdGF0ZS1lbmNvZGluZyBhbmQg CmRyYWZ0LWlldGYtcGNuLTMtaW4tMS1lbmNvZGluZy4gT25lIG9mIHRoZW0gKHdoaWNoPykgaXMg YmxvY2tlZCBkdWUgdG8gYSAKZGVwZW5kZW5jeSBvbiB0aGUgRUNOIHR1bm5lbGluZyBkcmFmdC4K CkJvYiBCcmlzY29lOiBFQ04gdHVubmVsbGluZyBkcmFmdC1yZWxhdGVkIGVuY29kaW5nIHN0YXR1 cyDigJMgSSB0aGluay9ob3BlIHRoYXQgSQpoYXZlIHJlc29sdmVkIHRoZSBibG9ja2luZyBpc3N1 ZXMgd2l0aCBEYXZpZCBCbGFjaywgc28gdGhlIGRyYWZ0IHNob3VsZCBzb29uIGJlCmFibGUgdG8g bW92ZSBmb3J3YXJkLgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpvIFNpZ25hbGluZyBSZXF1aXJl bWVudHMKICBkcmFmdC1rYXJhZ2lhbm5pcy1wY24tc2lnbmFsaW5nLXJlcXVpcmVtZW50cy0wMAoK VG9tIFRheWxvciBwcmVzZW50ZWQgc2xpZGVzIG9uIHRoZSBzaWduYWxpbmcgcmVxdWlyZW1lbnRz IGRyYWZ0LiAgQ3JlZGl0cyDigJMgCkdlb3JnaW9zIHN0YXJ0ZWQsIE1pY2hhZWwsIEt3b2ssIGFu ZCBUb20gd29ya2VkIG9uIHRoZSBkcmFmdC4gIFRoZSBjdXJyZW50IApkcmFmdCBkb2VzbuKAmXQg aW5jbHVkZSB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgcGlnZ3liYWNraW5nIGVkZ2UgYmVoYXZp b3VyLgoKVG9tIFRheWxvcjogTGFzdCBidWxsZXQgb2Ygc2xpZGUgMyDigJMg4oCcbm90IHN1cmUg SSBhZ3JlZSB3aXRoIGl0IeKAnS4KClN0ZXZlbiBCbGFrZTogV2hhdCBpcyBiZWhhdmlvdXIgaWYg dGhlIHNpZ25hbGluZyBjaGFubmVsIGJyZWFrcyAmIGhvdyBkbyB5b3UgCmtub3cgaWYgaXTigJlz IHN0aWxsIGFsaXZlPwoKVG9tIFRheWxvcjogQWRtaXNzaW9uIHN0YXRlIGlzIHNlbnQgcmVndWxh cmx5IHNvIHJlbGlhYmlsaXR5IGlzIGxlc3MgaW1wb3J0YW50IArigJMgb3Zlci1hZG1pdCBmb3Ig c2F5IDEwMG1zIOKAkyBidXQgZm9yIGZsb3cgdGVybWluYXRpb24sIHJlbGlhYmlsaXR5IHNlZW1z IG1vcmUKaW1wb3J0YW50LgoKVG9tIFRheWxvcjogSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUg c2xpZGVzIHNheSBNQVkgZm9yIHRyYWZmaWMgcmF0ZSAKcmVsaWFibHkgYW5kIE1VU1QgZm9yIGZs b3cgaWQgcmVsaWFibHkg4oCTIG9kZCBtaXg/CgpCb2IgQnJpc2NvZTogVGhlIHJlYXNvbmluZyBt YXkgYmUgdGhhdCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0byBkbyB0ZXJtaW5hdGlvbgplLmcuLCBp bmNyZW1lbnRhbGx5IHRlcm1pbmF0ZSBtb3JlICYgbW9yZSBmbG93IHVudGlsIHlvdSBsZWF2ZSBm bG93CnRlcm1pbmF0aW9uIHN0YXRlPwoKU3RldmVuIEJsYWtlOiBJZiB5b3XigJlyZSBnb2luZyB0 byBzZW5kIG9uZSByZWxpYWJseSwgdGhlbiBzZW5kaW5nIHRoZSBvdGhlciAKcmVsaWFibHkgaXMg dHJpdmlhbC4KClBoaWxpcCBFYXJkbGV5OiBSZXF1aXJlbWVudHMgYmV0d2VlbiBpbmdyZXNzICYg Y2VudHJhbGlzZWQgZGVjaXNpb24gbm9kZXMgYXJlCm1pc3NpbmcuICBBbHNvIHF1ZXN0aW9uIHdo ZXRoZXIgaXQgaXMgdmFsaWQgZm9yIHRoZSBjZW50cmFsaXNlZCBub2RlIGNhc2UgdG8gCmJlIGlu IHRoZSBkcmFmdCBnaXZlbiBpdOKAmXMgcmVhbGx5IG91dCBvZiBXRyBzY29wZS4KCkxhcnMgRWdn ZXJ0OiBOb3Qgc3VyZSBpZiBjZW50cmFsaXNlZCBub2RlIGNhc2Ugc2hvdWxkIGJlIGluLiAgVGhl IGRyYWZ0IGlzIHRvIApjYXB0dXJlIHJlcXVpcmVtZW50cyBmb3IgYWxsIHNpZ25hbGluZyBjYXNl cyB3aXRob3V0IHByZXNjcmliaW5nIG9uZSAKc2lnbmFsaW5nIHNvbHV0aW9uLiBXb3VsZCByYXRo ZXIgc2VlIHRoaXMgaXMgaW4gYSBjZW50cmFsaXNlZCBub2RlIGVkZ2UgCmJlaGF2aW91ciwgcmF0 aGVyIHRoYW4gaW4gdGhpcyBkcmFmdC4gIAoKVG9tIFRheWxvcjogWWVzLCB0aGlzIHdvdWxkIGZp dCBpbnRvIGEgZHJhZnQgSSB3YW50ZWQgdG8gcmV2aXNlLgoKU3RldmVuIEJsYWtlOiBQb3NzaWJs eSBjb3VsZCBkbyBoYW5kbGUgaXQgd2l0aCBuZXV0cmFsICJmdW5jdGlvbmFsIGVsZW1lbnQiCmxh bmd1YWdlLgoKUGhpbGlwIEVhcmRsZXk6IE5vdCBzdXJlIHRoaXMgd291bGQgd29yay4KClRvbSBU YXlsb3I6IElzIHRoaXMgcmVhZHkgdG8gYmVjb21lIGEgV0cgZHJhZnQ/CgpTdGV2ZW4gQmxha2U6 IERyYWZ0IGhhcyBiZWVuIHJlYWQgYnkgYSBmZXcgcGVvcGxlLiAgUGxlYXNlIHNlbmQgY29tbWVu dHMgdG8KdGhlIG1haWxpbmcgbGlzdC4gIFRoZW4gd2UgY2FuIGRlY2lkZSB3aGV0aGVyIHRvIGJl Y29tZSBhIFdHIGRyYWZ0OyB0aGUgCnF1ZXN0aW9uIHdpbGwgYmUgY2FsbGVkIG9uIGxpc3QuCgoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCm8gQ29udHJvbGxlZCBMb2FkIGFuZCBTaW5nbGUgTWFya2lu ZyBFZGdlIEJlaGF2aW91cnMKICBkcmFmdC1pZXRmLXBjbi1jbC1lZGdlLWJlaGF2aW91ci0wMQog IGRyYWZ0LWlldGYtcGNuLXNtLWVkZ2UtYmVoYXZpb3VyLTAxCiAgaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy8wOW5vdi9zbGlkZXMvcGNuLTMucGRmCgoKVG9tIFRheWxvciBwcmVzZW50 ZWQgc2xpZGVzIG9uIHRoZSBTaW5nbGUgTWFya2luZyAoU00pIGFuZCBDb250cm9sbGVkIExvYWQg KENMKQplZGdlIGJlaGF2aW91cnMuICBTTSBpcyBiaWxsZWQgYXMgaW50ZXJtZWRpYXRlIHN0ZXAg dG8gQ0wsIHNvIHdlIGFyZSB0cnlpbmcgdG8gCmtlZXAgdGhlbSBpbiBzdGVwIGFzIHNpbWlsYXIg dG8gZWFjaCBvdGhlci4KClRvbSBvdXRsaW5lZCB0aGUgaGlzdG9yeSBvZiB0aGUgZHJhZnRzIOKA kyB3aGF0IGlzIHJlcG9ydGVkIGFuZCB3aGVuIOKAkyBhbmQgaG93IAp0aGlzIGhhcyBhbHRlcmVk IGJldHdlZW4gdGhlIHZlcnNpb25zIG9mIHRoZSBkcmFmdHMuCgpQaGlsaXAgRWFyZGxleTogRXZl biBpbiB0aGUgQ0wgY2FzZSwgdGhlIGluZm8gYWJvdXQgdGhlIGFjdHVhbCBsZXZlbCBvZiBDTEUg aXMKdmFsdWFibGUuCgpQaGlsaXAgRWFyZGxleTogUmVwb3J0aW5nIGluZm8gYWJvdXQgYWxsIHRo ZSByYXRlcyBpcyBub3QgbXVjaCBkaWZmZXJlbnQgZnJvbSAKcmVwb3J0aW5nIG9uZSBiaXQsIGFz IGl04oCZcyBpbiBvbmUgbWVzc2FnZS4KClBoaWxpcCBFYXJkbGV5OiBQbGVhc2UgY2FuIHdlIGNv bmZpcm0gdGhhdCB3ZSBhZ3JlZSB3aXRoIHRoaXMgbm93LCBzbyB3ZSBkb27igJl0CnJlLXZpc2l0 IGl0IGFnYWluIGFzIHRob3VnaCB3ZSBhZ3JlZWQgdGhpcyBsYXN0IHRpbWUuCgpObyBkaXNhZ3Jl ZW1lbnQgd2FzIGV4cHJlc3NlZCBpbiB0aGUgcm9vbS4KCkxhcnMgRWdnZXJ0OiBEb27igJl0IHBy ZS1wcm9jZXNzIGRhdGEsIHJhdyBpbmZvIGlzIGdvb2Qgb3IgYmV0dGVyIGZvciB1c2UgY2FzZXMg CmluIHRoZSBmdXR1cmUgZG9u4oCZdCBrbm93IGFib3V0IG5vdy4gIERvbuKAmXQgY3V0IG9mZiBh dmVudWVzLiAKCkJvYiBCcmlzY29lOiBJZiBkb2luZyBwZXJpb2RpYyByZXBvcnRpbmcsIGhhdmUg Z290IHRvIHNheSB3aGVuIHRvIHN0b3AsIGdpdmVuIAptb3N0IHBhaXJzIHdvbuKAmXQgaGF2ZSBh bnkgdHJhZmZpYyBvbiwgc28gaXQncyBwb2ludGxlc3MgZG9pbmcgcGVyaW9kaWMKcmVwb3J0aW5n IG9uIHRoZW0uIAoKVG9tIFRheWxvcjogVGhpcyBoYXMgaW1wbGljYXRpb25zIGZvciB0aGUgc2ln bmFsaW5nIHByb3RvY29sLiAgTmVlZCByZWxpYWJsZSAKa2VlcCBhbGl2ZSBhbnl3YXk/CgpCb2Ig QnJpc2NvZTogU29tZSBzaWduYWxpbmcgYmV0d2VlbiBpbmdyZXNzICYgZWdyZXNzIHRvIGNsZWFy IGRvd24gbGFzdCBmbG93PwpPdGhlcndpc2UgcXVpdGUgd2FzdGVmdWwgZ2l2ZW4gbW9zdCBwYWly cyBkb27igJl0IGhhdmUgYW55IHRyYWZmaWMuCgpSdWVkaWdlciBHZWliOiBJIGZhdm91ciBzaW1w bGUgc29sdXRpb24gYnV0IHdpbGwgbm90IGZpZ2h0IGZvciBpdCwgYXMgbm90IAppbnRlcmVzdGVk IGluIHRoZSBSU1ZQIHN0eWxlIGNhc2UuICBJIHdvdWxkIGxpa2UgUENOIHdpdGhvdXQgdGhlIHNp Z25hbGluZyAKc3R1ZmY7IGkuZS4sIG1hcmtpbmcgaW4gY29yZSB3aXRob3V0IHNpZ25hbGluZyBt ZWNoYW5pc21zIGF0IGVkZ2VzLgoKVG9tIFRheWxvcjogSG93IGNhbiBpbmdyZXNzIGZpbmQgb3V0 IHdoYXQgdG8gYmxvY2sgd2l0aG91dCBzaWduYWxpbmc/IE9yIHdpbGwgCnBrdHMgYmUgZHJvcHBl ZCBhdCBlZ3Jlc3M/IERlY2lzaW9uIGlzIGVuZm9yY2VkIGF0IGluZ3Jlc3MuIAoKVG9tIFRheWxv cjogRGlzY3Vzc2lvbiBpc27igJl0IHRpZWQgdG8gYSBwYXJ0aWN1bGFyIHByb3RvY29sLgoKVG9t IFRheWxvcjogU3VtbWFyeS9kZWNpc2lvbjogd2XigJlsbCBzaWduYWwgcmF3IHJhdGVzIGZvciBm dXR1cmUgZmxleGliaWxpdHksCmV0Yy4KClRvbSBUYXlsb3I6IERvIHdlIHJlcG9ydCBwZXJpb2Rp Y2FsbHkgb3IgdHJ5IHRvIG9wdGltaXNlPyAgRW5naW5lZXJpbmcgZGVjaXNpb24K4oCTIGhvdyBm cmVxdWVudGx5IGFyZSB0aHJlc2hvbGRzIGNyb3NzZWQgY29tcGFyZWQgd2l0aCBwZXJpb2RpYyBy ZXBvcnRzPwoKTGFycyBFZ2dlcnQ6IFBlcmlvZGljYWxseSBtZWFucyBmaXhlZCBpbnRlcnZhbHMg Zm9yIHJlbGlhYmlsaXR5LiBTbyBhIGdhcCBpcyAKYXNzdW1lZCB0byBtZWFuIGxvc3MuIAoKU3Rl dmVuIEJsYWtlOiBSYW5kb21pc2Ugc2xpZ2h0bHkuICBJRVRGIGhpc3RvcmljYWxseSBhZ2FpbnN0 IGZpeGVkIGludGVydmFscyAKYmVjYXVzZSBtZXNzYWdlcyBjYW4gZ2V0IHN5bmNocm9uaXplZC4K ClRvbSBUYXlsb3I6IE5lZWRzIGRpc2N1c3Npb24gb24gbGlzdC4KClRvbSBUYXlsb3I6IElzIHNt b290aGluZyBlc3NlbnRpYWwgb3IgYSBkZXRhaWwgbGVmdCB0byBpbXBsZW1lbnRhdGlvbj8KUXVl c3Rpb24gaXMgc3dpdGNoaW5nIGJldHdlZW4gYmxvY2tpbmcgJiBhZG1pdCBzdGF0ZSDigJMgaXMg c21vb3RoaW5nIGhlcmUgbmljZT8KU2ltdWxhdGlvbnMgaGF2ZSBiZWVuIGRvbmUgd2l0aCBleHBv bmVudGlhbCBzbW9vdGhpbmcuCgpTdGV2ZW4gQmxha2U6IERyYWZ0cyBzYXkgcGFyYW1ldGVycyBk b27igJl0IG1hdHRlci4gQnV0IHdlIG5lZWQgdG8gcmVjb21tZW5kIApzb21ldGhpbmc7IGUuZy4s IOKAnGFib3V0IMK94oCdIG9yIOKAnHNldCB0byAxIGlzIG9r4oCdLiAgT3RoZXJ3aXNlIHdoeSBy ZWNvbW1lbmQgaXQ/CgpUb20gVGF5bG9yOiBRdWVzdGlvbiBvZiBob3cgcXVpY2tseSB5b3UgcmVh Y3QgdG8gc3R1ZmYsIGFuZCB3aGV0aGVyIHlvdSBjYW4gCmluZHVjZSBjb3JyZWxhdGlvbiBlZmZl Y3QgYnkgcmVhY3RpbmcgdG9vIHF1aWNrbHkuCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm8gUGln Z3liYWNraW5nIEVkZ2UgQmVoYXZpb3VyCiAgZHJhZnQtdGF5bG9yLXBjbi1waWdneWJhY2stZWRn ZS1iZWhhdmlvdXItMDAKICBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA5bm92L3Ns aWRlcy9wY24tNC5wZGYKClRvbSBUYXlsb3IgcHJlc2VudGVkIHNsaWRlcyBvbiB0aGUgcGlnZ3li YWNraW5nIGVkZ2UgYmVoYXZpb3VyLgoKRnJhbmNvaXMgTGUgRmF1Y2hlcjogRm9yIHNvbWUgc2ln bmFsaW5nIHByb3RvY29scywgdGhleeKAmXJlIHJlY2VpdmVyIGRyaXZlbjsKaS5lLiwgIHJlc2Vy dmF0aW9uIHJlcXVlc3QgY29tZXMgZnJvbSBlZ3Jlc3Mgc2lkZS4gIEhhdmUgeW91IHRob3VnaHQg YWJvdXQKdGhpcyBjYXNlPyAgVGhlIGdvYWwgaXMgYSBnb29kIHRoaW5nLiAgU2VlIHRoZSBvbGQg UlNWUCBkcmFmdCBhcyBzb3VyY2Ugb2YgCmluZm8uCgpOb3QgbWFueSBwZW9wbGUgaGF2ZSByZWFk IGRyYWZ0LiAgUG90ZW50aWFsbHkgYSBXRyBpdGVtLCBhZnRlciBpdCBpcyByZXZpc2VkCnRvIGFk ZHJlc3MgRnJhbmNvaXMgY29tbWVudC4KCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbyBIb3NlIEVk Z2UgQmVoYXZpb3VyCiAgZHJhZnQta2FyYWdpYW5uaXMtcGNuLWhvc2UtZWRnZS1iZWhhdmlvdXIt MDAKICBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA5bm92L3NsaWRlcy9wY24tMi5w ZGYKClJvbmFsZCBpbiAndCBWZWx0IHByZXNlbnRlZCBzbGlkZXMgb24gdGhlIEhPU0UgZWRnZSBi ZWhhdmlvdXIuICBUaGUgbWFya2luZyAKYmVoYXZpb3VyIGRyYWZ0IChkcmFmdC1pZXRmLXBjbi1t YXJraW5nLWJlaGF2aW91ci0wNSkgc2F5cyB0aGF0IEVUTS1tYXJrZWQKcGFja2V0cyBTSE9VTEQg YmUgcHJlZmVyZW50aWFsbHkgZHJvcHBlZCDigJMgd2hpY2ggaXMgbm90IHdoYXQgdGhlIEhPU0Ug ZWRnZQpiZWhhdmlvdXIgd2FudHMuCgpMYXJzIEVnZ2VydDogQ2Fu4oCZdCB1cGRhdGUgYSBzdGFu ZGFyZHMtdHJhY2sgZG9jdW1lbnQgaW4gYW4gaW5mb3JtYXRpb25hbCBlZGdlCmJlaGF2aW91ciBk b2N1bWVudC4KClBoaWxpcCBFYXJkbGV5OiBJdCBzZWVtcyBkb2RneSB0byBhZG1pdCBhIGZsb3cg aWYgdGhlIHNpZ25hbGluZyByZXF1ZXN0IGlzIAp1bm1hcmtlZCB3aGF0ZXZlciB0aGUgQ0xFLiAg VGhpcyBnaXZlcyBhbiBpbmNlbnRpdmUgdG8gc2VuZCAxMDAwcyBvZiByZXF1ZXN0CnJlcGVhdGVk bHkgdW50aWwgb25lIHdpbGwgZ2V0IHRocm91Z2guCgpOb3QgbWFueSBwZW9wbGUgaGF2ZSByZWFk IHRoZSBkcmFmdC4KClN0ZXZlbiBCbGFrZTogTmVlZCBkaXNjdXNzaW9uIG9uIGxpc3QgYmVmb3Jl IG1ha2luZyB0aGlzIGRyYWZ0IGEgd29ya2luZyBncm91cAppdGVtLCBidXQgdGhlIGJlaGF2aW91 ciBuZWVkcyB0byB3b3JrIHdpdGggdGhlIGFncmVlZCBtYXJraW5nIGJlaGF2aW91ciBmb3IKRVRN LW1hcmtlZCBwYWNrZXRzLiAgSSBiZWxpZXZlIHRoYXQgaXQgY2FuIHByb2JhYmx5IGNhbiBiZSBt YWRlIHRvIHdvcmsuCgpTdGV2ZW4gQmxha2U6IEVDTVAgc3VwcG9ydCAtIG5vdCBzYWZlIHRvIGFz c3VtZSB0aGF0IHBhdGggc2lnbmFsaW5nIG1lc3NhZ2UKd2lsbCBmb2xsb3cgdGhlIHNhbWUgcGF0 aCBhcyB0aGUgZGF0YSDigJMgc28gbm90IHNhZmUgdG8gc2F5IHRoYXQgdGhpcwpzY2hlbWUgc29s dmVzIHRoZSBFQ01QIHN1cHBvcnQgaXNzdWUuCgpGcmFuY29pcyBsZSBGYXVjaGVyOiBJcyBpdCBk ZXNpcmFibGUgdGhhdCwgaW4gY2FzZSB0aGUgbmV0d29yayBpcyBtYXJraW5nIDUwJSAKb2YgcGFj a2V0cywgdGhhdCB3ZSBzdGlsbCBhY2NlcHQgNTAlIG9mIG5ldyBjYWxscz8KClN0ZXZlbiBCbGFr ZTogU29tZW9uZSBwbGVhc2Ugc2VuZCBpbmZvIHRvIHRoZSBtYWlsaW5nIGxpc3QuCgpCb2IgQnJp c2NvZTogU3RhdHVzIHVwZGF0ZSBvbiB0aGUgRUNOIHR1bm5lbGxpbmcgZHJhZnQgaW4gdHN2d2c6 IHRoaW5rcyBpc3N1ZXMKaGF2ZSBub3cgYmVlbiByZXNvbHZlZCwgYnV0IHRob3VnaHQgdGhpcyBi ZWZvcmUuICBUaGVuIDMtaW4tMSBjYW4gZ28gYWhlYWQgdG8KbGFzdCBjYWxsLCBldGMuCgoKTWVl dGluZyBhZGpvdXJuZWQuCg== --=_b10f48f81409aa5dd217671f0c6262c9-- From karagian@cs.utwente.nl Thu Nov 12 07:02:35 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5E13A691F for ; Thu, 12 Nov 2009 07:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGWDjUnQ+cnw for ; Thu, 12 Nov 2009 07:02:35 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id A9BE43A69AB for ; Thu, 12 Nov 2009 07:02:34 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nACF2r1d014923; Thu, 12 Nov 2009 16:02:56 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> Date: Thu, 12 Nov 2009 16:02:49 +0100 Message-ID: <004c01ca63a9$36a9c900$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acpjhl9a06nwVmH2Tp2Uppdf1wLuYwAIjBtA X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Nov 2009 16:02:59 +0100 (MET) Subject: Re: [PCN] **DRAFT** IETF 76 PCN meeting minutes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:02:35 -0000 Hi Steven Thanks for sending the (draft) PCN meeting minutes! Regarding the minutes over the signaling requirements draft and the CL and SM edge behaviour drafts I would like to have a discussion with Tom before commenting on the comments/conlcuison of the meeting. Regarding the encoding comparison draft and the PCN HOSE edge behaviour draft, I will provide comments in subsequent drafts. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: donderdag 12 november 2009 11:53 > To: pcn@ietf.org > Subject: [PCN] **DRAFT** IETF 76 PCN meeting minutes > > Howdy. > > The draft meeting minutes from Tuesday are attached. Thanks > to Philip for taking them! > > Please send comments/corrections to the list within the next week. > > > Regards, > > // Steve > From karagian@cs.utwente.nl Thu Nov 12 07:17:47 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353C53A6BE5 for ; Thu, 12 Nov 2009 07:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FH98kgdkqgd for ; Thu, 12 Nov 2009 07:17:46 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 12F543A6BE0 for ; Thu, 12 Nov 2009 07:17:45 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nACFI9n0018912; Thu, 12 Nov 2009 16:18:12 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> Date: Thu, 12 Nov 2009 16:18:05 +0100 Message-ID: <004d01ca63ab$582e7ec0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acpjhl9a06nwVmH2Tp2Uppdf1wLuYwAIxdGQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Nov 2009 16:18:13 +0100 (MET) Subject: [PCN] Comments on encoding comparison discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:17:47 -0000 Hi Steven, Hi all The PCN encoding comparison draft minutes and my comments on them, are listed below! > o Encoding Comparison > draft-ietf-pcn-encoding-comparison-01 > http://www.ietf.org/proceedings/09nov/slides/pcn-5.pdf > Steven Blake presented the slides on behalf of Kwok Ho Chan, > who was not > able to attend. Thanks to Kwok for his work on it. > Steven polled the room to see how many had read the draft; few had. > Lars Eggert: It got added to the charter - so the people who > wanted it added to charter are expected/obliged to review it. > Steven Blake: Want to go to working group last call before the end of year. Georgios: I would like that too! > Philip Eardley: I have 2 comments that I think need to be solved before it is > ready for LC: > - It doesn't give a good sense of why baseline was chosen Georgios: Phil, please provide more detailed comments on this, such that we can update the draft accordingly! > - It doesn't give good sense of the pros & cons of various working-group > proposed extension encodings. Georgios: Please note that the goal of the current PCN encoding comparison draft is to present the decissions that have been made up to the time that the solution described in the baseline encoding draft has been chosen. The current version of the draft does not discuss the selection process of other extended proposed extension encodings. Phil, do you think that it makes sense to also include information about the selection process of the other proposed extension encodings? > Steven Blake asked for the status of draft-ietf-pcn-3-state-encoding and > draft-ietf-pcn-3-in-1-encoding. One of them (which?) is blocked due to a > dependency on the ECN tunneling draft. > Bob Briscoe: ECN tunnelling draft-related encoding status - I think/hope that I > have resolved the blocking issues with David Black, so the draft should soon be > able to move forward. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: donderdag 12 november 2009 11:53 > To: pcn@ietf.org > Subject: [PCN] **DRAFT** IETF 76 PCN meeting minutes > > Howdy. > > The draft meeting minutes from Tuesday are attached. Thanks > to Philip for taking them! > > Please send comments/corrections to the list within the next week. > > > Regards, > > // Steve > From karagian@cs.utwente.nl Thu Nov 12 07:32:42 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C953A68CB for ; Thu, 12 Nov 2009 07:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.016 X-Spam-Level: X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhEvIZkCaXeU for ; Thu, 12 Nov 2009 07:32:41 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id F38B83A688A for ; Thu, 12 Nov 2009 07:32:40 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nACFX2RS023018; Thu, 12 Nov 2009 16:33:06 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> Date: Thu, 12 Nov 2009 16:32:58 +0100 Message-ID: <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acpjhl9a06nwVmH2Tp2Uppdf1wLuYwAJPwWw X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Nov 2009 16:33:08 +0100 (MET) Subject: [PCN] Comments on HOSE edge behaviour discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:32:42 -0000 Hi Steven, Hi all The PCN HOSE edge behaviour draft minutes and my comments on them, are listed below! > o Hose Edge Behaviour > draft-karagiannis-pcn-hose-edge-behaviour-00 > http://www.ietf.org/proceedings/09nov/slides/pcn-2.pdf > Ronald in 't Velt presented slides on the HOSE edge behaviour. The marking > behaviour draft (draft-ietf-pcn-marking-behaviour-05) says that ETM-marked > packets SHOULD be preferentially dropped - which is not what the HOSE edge > behaviour wants. > Lars Eggert: Can't update a standards-track document in an informational edge > behaviour document. Georgios: Lars please note: In Section 2.2 of http://www.ietf.org/id/draft-ietf-pcn-marking-behaviour-05.txt is specified that: o PCN-packets that arrive at the PCN-node already excess-traffic- marked SHOULD be preferentially dropped; In Appendix B4 is mentioned: "The dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in recognition that other dropping behaviour may be preferred in particular circumstances, for example: (1) with the "marked flow" termination edge behaviour, preferential dropping of unmarked packets may be better [Menth09]; (2) tail dropping may make PCN-marking behaviour easier to implement on current routers. Exactly what "preferentially dropped" means is left to the implementation. It is also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant." The above emphasizes that in particular circummstances, preferential dropping of unmarked packets should be possible. Such as circumstnace is specified in the HOSE edge behaviour draft. > Philip Eardley: It seems dodgy to admit a flow if the signaling request is > unmarked whatever the CLE. This gives an incentive to send 1000s of request > repeatedly until one will get through. Georgios: Phil, I do not understand the comment! Are you saying that QoS signaling protocols, such as RSVP, cannot be used in such situations because no RSVP PATH messages will get through? Please explain! > Not many people have read the draft. > Steven Blake: Need discussion on list before making this draft a working group > item, but the behaviour needs to work with the agreed marking behaviour for > ETM-marked packets. I believe that it can probably can be made to work. Georgios: I agree! > Steven Blake: ECMP support - not safe to assume that path signaling message > will follow the same path as the data - so not safe to say that this > scheme solves the ECMP support issue. Georgios: Steve, please note that from the point of view of the followed communtication path for signaling messages and data packets, the same assumptions are used as the ones applied and used by RSVP PATH and data packets. Thus if the RSVP signaling works to support QOS, then the proposed ECMP solution will also work. > Francois le Faucher: Is it desirable that, in case the network is marking 50% > of packets, that we still accept 50% of new calls? Georgios: Francois, I do not understand the comment, please elaborate! > Steven Blake: Someone please send info to the mailing list. > Bob Briscoe: Status update on the ECN tunnelling draft in tsvwg: thinks issues > have now been resolved, but thought this before. Then 3-in-1 can go ahead to > last call, etc. Best regards, Georgios From slblake@petri-meat.com Thu Nov 12 16:56:44 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6874B28C0D8 for ; Thu, 12 Nov 2009 16:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nCej2+rMZxA for ; Thu, 12 Nov 2009 16:56:43 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id AEEE33A6358 for ; Thu, 12 Nov 2009 16:56:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8kTJ-0002Cm-F3; Thu, 12 Nov 2009 19:57:05 -0500 MIME-Version: 1.0 Date: Thu, 12 Nov 2009 19:57:05 -0500 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> Message-ID: <36fbd976ffe905dacd384b5af0330a00@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] Comments on HOSE edge behaviour discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:56:44 -0000 On Thu, 12 Nov 2009 16:32:58 +0100, "Georgios Karagiannis" wrote: >> Steven Blake: ECMP support - not safe to assume that path signaling > message will follow the same path as the data - so not safe to say that this >> scheme solves the ECMP support issue. > > Georgios: Steve, please note that from the point of view of the followed > communtication path for signaling messages and data packets, > the same assumptions are used as the ones applied and used by RSVP PATH and > data packets. Thus if the RSVP signaling works to support QOS, then the proposed ECMP > solution will also work. Georgios, I don't believe that is correct. Can you comment Francois? Regards, // Steve From carlberg@g11.org.uk Fri Nov 13 06:51:20 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930B93A69C3 for ; Fri, 13 Nov 2009 06:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsgq29A7yoRn for ; Fri, 13 Nov 2009 06:51:19 -0800 (PST) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id B59343A69A5 for ; Fri, 13 Nov 2009 06:51:19 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:65254 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N8xUx-0003yS-T0; Fri, 13 Nov 2009 14:51:40 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <36fbd976ffe905dacd384b5af0330a00@petri-meat.com> Date: Fri, 13 Nov 2009 09:51:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2B86CE7C-95D1-4D11-A63E-3E929C2FBD06@g11.org.uk> References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> <36fbd976ffe905dacd384b5af0330a00@petri-meat.com> To: Steven Blake X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: pcn@ietf.org Subject: Re: [PCN] Comments on HOSE edge behaviour discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 14:51:20 -0000 the answer is configuration and per-implementation dependent. A number = of implementations have a default setting of per-flow or per-destination = form of ECMP, which is what would be needed for RSVP. The danger arises = if an in-path router is configured for per-packet ECMP -- some = vendors/implementations support this, some don't. -ken On Nov 12, 2009, at 7:57 PM, Steven Blake wrote: > On Thu, 12 Nov 2009 16:32:58 +0100, "Georgios Karagiannis" > wrote: >=20 >>> Steven Blake: ECMP support - not safe to assume that path signaling >> message will follow the same path as the data - so not safe to say = that > this >>> scheme solves the ECMP support issue. >>=20 >> Georgios: Steve, please note that from the point of view of the = followed=20 >> communtication path for signaling messages and data packets,=20 >> the same assumptions are used as the ones applied and used by RSVP = PATH > and >> data packets. Thus if the RSVP signaling works to support QOS, then = the > proposed ECMP >> solution will also work. >=20 > Georgios, >=20 > I don't believe that is correct. Can you comment Francois? >=20 >=20 > Regards, >=20 > // Steve > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Sun Nov 15 05:09:37 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1AB3A692C for ; Sun, 15 Nov 2009 05:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU5evpbVb+JK for ; Sun, 15 Nov 2009 05:09:36 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 38FCD3A690F for ; Sun, 15 Nov 2009 05:09:35 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 13:10:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 13:05:14 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC05DF8AE7@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Comments on encoding comparison discussion Thread-Index: Acpjhl9a06nwVmH2Tp2Uppdf1wLuYwAIxdGQAJKzpVE= References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> <004d01ca63ab$582e7ec0$810c5982@dynamic.ewi.utwente.nl> From: To: , , X-OriginalArrivalTime: 15 Nov 2009 13:10:06.0016 (UTC) FILETIME=[F333BC00:01CA65F4] Subject: Re: [PCN] Comments on encoding comparison discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 13:09:37 -0000 > Philip Eardley: I have 2 comments that I think need to be solved = before it is > ready for LC: > - It doesn't give a good sense of why baseline was chosen Georgios: Phil, please provide more detailed comments on this, such that we can update the draft accordingly! =20 [phil] when you read the draft, you would be hard pushed to explain to = someone else why the baseline encoding was selected. it would even take = some effort to identify what the baseline was.=20 > - It doesn't give good sense of the pros & cons of various = working-group > proposed extension encodings. Georgios: Please note that the goal of the current PCN encoding = comparison draft is to present the decissions that have been made up to the time that the solution described in the baseline encoding draft has been chosen. The current version of the = draft does not discuss the selection process of other extended proposed extension encodings. Phil, do you think that it makes sense to also include information about the selection process of the other proposed extension encodings? [phil] the doc should explain what the idea of extensions to the = baseline is, and why that idea was adopted. =20 [phil] i also think the doc should give a sense of the pros and cons of = the various extension encodings that are still being pursued. i accept = it needs some careful word-smithing in view of the fact that they have = not been taken through WG last call etc.=20 From karagian@cs.utwente.nl Mon Nov 16 01:36:43 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFB93A6813 for ; Mon, 16 Nov 2009 01:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHWnaSLhJLji for ; Mon, 16 Nov 2009 01:36:42 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 2E7703A67A3 for ; Mon, 16 Nov 2009 01:36:42 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nAG9aSSx018639; Mon, 16 Nov 2009 10:36:32 +0100 (MET) From: "Georgios Karagiannis" To: "'ken carlberg'" , "'Steven Blake'" References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> <36fbd976ffe905dacd384b5af0330a00@petri-meat.com> <2B86CE7C-95D1-4D11-A63E-3E929C2FBD06@g11.org.uk> Date: Mon, 16 Nov 2009 10:36:28 +0100 Message-ID: <001c01ca66a0$48e94c90$810c5982@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 Thread-Index: AcpkcNg1brEgVl6LQdC6tqV/ZgGEJACLyLYA In-Reply-To: <2B86CE7C-95D1-4D11-A63E-3E929C2FBD06@g11.org.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 16 Nov 2009 10:36:33 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Comments on HOSE edge behaviour discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 09:36:43 -0000 Hi Ken Thanks for the clarification! In my reasoning I have assumed that the default setting of ECMP is per-flow or per-destination form. We could include this assumption in the HOSE edge behaviour draft! Best regards, Georgios > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: vrijdag 13 november 2009 15:52 > To: Steven Blake > Cc: Georgios Karagiannis; pcn@ietf.org > Subject: Re: [PCN] Comments on HOSE edge behaviour discussion > > the answer is configuration and per-implementation dependent. > A number of implementations have a default setting of > per-flow or per-destination form of ECMP, which is what would > be needed for RSVP. The danger arises if an in-path router > is configured for per-packet ECMP -- some > vendors/implementations support this, some don't. > > -ken > > > On Nov 12, 2009, at 7:57 PM, Steven Blake wrote: > > > On Thu, 12 Nov 2009 16:32:58 +0100, "Georgios Karagiannis" > > wrote: > > > >>> Steven Blake: ECMP support - not safe to assume that path > signaling > >> message will follow the same path as the data - so not safe to say > >> that > > this > >>> scheme solves the ECMP support issue. > >> > >> Georgios: Steve, please note that from the point of view of the > >> followed communtication path for signaling messages and > data packets, > >> the same assumptions are used as the ones applied and used by RSVP > >> PATH > > and > >> data packets. Thus if the RSVP signaling works to support > QOS, then > >> the > > proposed ECMP > >> solution will also work. > > > > Georgios, > > > > I don't believe that is correct. Can you comment Francois? > > > > > > Regards, > > > > // Steve > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > From carlberg@g11.org.uk Mon Nov 16 03:28:31 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984F028C11E for ; Mon, 16 Nov 2009 03:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38K7kx1uIo8y for ; Mon, 16 Nov 2009 03:28:30 -0800 (PST) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id BB61928C119 for ; Mon, 16 Nov 2009 03:28:30 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:55156 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N9zkq-0008F4-Gl; Mon, 16 Nov 2009 11:28:20 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <001c01ca66a0$48e94c90$810c5982@dynamic.ewi.utwente.nl> Date: Mon, 16 Nov 2009 06:28:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7569C719-4541-41CC-9640-C945D354F85F@g11.org.uk> References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> <36fbd976ffe905dacd384b5af0330a00@petri-meat.com> <2B86CE7C-95D1-4D11-A63E-3E929C2FBD06@g11.org.uk> <001c01ca66a0$48e94c90$810c5982@dynamic.ewi.utwente.nl> To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: pcn@ietf.org Subject: Re: [PCN] Comments on HOSE edge behaviour discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:28:31 -0000 Georgios, Personally, I would be more cautious in the wording of your document = regarding EMCP. For instance, I wouldn't assume the per-flow or = per-destination is the default case in all instances. Instead, I would = the more neutral stance and state that the these along with per-packet = configurations exist, and that in order to use the Hose model, the = per-flow/per-packet MUST be used. -ken On Nov 16, 2009, at 4:36 AM, Georgios Karagiannis wrote: > Hi Ken >=20 > Thanks for the clarification!=20 > In my reasoning I have assumed that the default setting of ECMP is=20 > per-flow or per-destination form. >=20 > We could include this assumption in the HOSE edge behaviour draft! >=20 > Best regards, > Georgios >=20 >=20 >> -----Original Message----- >> From: ken carlberg [mailto:carlberg@g11.org.uk]=20 >> Sent: vrijdag 13 november 2009 15:52 >> To: Steven Blake >> Cc: Georgios Karagiannis; pcn@ietf.org >> Subject: Re: [PCN] Comments on HOSE edge behaviour discussion >>=20 >> the answer is configuration and per-implementation dependent.=20 >> A number of implementations have a default setting of=20 >> per-flow or per-destination form of ECMP, which is what would=20 >> be needed for RSVP. The danger arises if an in-path router=20 >> is configured for per-packet ECMP -- some=20 >> vendors/implementations support this, some don't. >>=20 >> -ken >>=20 >>=20 >> On Nov 12, 2009, at 7:57 PM, Steven Blake wrote: >>=20 >>> On Thu, 12 Nov 2009 16:32:58 +0100, "Georgios Karagiannis" >>> wrote: >>>=20 >>>>> Steven Blake: ECMP support - not safe to assume that path=20 >> signaling >>>> message will follow the same path as the data - so not safe to say=20= >>>> that >>> this >>>>> scheme solves the ECMP support issue. >>>>=20 >>>> Georgios: Steve, please note that from the point of view of the=20 >>>> followed communtication path for signaling messages and=20 >> data packets,=20 >>>> the same assumptions are used as the ones applied and used by RSVP=20= >>>> PATH >>> and >>>> data packets. Thus if the RSVP signaling works to support=20 >> QOS, then=20 >>>> the >>> proposed ECMP >>>> solution will also work. >>>=20 >>> Georgios, >>>=20 >>> I don't believe that is correct. Can you comment Francois? >>>=20 >>>=20 >>> Regards, >>>=20 >>> // Steve >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>=20 >=20 >=20 From karagian@cs.utwente.nl Mon Nov 16 03:53:54 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0894228C144 for ; Mon, 16 Nov 2009 03:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUx1JQLFMRT0 for ; Mon, 16 Nov 2009 03:53:53 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 0293B28C0F4 for ; Mon, 16 Nov 2009 03:53:52 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id nAGBrcas001517; Mon, 16 Nov 2009 12:53:42 +0100 (MET) From: "Georgios Karagiannis" To: "'ken carlberg'" References: <51ae41c19a4ab2e8e6294c1788ef20a1@petri-meat.com> <004e01ca63ad$6d1d28c0$810c5982@dynamic.ewi.utwente.nl> <36fbd976ffe905dacd384b5af0330a00@petri-meat.com> <2B86CE7C-95D1-4D11-A63E-3E929C2FBD06@g11.org.uk> <001c01ca66a0$48e94c90$810c5982@dynamic.ewi.utwente.nl> <7569C719-4541-41CC-9640-C945D354F85F@g11.org.uk> Date: Mon, 16 Nov 2009 12:53:36 +0100 Message-ID: <006e01ca66b3$71488e40$810c5982@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 Thread-Index: Acpmr/F4bXGe+LQrQ6i7N9Ss5tJgQwAA2e6w In-Reply-To: <7569C719-4541-41CC-9640-C945D354F85F@g11.org.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 16 Nov 2009 12:53:43 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Comments on HOSE edge behaviour discussion X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:53:54 -0000 Hi Ken Okay! Thanks! Best regards, Georgios > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: maandag 16 november 2009 12:28 > To: Georgios Karagiannis > Cc: 'Steven Blake'; pcn@ietf.org > Subject: Re: [PCN] Comments on HOSE edge behaviour discussion > > Georgios, > > Personally, I would be more cautious in the wording of your > document regarding EMCP. For instance, I wouldn't assume the > per-flow or per-destination is the default case in all > instances. Instead, I would the more neutral stance and > state that the these along with per-packet configurations > exist, and that in order to use the Hose model, the > per-flow/per-packet MUST be used. > > -ken > > > On Nov 16, 2009, at 4:36 AM, Georgios Karagiannis wrote: > > > Hi Ken > > > > Thanks for the clarification! > > In my reasoning I have assumed that the default setting of ECMP is > > per-flow or per-destination form. > > > > We could include this assumption in the HOSE edge behaviour draft! > > > > Best regards, > > Georgios > > > > > >> -----Original Message----- > >> From: ken carlberg [mailto:carlberg@g11.org.uk] > >> Sent: vrijdag 13 november 2009 15:52 > >> To: Steven Blake > >> Cc: Georgios Karagiannis; pcn@ietf.org > >> Subject: Re: [PCN] Comments on HOSE edge behaviour discussion > >> > >> the answer is configuration and per-implementation dependent. > >> A number of implementations have a default setting of per-flow or > >> per-destination form of ECMP, which is what would be > needed for RSVP. > >> The danger arises if an in-path router is configured for > per-packet > >> ECMP -- some vendors/implementations support this, some don't. > >> > >> -ken > >> > >> > >> On Nov 12, 2009, at 7:57 PM, Steven Blake wrote: > >> > >>> On Thu, 12 Nov 2009 16:32:58 +0100, "Georgios Karagiannis" > >>> wrote: > >>> > >>>>> Steven Blake: ECMP support - not safe to assume that path > >> signaling > >>>> message will follow the same path as the data - so not > safe to say > >>>> that > >>> this > >>>>> scheme solves the ECMP support issue. > >>>> > >>>> Georgios: Steve, please note that from the point of view of the > >>>> followed communtication path for signaling messages and > >> data packets, > >>>> the same assumptions are used as the ones applied and > used by RSVP > >>>> PATH > >>> and > >>>> data packets. Thus if the RSVP signaling works to support > >> QOS, then > >>>> the > >>> proposed ECMP > >>>> solution will also work. > >>> > >>> Georgios, > >>> > >>> I don't believe that is correct. Can you comment Francois? > >>> > >>> > >>> Regards, > >>> > >>> // Steve > >>> _______________________________________________ > >>> PCN mailing list > >>> PCN@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pcn > >> > > > > > From rfc-editor@rfc-editor.org Mon Nov 23 16:34:41 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E4C3A6AE6; Mon, 23 Nov 2009 16:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.137 X-Spam-Level: X-Spam-Status: No, score=-17.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e27SnVbM9N0T; Mon, 23 Nov 2009 16:34:40 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id ABD243A6AE4; Mon, 23 Nov 2009 16:34:40 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id DD045372B78; Mon, 23 Nov 2009 16:29:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091124002929.DD045372B78@bosco.isi.edu> Date: Mon, 23 Nov 2009 16:29:29 -0800 (PST) Cc: pcn@ietf.org, rfc-editor@rfc-editor.org Subject: [PCN] RFC 5670 on Metering and Marking Behaviour of PCN-Nodes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:34:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5670 Title: Metering and Marking Behaviour of PCN-Nodes Author: P. Eardley, Ed. Status: Standards Track Date: November 2009 Mailbox: philip.eardley@bt.com Pages: 20 Characters: 44363 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pcn-marking-behaviour-05.txt URL: http://www.rfc-editor.org/rfc/rfc5670.txt The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS TRACK] This document is a product of the Congestion and Pre-Congestion Notification Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Mon Nov 23 16:35:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD093A6B03; Mon, 23 Nov 2009 16:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.127 X-Spam-Level: X-Spam-Status: No, score=-17.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbMz0WfGc4DR; Mon, 23 Nov 2009 16:35:06 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 2A67B3A6B00; Mon, 23 Nov 2009 16:35:06 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 160FA372B7A; Mon, 23 Nov 2009 16:29:54 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091124002954.160FA372B7A@bosco.isi.edu> Date: Mon, 23 Nov 2009 16:29:54 -0800 (PST) Cc: pcn@ietf.org, rfc-editor@rfc-editor.org Subject: [PCN] RFC 5696 on Baseline Encoding and Transport of Pre-Congestion Information X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:35:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5696 Title: Baseline Encoding and Transport of Pre-Congestion Information Author: T. Moncaster, B. Briscoe, M. Menth Status: Standards Track Date: November 2009 Mailbox: toby.moncaster@bt.com, bob.briscoe@bt.com, menth@informatik.uni-wuerzburg.de Pages: 15 Characters: 33112 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pcn-baseline-encoding-07.txt URL: http://www.rfc-editor.org/rfc/rfc5696.txt The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS TRACK] This document is a product of the Congestion and Pre-Congestion Notification Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute