From tom.taylor@rogers.com Tue Oct 6 16:33:22 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 E592E3A677E for ; Tue, 6 Oct 2009 16:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 UOF6tAzlk1y2 for ; Tue, 6 Oct 2009 16:33:22 -0700 (PDT) Received: from smtp107.rog.mail.re2.yahoo.com (smtp107.rog.mail.re2.yahoo.com [68.142.225.205]) by core3.amsl.com (Postfix) with SMTP id B511C3A683D for ; Tue, 6 Oct 2009 16:33:21 -0700 (PDT) Received: (qmail 42053 invoked from network); 6 Oct 2009 23:34:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=mykcDPS2lGAqu6uYxb4u8zU4L3tYRsTkPg7r56GHa0Uz+4Gt9d0iEYmvzZWkmKByqENisghQ6eWzHJeauyKnFCZhUm4YO/8G1CPephYc/qr5jPt8Xue1F/XCquiZ7wNolFjpi0ZtYcmL3EsC0yB3LAqa5haYqDprpQlbENVxWDI= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp107.rog.mail.re2.yahoo.com with SMTP; 6 Oct 2009 23:34:58 -0000 X-YMail-OSG: FIfr1hgVM1kTU6tlD_FPfzEf7BPFzMznUc9ltIMT3AmrjAIjQC1ZeeAEXAI3BXPFgQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACBD420.70206@rogers.com> Date: Tue, 06 Oct 2009 19:34:56 -0400 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 Subject: [PCN] Piggybacking -- a new edge behaviour 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, 06 Oct 2009 23:33:23 -0000 Bob and Phil in particular have expressed interest in documenting a mode of operation whereby PCN information is "piggybacked" on top of resource signalling. One of the desirable properties of this is fate sharing: if the message from the egress node goes missing, the flow is not admitted. We co-authors of the signalling requirements document had a discussion today to clarify the content of our draft. It was clear to me as a result of this discussion that piggybacking has to be treated as a separate edge behaviour. This behaviour differs from CL and SM because: (1) it assumes that resource signalling is being used; (2) it assumes that the egress node makes the admission decision for each flow based on its current CLI estimate, whereas CL and SM both assume the per-flow decision is made elsewhere; I propose to write a separate draft describing this edge behaviour. If the piggybacking edge behaviour is restricted to admission control only, it has no signalling requirements above those already defined for resource signalling. There is no point in transporting the CLI estimate back to the ingress node given that the egress node is the place where it is used. The interesting question is whether we would want the piggybacking edge behaviour to support flow termination. If it does, a signalling requirement exists, to transport the current estimate of supportable rate back to the ingress node. I think it is up for discussion whether this information would be piggybacked in the per-flow resource signalling or sent by a separate message. If the latter is the case, I would argue that the transport solution(s) specified for PCN should be used, whatever it is/they are. Note that the charter says PCN can define the requirements for a signalling protocol, but cannot specify the protocol itself. That means it's someone else's job to say what PCN's signalling transport is. (AD bait here -- I think the charter was written making some unstated assumptions.) We can't assume resource signalling will be the chosen vehicle, taking note that if it is chosen, Ruediger's network will not support it. Tom From menth@informatik.uni-wuerzburg.de Tue Oct 6 16:42:18 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 266073A6A1E for ; Tue, 6 Oct 2009 16:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 uhiattlhqfpZ for ; Tue, 6 Oct 2009 16:42:17 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 2044D3A6926 for ; Tue, 6 Oct 2009 16:42:16 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B125B5B89F; Wed, 7 Oct 2009 01:43:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id ADCC95B03E; Wed, 7 Oct 2009 01:43:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (e176230125.adsl.alicedsl.de [85.176.230.125]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 5F1255CC43; Wed, 7 Oct 2009 01:43:53 +0200 (CEST) Message-ID: <4ACBD635.4010902@informatik.uni-wuerzburg.de> Date: Wed, 07 Oct 2009 01:43:49 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Taylor References: <4ACBD420.70206@rogers.com> In-Reply-To: <4ACBD420.70206@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Piggybacking -- a new edge behaviour X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 23:42:18 -0000 Hi Tom, I thought that Bob's and Phil's proposal with piggybacking was the following. If many RESV messages are sent from the egress to the ingress to do per-flow resource signalling, the per ingress-egress-aggregate information from the egress to the ingress can be piggybacked on top of these per-flow RESV messages. That's what I understood when talking to them last time. Bob, Phil, can you clarify, please? Kind regards, Michael Tom Taylor schrieb: > Bob and Phil in particular have expressed interest in documenting a > mode of operation whereby PCN information is "piggybacked" on top of > resource signalling. One of the desirable properties of this is fate > sharing: if the message from the egress node goes missing, the flow is > not admitted. > > We co-authors of the signalling requirements document had a discussion > today to clarify the content of our draft. It was clear to me as a > result of this discussion that piggybacking has to be treated as a > separate edge behaviour. This behaviour differs from CL and SM because: > > (1) it assumes that resource signalling is being used; > > (2) it assumes that the egress node makes the admission decision for > each flow based on its current CLI estimate, whereas CL and SM both > assume the per-flow decision is made elsewhere; > > I propose to write a separate draft describing this edge behaviour. > > If the piggybacking edge behaviour is restricted to admission control > only, it has no signalling requirements above those already defined > for resource signalling. There is no point in transporting the CLI > estimate back to the ingress node given that the egress node is the > place where it is used. > > The interesting question is whether we would want the piggybacking > edge behaviour to support flow termination. If it does, a signalling > requirement exists, to transport the current estimate of supportable > rate back to the ingress node. I think it is up for discussion whether > this information would be piggybacked in the per-flow resource > signalling or sent by a separate message. If the latter is the case, I > would argue that the transport solution(s) specified for PCN should be > used, whatever it is/they are. > > Note that the charter says PCN can define the requirements for a > signalling protocol, but cannot specify the protocol itself. That > means it's someone else's job to say what PCN's signalling transport > is. (AD bait here -- I think the charter was written making some > unstated assumptions.) We can't assume resource signalling will be the > chosen vehicle, taking note that if it is chosen, Ruediger's network > will not support it. > > Tom > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From lars.eggert@nokia.com Wed Oct 7 00:04:18 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 38A4A3A683D for ; Wed, 7 Oct 2009 00:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 PDSqxtqp5vb8 for ; Wed, 7 Oct 2009 00:04:16 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 811DD3A67E5 for ; Wed, 7 Oct 2009 00:04:16 -0700 (PDT) Received: from [IPv6:2001:14b8:18f::225:ff:fe45:eccf] ([IPv6:2001:14b8:18f:0:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9775jD5081731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Oct 2009 10:05:45 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Lars Eggert In-Reply-To: <4ACBD420.70206@rogers.com> Date: Wed, 7 Oct 2009 10:05:39 +0300 Content-Transfer-Encoding: 7bit Message-Id: <02FF9572-89ED-4819-81A4-5DC24AE8BB70@nokia.com> References: <4ACBD420.70206@rogers.com> To: Tom Taylor X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Wed, 07 Oct 2009 10:05:46 +0300 (EEST) Cc: pcn Subject: Re: [PCN] Piggybacking -- a new edge behaviour 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, 07 Oct 2009 07:04:18 -0000 Hi, On 2009-10-7, at 2:34, Tom Taylor wrote: > Note that the charter says PCN can define the requirements for a > signalling > protocol, but cannot specify the protocol itself. That means it's > someone else's > job to say what PCN's signalling transport is. (AD bait here -- I > think the > charter was written making some unstated assumptions.) OK, I'll bite :-) It's not so much unstated assumption as a strong desire to not charter open-ended WGs, so we tried very hard to chop off the smallest possible set of initial work items when the WG was chartered. So important stuff is missing until after a recharter (e.g., inter-domain behavior, etc.) For signaling specifically, at charter time it sounded like there were multiple different use cases (ITU-T etc.) some of which had pre-existing signaling protocols and which wanted to roll in PCN support into whatever their broader architecture was. Hence, we decided to not mandate one signaling protocol. If that's now different, we can definitely talk about what to do at rechartering time (when a few more of your initial work items are nearing completion...) Lars From Ruediger.Geib@telekom.de Wed Oct 7 04:54:40 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 1210428C278 for ; Wed, 7 Oct 2009 04:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cs5YNVGsqWv4 for ; Wed, 7 Oct 2009 04:54:39 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id ADE983A683E for ; Wed, 7 Oct 2009 04:54:37 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 07 Oct 2009 13:56:10 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 13:56:09 +0200 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: Wed, 7 Oct 2009 13:56:10 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A50240EA3D@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <4ACBD420.70206@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Piggybacking -- a new edge behaviour Thread-Index: AcpG3aIGZl8m0wYNTe20SECa2VF9HwAPoZIA References: <4ACBD420.70206@rogers.com> From: To: X-OriginalArrivalTime: 07 Oct 2009 11:56:09.0869 (UTC) FILETIME=[28F12BD0:01CA4745] Cc: pcn@ietf.org Subject: Re: [PCN] Piggybacking -- a new edge behaviour 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, 07 Oct 2009 11:54:40 -0000 Tom, I agree to your proposal. Regards, Ruediger=20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Tom Taylor Sent: Wednesday, October 07, 2009 1:35 AM To: pcn Subject: [PCN] Piggybacking -- a new edge behaviour Bob and Phil in particular have expressed interest in documenting a mode = of=20 operation whereby PCN information is "piggybacked" on top of resource=20 signalling. One of the desirable properties of this is fate sharing: if = the=20 message from the egress node goes missing, the flow is not admitted. We co-authors of the signalling requirements document had a discussion = today to=20 clarify the content of our draft. It was clear to me as a result of this = discussion that piggybacking has to be treated as a separate edge = behaviour.=20 This behaviour differs from CL and SM because: (1) it assumes that resource signalling is being used; (2) it assumes that the egress node makes the admission decision for = each flow=20 based on its current CLI estimate, whereas CL and SM both assume the = per-flow=20 decision is made elsewhere; I propose to write a separate draft describing this edge behaviour. If the piggybacking edge behaviour is restricted to admission control = only, it=20 has no signalling requirements above those already defined for resource=20 signalling. There is no point in transporting the CLI estimate back to = the=20 ingress node given that the egress node is the place where it is used. The interesting question is whether we would want the piggybacking edge=20 behaviour to support flow termination. If it does, a signalling = requirement=20 exists, to transport the current estimate of supportable rate back to = the=20 ingress node. I think it is up for discussion whether this information = would be=20 piggybacked in the per-flow resource signalling or sent by a separate = message.=20 If the latter is the case, I would argue that the transport solution(s)=20 specified for PCN should be used, whatever it is/they are. Note that the charter says PCN can define the requirements for a = signalling=20 protocol, but cannot specify the protocol itself. That means it's = someone else's=20 job to say what PCN's signalling transport is. (AD bait here -- I think = the=20 charter was written making some unstated assumptions.) We can't assume = resource=20 signalling will be the chosen vehicle, taking note that if it is chosen, = Ruediger's network will not support it. Tom _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Mon Oct 12 07:53: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 312C528C18A for ; Mon, 12 Oct 2009 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_72=0.6, 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 AjaM3sexE+D2 for ; Mon, 12 Oct 2009 07:53:29 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9753C3A68F4 for ; Mon, 12 Oct 2009 07:53:29 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:53:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 15:53:28 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0636392E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4ACBD635.4010902@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Piggybacking -- a new edge behaviour thread-index: AcpG3uIYndN4ZSTQRee0C0+HyHTrFAEak+0A From: To: , X-OriginalArrivalTime: 12 Oct 2009 14:53:29.0353 (UTC) FILETIME=[C2A25790:01CA4B4B] Cc: pcn@ietf.org Subject: Re: [PCN] Piggybacking -- a new edge behaviour 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, 12 Oct 2009 14:53:31 -0000 Hi I think what Michael says basically agrees with what tom says (?) For admission control there seem to be 2 cases, basically as tom says: - where pcn signalling fate shares with existing resource signalling, eg by "piggybacking" in the RESV msgs - where pcn signalling doesn't fate share with existing resource signalling, eg a special pcn msg carries pcn info.=20 They key difference is that the first assumes there is an existing resource signalling mechanism, whilst the second needs reliability on the special pcn msg Tom, I don't see you difference (2) as significant - I think that the admission decision can be made at the ingress or egress for either [the case of centralised decision point makes no difference; if you want to fate share pcn signalling & resource signalling, then clearly the latter must go through the centralised node] for Flow termination Signalling of pcn info can use the existing resource signalling - if the latter allows asynchronous msgs. So for resource signalling protocols that don't support this, then you have to use a special psn msg=20 Best wishes, phil -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 07 October 2009 00:44 To: Tom Taylor Cc: pcn; Briscoe,RJ,Bob,XVR9 BRISCORJ R; Eardley,PL,Philip,DEE1 R Subject: Re: [PCN] Piggybacking -- a new edge behaviour Hi Tom, I thought that Bob's and Phil's proposal with piggybacking was the=20 following. If many RESV messages are sent from the egress to the ingress to do per-flow resource signalling, the per ingress-egress-aggregate=20 information from the egress to the ingress can be piggybacked on top of=20 these per-flow RESV messages. That's what I understood when talking to=20 them last time. Bob, Phil, can you clarify, please? Kind regards, Michael Tom Taylor schrieb: > Bob and Phil in particular have expressed interest in documenting a=20 > mode of operation whereby PCN information is "piggybacked" on top of=20 > resource signalling. One of the desirable properties of this is fate=20 > sharing: if the message from the egress node goes missing, the flow is > not admitted. > > We co-authors of the signalling requirements document had a discussion > today to clarify the content of our draft. It was clear to me as a=20 > result of this discussion that piggybacking has to be treated as a=20 > separate edge behaviour. This behaviour differs from CL and SM because: > > (1) it assumes that resource signalling is being used; > > (2) it assumes that the egress node makes the admission decision for=20 > each flow based on its current CLI estimate, whereas CL and SM both=20 > assume the per-flow decision is made elsewhere; > > I propose to write a separate draft describing this edge behaviour. > > If the piggybacking edge behaviour is restricted to admission control=20 > only, it has no signalling requirements above those already defined=20 > for resource signalling. There is no point in transporting the CLI=20 > estimate back to the ingress node given that the egress node is the=20 > place where it is used. > > The interesting question is whether we would want the piggybacking=20 > edge behaviour to support flow termination. If it does, a signalling=20 > requirement exists, to transport the current estimate of supportable=20 > rate back to the ingress node. I think it is up for discussion whether > this information would be piggybacked in the per-flow resource=20 > signalling or sent by a separate message. If the latter is the case, I > would argue that the transport solution(s) specified for PCN should be > used, whatever it is/they are. > > Note that the charter says PCN can define the requirements for a=20 > signalling protocol, but cannot specify the protocol itself. That=20 > means it's someone else's job to say what PCN's signalling transport=20 > is. (AD bait here -- I think the charter was written making some=20 > unstated assumptions.) We can't assume resource signalling will be the > chosen vehicle, taking note that if it is chosen, Ruediger's network=20 > will not support it. > > Tom > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn --=20 Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From tom111.taylor@bell.net Mon Oct 12 13:09:18 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 3432E28C110 for ; Mon, 12 Oct 2009 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, 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 74NF73Ft2Vay for ; Mon, 12 Oct 2009 13:09:17 -0700 (PDT) Received: from blu0-omc2-s23.blu0.hotmail.com (blu0-omc2-s23.blu0.hotmail.com [65.55.111.98]) by core3.amsl.com (Postfix) with ESMTP id 355FF28C154 for ; Mon, 12 Oct 2009 13:09:13 -0700 (PDT) Received: from BLU0-SMTP101 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:09:14 -0700 X-Originating-IP: [76.64.153.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([76.64.153.89]) by BLU0-SMTP101.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:09:12 -0700 Date: Mon, 12 Oct 2009 16:09:10 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC0636392E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0636392E@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2009 20:09:12.0838 (UTC) FILETIME=[DDD4C260:01CA4B77] Cc: pcn@ietf.org, tom.taylor@rogers.com Subject: Re: [PCN] Piggybacking -- a new edge behaviour 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, 12 Oct 2009 20:09:18 -0000 Please see below. philip.eardley@bt.com wrote: > Hi > > I think what Michael says basically agrees with what tom says (?) > > For admission control there seem to be 2 cases, basically as tom says: > > - where pcn signalling fate shares with existing resource signalling, eg > by "piggybacking" in the RESV msgs > - where pcn signalling doesn't fate share with existing resource > signalling, eg a special pcn msg carries pcn info. > > They key difference is that the first assumes there is an existing > resource signalling mechanism, whilst the second needs reliability on > the special pcn msg > > Tom, I don't see you difference (2) as significant - I think that the > admission decision can be made at the ingress or egress for either [the > case of centralised decision point makes no difference; if you want to > fate share pcn signalling & resource signalling, then clearly the latter > must go through the centralised node] > [PTT] No. You are confounding the per-flow decision with the reporting of an admission state that conditions that decision. The actual decision whether to admit a specific flow can be made at the egress node only when resource signalling is being used. Otherwise it MUST be made elsewhere. > for Flow termination > Signalling of pcn info can use the existing resource signalling - if the > latter allows asynchronous msgs. So for resource signalling protocols > that don't support this, then you have to use a special psn msg > > Best wishes, > phil ... From philip.eardley@bt.com Tue Oct 13 01:04: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 5A2DA3A69FD for ; Tue, 13 Oct 2009 01:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 kjZHxnlKMJaG for ; Tue, 13 Oct 2009 01:04:40 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 64BE43A677C for ; Tue, 13 Oct 2009 01:04:40 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:04:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 09:04:39 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363931@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Piggybacking -- a new edge behaviour thread-index: AcpLd9+Phh1Pk8l3Q2uQ55obK+CtgAAYtxpQ From: To: X-OriginalArrivalTime: 13 Oct 2009 08:04:40.0314 (UTC) FILETIME=[D099C5A0:01CA4BDB] Cc: pcn@ietf.org, tom.taylor@rogers.com Subject: Re: [PCN] Piggybacking -- a new edge behaviour 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, 13 Oct 2009 08:04:41 -0000 >=20 > Tom, I don't see you difference (2) as significant - I think that the > admission decision can be made at the ingress or egress for either [the > case of centralised decision point makes no difference; if you want to > fate share pcn signalling & resource signalling, then clearly the latter > must go through the centralised node] >=20 [PTT] No. You are confounding the per-flow decision with the reporting of an=20 admission state that conditions that decision. The actual decision whether to=20 admit a specific flow can be made at the egress node only when resource=20 signalling is being used. Otherwise it MUST be made elsewhere. [phil] don't agree with this MUST - you can make the decision wherever and this then sets what signalling msgs are needed.=20 But sure, I think it's fine for the i-d covering the case without the resource signalling to assume that the actual decision is not at the egress. From slblake@petri-meat.com Sat Oct 17 19:45: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 5CC0A3A68D4 for ; Sat, 17 Oct 2009 19:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 n7wwICoeODzC for ; Sat, 17 Oct 2009 19:45:34 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id AE0BD3A6358 for ; Sat, 17 Oct 2009 19:45:34 -0700 (PDT) Received: from cpe-075-182-068-102.nc.res.rr.com ([75.182.68.102]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MzLm6-0001zM-K5 for pcn@ietf.org; Sat, 17 Oct 2009 22:45:38 -0400 From: Steven Blake To: pcn Content-Type: text/plain Date: Sat, 17 Oct 2009 22:45:38 -0400 Message-Id: <1255833938.20634.11.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit 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] IETF 76 PCN agenda items 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, 18 Oct 2009 02:45:35 -0000 The Hiroshima IETF is fast approaching. PCN is currently scheduled to meet on Tuesday morning. Please send requests for agenda time to the chairs (mailto:pcn-chairs@tools.ietf.org). Here is a summary of the remaining important meeting dates: 2009-10-19 -00 I-D deadline 2009-10-26 I-D deadline 2009-10-28 Draft working group agendas due 2009-10-30 Early bird registration deadline 2009-11-02 Working group agendas due Regards, // Steve From karagian@cs.utwente.nl Sun Oct 18 05:00:18 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 15B3F3A6989 for ; Sun, 18 Oct 2009 05:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] 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 LG1TiXEgcxUj for ; Sun, 18 Oct 2009 05:00:17 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 081963A6974 for ; Sun, 18 Oct 2009 05:00:16 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n9IC0IrS009572 for ; Sun, 18 Oct 2009 14:00:21 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 18 Oct 2009 12:00:17 +0000 To: pcn@ietf.org Date: Sun, 18 Oct 2009 12:00:17 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Sun, 18 Oct 2009 14:00:22 +0200 (MEST) Subject: [PCN] New Version Notification for draft-karagiannis-pcn-signaling-requirements-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: Sun, 18 Oct 2009 12:00:18 -0000 A new version of I-D, draft-karagiannis-pcn-signaling-requirements-00.txt has been successfuly submitted by Georgios Karagiannis and posted to the IETF repository. http://www.ietf.org/id/draft-karagiannis-pcn-signaling-requirements-00.txt Filename:=09 draft-karagiannis-pcn-signaling-requirements Revision:=09 00 Title:=09=09 Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain Creation_date:=09 2009-10-19 WG ID:=09=09 Independent Submission Number_of_pages: 11 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 describes the requirements for the signaling applied within the PCN domain, to carry PCN content from the PCN-egress-node towards either the PCN-ingress-node or towards the centralised decision point. The IETF Secretariat. From karagian@cs.utwente.nl Tue Oct 20 03:03:51 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 EA0E83A6891 for ; Tue, 20 Oct 2009 03:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, 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 gAGeyzXlVWyn for ; Tue, 20 Oct 2009 03:03:51 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id CCDED3A6889 for ; Tue, 20 Oct 2009 03:03:50 -0700 (PDT) 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 n9KA3nZb010533 for ; Tue, 20 Oct 2009 12:03:54 +0200 (MEST) From: "Georgios Karagiannis" To: References: Date: Tue, 20 Oct 2009 12:03:52 +0200 Message-ID: <002201ca516c$a4bd2ee0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcpP6qrN4OWI3LlpS82N6UMOD7VdxQBgWsMg X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 Subject: Re: [PCN] New Version Notification fordraft-karagiannis-pcn-signaling-requirements-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, 20 Oct 2009 10:03:52 -0000 Hi all As you see below we (Tom, Kwok, Michael and I) have submitted a PCN signaling requirements draft that can be used to cover the following PCN charter goal/milestone: Jul 2009 Submit Requirements for Signaling of (Pre-) Congestion Information from Egress to Ingress in a DiffServ Domain to the IESG for consideration as a Informational RFC If you have any comments, please let us know! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: zondag 18 oktober 2009 14:00 > To: pcn@ietf.org > Subject: [PCN] New Version Notification > fordraft-karagiannis-pcn-signaling-requirements-00 > > A new version of I-D, > draft-karagiannis-pcn-signaling-requirements-00.txt > has been successfuly submitted by Georgios Karagiannis and > posted to the IETF repository. > http://www.ietf.org/id/draft-karagiannis-pcn-signaling-requirements-00.txt > > Filename: draft-karagiannis-pcn-signaling-requirements > Revision: 00 > Title: Requirements for Signaling of (Pre-) > Congestion Information in a > DiffServ Domain > Creation_date: 2009-10-19 > WG ID: Independent Submission > Number_of_pages: 11 > > 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 describes the requirements for the > signaling applied within the PCN domain, to carry PCN content > from the PCN-egress-node towards either the PCN-ingress-node > or towards the centralised decision point. > > > > The IETF Secretariat. > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From fqhuang@huawei.com Wed Oct 21 02:55:01 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 A57453A697A for ; Wed, 21 Oct 2009 02:55:01 -0700 (PDT) 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=[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 RnMNdocXfcA4 for ; Wed, 21 Oct 2009 02:55:00 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 948113A695C for ; Wed, 21 Oct 2009 02:55:00 -0700 (PDT) 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 <0KRU002LJZDH7W@szxga03-in.huawei.com> for pcn@ietf.org; Wed, 21 Oct 2009 17:51:17 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU009J6ZDHV4@szxga03-in.huawei.com> for pcn@ietf.org; Wed, 21 Oct 2009 17:51:17 +0800 (CST) Received: from h36145c ([10.70.39.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00KQFZDG8E@szxml06-in.huawei.com> for pcn@ietf.org; Wed, 21 Oct 2009 17:51:16 +0800 (CST) Date: Wed, 21 Oct 2009 17:51:18 +0800 From: Fortune HUANG In-reply-to: <002201ca516c$a4bd2ee0$810c5982@dynamic.ewi.utwente.nl> To: 'Georgios Karagiannis' , pcn@ietf.org Message-id: <002e01ca5234$09c01240$4027460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpP6qrN4OWI3LlpS82N6UMOD7VdxQBgWsMgADDH/nA= Subject: Re: [PCN] New Version Notificationfordraft-karagiannis-pcn-signaling-requirements-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: Wed, 21 Oct 2009 09:55:01 -0000 Hi Georgios, Tom, Kwok and Michael, The draft looks well-structured to me. It is great that you put the requirements for signaling from PCN-egress-nodes to PCN-ingress-nodes and the requirements for PCN-egress-node to centralised decision point signaling into different sections, which makes requirements very clear for different scenarios. It is also worth mentioning that you covers both scenarios, which makes the draft integrated. In short, well done! One minor comment about section 3. The identifier of the ingress-egress-aggregate or the PCN-ingress-node should normally be included in the signalling between PCN-egress-node and centralised decision point in order to distinguish different ingress-egress-aggregates, which is another difference between the two different kinds of signallings. Best regards, Fortune -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 20, 2009 6:04 PM To: pcn@ietf.org Subject: Re: [PCN] New Version Notificationfordraft-karagiannis-pcn-signaling-requirements-00 Hi all As you see below we (Tom, Kwok, Michael and I) have submitted a PCN signaling requirements draft that can be used to cover the following PCN charter goal/milestone: Jul 2009 Submit Requirements for Signaling of (Pre-) Congestion Information from Egress to Ingress in a DiffServ Domain to the IESG for consideration as a Informational RFC If you have any comments, please let us know! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: zondag 18 oktober 2009 14:00 > To: pcn@ietf.org > Subject: [PCN] New Version Notification > fordraft-karagiannis-pcn-signaling-requirements-00 > > A new version of I-D, > draft-karagiannis-pcn-signaling-requirements-00.txt > has been successfuly submitted by Georgios Karagiannis and posted to > the IETF repository. > http://www.ietf.org/id/draft-karagiannis-pcn-signaling-requirements-00.txt > > Filename: draft-karagiannis-pcn-signaling-requirements > Revision: 00 > Title: Requirements for Signaling of (Pre-) > Congestion Information in a > DiffServ Domain > Creation_date: 2009-10-19 > WG ID: Independent Submission > Number_of_pages: 11 > > 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 describes > the requirements for the signaling applied within the PCN domain, to > carry PCN content from the PCN-egress-node towards either the > PCN-ingress-node or towards the centralised decision point. > > > > The IETF Secretariat. > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Wed Oct 21 03:06:32 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 6D9543A69C9 for ; Wed, 21 Oct 2009 03:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.518 X-Spam-Level: X-Spam-Status: No, score=0.518 tagged_above=-999 required=5 tests=[AWL=1.022, 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 8Ttni7y6eDa8 for ; Wed, 21 Oct 2009 03:06:31 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 0B6C83A6A02 for ; Wed, 21 Oct 2009 03:06:09 -0700 (PDT) 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 n9LA67kl004842; Wed, 21 Oct 2009 12:06:11 +0200 (MEST) From: "Georgios Karagiannis" To: "'Fortune HUANG'" , References: <002201ca516c$a4bd2ee0$810c5982@dynamic.ewi.utwente.nl> <002e01ca5234$09c01240$4027460a@china.huawei.com> Date: Wed, 21 Oct 2009 12:06:03 +0200 Message-ID: <002801ca5236$1c46e400$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: <002e01ca5234$09c01240$4027460a@china.huawei.com> Thread-Index: AcpP6qrN4OWI3LlpS82N6UMOD7VdxQBgWsMgADDH/nAAAVyU0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 Subject: Re: [PCN] New Version Notificationfordraft-karagiannis-pcn-signaling-requirements-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: Wed, 21 Oct 2009 10:06:32 -0000 Hi Fortune Thanks for your comments, please see in line! > -----Original Message----- > From: Fortune HUANG [mailto:fqhuang@huawei.com] > Sent: woensdag 21 oktober 2009 11:51 > To: 'Georgios Karagiannis'; pcn@ietf.org > Subject: RE: [PCN] New Version > Notificationfordraft-karagiannis-pcn-signaling-requirements-00 > > > Hi Georgios, Tom, Kwok and Michael, > > The draft looks well-structured to me. It is great that you > put the requirements for signaling from PCN-egress-nodes to > PCN-ingress-nodes and the requirements for PCN-egress-node to > centralised decision point signaling into different sections, > which makes requirements very clear for different scenarios. > It is also worth mentioning that you covers both scenarios, > which makes the draft integrated. In short, well done! Georgios: Thank you very much! > > One minor comment about section 3. The identifier of the > ingress-egress-aggregate or the PCN-ingress-node should > normally be included in the signalling between > PCN-egress-node and centralised decision point in order to > distinguish different ingress-egress-aggregates, which is > another difference between the two different kinds of signallings. Georgios: Okay, we will inlcude this difference in the next version of the draft! Best regards, Georgios > > > Best regards, > Fortune > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Tuesday, October 20, 2009 6:04 PM > To: pcn@ietf.org > Subject: Re: [PCN] New Version > Notificationfordraft-karagiannis-pcn-signaling-requirements-00 > > Hi all > > As you see below we (Tom, Kwok, Michael and I) have submitted > a PCN signaling requirements draft that can be used to cover > the following PCN charter goal/milestone: > > Jul 2009 > Submit Requirements for Signaling of (Pre-) Congestion > Information from Egress to Ingress in a DiffServ Domain to > the IESG for consideration as a Informational RFC > > If you have any comments, please let us know! > > Best regards, > Georgios > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: zondag 18 oktober 2009 14:00 > > To: pcn@ietf.org > > Subject: [PCN] New Version Notification > > fordraft-karagiannis-pcn-signaling-requirements-00 > > > > A new version of I-D, > > draft-karagiannis-pcn-signaling-requirements-00.txt > > has been successfuly submitted by Georgios Karagiannis and > posted to > > the IETF repository. > > > http://www.ietf.org/id/draft-karagiannis-pcn-signaling-require ments-00.txt > > > > Filename: draft-karagiannis-pcn-signaling-requirements > > Revision: 00 > > Title: Requirements for Signaling of (Pre-) > > Congestion Information in a > > DiffServ Domain > > Creation_date: 2009-10-19 > > WG ID: Independent Submission > > Number_of_pages: 11 > > > > 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 describes > > the requirements for the signaling applied within the PCN > domain, to > > carry PCN content from the PCN-egress-node towards either the > > PCN-ingress-node or towards the centralised decision point. > > > > > > > > The IETF Secretariat. > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From tom111.taylor@bell.net Wed Oct 21 05:18: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 D5F5F3A686C for ; Wed, 21 Oct 2009 05:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001, 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 9VHd2xbbxRIV for ; Wed, 21 Oct 2009 05:18:08 -0700 (PDT) Received: from blu0-omc1-s3.blu0.hotmail.com (blu0-omc1-s3.blu0.hotmail.com [65.55.116.14]) by core3.amsl.com (Postfix) with ESMTP id 1A1C53A6925 for ; Wed, 21 Oct 2009 05:18:08 -0700 (PDT) Received: from BLU0-SMTP73 ([65.55.116.7]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 05:18:17 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP73.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 05:18:16 -0700 Date: Wed, 21 Oct 2009 08:18:14 -0400 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: 21 Oct 2009 12:18:16.0177 (UTC) FILETIME=[91443610:01CA5248] Subject: [PCN] draft-taylor-pcn-piggyback-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: Wed, 21 Oct 2009 12:18:08 -0000 As promised, draft-taylor-pcn-piggyback-edge-behaviour-00 has been posted. Here is the Abstract: 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 describes a behaviour for PCN egress nodes known as the "piggybacking" edge behaviour, because it "piggybacks" PCN information in resource signalling messages. This version of the memo describes two alternatives, where piggybacking is derived from the CL edge behaviour and where it is derived from the SM edge behaviour. The SM and CL edge behaviours are specified in companion documents. I will be updating the other two edge behaviour drafts shortly. Some other work I have been involved in has taken a great deal of time. Tom From karagian@cs.utwente.nl Wed Oct 21 06:59:19 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 E64C33A6967 for ; Wed, 21 Oct 2009 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.107 X-Spam-Level: * X-Spam-Status: No, score=1.107 tagged_above=-999 required=5 tests=[AWL=-0.248, 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 upXrxx5X0kFK for ; Wed, 21 Oct 2009 06:59:19 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id D95613A683A for ; Wed, 21 Oct 2009 06:59:18 -0700 (PDT) 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 n9LDxItL017383 for ; Wed, 21 Oct 2009 15:59:21 +0200 (MEST) From: "Georgios Karagiannis" To: Date: Wed, 21 Oct 2009 15:59:14 +0200 Message-ID: <003b01ca5256$af8bcbc0$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: AcpN0Z/r453Zm4BjRm2Ch1wDOVl4ewEg3UeA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 Subject: [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: Wed, 21 Oct 2009 13:59:20 -0000 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 From slblake@petri-meat.com Mon Oct 26 05:18: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 091353A6A6E for ; Mon, 26 Oct 2009 05:18:42 -0700 (PDT) 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=[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 Y58SMkoHgupC for ; Mon, 26 Oct 2009 05:18:41 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 45CD53A67DB for ; Mon, 26 Oct 2009 05:18:41 -0700 (PDT) Received: from cpe-024-211-225-075.nc.res.rr.com ([24.211.225.75]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2OXB-00071M-HM for pcn@ietf.org; Mon, 26 Oct 2009 08:18:49 -0400 From: Steven Blake To: pcn In-Reply-To: <1255833938.20634.11.camel@tachyon> References: <1255833938.20634.11.camel@tachyon> Content-Type: text/plain Date: Mon, 26 Oct 2009 08:16:20 -0400 Message-Id: <1256559380.5782.5.camel@tachyon.blake> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit 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: Re: [PCN] IETF 76 PCN agenda items 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, 26 Oct 2009 12:18:42 -0000 Reminder: deadlines approaching. Please submit agenda items ASAP. On Sat, 2009-10-17 at 22:45 -0400, Steven Blake wrote: > The Hiroshima IETF is fast approaching. PCN is currently scheduled to > meet on Tuesday morning. Please send requests for agenda time to the > chairs (mailto:pcn-chairs@tools.ietf.org). > > Here is a summary of the remaining important meeting dates: > > 2009-10-19 -00 I-D deadline > 2009-10-26 I-D deadline > 2009-10-28 Draft working group agendas due > 2009-10-30 Early bird registration deadline > 2009-11-02 Working group agendas due // Steve From tom111.taylor@bell.net Mon Oct 26 05:26:09 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 EE0153A67DF for ; Mon, 26 Oct 2009 05:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=1.100, 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 6Inmi+9ACqb9 for ; Mon, 26 Oct 2009 05:26:09 -0700 (PDT) Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by core3.amsl.com (Postfix) with ESMTP id 1F0F13A67AB for ; Mon, 26 Oct 2009 05:26:09 -0700 (PDT) Received: from BLU0-SMTP33 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 05:26:22 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP33.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 05:26:22 -0700 Date: Mon, 26 Oct 2009 08:26:19 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Steven Blake References: <1255833938.20634.11.camel@tachyon> <1256559380.5782.5.camel@tachyon.blake> In-Reply-To: <1256559380.5782.5.camel@tachyon.blake> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 12:26:22.0793 (UTC) FILETIME=[8760AB90:01CA5637] Cc: pcn Subject: Re: [PCN] IETF 76 PCN agenda items 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, 26 Oct 2009 12:26:10 -0000 CL, SM, and Piggybacking edge behaviour. Based on last time, 30 minutes anyway. Steven Blake wrote: > Reminder: deadlines approaching. Please submit agenda items ASAP. > > On Sat, 2009-10-17 at 22:45 -0400, Steven Blake wrote: > >> The Hiroshima IETF is fast approaching. PCN is currently scheduled to >> meet on Tuesday morning. Please send requests for agenda time to the >> chairs (mailto:pcn-chairs@tools.ietf.org). >> >> Here is a summary of the remaining important meeting dates: >> >> 2009-10-19 -00 I-D deadline >> 2009-10-26 I-D deadline >> 2009-10-28 Draft working group agendas due >> 2009-10-30 Early bird registration deadline >> 2009-11-02 Working group agendas due > > // Steve > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From root@core3.amsl.com Mon Oct 26 15:15:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A8EA328C15F; Mon, 26 Oct 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026221501.A8EA328C15F@core3.amsl.com> Date: Mon, 26 Oct 2009 15:15:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-01.txt 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, 26 Oct 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification Encoding Comparison Author(s) : K. Chan, et al. Filename : draft-ietf-pcn-encoding-comparison-01.txt Pages : 36 Date : 2009-10-26 A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document collects the lessons learned as we explore the different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide information on trade offs with the encoding choices, providing guidance based on different criteria. This document provides a historical trace of the consideration on different encoding alternatives for Pre-Congestion Notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-encoding-comparison-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26150038.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 27 09:45:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8E3C028C0F0; Tue, 27 Oct 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091027164501.8E3C028C0F0@core3.amsl.com> Date: Tue, 27 Oct 2009 09:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-sm-edge-behaviour-01.txt 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, 27 Oct 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation Author(s) : A. Charny, G. Karagiannis, M. Menth, T. Taylor Filename : draft-ietf-pcn-sm-edge-behaviour-01.txt Pages : 12 Date : 2009-10-27 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 that for two-state measurement-based load control, known informally as Single Marking (SM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-sm-edge-behaviour-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-27094254.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 27 09:45:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 925C93A69BF; Tue, 27 Oct 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091027164501.925C93A69BF@core3.amsl.com> Date: Tue, 27 Oct 2009 09:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-cl-edge-behaviour-01.txt 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, 27 Oct 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation Author(s) : A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor Filename : draft-ietf-pcn-cl-edge-behaviour-01.txt Pages : 14 Date : 2009-10-27 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 that for three-state measurement-based load control, known informally as Controlled Load (CL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-cl-edge-behaviour-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-27094438.I-D@ietf.org> --NextPart-- From Ruediger.Geib@telekom.de Wed Oct 28 08:08:48 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 EE9133A684E for ; Wed, 28 Oct 2009 08:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 6hwNaKY4lHAv for ; Wed, 28 Oct 2009 08:08:48 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 9EF8E3A6833 for ; Wed, 28 Oct 2009 08:08:47 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 28 Oct 2009 16:08:59 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 16:08:59 +0100 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: Wed, 28 Oct 2009 16:09:00 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A5026D1198@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <20091027164501.8E3C028C0F0@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Termination of flows in small aggregates thread-index: AcpXJQrRaoXOCCfoQzO7bohRt6XdogAtfE9w References: <20091027164501.8E3C028C0F0@core3.amsl.com> From: To: X-OriginalArrivalTime: 28 Oct 2009 15:08:59.0745 (UTC) FILETIME=[93CCE510:01CA57E0] Cc: pcn@ietf.org Subject: [PCN] Termination of flows in small aggregates 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, 28 Oct 2009 15:08:49 -0000 Hi Phil, I'm not a staunch supporter of termination. I'm having a question = related=20 to termination of small aggregates. Assume 10% excess marked traffic at a particular egress. - 5 flows for IEA1 - 3 flows for IEA2 Each flow consumes the same bandwidth.=20 I don't think that it matters whether decisions are taken at ingress or=20 egress. The farther congestion is from an ingress or egress, the lower=20 the number of IEAs. That means, that either the ingress or egress may=20 control a number of small aggregate IEAs, depending on the location of=20 the pre-congested interface. As far as I understand, there's no way to signal which flows are the = most=20 burdensome for a pre-congested interface. Maybe the above 8 flows = consume 10 times the average bandwidth of any other flow passing the = pre-congested=20 interface. The egress can't learn about that. I'm not out for an endemic fairness discussion and I don't want to start = a re-ECN discussion here. A pragmatic rule then would be "terminate=20 one flow"? Or should the reaction be configurable? I'm not looking for solutions which result in flow awareness at=20 pre congested interfaces or centralised systems having an overview. Regards, Ruediger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 From menth@informatik.uni-wuerzburg.de Wed Oct 28 09:08:18 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 C1C573A69FF for ; Wed, 28 Oct 2009 09:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 JNHfdM2ErQuw for ; Wed, 28 Oct 2009 09:08:17 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A8E2F3A67E7 for ; Wed, 28 Oct 2009 09:08:17 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 359695BC7E; Wed, 28 Oct 2009 17:08:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 31A4E5BC75; Wed, 28 Oct 2009 17:08:32 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0E19419AACF; Wed, 28 Oct 2009 17:08:32 +0100 (CET) Message-ID: <4AE86C68.80907@informatik.uni-wuerzburg.de> Date: Wed, 28 Oct 2009 17:08:08 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <20091027164501.8E3C028C0F0@core3.amsl.com> <151C164FE2E066418D8D44D0801543A5026D1198@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A5026D1198@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcn@ietf.org Subject: Re: [PCN] Termination of flows in small aggregates X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:08:18 -0000 Hi Rüdiger, you are right that small overtermination can be problematic with small aggregates. This has been studied in Section 4.6 in http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf and solutions that can be locally implemented have been proposed and demonstrated. Regards, Michael Ruediger.Geib@telekom.de schrieb: > Hi Phil, > > I'm not a staunch supporter of termination. I'm having a question related > to termination of small aggregates. > > Assume 10% excess marked traffic at a particular egress. > > - 5 flows for IEA1 > - 3 flows for IEA2 > > Each flow consumes the same bandwidth. > > I don't think that it matters whether decisions are taken at ingress or > egress. The farther congestion is from an ingress or egress, the lower > the number of IEAs. That means, that either the ingress or egress may > control a number of small aggregate IEAs, depending on the location of > the pre-congested interface. > > As far as I understand, there's no way to signal which flows are the most > burdensome for a pre-congested interface. Maybe the above 8 flows consume > 10 times the average bandwidth of any other flow passing the pre-congested > interface. The egress can't learn about that. > > I'm not out for an endemic fairness discussion and I don't want to start > a re-ECN discussion here. A pragmatic rule then would be "terminate > one flow"? Or should the reaction be configurable? > > I'm not looking for solutions which result in flow awareness at > pre congested interfaces or centralised systems having an overview. > > Regards, > > Ruediger > > > > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einführung > Technik Internet Backbone, TE142-19 > Rüdiger Geib > Heinrich Hertz Str. 3-7 > 64297 Darmstadt > Tel.: 06151/6282747 > Fax: 0251/7985109 > > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 > > > > > > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From slblake@petri-meat.com Wed Oct 28 15:26:00 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 D053D3A69C2 for ; Wed, 28 Oct 2009 15:26:00 -0700 (PDT) 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=[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 25-jbtVV8mb4 for ; Wed, 28 Oct 2009 15:26:00 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 2A13B3A69C5 for ; Wed, 28 Oct 2009 15:26:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3Gxz-0007Vg-T3 for pcn@ietf.org; Wed, 28 Oct 2009 18:26:07 -0400 MIME-Version: 1.0 Date: Wed, 28 Oct 2009 18:26:07 -0400 From: To: pcn@ietf.org 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 Subject: [PCN] IETF 76 PCN **DRAFT** agenda 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, 28 Oct 2009 22:26:00 -0000 I've uploaded the draft meeting agenda to http://www.ietf.org/proceedings/09nov/agenda/pcn.txt. Notice that the agenda is quite lite. Please send comments & corrections to the list ASAP. Regards, // Steve From tom111.taylor@bell.net Thu Oct 29 05:39:48 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 2F8F23A68F3 for ; Thu, 29 Oct 2009 05:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_20=-0.74, 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 2dwtxDnZFHE0 for ; Thu, 29 Oct 2009 05:39:47 -0700 (PDT) Received: from blu0-omc1-s30.blu0.hotmail.com (blu0-omc1-s30.blu0.hotmail.com [65.55.116.41]) by core3.amsl.com (Postfix) with ESMTP id 5CF333A67D3 for ; Thu, 29 Oct 2009 05:39:47 -0700 (PDT) Received: from BLU0-SMTP34 ([65.55.116.7]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 05:40:03 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP34.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 05:40:03 -0700 Date: Thu, 29 Oct 2009 08:39:59 -0400 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: 29 Oct 2009 12:40:03.0636 (UTC) FILETIME=[EFE09F40:01CA5894] Subject: [PCN] CLE vs. admission state 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, 29 Oct 2009 12:39:48 -0000 The current versions of the edge behaviour drafts have stepped back slightly from the extreme of reporting only transitions in admission state. Now admission state is reported at regular intervals. A fair amount of off-list discussion has been happening over the appropriateness of the current arrangement. For one, there is a certain amount of opposition to specifying exponential smoothing of the CLE. For another, Phil has raised the possibility of a CLE-dependent policy at the decision point, where more important flows are allowed in at higher CLE values than less important flows. That suggests that instead of admission state, the egress node should be reporting at least the CLE. I believe the discussion should be happening on the list -- that's what it is for. Michael Menth suggested an useful principle to which the present drafts adhere: actions at the decision point/ingress node should be exactly the same for CL and SM. He argued that the egress node unavoidably knows the difference between CL and SM in any case, so it might as well absorb all the differences. It is true that at least one end has to know the difference, but it doesn't have to be the egress node. If the egress node simply reports rates of unmarked, threshold-marked, and excess-traffic-marked traffic each interval, the decision point/ingress node can apply the CL- or SM-specific algorithms and draw the correct conclusions. It seems reasonable to design the system so one end is the same whether CL or SM is deployed. If we accept that, we have one-and-a-half questions really: 1) Which end should know that SM or CL is deployed? 1) a) If it is the egress node, should it report admission state or CLE? Either way, the egress node would have to report the estimated edge-to-edge supportable traffic rate whenever termination might possibly be required, and the decision point/ingress node would have to compare that with the admitted traffic rate to see if termination is really needed. Tom From menth@informatik.uni-wuerzburg.de Thu Oct 29 08:19:25 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 0929C3A67DF for ; Thu, 29 Oct 2009 08:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6] 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 pTN3f1M42Vg7 for ; Thu, 29 Oct 2009 08:19:23 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6453F3A6783 for ; Thu, 29 Oct 2009 08:19:23 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 41C6B5BD45; Thu, 29 Oct 2009 16:19:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3E2AB5BD09; Thu, 29 Oct 2009 16:19:39 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (e179088012.adsl.alicedsl.de [85.179.88.12]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id ED1745D776; Thu, 29 Oct 2009 16:19:38 +0100 (CET) Message-ID: <4AE9B276.9010001@informatik.uni-wuerzburg.de> Date: Thu, 29 Oct 2009 16:19:18 +0100 From: Michael Menth Organization: University of Wuerzburg 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 Subject: Re: [PCN] CLE vs. admission state X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:19:25 -0000 Hi all, I summarize the issue I raised during the spec writing process. It would be good to keep either the PCN egress or the decision point / PCN ingress unaware of CL or SM is used. This automatically leads to the same signalling protocol for CL and SM, too. Benefits of such an approach are obvious (one signalling protocol for CL/SM, simplified migration from SM to CL). This can be achieved in two different ways. A) egress-based-PCN-calculation The egress calculates a PCN-admission-state (admit/block) as well as the edge-to-edge supportable rate (ETM traffic in CL, u*ThM traffic in SM) and sends these values to the decision node. The decision node can do its operation (admit/block traffic, measure ingress PCN traffic and possibly terminate PCN traffic) without knowing whether the PCN reports from the egress node are based on CL or SM. B) decision-point-PCN-calculation The decision-point (ingress) calculates the PCN-admission-state and the edge-to-edge supportable rate. To that end, the egress transmits the measured rates of NM, ThM, and ETM traffic in regular intervals. Advantages of egress-based-PCN-calculation (A): 1) The PCN calculation algorithm can be exchanged locally at the egress node without changes to the signalling protocol and the ingress node. Example: the egress may send "block" immediately when it observes a marked packet. It is basically a different edge behavior that is able to work with smaller ingress-egress-aggregates. Reason: small ingress-egress-aggregates need long measurement intervals for meaningful rate estimates and then it is good when a block-message can be sent before the end of the measurement interval. 2) If the PCN-admission-state does not change at the egress and the edge-to-edge supportable rate is zero, regular reports which are usually carried every 100 ms from egress to ingress can be suppressed until the next change. The saved signalling overhead can be significant when the rate of ingress-egress-aggregates is small. Advantage of decision-point-based-PCN-calculation (B): 3) In case of SM, the CLE increases proportionally with the load. It is possible to use different CLE-admission-thresholds for high- and low-priority traffic so that high priority traffic has a lower blocking probability than low priority traffic when the system is near to pre-congestion. Below the line, the question whether A or B is better boils down to the issue what's more important for PCN under the assumption that we want to keep either the ingress or egress unaware of CL/SM: i) Potential support for smaller ingress-egress-aggregates ii) Differentiated blocking probabilities for low- and high-priority traffic (only for SM) Basically we need to decide which of the two issues is more important for PCN. Regards, Michael Tom Taylor schrieb: > The current versions of the edge behaviour drafts have stepped back > slightly from the extreme of reporting only transitions in admission > state. Now admission state is reported at regular intervals. > > A fair amount of off-list discussion has been happening over the > appropriateness of the current arrangement. For one, there is a > certain amount of opposition to specifying exponential smoothing of > the CLE. For another, Phil has raised the possibility of a > CLE-dependent policy at the decision point, where more important flows > are allowed in at higher CLE values than less important flows. That > suggests that instead of admission state, the egress node should be > reporting at least the CLE. > > I believe the discussion should be happening on the list -- that's > what it is for. > > Michael Menth suggested an useful principle to which the present > drafts adhere: actions at the decision point/ingress node should be > exactly the same for CL and SM. He argued that the egress node > unavoidably knows the difference between CL and SM in any case, so it > might as well absorb all the differences. > > It is true that at least one end has to know the difference, but it > doesn't have to be the egress node. If the egress node simply reports > rates of unmarked, threshold-marked, and excess-traffic-marked traffic > each interval, the decision point/ingress node can apply the CL- or > SM-specific algorithms and draw the correct conclusions. > > It seems reasonable to design the system so one end is the same > whether CL or SM is deployed. If we accept that, we have > one-and-a-half questions really: > > 1) Which end should know that SM or CL is deployed? > > 1) a) If it is the egress node, should it report admission state or > CLE? Either way, the egress node would have to report the estimated > edge-to-edge supportable traffic rate whenever termination might > possibly be required, and the decision point/ingress node would have > to compare that with the admitted traffic rate to see if termination > is really needed. > > Tom > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From acharny@cisco.com Thu Oct 29 10:11:57 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 4BC0F3A68AA for ; Thu, 29 Oct 2009 10:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 nOo+Kv8JofgX for ; Thu, 29 Oct 2009 10:11:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 174303A6882 for ; Thu, 29 Oct 2009 10:11:56 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL5p6UqrR7Ht/2dsb2JhbADHAYkmCY5pAoJSgWkEgWI X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="263459340" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2009 17:12:09 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9THBw47014697; Thu, 29 Oct 2009 17:12:09 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 13:12:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 13:12:03 -0400 Message-ID: In-Reply-To: <4AE9B276.9010001@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] CLE vs. admission state Thread-Index: AcpYq0D+xf8rgZbrQfGya5xmWXAx9AADxEzw References: <4AE9B276.9010001@informatik.uni-wuerzburg.de> From: "Anna Charny (acharny)" To: , "pcn" X-OriginalArrivalTime: 29 Oct 2009 17:12:04.0312 (UTC) FILETIME=[EFC22580:01CA58BA] Subject: Re: [PCN] CLE vs. admission state 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, 29 Oct 2009 17:11:57 -0000 Hi Michael, I am not sure I understand the goal. Why is it good to keep either the ingress or the egress unaware o whether it is CL or SM used? Usually the egress and the ingress side is implemented in the same device, so I am not sure why that requirement?=20 I do understand that it is good to have the same signaling protocol for SL mad CL, but I still do not see a clear connection between these two statements. What am I missing? Anna=20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: Thursday, October 29, 2009 11:19 AM To: pcn Subject: Re: [PCN] CLE vs. admission state Hi all, I summarize the issue I raised during the spec writing process. It would be good to keep either the PCN egress or the decision point / PCN ingress unaware of CL or SM is used. This automatically leads to the same signalling protocol for CL and SM, too. Benefits of such an approach are obvious (one signalling protocol for CL/SM, simplified migration from SM to CL). This can be achieved in two different ways. A) egress-based-PCN-calculation The egress calculates a PCN-admission-state (admit/block) as well as the edge-to-edge supportable rate (ETM traffic in CL, u*ThM traffic in SM) and sends these values to the decision node. The decision node can do its operation (admit/block traffic, measure ingress PCN traffic and possibly terminate PCN traffic) without knowing whether the PCN reports from the egress node are based on CL or SM. B) decision-point-PCN-calculation The decision-point (ingress) calculates the PCN-admission-state and the edge-to-edge supportable rate. To that end, the egress transmits the measured rates of NM, ThM, and ETM traffic in regular intervals. Advantages of egress-based-PCN-calculation (A): 1) The PCN calculation algorithm can be exchanged locally at the egress node without changes to the signalling protocol and the ingress node.=20 Example: the egress may send "block" immediately when it observes a marked packet. It is basically a different edge behavior that is able to work with smaller ingress-egress-aggregates. Reason: small ingress-egress-aggregates need long measurement intervals for meaningful rate estimates and then it is good when a block-message can be sent before the end of the measurement interval. 2) If the PCN-admission-state does not change at the egress and the edge-to-edge supportable rate is zero, regular reports which are usually carried every 100 ms from egress to ingress can be suppressed until the next change. The saved signalling overhead can be significant when the rate of ingress-egress-aggregates is small. Advantage of decision-point-based-PCN-calculation (B): 3) In case of SM, the CLE increases proportionally with the load. It is possible to use different CLE-admission-thresholds for high- and low-priority traffic so that high priority traffic has a lower blocking probability than low priority traffic when the system is near to pre-congestion. Below the line, the question whether A or B is better boils down to the issue what's more important for PCN under the assumption that we want to keep either the ingress or egress unaware of CL/SM: i) Potential support for smaller ingress-egress-aggregates ii) Differentiated blocking probabilities for low- and high-priority traffic (only for SM) Basically we need to decide which of the two issues is more important for PCN. Regards, Michael Tom Taylor schrieb: > The current versions of the edge behaviour drafts have stepped back=20 > slightly from the extreme of reporting only transitions in admission=20 > state. Now admission state is reported at regular intervals. > > A fair amount of off-list discussion has been happening over the=20 > appropriateness of the current arrangement. For one, there is a=20 > certain amount of opposition to specifying exponential smoothing of=20 > the CLE. For another, Phil has raised the possibility of a=20 > CLE-dependent policy at the decision point, where more important flows > are allowed in at higher CLE values than less important flows. That=20 > suggests that instead of admission state, the egress node should be=20 > reporting at least the CLE. > > I believe the discussion should be happening on the list -- that's=20 > what it is for. > > Michael Menth suggested an useful principle to which the present=20 > drafts adhere: actions at the decision point/ingress node should be=20 > exactly the same for CL and SM. He argued that the egress node=20 > unavoidably knows the difference between CL and SM in any case, so it=20 > might as well absorb all the differences. > > It is true that at least one end has to know the difference, but it=20 > doesn't have to be the egress node. If the egress node simply reports=20 > rates of unmarked, threshold-marked, and excess-traffic-marked traffic > each interval, the decision point/ingress node can apply the CL- or=20 > SM-specific algorithms and draw the correct conclusions. > > It seems reasonable to design the system so one end is the same=20 > whether CL or SM is deployed. If we accept that, we have=20 > one-and-a-half questions really: > > 1) Which end should know that SM or CL is deployed? > > 1) a) If it is the egress node, should it report admission state or=20 > CLE? Either way, the egress node would have to report the estimated=20 > edge-to-edge supportable traffic rate whenever termination might=20 > possibly be required, and the decision point/ingress node would have=20 > to compare that with the admitted traffic rate to see if termination=20 > is really needed. > > Tom > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-wuerzburg.de Thu Oct 29 10:27:52 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 4DD8C3A6882 for ; Thu, 29 Oct 2009 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6] 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 DhTiadxXSj9x for ; Thu, 29 Oct 2009 10:27:51 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id F36883A6835 for ; Thu, 29 Oct 2009 10:27:50 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id BD4815BD4A; Thu, 29 Oct 2009 18:28:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id BAD9F5BD3E; Thu, 29 Oct 2009 18:28:06 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (e179088012.adsl.alicedsl.de [85.179.88.12]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 70DF25D785; Thu, 29 Oct 2009 18:28:06 +0100 (CET) Message-ID: <4AE9D092.2050905@informatik.uni-wuerzburg.de> Date: Thu, 29 Oct 2009 18:27:46 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anna Charny (acharny)" References: <4AE9B276.9010001@informatik.uni-wuerzburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] CLE vs. admission state X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 17:27:52 -0000 Hi Anna, Anna Charny (acharny) schrieb: > Hi Michael, > > I am not sure I understand the goal. Why is it good to keep either the > ingress or the egress unaware o whether it is CL or SM used? Usually > the egress and the ingress side is implemented in the same device, so I > am not sure why that requirement? > I don't say it's a requirement, but a nice feature. Moreover, the decision point can also be in a centralized node and then ingress and egress do not sit in the same device. Then it matters. Regards, Michael > I do understand that it is good to have the same signaling protocol for > SL mad CL, but I still do not see a clear connection between these two > statements. What am I missing? > > Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: Thursday, October 29, 2009 11:19 AM > To: pcn > Subject: Re: [PCN] CLE vs. admission state > > Hi all, > > I summarize the issue I raised during the spec writing process. It would > be good to keep either the PCN egress or the decision point / PCN > ingress unaware of CL or SM is used. This automatically leads to the > same signalling protocol for CL and SM, too. Benefits of such an > approach are obvious (one signalling protocol for CL/SM, simplified > migration from SM to CL). This can be achieved in two different ways. > > A) egress-based-PCN-calculation > > The egress calculates a PCN-admission-state (admit/block) as well as the > edge-to-edge supportable rate (ETM traffic in CL, u*ThM traffic in SM) > and sends these values to the decision node. The decision node can do > its operation (admit/block traffic, measure ingress PCN traffic and > possibly terminate PCN traffic) without knowing whether the PCN reports > from the egress node are based on CL or SM. > > B) decision-point-PCN-calculation > > The decision-point (ingress) calculates the PCN-admission-state and the > edge-to-edge supportable rate. To that end, the egress transmits the > measured rates of NM, ThM, and ETM traffic in regular intervals. > > > Advantages of egress-based-PCN-calculation (A): > > 1) The PCN calculation algorithm can be exchanged locally at the egress > node without changes to the signalling protocol and the ingress node. > Example: the egress may send "block" immediately when it observes a > marked packet. It is basically a different edge behavior that is able to > work with smaller ingress-egress-aggregates. Reason: small > ingress-egress-aggregates need long measurement intervals for meaningful > rate estimates and then it is good when a block-message can be sent > before the end of the measurement interval. > > 2) If the PCN-admission-state does not change at the egress and the > edge-to-edge supportable rate is zero, regular reports which are usually > carried every 100 ms from egress to ingress can be suppressed until the > next change. The saved signalling overhead can be significant when the > rate of ingress-egress-aggregates is small. > > > > Advantage of decision-point-based-PCN-calculation (B): > > 3) In case of SM, the CLE increases proportionally with the load. It is > possible to use different CLE-admission-thresholds for high- and > low-priority traffic so that high priority traffic has a lower blocking > probability than low priority traffic when the system is near to > pre-congestion. > > > Below the line, the question whether A or B is better boils down to the > issue what's more important for PCN under the assumption that we want to > keep either the ingress or egress unaware of CL/SM: > > i) Potential support for smaller ingress-egress-aggregates > > ii) Differentiated blocking probabilities for low- and high-priority > traffic (only for SM) > > Basically we need to decide which of the two issues is more important > for PCN. > > Regards, > > Michael > > > Tom Taylor schrieb: > >> The current versions of the edge behaviour drafts have stepped back >> slightly from the extreme of reporting only transitions in admission >> state. Now admission state is reported at regular intervals. >> >> A fair amount of off-list discussion has been happening over the >> appropriateness of the current arrangement. For one, there is a >> certain amount of opposition to specifying exponential smoothing of >> the CLE. For another, Phil has raised the possibility of a >> CLE-dependent policy at the decision point, where more important flows >> > > >> are allowed in at higher CLE values than less important flows. That >> suggests that instead of admission state, the egress node should be >> reporting at least the CLE. >> >> I believe the discussion should be happening on the list -- that's >> what it is for. >> >> Michael Menth suggested an useful principle to which the present >> drafts adhere: actions at the decision point/ingress node should be >> exactly the same for CL and SM. He argued that the egress node >> unavoidably knows the difference between CL and SM in any case, so it >> might as well absorb all the differences. >> >> It is true that at least one end has to know the difference, but it >> doesn't have to be the egress node. If the egress node simply reports >> rates of unmarked, threshold-marked, and excess-traffic-marked traffic >> > > >> each interval, the decision point/ingress node can apply the CL- or >> SM-specific algorithms and draw the correct conclusions. >> >> It seems reasonable to design the system so one end is the same >> whether CL or SM is deployed. If we accept that, we have >> one-and-a-half questions really: >> >> 1) Which end should know that SM or CL is deployed? >> >> 1) a) If it is the egress node, should it report admission state or >> CLE? Either way, the egress node would have to report the estimated >> edge-to-edge supportable traffic rate whenever termination might >> possibly be required, and the decision point/ingress node would have >> to compare that with the admitted traffic rate to see if termination >> is really needed. >> >> Tom >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science Am Hubland, > D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn