From toby@moncaster.com Thu Jun 2 07:52:05 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0220DE07E1 for ; Thu, 2 Jun 2011 07:52:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HMM4yAnacyK for ; Thu, 2 Jun 2011 07:52:04 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id B236BE07DA for ; Thu, 2 Jun 2011 07:52:03 -0700 (PDT) Received: from TobysHP (host86-156-248-136.range86-156.btcentralplus.com [86.156.248.136]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MOlGA-1QUuw80vLS-005jb6; Thu, 02 Jun 2011 16:52:02 +0200 From: "Toby Moncaster" To: Date: Thu, 2 Jun 2011 15:51:58 +0100 Message-ID: <003701cc2134$a022e840$e068b8c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcwhNJ+uUAI1A5VhR2668ytUOTdYfQ== Content-Language: en-gb X-Provags-ID: V02:K0:2GtAkYkWwMlgpYJ107dZd55tCs4xZ65+xxSUXuKlCRD 6jNcdWjGxKrcRGJkGo7lJ2RrLesglOQuM7PXZhHKKRRHjLH/JZ 9qxgZjup/VirzrZR+Z4q+UiK4xeQibuOr20LwG1MuWAZZknDdq Gr1+pTGYsVXxU6wwuuwCytaYCNMCOjEVBgm+DEtZk6vBKmXxJK fvf/zB1HvtRGP8U4GuYzYx2JLNtAPTqT6dDHkcYLFM= Subject: [PCN] proposed status for 3-in-1 and basleine X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:52:05 -0000 Hi All, The authors of draft-ietf-pcn-3-in-1-encoding have been trying to figure out exactly what to do regarding the potential conflict between this and the baseline encoding RFC5696. We still haven't reached complete agreement, but we seem to be moving closer. At this stage it seems appropriate to get the WG to comment and decide whether they agree with our proposals or not. The problem is twofold - firstly, if both of these become a standard there will be a conflict over the definition of the 01 codepoint (EXP in RFC5696 and ThM in 3-in-1). Secondly, as it stands 3-in-1 makes it hard for an operator to choose to only run threshold marking in their domain (unless they can be certain that all tunnel endpoints are fully compliant with RFC6040). Our 2 proposed solutions are as follows: Both options require RFC5696 to be obsolete and key parts of the text of that RFC to be moved into the new 3-in-1. In both options: * 00 MUST indicate Not PCN * 10 MUST indicate Not Marked (NM) Option A: * The Threshold Marker MUST mark 01 * The Excess Traffic Marker MUST mark 11 Option B * The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however the second option is NOT RECOMMENDED. If the Threshold marker does mark 11 then nodes in the PCN-domain MUST NOT be marking using the excess traffic meter (since that meter needs to know which packets had already been marked ETM). * The Excess Traffic meter MUST mark 11 Option A is what 3-in-1 currently says. This restricts ThM to only ever marking 01 and thus risking being lost in a tunnel that isn't compliant with RFC6040 normal mode. Option B holds open the door for operators wishing to use only threshold marking but wanting to not worry about which tunnels are running. It was Bob's suggestion to define this in terms of what the traffic meter functions do, rather than the other way round. This allows us to be flexible with the definition of threshold marking (although the text of RFC5670 makes it harder to do the same for excess traffic marking as it assumes that an ETM packet is a defined entity). I personally prefer option B and I believe Bob also favours that option. I am not clear what Michael's position is but I know he is uneasy about obsoleting RFC5696. We would welcome feedback from the WG, especially from those members with significant experience of updating and revising standards... Toby From menth@informatik.uni-tuebingen.de Thu Jun 2 13:29:54 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC259E0876 for ; Thu, 2 Jun 2011 13:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkIxtKRRtYCx for ; Thu, 2 Jun 2011 13:29:53 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id E53FBE081A for ; Thu, 2 Jun 2011 13:29:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id EA4B852C8 for ; Thu, 2 Jun 2011 22:29:45 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMpuYjiakEZm for ; Thu, 2 Jun 2011 22:29:43 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0DC0652CD for ; Thu, 2 Jun 2011 22:29:43 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5FBAA1126917 for ; Thu, 2 Jun 2011 22:29:43 +0200 (CEST) Message-ID: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> Date: Thu, 02 Jun 2011 22:29:57 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "pcn@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:29:55 -0000 Hi all, here is my interpretation of Option B. It is probably more restrictive than the general formulation, but defining four PCN-encoding types simplifies talking about them. Names ma be changed. Bob, please correct me if I am wrong! In the following, four different types of PCN encoding are presented. The codepoints are labeled with the type-specific meaning, and the type-specific transition diagram is given that indicates how excess-traffic-marking and threshold-marking re-mark the codepoint if their meters indicate to re-mark a packet. 1. ETM-baseline (used for excess-traffic-marking only) 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = excess-traffic-marked (ETM) excess-traffic-marker 10 ---------------------> 11 2. ThM-baseline (used for threshold-marking only) 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = threshold-marked (ThM) threshold-marker 10 --------------------> 11 3. 3-in-1 (extension of ETM-baseline, used for parallel use of excess-traffic-marking and threshold-marking in networks with only RFC6040-compliant tunnel decapsulators) 00 = not-PCN, 10 = not-marked (NM), 10 = threshold-marked (ThM), 11 = excess-traffic-marked (ETM) excess-traffic-marker +-------------------------------------+ | | | V 10 -----------> 01 -----------------> 11 threshold- excess-traffic- marker marker 4. PSDM (extension of ETM-baseline, used for parallel use of excess-traffic-marking and threshold-marking in networks with non-RFC6040-compliant tunnel decapsulators) 00 = not-PCN, 10 = not-excess-traffic-marked (NETM), 10 = not-threshold-marked (NThM), 11 = marked (M) excess-traffic-marker +----------------------------+ | | | V 10 10 ---------------> 11 threshold-marker All four types are designed in a way that o excess-traffic-metering MUST count the bytes of all 10- and 01-marked packets. o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked packets. o 11 indicates most severe pre-congestion. If packets need to be dropped in case of overload, existing edge behaviors [CL, SM] require that 11-marked packet SHOULD preferentially be dropped. Example uses o In SM, nodes work with ETM-baseline. o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not perform threshold-marking. o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if they do not perform threshold-marking. o The AC-subset of CL works with nodes that perform only threshold-marking and ThM-baseline. Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Thu Jun 2 13:29:54 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A9E085D for ; Thu, 2 Jun 2011 13:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc1MGfvHtYkU for ; Thu, 2 Jun 2011 13:29:53 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id E4F4CE0814 for ; Thu, 2 Jun 2011 13:29:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 21CA852D1 for ; Thu, 2 Jun 2011 22:29:46 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIMQgxJKMuiD for ; Thu, 2 Jun 2011 22:29:41 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 29C815281 for ; Thu, 2 Jun 2011 22:29:41 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1EA0B1126916 for ; Thu, 2 Jun 2011 22:29:41 +0200 (CEST) Message-ID: <4DE7F2C1.1030404@informatik.uni-tuebingen.de> Date: Thu, 02 Jun 2011 22:29:53 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: pcn@ietf.org References: <003701cc2134$a022e840$e068b8c0$@com> In-Reply-To: <003701cc2134$a022e840$e068b8c0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] proposed status for 3-in-1 and basleine X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:29:55 -0000 Hi all, Am 02.06.2011 16:51, schrieb Toby Moncaster: > Hi All, > > The authors of draft-ietf-pcn-3-in-1-encoding have been trying to figure out > exactly what to do regarding the potential conflict between this and the > baseline encoding RFC5696. > > We still haven't reached complete agreement, but we seem to be moving > closer. At this stage it seems appropriate to get the WG to comment and > decide whether they agree with our proposals or not. > > The problem is twofold - firstly, if both of these become a standard there > will be a conflict over the definition of the 01 codepoint (EXP in RFC5696 > and ThM in 3-in-1). Secondly, as it stands 3-in-1 makes it hard for an > operator to choose to only run threshold marking in their domain (unless > they can be certain that all tunnel endpoints are fully compliant with > RFC6040). > > Our 2 proposed solutions are as follows: > > Both options require RFC5696 to be obsolete and key parts of the text of > that RFC to be moved into the new 3-in-1. In both options: > > * 00 MUST indicate Not PCN > * 10 MUST indicate Not Marked (NM) > > Option A: > > * The Threshold Marker MUST mark 01 > * The Excess Traffic Marker MUST mark 11 > > Option B > > * The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however > the second option is NOT RECOMMENDED. If the Threshold marker does mark 11 > then nodes in the > PCN-domain MUST NOT be marking using the excess traffic meter (since that > meter needs to know which packets had already been marked ETM). > > * The Excess Traffic meter MUST mark 11 This text is designed in a way to keep the door open for baseline encoding applied for threshold marking and for PSDM - which is good. So if this is the case, I agree 100% about the contents, but I do not agree about the formulation for two reasons: 1) It is so complicated that only experts know what this formulation is good for. 2) It allows for different options without naming them. Therefore, referring to this formulation alone does not create a clear standard since it is difficult to describe which option is needed for a specific edge behavior. Therefore, I suggest to give names to the options and clarify or illustrate that text in some form. I'll propose such text in a separate email. Regards, Michael > Option A is what 3-in-1 currently says. This restricts ThM to only ever > marking 01 and thus risking being lost in a tunnel that isn't compliant with > RFC6040 normal mode. > > Option B holds open the door for operators wishing to use only threshold > marking but wanting to not worry about which tunnels are running. > > It was Bob's suggestion to define this in terms of what the traffic meter > functions do, rather than the other way round. This allows us to be flexible > with the definition of threshold marking (although the text of RFC5670 makes > it harder to do the same for excess traffic marking as it assumes that an > ETM packet is a defined entity). > > I personally prefer option B and I believe Bob also favours that option. I > am not clear what Michael's position is but I know he is uneasy about > obsoleting RFC5696. > > We would welcome feedback from the WG, especially from those members with > significant experience of updating and revising standards... > > Toby > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From philip.eardley@bt.com Fri Jun 3 01:15:14 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418BAE06FD for ; Fri, 3 Jun 2011 01:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.896 X-Spam-Level: X-Spam-Status: No, score=-101.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlYhnGiW+76c for ; Fri, 3 Jun 2011 01:15:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6521FE065D for ; Fri, 3 Jun 2011 01:15:13 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 3 Jun 2011 09:15:12 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.151]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 3 Jun 2011 09:15:11 +0100 From: To: , Date: Fri, 3 Jun 2011 09:15:09 +0100 Thread-Topic: [PCN] Additional formulation to illustrate PCN encoding types Thread-Index: AcwhY9pgzy4tkcoOTX2vTWUVX5UVqQAYD70w Message-ID: <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> In-Reply-To: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:15:14 -0000 Sort of... (note you have a typo, as you have '10' twice in each case) BUT Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it MUST ha= ve the ability to be reconfigured to mark 11) Bob is suggesting that a case when the SHOULD may not apply is when you hav= e non 6040 tunnels inside your PCN-domain; the default choice is single (ex= cess) marking, but you could also do either your option 2 or 4 below - note= Option 2 & 4 both break the SHOULD) The way you have written it below has a quite different emphasis (a series = of options of equal merit) Personally I'm inclined to think allowing the flexibility is not worth it (= but open to persuasion) I'm also inclined to think that it is disguising one form of flexibility (p= sdm) in a way that is not obvious, so would need spelling out in an illustr= ative appendix. =09 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: 02 June 2011 21:30 To: pcn@ietf.org Subject: [PCN] Additional formulation to illustrate PCN encoding types Hi all, here is my interpretation of Option B. It is probably more restrictive=20 than the general formulation, but defining four PCN-encoding types=20 simplifies talking about them. Names ma be changed. Bob, please correct=20 me if I am wrong! In the following, four different types of PCN encoding are presented.=20 The codepoints are labeled with the type-specific meaning, and the=20 type-specific transition diagram is given that indicates how=20 excess-traffic-marking and threshold-marking re-mark the codepoint if=20 their meters indicate to re-mark a packet. 1. ETM-baseline (used for excess-traffic-marking only) 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D not-used (NU), 11 =3D=20 excess-traffic-marked (ETM) excess-traffic-marker 10 ---------------------> 11 2. ThM-baseline (used for threshold-marking only) 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D not-used (NU), 11 =3D=20 threshold-marked (ThM) threshold-marker 10 --------------------> 11 3. 3-in-1 (extension of ETM-baseline, used for parallel use of=20 excess-traffic-marking and threshold-marking in networks with only=20 RFC6040-compliant tunnel decapsulators) 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D threshold-marked (ThM), 11 = =3D=20 excess-traffic-marked (ETM) excess-traffic-marker +-------------------------------------+ | | | V 10 -----------> 01 -----------------> 11 threshold- excess-traffic- marker marker 4. PSDM (extension of ETM-baseline, used for parallel use of=20 excess-traffic-marking and threshold-marking in networks with=20 non-RFC6040-compliant tunnel decapsulators) 00 =3D not-PCN, 10 =3D not-excess-traffic-marked (NETM), 10 =3D=20 not-threshold-marked (NThM), 11 =3D marked (M) excess-traffic-marker +----------------------------+ | | | V 10 10 ---------------> 11 threshold-marker All four types are designed in a way that o excess-traffic-metering MUST count the bytes of all 10- and 01-marked=20 packets. o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked=20 packets. o 11 indicates most severe pre-congestion. If packets need to be dropped=20 in case of overload, existing edge behaviors [CL, SM] require that=20 11-marked packet SHOULD preferentially be dropped. Example uses o In SM, nodes work with ETM-baseline. o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not=20 perform threshold-marking. o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if=20 they do not perform threshold-marking. o The AC-subset of CL works with nodes that perform only=20 threshold-marking and ThM-baseline. Regards, Michael --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Fri Jun 3 01:17:39 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF89E0696 for ; Fri, 3 Jun 2011 01:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.946 X-Spam-Level: X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4lTisXGAZW2 for ; Fri, 3 Jun 2011 01:17:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E2CD2E065D for ; Fri, 3 Jun 2011 01:17:38 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 3 Jun 2011 09:17:38 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.151]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 3 Jun 2011 09:17:37 +0100 From: To: , Date: Fri, 3 Jun 2011 09:17:36 +0100 Thread-Topic: [PCN] proposed status for 3-in-1 and basleine Thread-Index: AcwhY+P0aV8ylvrESVqYaAg3quyCJQAYorog Message-ID: <9510D26531EF184D9017DF24659BB87F32DE7E9C19@EMV65-UKRD.domain1.systemhost.net> References: <003701cc2134$a022e840$e068b8c0$@com> <4DE7F2C1.1030404@informatik.uni-tuebingen.de> In-Reply-To: <4DE7F2C1.1030404@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] proposed status for 3-in-1 and basleine X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:17:39 -0000 > Both options require RFC5696 to be obsolete and key parts of the text of > that RFC to be moved into the new 3-in-1. In both options: > > * 00 MUST indicate Not PCN > * 10 MUST indicate Not Marked (NM) > > Option A: > > * The Threshold Marker MUST mark 01 > * The Excess Traffic Marker MUST mark 11 > > Option B > > * The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however > the second option is NOT RECOMMENDED. If the Threshold marker does mark 1= 1 > then nodes in the > PCN-domain MUST NOT be marking using the excess traffic meter (since that > meter needs to know which packets had already been marked ETM). > > * The Excess Traffic meter MUST mark 11 This text is designed in a way to keep the door open for baseline=20 encoding applied for threshold marking and for PSDM - which is good. So=20 if this is the case, I agree 100% about the contents, but I do not agree=20 about the formulation for two reasons: 1) It is so complicated that only experts know what this formulation is=20 good for. 2) It allows for different options without naming them. Therefore,=20 referring to this formulation alone does not create a clear standard=20 since it is difficult to describe which option is needed for a specific=20 edge behavior. Therefore, I suggest to give names to the options and clarify or=20 illustrate that text in some form. I'll propose such text in a separate=20 email. [phil] This can be done by having a short Normative section with Bob-style text an= d a longer Informative appendix with Mcihael-style text. That also helps ex= plain what the Normative text means. From philip.eardley@bt.com Fri Jun 3 01:23:31 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3878E065D for ; Fri, 3 Jun 2011 01:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR4H5AdpwhTc for ; Fri, 3 Jun 2011 01:23:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA7E06F8 for ; Fri, 3 Jun 2011 01:23:27 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 3 Jun 2011 09:23:26 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.151]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 3 Jun 2011 09:23:26 +0100 From: To: , Date: Fri, 3 Jun 2011 09:23:25 +0100 Thread-Topic: [PCN] Additional formulation to illustrate PCN encoding types Thread-Index: AcwhY9pgzy4tkcoOTX2vTWUVX5UVqQAYt7/Q Message-ID: <9510D26531EF184D9017DF24659BB87F32DE7E9C30@EMV65-UKRD.domain1.systemhost.net> References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> In-Reply-To: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:23:31 -0000 o 11 indicates most severe pre-congestion. If packets need to be dropped=20 in case of overload, existing edge behaviors [CL, SM] require that=20 11-marked packet SHOULD preferentially be dropped. [phil] Just to be exact, 5670 says that o PCN-packets that arrive at the PCN-node already excess-traffic- marked SHOULD be preferentially dropped. From menth@informatik.uni-tuebingen.de Fri Jun 3 01:28:49 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41467E070C for ; Fri, 3 Jun 2011 01:28:49 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkQlj2fDUEya for ; Fri, 3 Jun 2011 01:28:48 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.informatik.uni-tuebingen.de [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 04625E0696 for ; Fri, 3 Jun 2011 01:28:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 719905218; Fri, 3 Jun 2011 10:28:46 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWflVqSTJUyk; Fri, 3 Jun 2011 10:28:44 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D771D512D; Fri, 3 Jun 2011 10:28:43 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0160B1CF33B6; Fri, 3 Jun 2011 10:28:43 +0200 (CEST) Message-ID: <4DE89B49.5020809@informatik.uni-tuebingen.de> Date: Fri, 03 Jun 2011 10:28:57 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C30@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DE7E9C30@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:28:49 -0000 Yes, RFC5670 should be added as reference here. Am 03.06.2011 10:23, schrieb philip.eardley@bt.com: > o 11 indicates most severe pre-congestion. If packets need to be dropped > in case of overload, existing edge behaviors [CL, SM] require that > 11-marked packet SHOULD preferentially be dropped. > > [phil] > Just to be exact, 5670 says that > o PCN-packets that arrive at the PCN-node already excess-traffic- > marked SHOULD be preferentially dropped. -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Fri Jun 3 01:38:47 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9138E0752 for ; Fri, 3 Jun 2011 01:38:47 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys2X6gBCwwkd for ; Fri, 3 Jun 2011 01:38:47 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.informatik.uni-tuebingen.de [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id CBFC5E065D for ; Fri, 3 Jun 2011 01:38:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B0C875218; Fri, 3 Jun 2011 10:38:45 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx9N+yyEmETv; Fri, 3 Jun 2011 10:38:42 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 45A23512D; Fri, 3 Jun 2011 10:38:42 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6194F112A239; Fri, 3 Jun 2011 10:38:42 +0200 (CEST) Message-ID: <4DE89DA0.1060400@informatik.uni-tuebingen.de> Date: Fri, 03 Jun 2011 10:38:56 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:38:48 -0000 Hi Phil, yes, the cases should be ordered in a different way. I believe that it is most important to give them names so tat manufacturers can say what type of PCN encoding their equipment supports. I'd say that ETM-baseline and 3-in-1 are MUST for implementations supporting systems with excess traffic marking and threshold marking while ThM-baseline and PSDM may also be provided in order to allow for PCN implementations with pre-RFC6040 network support. Best wishes, Michael Am 03.06.2011 10:15, schrieb philip.eardley@bt.com: > Sort of... > > (note you have a typo, as you have '10' twice in each case) > > BUT > Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it MUST have the ability to be reconfigured to mark 11) > Bob is suggesting that a case when the SHOULD may not apply is when you have non 6040 tunnels inside your PCN-domain; the default choice is single (excess) marking, but you could also do either your option 2 or 4 below - note Option 2& 4 both break the SHOULD) > > The way you have written it below has a quite different emphasis (a series of options of equal merit) > > Personally I'm inclined to think allowing the flexibility is not worth it (but open to persuasion) > I'm also inclined to think that it is disguising one form of flexibility (psdm) in a way that is not obvious, so would need spelling out in an illustrative appendix. > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth > Sent: 02 June 2011 21:30 > To: pcn@ietf.org > Subject: [PCN] Additional formulation to illustrate PCN encoding types > > Hi all, > > here is my interpretation of Option B. It is probably more restrictive > than the general formulation, but defining four PCN-encoding types > simplifies talking about them. Names ma be changed. Bob, please correct > me if I am wrong! > > In the following, four different types of PCN encoding are presented. > The codepoints are labeled with the type-specific meaning, and the > type-specific transition diagram is given that indicates how > excess-traffic-marking and threshold-marking re-mark the codepoint if > their meters indicate to re-mark a packet. > > > 1. ETM-baseline (used for excess-traffic-marking only) > > 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = > excess-traffic-marked (ETM) > > excess-traffic-marker > 10 ---------------------> 11 > > > > 2. ThM-baseline (used for threshold-marking only) > > 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = > threshold-marked (ThM) > > threshold-marker > 10 --------------------> 11 > > > > 3. 3-in-1 (extension of ETM-baseline, used for parallel use of > excess-traffic-marking and threshold-marking in networks with only > RFC6040-compliant tunnel decapsulators) > > 00 = not-PCN, 10 = not-marked (NM), 10 = threshold-marked (ThM), 11 = > excess-traffic-marked (ETM) > > excess-traffic-marker > +-------------------------------------+ > | | > | V > 10 -----------> 01 -----------------> 11 > threshold- excess-traffic- > marker marker > > > 4. PSDM (extension of ETM-baseline, used for parallel use of > excess-traffic-marking and threshold-marking in networks with > non-RFC6040-compliant tunnel decapsulators) > > 00 = not-PCN, 10 = not-excess-traffic-marked (NETM), 10 = > not-threshold-marked (NThM), 11 = marked (M) > > excess-traffic-marker > +----------------------------+ > | | > | V > 10 10 ---------------> 11 > threshold-marker > > > All four types are designed in a way that > > o excess-traffic-metering MUST count the bytes of all 10- and 01-marked > packets. > o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked > packets. > o 11 indicates most severe pre-congestion. If packets need to be dropped > in case of overload, existing edge behaviors [CL, SM] require that > 11-marked packet SHOULD preferentially be dropped. > > Example uses > > o In SM, nodes work with ETM-baseline. > o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not > perform threshold-marking. > o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if > they do not perform threshold-marking. > o The AC-subset of CL works with nodes that perform only > threshold-marking and ThM-baseline. > > > Regards, > > Michael > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From philip.eardley@bt.com Fri Jun 3 02:08:09 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8BEE06C0 for ; Fri, 3 Jun 2011 02:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.686 X-Spam-Level: X-Spam-Status: No, score=-101.686 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVjDJYKXVKwh for ; Fri, 3 Jun 2011 02:08:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2EE06F4 for ; Fri, 3 Jun 2011 02:08:08 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 3 Jun 2011 10:08:06 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.151]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 3 Jun 2011 10:08:06 +0100 From: To: Date: Fri, 3 Jun 2011 10:08:05 +0100 Thread-Topic: [PCN] Additional formulation to illustrate PCN encoding types Thread-Index: Acwhyam3iapMCQQmQA2bVrH5wJuvVwAA4Phw Message-ID: <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> <4DE89DA0.1060400@informatik.uni-tuebingen.de> In-Reply-To: <4DE89DA0.1060400@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 09:08:09 -0000 We need to be exact. Option B doesn't say "may also be provided". It says=20 Threshold marking SHOULD mark 01 but MUST be able to mark 11 I dont mind us discussing Option C, D.... but let's be clear what we're dis= cussing I suggest we first discuss which Option we want to go forward with, then we= discuss how to phrase it=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]=20 Sent: 03 June 2011 09:39 To: Eardley,PL,Philip,DES8 R Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types Hi Phil, yes, the cases should be ordered in a different way. I believe that it=20 is most important to give them names so tat manufacturers can say what=20 type of PCN encoding their equipment supports. I'd say that ETM-baseline and 3-in-1 are MUST for implementations=20 supporting systems with excess traffic marking and threshold marking=20 while ThM-baseline and PSDM may also be provided in order to allow for=20 PCN implementations with pre-RFC6040 network support. Best wishes, Michael Am 03.06.2011 10:15, schrieb philip.eardley@bt.com: > Sort of... > > (note you have a typo, as you have '10' twice in each case) > > BUT > Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it MUST = have the ability to be reconfigured to mark 11) > Bob is suggesting that a case when the SHOULD may not apply is when you h= ave non 6040 tunnels inside your PCN-domain; the default choice is single (= excess) marking, but you could also do either your option 2 or 4 below - no= te Option 2& 4 both break the SHOULD) > > The way you have written it below has a quite different emphasis (a serie= s of options of equal merit) > > Personally I'm inclined to think allowing the flexibility is not worth it= (but open to persuasion) > I'm also inclined to think that it is disguising one form of flexibility = (psdm) in a way that is not obvious, so would need spelling out in an illus= trative appendix. > =09 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Mic= hael Menth > Sent: 02 June 2011 21:30 > To: pcn@ietf.org > Subject: [PCN] Additional formulation to illustrate PCN encoding types > > Hi all, > > here is my interpretation of Option B. It is probably more restrictive > than the general formulation, but defining four PCN-encoding types > simplifies talking about them. Names ma be changed. Bob, please correct > me if I am wrong! > > In the following, four different types of PCN encoding are presented. > The codepoints are labeled with the type-specific meaning, and the > type-specific transition diagram is given that indicates how > excess-traffic-marking and threshold-marking re-mark the codepoint if > their meters indicate to re-mark a packet. > > > 1. ETM-baseline (used for excess-traffic-marking only) > > 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D not-used (NU), 11 =3D > excess-traffic-marked (ETM) > > excess-traffic-marker > 10 ---------------------> 11 > > > > 2. ThM-baseline (used for threshold-marking only) > > 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D not-used (NU), 11 =3D > threshold-marked (ThM) > > threshold-marker > 10 --------------------> 11 > > > > 3. 3-in-1 (extension of ETM-baseline, used for parallel use of > excess-traffic-marking and threshold-marking in networks with only > RFC6040-compliant tunnel decapsulators) > > 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D threshold-marked (ThM), 11= =3D > excess-traffic-marked (ETM) > > excess-traffic-marker > +-------------------------------------+ > | | > | V > 10 -----------> 01 -----------------> 11 > threshold- excess-traffic- > marker marker > > > 4. PSDM (extension of ETM-baseline, used for parallel use of > excess-traffic-marking and threshold-marking in networks with > non-RFC6040-compliant tunnel decapsulators) > > 00 =3D not-PCN, 10 =3D not-excess-traffic-marked (NETM), 10 =3D > not-threshold-marked (NThM), 11 =3D marked (M) > > excess-traffic-marker > +----------------------------+ > | | > | V > 10 10 ---------------> 11 > threshold-marker > > > All four types are designed in a way that > > o excess-traffic-metering MUST count the bytes of all 10- and 01-marked > packets. > o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked > packets. > o 11 indicates most severe pre-congestion. If packets need to be dropped > in case of overload, existing edge behaviors [CL, SM] require that > 11-marked packet SHOULD preferentially be dropped. > > Example uses > > o In SM, nodes work with ETM-baseline. > o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not > perform threshold-marking. > o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if > they do not perform threshold-marking. > o The AC-subset of CL works with nodes that perform only > threshold-marking and ThM-baseline. > > > Regards, > > Michael > --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From toby@moncaster.com Fri Jun 3 02:27:35 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8BE0747 for ; Fri, 3 Jun 2011 02:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ahJulIv4fx9 for ; Fri, 3 Jun 2011 02:27:34 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5B517E0720 for ; Fri, 3 Jun 2011 02:27:34 -0700 (PDT) Received: from TobysHP (host86-156-248-136.range86-156.btcentralplus.com [86.156.248.136]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M0RJt-1PajaD08Vh-00uWsh; Fri, 03 Jun 2011 11:27:32 +0200 From: "Toby Moncaster" To: , References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> <4DE89DA0.1060400@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> Date: Fri, 3 Jun 2011 10:27:29 +0100 Message-ID: <000f01cc21d0$75d24350$6176c9f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acwhyam3iapMCQQmQA2bVrH5wJuvVwAA4PhwAACHo9A= Content-Language: en-gb X-Provags-ID: V02:K0:fTfL8ar8jkvvPzyIbPWiOIel8S62fyF6g/C2wgZltBy qNaVF2Re3B+kCtf/XG5+woAR0FhFsWTtriT3rOzQBVaId4dia4 b5a6TTAKsFOvy1bO52nCJ6EG72WQzfZEwRHaRW6WqyXxC5Wa7q 9UGLb95u4SJo+nlHv7hpfnhh3JQNA9ZYa4UfOgN7z/00YUUaqK VjykKrRNbtju0u41XsB2YGAV4rZn1pEsKN+iCtdOiQ= Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 09:27:35 -0000 Unless I've got the wrong end of the stick, there seems to be a consensus that something akin to Option B is favoured. The debate seems to be about how can we limit any additional complexity whilst still holding the door open to alternative marking schemes... I am keen that we shouldn't lock this down too hard because I don't want to slip into the usual IETF trap of having a standard that blocks future development. However I want to make it as easy as possible for vendors to see what we recommend as the default behaviour. Incidentally Michael, I am not 100% sure that PSDM survives all pre-6040 tunnels. Make sure you read 6040 really carefully and look at all the possible transitions that existed before then. I am sure I came across one that was bad for the ECT(1) codepoint... Final note to everyone: The NM codepoint is (and always will be) 10 which corresponds to ECT(0) in ECN. It's that way round (rather than 01) because originally it was a pair of flags for ECT and CE... So all our discussions are about the meaning of the 01 codepoint (or ECT(1)). Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 03 June 2011 10:08 > To: menth@informatik.uni-tuebingen.de > Cc: pcn@ietf.org > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding > types > > We need to be exact. > Option B doesn't say "may also be provided". It says > Threshold marking SHOULD mark 01 but MUST be able to mark 11 > > I dont mind us discussing Option C, D.... but let's be clear what we're > discussing > > I suggest we first discuss which Option we want to go forward with, > then we discuss how to phrase it > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 03 June 2011 09:39 > To: Eardley,PL,Philip,DES8 R > Cc: pcn@ietf.org > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding > types > > Hi Phil, > > yes, the cases should be ordered in a different way. I believe that it > is most important to give them names so tat manufacturers can say what > type of PCN encoding their equipment supports. > > I'd say that ETM-baseline and 3-in-1 are MUST for implementations > supporting systems with excess traffic marking and threshold marking > while ThM-baseline and PSDM may also be provided in order to allow for > PCN implementations with pre-RFC6040 network support. > > Best wishes, > > Michael > > Am 03.06.2011 10:15, schrieb philip.eardley@bt.com: > > Sort of... > > > > (note you have a typo, as you have '10' twice in each case) > > > > BUT > > Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it > MUST have the ability to be reconfigured to mark 11) > > Bob is suggesting that a case when the SHOULD may not apply is when > you have non 6040 tunnels inside your PCN-domain; the default choice is > single (excess) marking, but you could also do either your option 2 or > 4 below - note Option 2& 4 both break the SHOULD) > > > > The way you have written it below has a quite different emphasis (a > series of options of equal merit) > > > > Personally I'm inclined to think allowing the flexibility is not > worth it (but open to persuasion) > > I'm also inclined to think that it is disguising one form of > flexibility (psdm) in a way that is not obvious, so would need spelling > out in an illustrative appendix. > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > > Sent: 02 June 2011 21:30 > > To: pcn@ietf.org > > Subject: [PCN] Additional formulation to illustrate PCN encoding > types > > > > Hi all, > > > > here is my interpretation of Option B. It is probably more > restrictive > > than the general formulation, but defining four PCN-encoding types > > simplifies talking about them. Names ma be changed. Bob, please > correct > > me if I am wrong! > > > > In the following, four different types of PCN encoding are presented. > > The codepoints are labeled with the type-specific meaning, and the > > type-specific transition diagram is given that indicates how > > excess-traffic-marking and threshold-marking re-mark the codepoint if > > their meters indicate to re-mark a packet. > > > > > > 1. ETM-baseline (used for excess-traffic-marking only) > > > > 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = > > excess-traffic-marked (ETM) > > > > excess-traffic-marker > > 10 ---------------------> 11 > > > > > > > > 2. ThM-baseline (used for threshold-marking only) > > > > 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = > > threshold-marked (ThM) > > > > threshold-marker > > 10 --------------------> 11 > > > > > > > > 3. 3-in-1 (extension of ETM-baseline, used for parallel use of > > excess-traffic-marking and threshold-marking in networks with only > > RFC6040-compliant tunnel decapsulators) > > > > 00 = not-PCN, 10 = not-marked (NM), 10 = threshold-marked (ThM), 11 = > > excess-traffic-marked (ETM) > > > > excess-traffic-marker > > +-------------------------------------+ > > | | > > | V > > 10 -----------> 01 -----------------> 11 > > threshold- excess-traffic- > > marker marker > > > > > > 4. PSDM (extension of ETM-baseline, used for parallel use of > > excess-traffic-marking and threshold-marking in networks with > > non-RFC6040-compliant tunnel decapsulators) > > > > 00 = not-PCN, 10 = not-excess-traffic-marked (NETM), 10 = > > not-threshold-marked (NThM), 11 = marked (M) > > > > excess-traffic-marker > > +----------------------------+ > > | | > > | V > > 10 10 ---------------> 11 > > threshold-marker > > > > > > All four types are designed in a way that > > > > o excess-traffic-metering MUST count the bytes of all 10- and 01- > marked > > packets. > > o threshold-metering MUST count the bytes of all 10-, 01-, and 11- > marked > > packets. > > o 11 indicates most severe pre-congestion. If packets need to be > dropped > > in case of overload, existing edge behaviors [CL, SM] require that > > 11-marked packet SHOULD preferentially be dropped. > > > > Example uses > > > > o In SM, nodes work with ETM-baseline. > > o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not > > perform threshold-marking. > > o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if > > they do not perform threshold-marking. > > o The AC-subset of CL works with nodes that perform only > > threshold-marking and ThM-baseline. > > > > > > Regards, > > > > Michael > > > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-tuebingen.de Fri Jun 3 09:08:42 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D38E077E for ; Fri, 3 Jun 2011 09:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJP5xBe5Yina for ; Fri, 3 Jun 2011 09:08:41 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.informatik.uni-tuebingen.de [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 22085E06D5 for ; Fri, 3 Jun 2011 09:08:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AEC0D5239; Fri, 3 Jun 2011 18:08:37 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOXHMdZNt5Y8; Fri, 3 Jun 2011 18:08:34 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 92B9D512D; Fri, 3 Jun 2011 18:08:34 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 414791CF973B; Fri, 3 Jun 2011 18:08:34 +0200 (CEST) Message-ID: <4DE90710.2020206@informatik.uni-tuebingen.de> Date: Fri, 03 Jun 2011 18:08:48 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> <4DE89DA0.1060400@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:08:42 -0000 Hi Phil, Am 03.06.2011 11:08, schrieb philip.eardley@bt.com: > We need to be exact. Clarity is what I want to achieve ... > Option B doesn't say "may also be provided". It says > Threshold marking SHOULD mark 01 but MUST be able to mark 11 The latter sentence looks like a contradiction, especially if we say in addiction that the MUST-case is not recommended ... That's why I think it is nececcary to give an explantation that boils this down to concrete PCN encodings and say which of them is a MUST and which of them is not so necessary if we want to rank them for whatever reason. Best wishes, Michael > I dont mind us discussing Option C, D.... but let's be clear what we're discussing > > I suggest we first discuss which Option we want to go forward with, then we discuss how to phrase it > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 03 June 2011 09:39 > To: Eardley,PL,Philip,DES8 R > Cc: pcn@ietf.org > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types > > Hi Phil, > > yes, the cases should be ordered in a different way. I believe that it > is most important to give them names so tat manufacturers can say what > type of PCN encoding their equipment supports. > > I'd say that ETM-baseline and 3-in-1 are MUST for implementations > supporting systems with excess traffic marking and threshold marking > while ThM-baseline and PSDM may also be provided in order to allow for > PCN implementations with pre-RFC6040 network support. > > Best wishes, > > Michael > > Am 03.06.2011 10:15, schrieb philip.eardley@bt.com: >> Sort of... >> >> (note you have a typo, as you have '10' twice in each case) >> >> BUT >> Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it MUST have the ability to be reconfigured to mark 11) >> Bob is suggesting that a case when the SHOULD may not apply is when you have non 6040 tunnels inside your PCN-domain; the default choice is single (excess) marking, but you could also do either your option 2 or 4 below - note Option 2& 4 both break the SHOULD) >> >> The way you have written it below has a quite different emphasis (a series of options of equal merit) >> >> Personally I'm inclined to think allowing the flexibility is not worth it (but open to persuasion) >> I'm also inclined to think that it is disguising one form of flexibility (psdm) in a way that is not obvious, so would need spelling out in an illustrative appendix. >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth >> Sent: 02 June 2011 21:30 >> To: pcn@ietf.org >> Subject: [PCN] Additional formulation to illustrate PCN encoding types >> >> Hi all, >> >> here is my interpretation of Option B. It is probably more restrictive >> than the general formulation, but defining four PCN-encoding types >> simplifies talking about them. Names ma be changed. Bob, please correct >> me if I am wrong! >> >> In the following, four different types of PCN encoding are presented. >> The codepoints are labeled with the type-specific meaning, and the >> type-specific transition diagram is given that indicates how >> excess-traffic-marking and threshold-marking re-mark the codepoint if >> their meters indicate to re-mark a packet. >> >> >> 1. ETM-baseline (used for excess-traffic-marking only) >> >> 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = >> excess-traffic-marked (ETM) >> >> excess-traffic-marker >> 10 ---------------------> 11 >> >> >> >> 2. ThM-baseline (used for threshold-marking only) >> >> 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = >> threshold-marked (ThM) >> >> threshold-marker >> 10 --------------------> 11 >> >> >> >> 3. 3-in-1 (extension of ETM-baseline, used for parallel use of >> excess-traffic-marking and threshold-marking in networks with only >> RFC6040-compliant tunnel decapsulators) >> >> 00 = not-PCN, 10 = not-marked (NM), 10 = threshold-marked (ThM), 11 = >> excess-traffic-marked (ETM) >> >> excess-traffic-marker >> +-------------------------------------+ >> | | >> | V >> 10 -----------> 01 -----------------> 11 >> threshold- excess-traffic- >> marker marker >> >> >> 4. PSDM (extension of ETM-baseline, used for parallel use of >> excess-traffic-marking and threshold-marking in networks with >> non-RFC6040-compliant tunnel decapsulators) >> >> 00 = not-PCN, 10 = not-excess-traffic-marked (NETM), 10 = >> not-threshold-marked (NThM), 11 = marked (M) >> >> excess-traffic-marker >> +----------------------------+ >> | | >> | V >> 10 10 ---------------> 11 >> threshold-marker >> >> >> All four types are designed in a way that >> >> o excess-traffic-metering MUST count the bytes of all 10- and 01-marked >> packets. >> o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked >> packets. >> o 11 indicates most severe pre-congestion. If packets need to be dropped >> in case of overload, existing edge behaviors [CL, SM] require that >> 11-marked packet SHOULD preferentially be dropped. >> >> Example uses >> >> o In SM, nodes work with ETM-baseline. >> o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not >> perform threshold-marking. >> o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if >> they do not perform threshold-marking. >> o The AC-subset of CL works with nodes that perform only >> threshold-marking and ThM-baseline. >> >> >> Regards, >> >> Michael >> From philip.eardley@bt.com Fri Jun 3 09:19:08 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD72E0726 for ; Fri, 3 Jun 2011 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.946 X-Spam-Level: X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxk-51iuLWjL for ; Fri, 3 Jun 2011 09:19:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9F170E067F for ; Fri, 3 Jun 2011 09:19:07 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 3 Jun 2011 17:19:06 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.151]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 3 Jun 2011 17:19:06 +0100 From: To: , Date: Fri, 3 Jun 2011 17:19:05 +0100 Thread-Topic: [PCN] proposed status for 3-in-1 and basleine Thread-Index: AcwhNJ+uUAI1A5VhR2668ytUOTdYfQA1P4fw Message-ID: <9510D26531EF184D9017DF24659BB87F32DE8CF173@EMV65-UKRD.domain1.systemhost.net> References: <003701cc2134$a022e840$e068b8c0$@com> In-Reply-To: <003701cc2134$a022e840$e068b8c0$@com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] proposed status for 3-in-1 and basleine X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:19:08 -0000 ... Option B * The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however the second option is NOT RECOMMENDED. If the Threshold marker does mark 11 then nodes in the PCN-domain MUST NOT be marking using the excess traffic meter (since that meter needs to know which packets had already been marked ETM). [phil] Toby, did you mean this? (psdm does do both threshold and excess traffic ma= rking) From menth@informatik.uni-tuebingen.de Fri Jun 3 09:36:20 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E2AE0776 for ; Fri, 3 Jun 2011 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8jjfow9z5oj for ; Fri, 3 Jun 2011 09:36:18 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.informatik.uni-tuebingen.de [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 2EF1EE067F for ; Fri, 3 Jun 2011 09:36:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4AD645239 for ; Fri, 3 Jun 2011 18:36:17 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x++i7CW2oE8p for ; Fri, 3 Jun 2011 18:36:13 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E3164512D for ; Fri, 3 Jun 2011 18:36:12 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id F26811CF9D8E for ; Fri, 3 Jun 2011 18:36:12 +0200 (CEST) Message-ID: <4DE90D8A.6030704@informatik.uni-tuebingen.de> Date: Fri, 03 Jun 2011 18:36:26 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: pcn@ietf.org References: <003701cc2134$a022e840$e068b8c0$@com> <9510D26531EF184D9017DF24659BB87F32DE8CF173@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DE8CF173@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] proposed status for 3-in-1 and basleine X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:36:20 -0000 Hi Phil, Am 03.06.2011 18:19, schrieb philip.eardley@bt.com: > ... > > Option B > > * The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however > the second option is NOT RECOMMENDED. If the Threshold marker does mark 11 > then nodes in the > PCN-domain MUST NOT be marking using the excess traffic meter (since that > meter needs to know which packets had already been marked ETM). > > > [phil] > Toby, did you mean this? (psdm does do both threshold and excess traffic marking) Yes, psdm (packet-specific dual marking) supports both threshold and excess-traffic-marking, but for different packets. When reading the last sentence again, I realize that this conflicts with psdm. It should rather be formulated as follows: The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however the second option is NOT RECOMMENDED. If the Threshold marker does mark 11 then nodes in the PCN-domain MUST NOT be marking * the same set of packets * using the excess traffic meter (since that meter needs to know which packets had already been marked ETM). That probably reflects Bob's intention. Best wishes, Michael > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From philip.eardley@bt.com Fri Jun 3 10:22:49 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4AAE07B4 for ; Fri, 3 Jun 2011 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.51 X-Spam-Level: X-Spam-Status: No, score=-100.51 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghWB1zxvUQ2H for ; Fri, 3 Jun 2011 10:22:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 858C7E06BB for ; Fri, 3 Jun 2011 10:22:48 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 3 Jun 2011 18:22:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.151]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 3 Jun 2011 18:22:47 +0100 From: To: Date: Fri, 3 Jun 2011 18:22:45 +0100 Thread-Topic: [PCN] Additional formulation to illustrate PCN encoding types Thread-Index: AcwiCIcm1MLZiLtQTW24562XpgCzzwAAEGjQ Message-ID: <9510D26531EF184D9017DF24659BB87F32DE8CF1E3@EMV65-UKRD.domain1.systemhost.net> References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> <4DE89DA0.1060400@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> <4DE90710.2020206@informatik.uni-tuebingen.de> In-Reply-To: <4DE90710.2020206@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 17:22:50 -0000 The first thing is to choose between Option A: * The Threshold Marker MUST mark 01 * The Excess Traffic Marker MUST mark 11 Option B * The Threshold meter SHOULD mark 01=20 * The Threshold meter MUST be able to be configured instead to mark 11 (ie = not follow the SHOULD. Why? pre-6040 tunnels etc),=20 * The Excess Traffic meter MUST mark 11 Option C Something else Pros and cons: Option A: Simple But only choice in pre-6040 environment is Single marking (or accept that P= CN-marking is effectively switched off along the tunnel) Option B: Allows some flexibility (*)=20 But requires meter/marker to have ability to be configured; requires operat= or to configure all PCN-nodes correctly. (*)in a pre-6040 environment, you can break the SHOULD, and either just mar= k with the Threshold meter to 11 (excess traffic meter off, admission contr= ol but no flow termination) - or you can do PSDM, with the threshold meter = marking 01 to 11, and excess traffic meter marking 10 to 11) I am somewhat uncertain what this flexibility actually means. For example,= =20 - a vendor could build a compliant meter/marker that doesn't do psdm (it do= es the 'either' option in the previous para) - another vendor could build a compliant meter/marker that does do psdm (it= does the or' option in the previous para, but not the 'either' option) - the operator could therefore buy compliant kit from the two vendors which= would not interoperate (to the extent that in a pre-6040 environment it wo= uld only be able to do Single marking) The basic issue is that psdm has to do additional BA aggregate classificati= on (not just 'is it a PCN-pkt?' but also 'is it a not-marked PCN-pkt open f= or threshold marking, or a not-marked PCN-pkt open for excess traffic marki= ng?') So the question is whether we just say " The Threshold meter MUST be able t= o be configured instead to mark 11" (and leave it to the vendor and operato= r to discuss what exactly this MUST means) or we say something more explici= t:- a. threshold marker MUST be able to be configured to mark 10 to 11 (instead= of the default, 10 to 01) and (presumably) the excess traffic marker is sw= itched off [corresponds to the 'either' option of the (*) para] b. threshold marker MUST be able to be configured instead to mark 01 to 11 = and excess traffic marker MUST be able to be configured _not_ to mark 01 to= 11 [corresponds to the 'or' option of the (*) para] c. MUST be able to do both a & b I think "a" is quite a small change for a vendor and probably doesnt cause = too many issues if the operator misconfigures, so is probably OK to require= /allow this. Whereas "b" seems a bigger change for a vendor and probably leads to signif= icant issues if the operator misconfigures, so I'm not convinced this is fl= exibility that we should require/allow. phil -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]=20 Sent: 03 June 2011 17:09 To: Eardley,PL,Philip,DES8 R Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types Hi Phil, Am 03.06.2011 11:08, schrieb philip.eardley@bt.com: > We need to be exact. Clarity is what I want to achieve ... > Option B doesn't say "may also be provided". It says > Threshold marking SHOULD mark 01 but MUST be able to mark 11 The latter sentence looks like a contradiction, especially if we say in=20 addiction that the MUST-case is not recommended ... That's why I think=20 it is nececcary to give an explantation that boils this down to concrete=20 PCN encodings and say which of them is a MUST and which of them is not=20 so necessary if we want to rank them for whatever reason. Best wishes, Michael > I dont mind us discussing Option C, D.... but let's be clear what we're d= iscussing > > I suggest we first discuss which Option we want to go forward with, then = we discuss how to phrase it > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 03 June 2011 09:39 > To: Eardley,PL,Philip,DES8 R > Cc: pcn@ietf.org > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding type= s > > Hi Phil, > > yes, the cases should be ordered in a different way. I believe that it > is most important to give them names so tat manufacturers can say what > type of PCN encoding their equipment supports. > > I'd say that ETM-baseline and 3-in-1 are MUST for implementations > supporting systems with excess traffic marking and threshold marking > while ThM-baseline and PSDM may also be provided in order to allow for > PCN implementations with pre-RFC6040 network support. > > Best wishes, > > Michael > > Am 03.06.2011 10:15, schrieb philip.eardley@bt.com: >> Sort of... >> >> (note you have a typo, as you have '10' twice in each case) >> >> BUT >> Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it MUST= have the ability to be reconfigured to mark 11) >> Bob is suggesting that a case when the SHOULD may not apply is when you = have non 6040 tunnels inside your PCN-domain; the default choice is single = (excess) marking, but you could also do either your option 2 or 4 below - n= ote Option 2& 4 both break the SHOULD) >> >> The way you have written it below has a quite different emphasis (a seri= es of options of equal merit) >> >> Personally I'm inclined to think allowing the flexibility is not worth i= t (but open to persuasion) >> I'm also inclined to think that it is disguising one form of flexibility= (psdm) in a way that is not obvious, so would need spelling out in an illu= strative appendix. >> =09 >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Mi= chael Menth >> Sent: 02 June 2011 21:30 >> To: pcn@ietf.org >> Subject: [PCN] Additional formulation to illustrate PCN encoding types >> >> Hi all, >> >> here is my interpretation of Option B. It is probably more restrictive >> than the general formulation, but defining four PCN-encoding types >> simplifies talking about them. Names ma be changed. Bob, please correct >> me if I am wrong! >> >> In the following, four different types of PCN encoding are presented. >> The codepoints are labeled with the type-specific meaning, and the >> type-specific transition diagram is given that indicates how >> excess-traffic-marking and threshold-marking re-mark the codepoint if >> their meters indicate to re-mark a packet. >> >> >> 1. ETM-baseline (used for excess-traffic-marking only) >> >> 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D not-used (NU), 11 =3D >> excess-traffic-marked (ETM) >> >> excess-traffic-marker >> 10 ---------------------> 11 >> >> >> >> 2. ThM-baseline (used for threshold-marking only) >> >> 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D not-used (NU), 11 =3D >> threshold-marked (ThM) >> >> threshold-marker >> 10 --------------------> 11 >> >> >> >> 3. 3-in-1 (extension of ETM-baseline, used for parallel use of >> excess-traffic-marking and threshold-marking in networks with only >> RFC6040-compliant tunnel decapsulators) >> >> 00 =3D not-PCN, 10 =3D not-marked (NM), 10 =3D threshold-marked (ThM), 1= 1 =3D >> excess-traffic-marked (ETM) >> >> excess-traffic-marker >> +-------------------------------------+ >> | | >> | V >> 10 -----------> 01 -----------------> 11 >> threshold- excess-traffic- >> marker marker >> >> >> 4. PSDM (extension of ETM-baseline, used for parallel use of >> excess-traffic-marking and threshold-marking in networks with >> non-RFC6040-compliant tunnel decapsulators) >> >> 00 =3D not-PCN, 10 =3D not-excess-traffic-marked (NETM), 10 =3D >> not-threshold-marked (NThM), 11 =3D marked (M) >> >> excess-traffic-marker >> +----------------------------+ >> | | >> | V >> 10 10 ---------------> 11 >> threshold-marker >> >> >> All four types are designed in a way that >> >> o excess-traffic-metering MUST count the bytes of all 10- and 01-marked >> packets. >> o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked >> packets. >> o 11 indicates most severe pre-congestion. If packets need to be dropped >> in case of overload, existing edge behaviors [CL, SM] require that >> 11-marked packet SHOULD preferentially be dropped. >> >> Example uses >> >> o In SM, nodes work with ETM-baseline. >> o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not >> perform threshold-marking. >> o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if >> they do not perform threshold-marking. >> o The AC-subset of CL works with nodes that perform only >> threshold-marking and ThM-baseline. >> >> >> Regards, >> >> Michael >> From toby@moncaster.com Fri Jun 3 12:35:55 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D1AE07DE for ; Fri, 3 Jun 2011 12:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=-1.375, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEYa3kwswelB for ; Fri, 3 Jun 2011 12:35:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id C8FC9E067F for ; Fri, 3 Jun 2011 12:35:53 -0700 (PDT) Received: from TobysHP (host86-156-248-136.range86-156.btcentralplus.com [86.156.248.136]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LsNui-1PQxzj1XE8-012Nor; Fri, 03 Jun 2011 21:35:52 +0200 From: "Toby Moncaster" To: , References: <4DE7F2C5.6040101@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9C12@EMV65-UKRD.domain1.systemhost.net> <4DE89DA0.1060400@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE7E9CE7@EMV65-UKRD.domain1.systemhost.net> <4DE90710.2020206@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32DE8CF1E3@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DE8CF1E3@EMV65-UKRD.domain1.systemhost.net> Date: Fri, 3 Jun 2011 20:35:48 +0100 Message-ID: <002601cc2225$711779c0$53466d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwiCIcm1MLZiLtQTW24562XpgCzzwAAEGjQAAcRZ1A= Content-Language: en-gb X-Provags-ID: V02:K0:jUNwBuBSD/uoLBrnrjth3r7Bj4vIEPeBZYTq0ArWrm7 3vDEZP+G8W5MF3lRWbPbNPMrjgaOs+M8Eyv7lhfMqazNfE8jcf Ihoa2EkqjpmKIXUD38321qy6jzw5JDPSJNk8SWdDkuSHLubcST ioc28sa+xMhYjrVbbiJeotX4WXSEBkOS7C8716MiNFcLhsxqfn sJmALPKeiX9fCNFWhMduB4v9z28YHK549IMQFxhPOY= Cc: pcn@ietf.org Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 19:35:55 -0000 I think this comes down to - it is easy to formulate clear text that allows for PCN-domains where only ThM is used, and where the 11 codepoint means ThM. Once one starts trying to allow for PSDM the text has to become more complex and you start to create potential issues as Phil outlines below. So the question to the WG has to be do we want to explicitly create support for PSDM in this encoding or not? Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 03 June 2011 18:23 > To: menth@informatik.uni-tuebingen.de > Cc: pcn@ietf.org > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding > types > > The first thing is to choose between > > Option A: > > * The Threshold Marker MUST mark 01 > * The Excess Traffic Marker MUST mark 11 > > Option B > > * The Threshold meter SHOULD mark 01 > * The Threshold meter MUST be able to be configured instead to mark 11 > (ie not follow the SHOULD. Why? pre-6040 tunnels etc), > * The Excess Traffic meter MUST mark 11 > > Option C > Something else > > Pros and cons: > Option A: > Simple > But only choice in pre-6040 environment is Single marking (or accept > that PCN-marking is effectively switched off along the tunnel) > > Option B: > Allows some flexibility (*) > But requires meter/marker to have ability to be configured; requires > operator to configure all PCN-nodes correctly. > > (*)in a pre-6040 environment, you can break the SHOULD, and either just > mark with the Threshold meter to 11 (excess traffic meter off, > admission control but no flow termination) - or you can do PSDM, with > the threshold meter marking 01 to 11, and excess traffic meter marking > 10 to 11) > > I am somewhat uncertain what this flexibility actually means. For > example, > - a vendor could build a compliant meter/marker that doesn't do psdm > (it does the 'either' option in the previous para) > - another vendor could build a compliant meter/marker that does do psdm > (it does the or' option in the previous para, but not the 'either' > option) > - the operator could therefore buy compliant kit from the two vendors > which would not interoperate (to the extent that in a pre-6040 > environment it would only be able to do Single marking) > The basic issue is that psdm has to do additional BA aggregate > classification (not just 'is it a PCN-pkt?' but also 'is it a not- > marked PCN-pkt open for threshold marking, or a not-marked PCN-pkt open > for excess traffic marking?') > > So the question is whether we just say " The Threshold meter MUST be > able to be configured instead to mark 11" (and leave it to the vendor > and operator to discuss what exactly this MUST means) or we say > something more explicit:- > a. threshold marker MUST be able to be configured to mark 10 to 11 > (instead of the default, 10 to 01) and (presumably) the excess traffic > marker is switched off [corresponds to the 'either' option of the (*) > para] > b. threshold marker MUST be able to be configured instead to mark 01 to > 11 and excess traffic marker MUST be able to be configured _not_ to > mark 01 to 11 [corresponds to the 'or' option of the (*) para] > c. MUST be able to do both a & b > > I think "a" is quite a small change for a vendor and probably doesnt > cause too many issues if the operator misconfigures, so is probably OK > to require/allow this. > Whereas "b" seems a bigger change for a vendor and probably leads to > significant issues if the operator misconfigures, so I'm not convinced > this is flexibility that we should require/allow. > > phil > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: 03 June 2011 17:09 > To: Eardley,PL,Philip,DES8 R > Cc: pcn@ietf.org > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding > types > > Hi Phil, > > Am 03.06.2011 11:08, schrieb philip.eardley@bt.com: > > We need to be exact. > Clarity is what I want to achieve ... > > > Option B doesn't say "may also be provided". It says > > Threshold marking SHOULD mark 01 but MUST be able to mark 11 > The latter sentence looks like a contradiction, especially if we say in > addiction that the MUST-case is not recommended ... That's why I think > it is nececcary to give an explantation that boils this down to > concrete > PCN encodings and say which of them is a MUST and which of them is not > so necessary if we want to rank them for whatever reason. > > Best wishes, > > Michael > > > > I dont mind us discussing Option C, D.... but let's be clear what > we're discussing > > > > I suggest we first discuss which Option we want to go forward with, > then we discuss how to phrase it > > > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > > Sent: 03 June 2011 09:39 > > To: Eardley,PL,Philip,DES8 R > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Additional formulation to illustrate PCN encoding > types > > > > Hi Phil, > > > > yes, the cases should be ordered in a different way. I believe that > it > > is most important to give them names so tat manufacturers can say > what > > type of PCN encoding their equipment supports. > > > > I'd say that ETM-baseline and 3-in-1 are MUST for implementations > > supporting systems with excess traffic marking and threshold marking > > while ThM-baseline and PSDM may also be provided in order to allow > for > > PCN implementations with pre-RFC6040 network support. > > > > Best wishes, > > > > Michael > > > > Am 03.06.2011 10:15, schrieb philip.eardley@bt.com: > >> Sort of... > >> > >> (note you have a typo, as you have '10' twice in each case) > >> > >> BUT > >> Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it > MUST have the ability to be reconfigured to mark 11) > >> Bob is suggesting that a case when the SHOULD may not apply is when > you have non 6040 tunnels inside your PCN-domain; the default choice is > single (excess) marking, but you could also do either your option 2 or > 4 below - note Option 2& 4 both break the SHOULD) > >> > >> The way you have written it below has a quite different emphasis (a > series of options of equal merit) > >> > >> Personally I'm inclined to think allowing the flexibility is not > worth it (but open to persuasion) > >> I'm also inclined to think that it is disguising one form of > flexibility (psdm) in a way that is not obvious, so would need spelling > out in an illustrative appendix. > >> > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of Michael Menth > >> Sent: 02 June 2011 21:30 > >> To: pcn@ietf.org > >> Subject: [PCN] Additional formulation to illustrate PCN encoding > types > >> > >> Hi all, > >> > >> here is my interpretation of Option B. It is probably more > restrictive > >> than the general formulation, but defining four PCN-encoding types > >> simplifies talking about them. Names ma be changed. Bob, please > correct > >> me if I am wrong! > >> > >> In the following, four different types of PCN encoding are > presented. > >> The codepoints are labeled with the type-specific meaning, and the > >> type-specific transition diagram is given that indicates how > >> excess-traffic-marking and threshold-marking re-mark the codepoint > if > >> their meters indicate to re-mark a packet. > >> > >> > >> 1. ETM-baseline (used for excess-traffic-marking only) > >> > >> 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = > >> excess-traffic-marked (ETM) > >> > >> excess-traffic-marker > >> 10 ---------------------> 11 > >> > >> > >> > >> 2. ThM-baseline (used for threshold-marking only) > >> > >> 00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = > >> threshold-marked (ThM) > >> > >> threshold-marker > >> 10 --------------------> 11 > >> > >> > >> > >> 3. 3-in-1 (extension of ETM-baseline, used for parallel use of > >> excess-traffic-marking and threshold-marking in networks with only > >> RFC6040-compliant tunnel decapsulators) > >> > >> 00 = not-PCN, 10 = not-marked (NM), 10 = threshold-marked (ThM), 11 > = > >> excess-traffic-marked (ETM) > >> > >> excess-traffic-marker > >> +-------------------------------------+ > >> | | > >> | V > >> 10 -----------> 01 -----------------> 11 > >> threshold- excess-traffic- > >> marker marker > >> > >> > >> 4. PSDM (extension of ETM-baseline, used for parallel use of > >> excess-traffic-marking and threshold-marking in networks with > >> non-RFC6040-compliant tunnel decapsulators) > >> > >> 00 = not-PCN, 10 = not-excess-traffic-marked (NETM), 10 = > >> not-threshold-marked (NThM), 11 = marked (M) > >> > >> excess-traffic-marker > >> +----------------------------+ > >> | | > >> | V > >> 10 10 ---------------> 11 > >> threshold-marker > >> > >> > >> All four types are designed in a way that > >> > >> o excess-traffic-metering MUST count the bytes of all 10- and 01- > marked > >> packets. > >> o threshold-metering MUST count the bytes of all 10-, 01-, and 11- > marked > >> packets. > >> o 11 indicates most severe pre-congestion. If packets need to be > dropped > >> in case of overload, existing edge behaviors [CL, SM] require that > >> 11-marked packet SHOULD preferentially be dropped. > >> > >> Example uses > >> > >> o In SM, nodes work with ETM-baseline. > >> o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not > >> perform threshold-marking. > >> o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline > if > >> they do not perform threshold-marking. > >> o The AC-subset of CL works with nodes that perform only > >> threshold-marking and ThM-baseline. > >> > >> > >> Regards, > >> > >> Michael > >> > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From sob@harvard.edu Sat Jun 4 10:42:22 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612FEE06DB for ; Sat, 4 Jun 2011 10:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTXPL1FEQrzD for ; Sat, 4 Jun 2011 10:42:20 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id A0D78E06DA for ; Sat, 4 Jun 2011 10:42:20 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 4DDEABC22AC; Sat, 4 Jun 2011 13:42:19 -0400 (EDT) To: pcn@ietf.org Message-Id: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> Date: Sat, 4 Jun 2011 13:42:19 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 17:42:22 -0000 I put in a just-in-case request fr a 1 hour PCN session for Quebec City. But do we need to meet? most of the work is about done - are there things we need to still talk about? Scott From menth@informatik.uni-tuebingen.de Sat Jun 4 12:16:43 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846D5228009 for ; Sat, 4 Jun 2011 12:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.798 X-Spam-Level: * X-Spam-Status: No, score=1.798 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6IrhghzFeid for ; Sat, 4 Jun 2011 12:16:42 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 5C54C228006 for ; Sat, 4 Jun 2011 12:16:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4C7E15240 for ; Sat, 4 Jun 2011 21:16:31 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTkCw1hoFa6h for ; Sat, 4 Jun 2011 21:16:27 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C46A149A7 for ; Sat, 4 Jun 2011 21:16:27 +0200 (MEST) Received: from [134.2.186.5] (vpn2505.extern.uni-tuebingen.de [134.2.186.5]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3BCFA1D0F576 for ; Sat, 4 Jun 2011 21:16:27 +0200 (CEST) Message-ID: <4DEA8499.80702@informatik.uni-tuebingen.de> Date: Sat, 04 Jun 2011 21:16:41 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "pcn@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] PCN edge behavior for pre-6040 tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 19:16:43 -0000 Hi all, at the last meeting in Prague I presented a new PCN edge behavior. The slides are available at: http://atlas2.informatik.uni-tuebingen.de/menth/papers/ietf-80-pcn-Menth.pdf The AC part uses threshold-marking and is described in: http://tools.ietf.org/html/draft-menth-pcn-marked-signaling-ac-00 The FT part uses excess-traffic-marking and is described in: http://atlas2.informatik.uni-tuebingen.de/menth/papers/Menth10-Sub-8.pdf Benefits * supports AC and FT with legacy tunnels, but more accurate than SM * no need to define ingress-egress-aggregates * no need for measurements * no need for additional PCN signalling Requirements * path-coupled end-to-end resource signalling per flow (e.g. RSVP or SIP-like signalling) * psdm encoding for packet-specific dual marking: http://tools.ietf.org/html/draft-ietf-pcn-psdm-encoding-01 Note that psdm encoding is needed only to make this PCN edge behavior work with pre-6040 tunnels. 3-in-1 encoding may also be used but then all tunnels must comply with RFC6040 so that one major advange is lost. If this method is of interest to the WG, I'll provide an ID for the next meeting and we know that we should keep the door open for psdm in the encoding options. I would like to ask the WG whether we should continue with this new PCN edge behavior? The answer has impact on the required PCN encodings. Kind regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From slblake@petri-meat.com Tue Jun 7 21:21:54 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E0C11E8093 for ; Tue, 7 Jun 2011 21:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAF9e2aFBn94 for ; Tue, 7 Jun 2011 21:21:54 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DB11E8071 for ; Tue, 7 Jun 2011 21:21:52 -0700 (PDT) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1QUAH8-0003MJ-4J for pcn@ietf.org; Wed, 08 Jun 2011 00:21:50 -0400 From: Steven Blake To: pcn In-Reply-To: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Jun 2011 00:21:50 -0400 Message-ID: <1307506910.11536.5.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) 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] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 04:21:54 -0000 On Sat, 2011-06-04 at 13:42 -0400, Scott O. Bradner wrote: > I put in a just-in-case request fr a 1 hour PCN session for > Quebec City. > > But do we need to meet? > > most of the work is about done - are there things we need to > still talk about? Hi folks, If we don't get some suggestions for the WG agenda, the IESG will reject our slot request. Please respond ASAP. Here is our WG document status (see http://tools.ietf.org/wg/pcn/): - draft-ietf-pcn-sm-edge-behaviour is in IETF last call - draft-ietf-pcn-cl-edge-behaviour is in IETF last call - draft-ietf-pcn-encoding-comparison-05 has completed WGLC - draft-ietf-pcn-signaling-requirements-04 has completed WGLC - draft-ietf-pcn-3-in-1-encoding-04 failed WGLC (2011-03-30). draft-ietf-pcn-3-in-1-encoding-05 was published on 2011-05-21 and is still being discussed on the list. I have been the bottleneck for getting draft-ietf-pcn-encoding-comparison-05 and draft-ietf-pcn-signaling-requirements-04 to the IESG. These drafts need be updated to remove the errors flagged by the ID-nits checker (draft editors: *please* run ID-nits before submitting). Once the updates are available, I will submit the drafts with the shepherd write-up ASAP. The WG needs to conclude the discussion on draft-ietf-pcn-3-in-1-encoding-05 so that it can go through another WGLC. Regards, // Steve From philip.eardley@bt.com Wed Jun 8 00:18:09 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEC011E809F for ; Wed, 8 Jun 2011 00:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr2WfoY78YEi for ; Wed, 8 Jun 2011 00:17:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id C526811E807B for ; Wed, 8 Jun 2011 00:17:47 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 8 Jun 2011 08:17:46 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.239]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 8 Jun 2011 08:17:46 +0100 From: To: , Date: Wed, 8 Jun 2011 08:17:45 +0100 Thread-Topic: [PCN] PCN session in Quebec City? Thread-Index: Acwlk5v8/53ILUtUQgqcN28dP44IqAAGGycA Message-ID: <9510D26531EF184D9017DF24659BB87F32DF35E174@EMV65-UKRD.domain1.systemhost.net> References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> <1307506910.11536.5.camel@tachyon> In-Reply-To: <1307506910.11536.5.camel@tachyon> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:18:09 -0000 Hopefully we can conclude the encoding (3-in-1 ...) discussion on the list = soon, but may be worth holding some agenda time in case we don't -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steve= n Blake Sent: 08 June 2011 05:22 To: pcn Subject: Re: [PCN] PCN session in Quebec City? On Sat, 2011-06-04 at 13:42 -0400, Scott O. Bradner wrote: > I put in a just-in-case request fr a 1 hour PCN session for=20 > Quebec City. >=20 > But do we need to meet? >=20 > most of the work is about done - are there things we need to > still talk about? Hi folks, If we don't get some suggestions for the WG agenda, the IESG will reject our slot request. Please respond ASAP. Here is our WG document status (see http://tools.ietf.org/wg/pcn/): - draft-ietf-pcn-sm-edge-behaviour is in IETF last call - draft-ietf-pcn-cl-edge-behaviour is in IETF last call - draft-ietf-pcn-encoding-comparison-05 has completed WGLC - draft-ietf-pcn-signaling-requirements-04 has completed WGLC - draft-ietf-pcn-3-in-1-encoding-04 failed WGLC (2011-03-30). draft-ietf-pcn-3-in-1-encoding-05 was published on 2011-05-21 and is still being discussed on the list. I have been the bottleneck for getting draft-ietf-pcn-encoding-comparison-05 and draft-ietf-pcn-signaling-requirements-04 to the IESG. These drafts need be updated to remove the errors flagged by the ID-nits checker (draft editors: *please* run ID-nits before submitting). Once the updates are available, I will submit the drafts with the shepherd write-up ASAP. The WG needs to conclude the discussion on draft-ietf-pcn-3-in-1-encoding-05 so that it can go through another WGLC. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Wed Jun 8 01:19:41 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662DC11E809F for ; Wed, 8 Jun 2011 01:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdpwtrrPjsag for ; Wed, 8 Jun 2011 01:19:40 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A911E8106 for ; Wed, 8 Jun 2011 01:19:39 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 08 Jun 2011 10:19:30 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 8 Jun 2011 10:19:30 +0200 From: To: Date: Wed, 8 Jun 2011 10:19:28 +0200 Thread-Topic: [PCN] proposed status for 3-in-1 and basleine Thread-Index: AcwiDGG2fRCK+QDgRhqFtXPO7+fGsgDopEtg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DCC2500@HE111648.emea1.cds.t-internal.com> References: <003701cc2134$a022e840$e068b8c0$@com> <9510D26531EF184D9017DF24659BB87F32DE8CF173@EMV65-UKRD.domain1.systemhost.net> <4DE90D8A.6030704@informatik.uni-tuebingen.de> In-Reply-To: <4DE90D8A.6030704@informatik.uni-tuebingen.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] proposed status for 3-in-1 and basleine X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:19:41 -0000 Hi Michael, Phil and Toby it may be useful to add a brief statement which marking method should be us= ed. The implementation options alone may be to worrying. PSDM may require m= ore than a single sentence. To sum up: - 3 in 1 is the SHOULD behaviour (ThM 10 -> 01). - SM MUST be supported, but is NOT RECOMMENDED (10 -> 11). If pre-6040 is t= he better justification, use that or use SM and pre-6040 as justification. - Other marking behaviours beside 3 in 1 and SM/pre-6040 MAY be specified. If it is roughly that, is adding three sentences in the text about option B= sufficient (not excluding an appendix containing more discussion)? Michael, you now assume the ThM to mark to 11 in the case of http://tools.ietf.org/html/draft-menth-pcn-marked-signaling-ac-00. and in the case of PSDM. Is that correct? You'd like to be able to enhance the above with a termination option, so yo= u require an additional codepoint and a specific marking behaviour. Let's keep in mind that 11 also MUST bear the more severe indication of con= gestion. Then combining marked signaling with any kind of termination requires 11 to= be the codepoint for termination. But your concern isn't just the codepoint - you are concerned about the mar= king algorithm. Correct? As stated above, a different marking algorithm MAY be s= pecified. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: Friday, June 03, 2011 6:36 PM To: pcn@ietf.org Subject: Re: [PCN] proposed status for 3-in-1 and basleine Hi Phil, Am 03.06.2011 18:19, schrieb philip.eardley@bt.com: > ... > > Option B > > * The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however > the second option is NOT RECOMMENDED. If the Threshold marker does mark 1= 1 > then nodes in the > PCN-domain MUST NOT be marking using the excess traffic meter (since that > meter needs to know which packets had already been marked ETM). > > > [phil] > Toby, did you mean this? (psdm does do both threshold and excess traffic = marking) Yes, psdm (packet-specific dual marking) supports both threshold and excess-traffic-marking, but for different packets. When reading the last sentence again, I realize that this conflicts with psdm. It should rather be formulated as follows: The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however the second option is NOT RECOMMENDED. If the Threshold marker does mark 11 then nodes in the PCN-domain MUST NOT be marking * the same set of packets * using the excess traffic meter (since that meter needs to know which packets had already been marked ETM). That probably reflects Bob's intention. Best wishes, Michael > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From toby@moncaster.com Wed Jun 8 01:22:33 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7D921F84E4 for ; Wed, 8 Jun 2011 01:22:33 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOJrmIcZFAFx for ; Wed, 8 Jun 2011 01:22:33 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3621F84E5 for ; Wed, 8 Jun 2011 01:22:33 -0700 (PDT) Received: from TobysHP (host86-156-248-136.range86-156.btcentralplus.com [86.156.248.136]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0McRue-1QCh9D1LWq-00Hcn6; Wed, 08 Jun 2011 10:22:31 +0200 From: "Toby Moncaster" To: , , References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> <1307506910.11536.5.camel@tachyon> <9510D26531EF184D9017DF24659BB87F32DF35E174@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DF35E174@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 8 Jun 2011 09:22:26 +0100 Message-ID: <001001cc25b5$337bee50$9a73caf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acwlk5v8/53ILUtUQgqcN28dP44IqAAGGycAAAIorIA= Content-Language: en-gb X-Provags-ID: V02:K0:wNABXW3RqBWWpkRO1mULeytfBUqTbhr8tdvmuRlUXRD anNbZOPbwZQQQZFFjoCod+Tk/sboVPFR13KmoKaOrXOTx+2Tid C248IKnX4wBXfZ8DUf7m7UCf6Xl26pmwbppdJj48jPZxGJqAss fi/4T5NB9We7ggtTd3sc9BCDF6UVoM9bkBkPn0En6fAQJUV0fn w6LJW/OMiQOqSkEgL/hQkRO5xrvtgnc9YmNgWAnBAI= Subject: Re: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:22:34 -0000 My guess is there will still be some loose ends from the 3-in-1 discussion so it would be good to have an agenda slot for that. Just to warn the WG, there is going to be a -06 version of the 3-in-1 document, hopefully by this time next week. More on that later... Regarding the two drafts with id-nits... I believe Georgios has been creating these in M$ Word which is the source of the nits. This is unlikely to go down well with the rfc-editor as they usually use the XML to generate the final RFC. As I am a co-author of the encoding comparison I will try and find time to convert that to XML using the current version of the text document. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 08 June 2011 08:18 > To: slblake@petri-meat.com; pcn@ietf.org > Subject: Re: [PCN] PCN session in Quebec City? > > Hopefully we can conclude the encoding (3-in-1 ...) discussion on the > list soon, but may be worth holding some agenda time in case we don't > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: 08 June 2011 05:22 > To: pcn > Subject: Re: [PCN] PCN session in Quebec City? > > On Sat, 2011-06-04 at 13:42 -0400, Scott O. Bradner wrote: > > > I put in a just-in-case request fr a 1 hour PCN session for > > Quebec City. > > > > But do we need to meet? > > > > most of the work is about done - are there things we need to > > still talk about? > > Hi folks, > > If we don't get some suggestions for the WG agenda, the IESG will > reject > our slot request. Please respond ASAP. > > Here is our WG document status (see http://tools.ietf.org/wg/pcn/): > > - draft-ietf-pcn-sm-edge-behaviour is in IETF last call > > - draft-ietf-pcn-cl-edge-behaviour is in IETF last call > > - draft-ietf-pcn-encoding-comparison-05 has completed WGLC > > - draft-ietf-pcn-signaling-requirements-04 has completed WGLC > > - draft-ietf-pcn-3-in-1-encoding-04 failed WGLC (2011-03-30). > draft-ietf-pcn-3-in-1-encoding-05 was published on 2011-05-21 and is > still being discussed on the list. > > I have been the bottleneck for getting > draft-ietf-pcn-encoding-comparison-05 and > draft-ietf-pcn-signaling-requirements-04 to the IESG. These drafts > need > be updated to remove the errors flagged by the ID-nits checker (draft > editors: *please* run ID-nits before submitting). Once the updates are > available, I will submit the drafts with the shepherd write-up ASAP. > > The WG needs to conclude the discussion on > draft-ietf-pcn-3-in-1-encoding-05 so that it can go through another > WGLC. > > > Regards, > > > // Steve > > > > _______________________________________________ > 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 slblake@petri-meat.com Wed Jun 8 05:23:09 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEED021F8466 for ; Wed, 8 Jun 2011 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y49BZSSkX5OO for ; Wed, 8 Jun 2011 05:23:09 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3700421F8467 for ; Wed, 8 Jun 2011 05:23:08 -0700 (PDT) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1QUHmp-0001a6-9b; Wed, 08 Jun 2011 08:23:03 -0400 From: Steven Blake To: Toby Moncaster In-Reply-To: <001001cc25b5$337bee50$9a73caf0$@com> References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> <1307506910.11536.5.camel@tachyon> <9510D26531EF184D9017DF24659BB87F32DF35E174@EMV65-UKRD.domain1.systemhost.net> <001001cc25b5$337bee50$9a73caf0$@com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Jun 2011 08:23:05 -0400 Message-ID: <1307535785.11536.10.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) 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 Cc: pcn@ietf.org Subject: Re: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 12:23:10 -0000 On Wed, 2011-06-08 at 09:22 +0100, Toby Moncaster wrote: > My guess is there will still be some loose ends from the 3-in-1 discussion > so it would be good to have an agenda slot for that. > > Just to warn the WG, there is going to be a -06 version of the 3-in-1 > document, hopefully by this time next week. More on that later... > > Regarding the two drafts with id-nits... I believe Georgios has been > creating these in M$ Word which is the source of the nits. This is unlikely > to go down well with the rfc-editor as they usually use the XML to generate > the final RFC. As I am a co-author of the encoding comparison I will try and > find time to convert that to XML using the current version of the text > document. The RFC Editor does not require XML (I think they are still converting .txt to nroff). The most expedient thing to do is edit the ASCII produced by MSWord to comply (tedious). Or, check that the right MSWord template is being used. Regards, // Steve From Ruediger.Geib@telekom.de Thu Jun 9 02:39:30 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AB621F846F for ; Thu, 9 Jun 2011 02:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feh4EOfqdCPR for ; Thu, 9 Jun 2011 02:39:28 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 264DC21F846D for ; Thu, 9 Jun 2011 02:39:27 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 09 Jun 2011 11:36:41 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Thu, 9 Jun 2011 11:36:41 +0200 From: To: Date: Thu, 9 Jun 2011 11:36:41 +0200 Thread-Topic: [PCN] PCN edge behavior for pre-6040 tunnels Thread-Index: Acwi6/zapgNI5MpsTTGMwey0z4AksgDmzpoQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DD89F5A@HE111648.emea1.cds.t-internal.com> References: <4DEA8499.80702@informatik.uni-tuebingen.de> In-Reply-To: <4DEA8499.80702@informatik.uni-tuebingen.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behavior for pre-6040 tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 09:39:30 -0000 Hi Michael, as co-author I of course would be happy, if the draft would see some suppor= t (it's content is ThM to perform admission control by identifying marked signaling packets, and that's it). You propose to add a termination method which works without IEA measurements and feedback. So the edge behaviour is simplified (for admission control as well as for termination). Both methods work in the presence of ECMP, which is another clear advantage= in many backbone networks. My personal take is, that as ECN/PCN saw little deployment in backbone networks, pre-6040 support of tunneling may be dropped. That would allow to use 3-in-1 marking for the proposed experimental edge behaviours. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: Saturday, June 04, 2011 9:17 PM To: pcn@ietf.org Subject: [PCN] PCN edge behavior for pre-6040 tunnels Hi all, at the last meeting in Prague I presented a new PCN edge behavior. The slides are available at: http://atlas2.informatik.uni-tuebingen.de/menth/papers/ietf-80-pcn-Menth.pd= f The AC part uses threshold-marking and is described in: http://tools.ietf.org/html/draft-menth-pcn-marked-signaling-ac-00 The FT part uses excess-traffic-marking and is described in: http://atlas2.informatik.uni-tuebingen.de/menth/papers/Menth10-Sub-8.pdf Benefits * supports AC and FT with legacy tunnels, but more accurate than SM * no need to define ingress-egress-aggregates * no need for measurements * no need for additional PCN signalling Requirements * path-coupled end-to-end resource signalling per flow (e.g. RSVP or SIP-like signalling) * psdm encoding for packet-specific dual marking: http://tools.ietf.org/html/draft-ietf-pcn-psdm-encoding-01 Note that psdm encoding is needed only to make this PCN edge behavior work with pre-6040 tunnels. 3-in-1 encoding may also be used but then all tunnels must comply with RFC6040 so that one major advange is lost. If this method is of interest to the WG, I'll provide an ID for the next meeting and we know that we should keep the door open for psdm in the encoding options. I would like to ask the WG whether we should continue with this new PCN edge behavior? The answer has impact on the required PCN encodings. Kind regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Thu Jun 9 06:30:44 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9D11E808F for ; Thu, 9 Jun 2011 06:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM1e5dGfvKNV for ; Thu, 9 Jun 2011 06:30:42 -0700 (PDT) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8D11E8081 for ; Thu, 9 Jun 2011 06:30:42 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p59DUJPW013601; Thu, 9 Jun 2011 15:30:20 +0200 From: "Georgios Karagiannis" To: "'Steven Blake'" , "'pcn'" References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> <1307506910.11536.5.camel@tachyon> In-Reply-To: <1307506910.11536.5.camel@tachyon> Date: Thu, 9 Jun 2011 15:30:19 +0200 Message-ID: <019b01cc26a9$60dc7190$229554b0$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvv3NhtS1hod5iFvx2Mipg6ABrwwKv4UVJlFhRCOA= Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Subject: Re: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 13:30:44 -0000 Hi Steve, Hi all, Agree, I think that we need to have a meeting in Quebec! Regarding the encoding draft and signaling draft, Steve thanks! Please note that I had run the ID-nits checker before submitting and I had not seen any errors at that time! I will update the draft and resubmit asap, (by tomorrow)! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: woensdag 8 juni 2011 6:22 > To: pcn > Subject: Re: [PCN] PCN session in Quebec City? > > On Sat, 2011-06-04 at 13:42 -0400, Scott O. Bradner wrote: > > > I put in a just-in-case request fr a 1 hour PCN session for Quebec > > City. > > > > But do we need to meet? > > > > most of the work is about done - are there things we need to still > > talk about? > > Hi folks, > > If we don't get some suggestions for the WG agenda, the IESG will reject our > slot request. Please respond ASAP. > > Here is our WG document status (see http://tools.ietf.org/wg/pcn/): > > - draft-ietf-pcn-sm-edge-behaviour is in IETF last call > > - draft-ietf-pcn-cl-edge-behaviour is in IETF last call > > - draft-ietf-pcn-encoding-comparison-05 has completed WGLC > > - draft-ietf-pcn-signaling-requirements-04 has completed WGLC > > - draft-ietf-pcn-3-in-1-encoding-04 failed WGLC (2011-03-30). > draft-ietf-pcn-3-in-1-encoding-05 was published on 2011-05-21 and is > still being discussed on the list. > > I have been the bottleneck for getting > draft-ietf-pcn-encoding-comparison-05 and > draft-ietf-pcn-signaling-requirements-04 to the IESG. These drafts need be > updated to remove the errors flagged by the ID-nits checker (draft > editors: *please* run ID-nits before submitting). Once the updates are > available, I will submit the drafts with the shepherd write-up ASAP. > > The WG needs to conclude the discussion on > draft-ietf-pcn-3-in-1-encoding-05 so that it can go through another WGLC. > > > Regards, > > > // Steve > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Thu Jun 9 06:30:48 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392411E80DB for ; Thu, 9 Jun 2011 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH7voIacUNuW for ; Thu, 9 Jun 2011 06:30:47 -0700 (PDT) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0326B11E8081 for ; Thu, 9 Jun 2011 06:30:44 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p59DUJPV013601; Thu, 9 Jun 2011 15:30:19 +0200 From: "Georgios Karagiannis" To: "'Toby Moncaster'" References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> <1307506910.11536.5.camel@tachyon> <9510D26531EF184D9017DF24659BB87F32DF35E174@EMV65-UKRD.domain1.systemhost.net> <001001cc25b5$337bee50$9a73caf0$@com> In-Reply-To: <001001cc25b5$337bee50$9a73caf0$@com> Date: Thu, 9 Jun 2011 15:30:19 +0200 Message-ID: <019901cc26a9$60b3daf0$221b90d0$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvv3NhtS1hod5iFvx2Mipg6ABrwwKv4UVJAiRpJC0BsoVaDpQ5m5MQ Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: pcn@ietf.org Subject: Re: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 13:30:48 -0000 Hi Toby, Thanks for the offer, but I will correct the ID-nits errors and resubmit bot drafts by tomorrow! The issue with the ID-nits checker is that I have used only the simplest checking feature! I will use the complete set of ID-nits checking features and it will go okay! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Toby Moncaster > Sent: woensdag 8 juni 2011 10:22 > To: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > Subject: Re: [PCN] PCN session in Quebec City? > > My guess is there will still be some loose ends from the 3-in-1 discussion so it > would be good to have an agenda slot for that. > > Just to warn the WG, there is going to be a -06 version of the 3-in-1 > document, hopefully by this time next week. More on that later... > > Regarding the two drafts with id-nits... I believe Georgios has been creating > these in M$ Word which is the source of the nits. This is unlikely to go down > well with the rfc-editor as they usually use the XML to generate the final RFC. > As I am a co-author of the encoding comparison I will try and find time to > convert that to XML using the current version of the text document. > > Toby > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > philip.eardley@bt.com > > Sent: 08 June 2011 08:18 > > To: slblake@petri-meat.com; pcn@ietf.org > > Subject: Re: [PCN] PCN session in Quebec City? > > > > Hopefully we can conclude the encoding (3-in-1 ...) discussion on the > > list soon, but may be worth holding some agenda time in case we don't > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Steven Blake > > Sent: 08 June 2011 05:22 > > To: pcn > > Subject: Re: [PCN] PCN session in Quebec City? > > > > On Sat, 2011-06-04 at 13:42 -0400, Scott O. Bradner wrote: > > > > > I put in a just-in-case request fr a 1 hour PCN session for Quebec > > > City. > > > > > > But do we need to meet? > > > > > > most of the work is about done - are there things we need to still > > > talk about? > > > > Hi folks, > > > > If we don't get some suggestions for the WG agenda, the IESG will > > reject our slot request. Please respond ASAP. > > > > Here is our WG document status (see http://tools.ietf.org/wg/pcn/): > > > > - draft-ietf-pcn-sm-edge-behaviour is in IETF last call > > > > - draft-ietf-pcn-cl-edge-behaviour is in IETF last call > > > > - draft-ietf-pcn-encoding-comparison-05 has completed WGLC > > > > - draft-ietf-pcn-signaling-requirements-04 has completed WGLC > > > > - draft-ietf-pcn-3-in-1-encoding-04 failed WGLC (2011-03-30). > > draft-ietf-pcn-3-in-1-encoding-05 was published on 2011-05-21 and is > > still being discussed on the list. > > > > I have been the bottleneck for getting > > draft-ietf-pcn-encoding-comparison-05 and > > draft-ietf-pcn-signaling-requirements-04 to the IESG. These drafts > > need be updated to remove the errors flagged by the ID-nits checker > > (draft > > editors: *please* run ID-nits before submitting). Once the updates > > are available, I will submit the drafts with the shepherd write-up ASAP. > > > > The WG needs to conclude the discussion on > > draft-ietf-pcn-3-in-1-encoding-05 so that it can go through another > > WGLC. > > > > > > Regards, > > > > > > // Steve > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Thu Jun 9 06:36:36 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EB11E80B7 for ; Thu, 9 Jun 2011 06:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaSKyMXYUZl0 for ; Thu, 9 Jun 2011 06:36:36 -0700 (PDT) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 28E0211E8081 for ; Thu, 9 Jun 2011 06:36:36 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p59DaUPV016340; Thu, 9 Jun 2011 15:36:30 +0200 From: "Georgios Karagiannis" To: "'Steven Blake'" , "'Toby Moncaster'" References: <20110604174219.4DDEABC22AC@newdev.eecs.harvard.edu> <1307506910.11536.5.camel@tachyon> <9510D26531EF184D9017DF24659BB87F32DF35E174@EMV65-UKRD.domain1.systemhost.net> <001001cc25b5$337bee50$9a73caf0$@com> <1307535785.11536.10.camel@tachyon> In-Reply-To: <1307535785.11536.10.camel@tachyon> Date: Thu, 9 Jun 2011 15:36:30 +0200 Message-ID: <03d401cc26aa$3d914c50$b8b3e4f0$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvv3NhtS1hod5iFvx2Mipg6ABrwwKv4UVJAiRpJC0BsoVaDgLJG6/0lCNWEMA= Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: pcn@ietf.org Subject: Re: [PCN] PCN session in Quebec City? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 13:36:37 -0000 Hi Steve, Agree, I will correct the ID-nits errors and resubmit bot drafts by tomorrow! The issue with the ID-nits checker is that I have used only the simplest checking feature! I will use the complete set of ID-nits checking features and it will go okay! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: woensdag 8 juni 2011 14:23 > To: Toby Moncaster > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN session in Quebec City? > > On Wed, 2011-06-08 at 09:22 +0100, Toby Moncaster wrote: > > > My guess is there will still be some loose ends from the 3-in-1 > > discussion so it would be good to have an agenda slot for that. > > > > Just to warn the WG, there is going to be a -06 version of the 3-in-1 > > document, hopefully by this time next week. More on that later... > > > > Regarding the two drafts with id-nits... I believe Georgios has been > > creating these in M$ Word which is the source of the nits. This is > > unlikely to go down well with the rfc-editor as they usually use the > > XML to generate the final RFC. As I am a co-author of the encoding > > comparison I will try and find time to convert that to XML using the > > current version of the text document. > > The RFC Editor does not require XML (I think they are still converting .txt to > nroff). The most expedient thing to do is edit the ASCII produced by > MSWord to comply (tedious). Or, check that the right MSWord template is > being used. > > > Regards, > > // Steve > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-tuebingen.de Fri Jun 10 09:44:18 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6019021F8441 for ; Fri, 10 Jun 2011 09:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSjviKxkADZI for ; Fri, 10 Jun 2011 09:44:17 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 03AC621F8440 for ; Fri, 10 Jun 2011 09:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4668452D3; Fri, 10 Jun 2011 18:44:10 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+MgBRsVJ-GA; Fri, 10 Jun 2011 18:44:01 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 38E7A5288; Fri, 10 Jun 2011 18:44:01 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9DDA11D98A7D; Fri, 10 Jun 2011 18:43:52 +0200 (CEST) Message-ID: <4DF249D6.2080807@informatik.uni-tuebingen.de> Date: Fri, 10 Jun 2011 18:44:06 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Toby Moncaster Content-Type: multipart/mixed; boundary="------------070504010501000702090805" Cc: "pcn@ietf.org" Subject: [PCN] PCN encoding for MPLS shim headers X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:44:18 -0000 This is a multi-part message in MIME format. --------------070504010501000702090805 Content-Type: multipart/alternative; boundary="------------050704030000000107080007" --------------050704030000000107080007 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Toby, I just realized that the introduction of the 3-in-1 doc says "For example, the MPLS encoding is defined in [RFC5129 ] and Appendix A of that document provides an informative example for a mapping between the encodings in IP and in MPLS." but the Appendix does not provide such information. We agreed about a year ago to provide such information in an appendix of the 3-in-1 encoding doc as RFC5129 is not explicit enough about how PCN may be encoded in MPLS shim headers. Somehow this information was lost. I digged in my emails. You find the lost appendix in the Word file attachment in the attached private email. Can you please add that before it is lost again? Best wishes, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de --------------050704030000000107080007 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Toby,

I just realized that the introduction of the 3-in-1 doc says "For example, the MPLS encoding is defined in [RFC5129] and Appendix A of that document provides an informative example for a mapping between the encodings in IP and in MPLS." but the Appendix does not provide such information.

We agreed about a year ago to provide such information in an appendix of the 3-in-1 encoding doc as RFC5129 is not explicit enough about how PCN may be encoded in MPLS shim headers. Somehow this information was lost. I digged in my emails. You find the lost appendix in the Word file attachment in the attached private email. Can you please add that before it is lost again?

Best wishes,

=A0=A0=A0 Michael
--=20
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:menth@uni-tuebingen.de
http://www-kn.informatik.uni-tuebingen.de
--------------050704030000000107080007-- --------------070504010501000702090805 Content-Type: message/rfc822; name="Nachricht als Anhang" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Nachricht als Anhang" Return-Path: X-Original-To: menth@nero.informatik.uni-wuerzburg.de Delivered-To: menth@nero.informatik.uni-wuerzburg.de Received: from wrzh078.rzhousing.uni-wuerzburg.de (wrzh078.rzhousing.uni-wuerzburg.de [132.187.226.78]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 9297CC867E for ; Mon, 19 Jul 2010 23:13:59 +0200 (CEST) Received: by wrzh078.rzhousing.uni-wuerzburg.de (Postfix) id 948B0535E8; Mon, 19 Jul 2010 23:13:59 +0200 (CEST) Delivered-To: menth@informatik.uni-wuerzburg.de Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by wrzh078.rzhousing.uni-wuerzburg.de (Postfix) with ESMTP id 91C8B534AB for ; Mon, 19 Jul 2010 23:13:59 +0200 (CEST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 84E5B5AD0E for ; Mon, 19 Jul 2010 23:13:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 80A645AD0A for ; Mon, 19 Jul 2010 23:13:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mailgate.uni-wuerzburg.de (localhost [127.0.0.1]) by spamcheck (Postfix) with SMTP id 435F15ECF3 for ; Mon, 19 Jul 2010 23:13:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mx01.mail X-Spam-Level: X-Spam-Status: No, score=-1.0 required=8.0 tests=ESTABLISHED_CONTACT, MX_UNDEFINED autolearn=disabled version=3.2.5 Received: from smtp3.smtp.bt.com (localhost [127.0.0.1]) by proxyscan.mail (Postfix) with SMTP id 301F35EC66 for ; Mon, 19 Jul 2010 23:13:58 +0200 (CEST) X-Info-Properties: mxundef,plaintext,badmimeseparator,multipart,manyhops,url_de,msword,application,reply,established,bulksender X-Info-Sender: rbriscoe@jungle.bt.co.uk; count=158 relay=158 ham=100% new=1% spam=0% virus=0% X-Info-Client: smtp3.smtp.bt.com[217.32.164.138] X-Info-Policy: ignored by mx01; recipient= Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by mailgate4.uni-wuerzburg.de (Postfix) with ESMTP for ; Mon, 19 Jul 2010 23:13:56 +0200 (CEST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 22:13:55 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 22:13:55 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1279574033841; Mon, 19 Jul 2010 22:13:53 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6JLDqJx005110 for ; Mon, 19 Jul 2010 22:13:52 +0100 Message-Id: <201007192113.o6JLDqJx005110@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 22:13:43 +0100 To: Michael Menth From: Bob Briscoe Subject: Fwd: Re: deferring PCN stuff to next Monday - week off Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_17385529==_" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Jul 2010 21:13:55.0472 (UTC) FILETIME=[4BB9B100:01CB2787] --=====================_17385529==_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Michael, I just noticed your final comment about missing the MPLS appendix by= accident. I've attached your Word doc, but with some=20 additional edits within that final appendix, to=20 explain better and to warn that it's non-normative etc. THere are no other edits outside that appendix. HTH BOb >Date: Mon, 19 Jul 2010 21:41:52 +0100 >To: menth@informatik.uni-wuerzburg.de >From: Bob Briscoe >Subject: Re: deferring PCN stuff to next Monday - week off >Cc: Toby Moncaster , Michael=20 >H=F6fli ng >Bcc: =83\In 2009 > >Michael, > >Thanks for confirmation of most of the changes=20 >(snipped). And for the XML. Just one outstanding issue below... > >At 20:28 14/07/2010, Michael Menth wrote: >>The only disagreement we still have is that you=20 >>say ETM must be more severe than ThM while I do=20 >>not see any strong reason to have that=20 >>constraint which possibly could preclude future=20 >>use of pcn-marking for whatever. >> >>You find my comments in the attached doc file. > >In your Word comment responding to my suggested=20 >change concerning severity ordering, you said: > >>That was my =93favourite debate=94 some years ago.=20 >>The pcn-admissible-rate must be smaller than=20 >>the pcn-supportable-rate, but anything about=20 >>the marking stuff depends on the edge behaviour. >> >>Just saying that the informational RFC says=20 >>that excess-traffic-marking is more severe than=20 >>threshold-marking is from my perspective not=20 >>sufficient. Are there good reasons to have that=20 >>order? I do not see any reasonable edge=20 >>behaviour that would use the two marking=20 >>schemes the other way around, but I do not see=20 >>any reasons either why we need this constraint=20 >>that possibly might prohibit future use of pcn-marking for different apps. > >I thought about this before writing. If one rate=20 >is higher than another, then the encoded marking=20 >of that higher rate has to rank higher than the=20 >marking of the lower rate, for cases with=20 >multiple bottlenecks. Otherwise the marking algo=20 >doesn't know whether it is allowed to overwrite=20 >marking Th with marking E and whether it is not=20 >allowed to overwrite marking E with marking Th. > >Or am I missing some subtlety in your point? > > >Bob > > >>Best wishes, >> >> Michael >> >>> >>> >>> >>>Bob >>> >>>At 23:15 12/07/2010, Bob Briscoe wrote: >>>>Michael, >>>> >>>>SOrry I'm back to this late (just been over=20 >>>>to my fathers for his 80th birthday) - I see=20 >>>>you've posted the draft, so it's fine. Thank=20 >>>>you v much and thank you to Michael H=F6fling also. >>>> >>>>I've answered your questions anyway below... >>>> >>>>At 17:12 12/07/2010, Michael Menth wrote: >>>>>Hi Bob, >>>>> >>>>>I had a hard time to understand what you wrote in the >>>>>compatibility section 6.1. I think that I have understood it now >>>>>and reformulated it so that I could understand it faster. Is that >>>>>wording ok with you? >>>>> >>>>>"The term "compatibility" is meant in the following sense. It is >>>>>possible to operate nodes with baseline encoding [5696] and 3-in-1 >>>>>encoding in the same PCN domain. The nodes with baseline encoding >>>>>MUST perform excess-traffic-marking because the 11 codepoint of >>>>>3-in-1 encoding also means excess-traffic-marked. >>>>>PCN-boundary-nodes of such domains are required to interpret the >>>>>full 3-in-1 encoding and not just baseline encoding, otherwise >>>>>they cannot interpret the 01 codepoint. >>>>> >>>>>Using nodes that perform only excess-traffic-marking may make >>>>>sense in networks using the CL edge behavior >>>>>[I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify >>>>>the egress only about severe pre-congestion when traffic needs to >>>>>be terminated. This seems reasonable for locations that are not >>>>>expected to see any pre-congestion, but excess-traffic-marking >>>>>gives them a means to terminate traffic if unexpected overload >>>>>still occurs." >>>> >>>>That's correct. >>>> >>>> >>>> >>>>>Where exactly is the appropriate location in the draft for this >>>>>text? >>>>> >>>>>"Note: IANA Considerations >>>>> >>>>> This memo includes no request to IANA. >>>>> >>>>> Note to RFC Editor: this section may be removed on publication as an >>>>> RFC." >>>>> >>>>>Shouldn't that be an extra section? I don't understand what it has >>>>>to do in the compatibility section. >>>> >>>>Sorry - rather than incrementing all the=20 >>>>section numbers to allow for the section I=20 >>>>had just inserted, I merely turned this into=20 >>>>a note. It was meant to be another section (but it will be deleted= anyway). >>>> >>>>Thank you again. >>>> >>>> >>>>Bob >>>> >>>> >>>>>Regards, >>>>> >>>>> Michael >>>>> >>>>>Bob Briscoe schrieb: >>>>>>Michael, >>>>>> >>>>>>[Toby, pls supply Michael with new contact=20 >>>>>>details. I have listed your affiliation as=20 >>>>>>'independent' - you may choose some other wording.] >>>>>> >>>>>>Attached are my comments. >>>>>> >>>>>>They are all largely cosmetic, or reducing ambiguity. >>>>>> >>>>>>I have added section 6 on backward=20 >>>>>>compatibility. You may choose to edit it=20 >>>>>>yourself. I have shifted your Appx A into it as Section 6.3. >>>>>> >>>>>> >>>>>>[Sorry 90mins late - I had to go to the=20 >>>>>>doctors this morning on top of everything else.] >>>>>> >>>>>> >>>>>>Bob >>>>>> >>>>>>At 03:03 12/07/2010, Bob Briscoe wrote: >>>>>>>Michael, >>>>>>> >>>>>>>At 10:57 05/07/2010, Michael Menth wrote: >>>>>>>>Hi Bob, >>>>>>>> >>>>>>>>ok. I can wait until next Monday with=20 >>>>>>>>this draft. But it's important to have=20 >>>>>>>>your feedback by 11am so that we have a=20 >>>>>>>>fair chance to integrate your comments,=20 >>>>>>>>update the xml, and submit it by the evening. >>>>>>> >>>>>>>OK, I will try. >>>>>>>I have just returned from the C16 and=20 >>>>>>>printed it out to read and comment in the morning. >>>>>>> >>>>>>> >>>>>>>Bob >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Best wishes, >>>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>>Bob Briscoe schrieb: >>>>>>>>>Toby, Michael, >>>>>>>>> >>>>>>>>>Not ideal, but I will return to the grid=20 >>>>>>>>>next Sunday/Monday, leaving one day=20 >>>>>>>>>before the IETF deadline. Ran out of time this weekend. Sorry. >>>>>>>>> >>>>>>>>> >>>>>>>>>Bob >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>________________________________________________________________ >>>>>>>>>Bob Briscoe, BT Innovate & Design >>>>>>>> >>>>>>>>-- >>>>>>>>PD Dr. habil. 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/31-86632 (new) >>>>>>>>mailto:menth@informatik.uni-wuerzburg.de >>>>>>>>http://www3.informatik.uni-wuerzburg.de/research/ngn >>>>>>> >>>>>>>________________________________________________________________ >>>>>>>Bob Briscoe, BT Innovate & Design >>>>>> >>>>>>________________________________________________________________ >>>>>>Bob Briscoe, BT Innovate & Design >>>>> >>>>>-- >>>>>PD Dr. habil. 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/31-86632 (new) >>>>>mailto:menth@informatik.uni-wuerzburg.de >>>>>http://www3.informatik.uni-wuerzburg.de/research/ngn >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT Innovate & Design >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >> >>-- >>PD Dr. habil. 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/31-86632 (new) >>mailto:menth@informatik.uni-wuerzburg.de >>http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> >> >> >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_17385529==_ Content-Type: application/msword; name="draft-ietf-pcn-3-in-1-encoding-04a-MM-BB.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-pcn-3-in-1-encoding-04a-MM-BB.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA1QAAAAAAAAAA EAAA1wAAAAEAAAD+////AAAAANMAAADUAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANUAJBAAA8BK/AAAAAAAAMAAAAAAABgAAjocAAA4AYmpias8yzzIAAAAAAAAAAAAAAAAAAAAA AAAJBBYANOIAAK1YAACtWAAAxHUAAAAAAAAAAAAAAAAAAMkJAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAANYDAAAAAAAA1gMAANYD AAAAAAAA1gMAAAAAAAAqBAAAWAEAADYGAAAwAAAAZgYAABQAAAAAAAAAAAAAAHoGAAAAAAAAgmYA AAAAAACCZgAAAAAAAIJmAAAAAAAAgmYAAFwAAADeZgAADAEAAHoGAAAAAAAAG4wAALABAAD2ZwAA AAAAAPZnAAAAAAAA9mcAAAAAAAD2ZwAAAAAAAPZnAAAAAAAA0WgAAAAAAADRaAAAAAAAANFoAAAA AAAALosAAAIAAAAwiwAAAAAAADCLAAAAAAAAMIsAAAAAAAAwiwAAAAAAADCLAAAAAAAAMIsAACQA AADLjQAAUgIAAB2QAADUAAAAVIsAABUAAAAAAAAAAAAAAAAAAAAAAAAA1gMAAFQAAAC7cgAAQgAA AAAAAAAAAAAAAAAAAAAAAADRaAAAAAAAANFoAAAAAAAA/XIAACwAAAApcwAAGAAAAFSLAAAAAAAA AAAAAAAAAADWAwAAAAAAANYDAAAAAAAA9mcAAAAAAAAAAAAAAAAAAPZnAADbAAAAaYsAAGoAAADx hAAAAAAAAPGEAAAAAAAA8YQAAAAAAABBcwAAjAUAANYDAAAAAAAA9mcAAAAAAADWAwAAAAAAAPZn AAAAAAAALosAAAAAAAAAAAAAAAAAAPGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAu3IAAAAAAAAuiwAAAAAAAPGEAAAgAAAA8YQAAAAAAAARhQAA OgAAAFaKAAAsAAAA1gMAAAAAAADWAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlooAAAAAAAD2ZwAAAAAAAOpnAAAMAAAA4L77+IYn ywEAAAAAAAAAAIJmAAAAAAAAzXgAAIALAACCigAACgAAAAAAAAAAAAAAGosAABQAAADTiwAASAAA ABuMAAAAAAAAjIoAAAoAAADxkAAAAAAAAE2EAACUAAAA8ZAAABQAAACWigAAAAAAAAAAAAAAAAAA egYAAAAAAAB6BgAAAAAAANYDAAAAAAAA1gMAAAAAAADWAwAAAAAAANYDAAAAAAAAAAAAAAAAAACW igAAFAAAAPGQAAAAAAAAAAAAAAAAAACCBQAAtAAAAKqKAABwAAAA0WgAAKYCAAB3awAA5AEAAPGE AAAAAAAAW20AAIQBAADfbgAA3AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0WgA AAAAAADRaAAAAAAAANFoAAAAAAAAVIsAAAAAAABUiwAAAAAAAHoGAAAAAAAAegYAAARdAAB+YwAA BAMAAAAAAAAAAAAA4YQAABAAAAB6BgAAAAAAAHoGAAAAAAAAfmMAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NDQ1D b25nZXN0aW9uIGFuZCBQcmUtQ29uZ2VzdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEIuIEJyaXNjb2UNTm90aWZpY2F0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJUDUludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vbmNhc3Rlcg1JbnRlbmRlZCBz dGF0dXM6IEV4cGVyaW1lbnRhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RhbmRh cmRzIHRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRlcGVuZGVudA1FeHBpcmVz OiBKYW51YXJ5IDEzLCAyMDExICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg TS4gTWVudGgNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFVuaXZlcnNpdHkgb2YgV3VlcnpidXJnDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAxMiwgMjAxMA0NDSAgICAgICBFbmNvZGlu ZyAzIFBDTi1TdGF0ZXMgaW4gdGhlIElQIGhlYWRlciB1c2luZyBhIHNpbmdsZSBEU0NQDSAgICAg ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXBjbi0zLWluLTEtZW5jb2RpbmctMDMNDUFic3RyYWN0 DQ0gICBUaGUgb2JqZWN0aXZlIG9mIFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoUENOKSBp cyB0byBwcm90ZWN0IHRoZQ0gICBxdWFsaXR5IG9mIHNlcnZpY2UgKFFvUykgb2YgaW5lbGFzdGlj IGZsb3dzIHdpdGhpbiBhIERpZmZzZXJ2IGRvbWFpbi4NICAgT24gZXZlcnkgbGluayBpbiB0aGUg UENOIGRvbWFpbiwgdGhlIG92ZXJhbGwgcmF0ZSBvZiB0aGUgUENOLXRyYWZmaWMNICAgaXMgbWV0 ZXJlZCwgYW5kIFBDTi1wYWNrZXRzIGFyZSBhcHByb3ByaWF0ZWx5IG1hcmtlZCB3aGVuIGNlcnRh aW4NICAgY29uZmlndXJlZCByYXRlcyBhcmUgZXhjZWVkZWQuICBFZ3Jlc3Mgbm9kZXMgcHJvdmlk ZSBkZWNpc2lvbiBwb2ludHMNICAgd2l0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUENOLW1hcmtz IG9mIFBDTi1wYWNrZXRzIHdoaWNoIGFsbG93cyB0aGVtDSAgIHRvIHRha2UgZGVjaXNpb25zIGFi b3V0IHdoZXRoZXIgdG8gYWRtaXQgb3IgYmxvY2sgYSBuZXcgZmxvdyByZXF1ZXN0LA0gICBhbmQg dG8gdGVybWluYXRlIHNvbWUgYWxyZWFkeSBhZG1pdHRlZCBmbG93cyBkdXJpbmcgc2VyaW91cyBw cmUtDSAgIGNvbmdlc3Rpb24uDQ0gICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgUENOLW1h cmtzIGFyZSB0byBiZSBlbmNvZGVkIGludG8gdGhlIElQDSAgIGhlYWRlciBieSByZS11c2luZyB0 aGUgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikNICAgY29kZXBvaW50cyB3 aXRoaW4gYSBQQ04tZG9tYWluLiAgVGhpcyBlbmNvZGluZyBidWlsZHMgb24gdGhlIGJhc2VsaW5l DSAgIGVuY29kaW5nIG9mIFJGQzU2OTYgYW5kIHByb3ZpZGVzIGZvciB0aHJlZSBkaWZmZXJlbnQg UENOIG1hcmtpbmcNICAgc3RhdGVzIHVzaW5nIGEgc2luZ2xlIERTQ1A6IG5vdC1tYXJrZWQgKE5N KSwgdGhyZXNob2xkLW1hcmtlZCAoVGhNKQ0gICBhbmQgZXhjZXNzLXRyYWZmaWMtbWFya2VkIChF VE0pLiAgSGVuY2UsIGl0IGlzIGNhbGxlZCB0aGUgMy1pbi0xIFBDTg0gICBlbmNvZGluZy4NDVN0 YXR1cyBvZiB0aGlzIE1lbW8NDSAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJD UCA3OS4NDSAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nDSAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDSAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy bmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDSAgIERyYWZ0cyBpcyBh dCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0NICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzDSAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55DSAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDSAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINDSAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gSmFudWFyeSAxMywgMjAxMS4NDQ0NQnJpc2NvZSwgZXQgYWwuICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEzLCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDFdDQwN SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgMy1pbi0xIFBDTiBFbmNvZGluZyAgICAgICAgICAg ICAgICAgSnVseSAyMDEwDQ0NQ29weXJpZ2h0IE5vdGljZQ0NICAgQ29weXJpZ2h0IChjKSAyMDEw IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDSAgIGRvY3VtZW50 IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0NICAgVGhpcyBkb2N1bWVudCBpcyBzdWJq ZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0gICBQcm92aXNpb25zIFJl bGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDSAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0gICBwdWJsaWNhdGlvbiBvZiB0aGlz IGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNICAgY2FyZWZ1bGx5LCBh cyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0 DSAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhp cyBkb2N1bWVudCBtdXN0DSAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9u cyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNICAgZGVzY3JpYmVkIGluIHRo ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0NDVRhYmxlIG9mIENvbnRlbnRzDQ0gICAxLiAgSW50 cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNICAgICAxLjEuICBDaGFuZ2VzIGluIFRoaXMgVmVyc2lvbiAodG8gYmUgcmVtb3ZlZCBi eSBSRkMgRWRpdG9yKSAgLiAuICA0DSAgIDIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0gICAgIDIuMS4gIFRlcm1pbm9s b2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNICAg My4gIFJlcXVpcmVtZW50cyBmb3IgYW5kIEFwcGxpY2FiaWxpdHkgb2YgMy1pbi0xIFBDTiBFbmNv ZGluZyAgLiAuICA1DSAgICAgMy4xLiAgUENOIFJlcXVpcmVtZW50cyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0gICAgIDMuMi4gIFJlcXVpcmVtZW50cyBJbXBv c2VkIGJ5IEJhc2VsaW5lIEVuY29kaW5nICAuIC4gLiAuIC4gLiAuIC4gIDYNICAgICAzLjMuICBB cHBsaWNhYmlsaXR5IG9mIDMtaW4tMSBQQ04gRW5jb2RpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA2DSAgIDQuICBEZWZpbml0aW9uIG9mIDMtaW4tMSBQQ04gRW5jb2RpbmcgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNw0gICA1LiAgQmVoYXZpb3VyIG9mIGEgUENOIE5vZGUgQ29tcGxp YW50IHdpdGggdGhlIDMtaW4tMSBQQ04NICAgICAgIEVuY29kaW5nIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DSAgIDYuICBCYWNrd2FyZCBD b21wYXRpYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0g ICAgIDYuMS4gIEJhY2t3YXJkIENvbXBhdGliaWxpdHkgd2l0aCBQcmUtZXhpc3RpbmcgUENODSAg ICAgICAgICAgSW1wbGVtZW50YXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOA0gICAgIDYuMi4gIFJlY29tbWVuZGF0aW9ucyBmb3IgdGhlIFVzZSBvZiBQ Q04gRW5jb2RpbmcgU2NoZW1lcyAgLiAuIC4gIDkNICAgICAgIDYuMi4xLiAgVXNlIG9mIEJvdGgg RXhjZXNzLVRyYWZmaWMtTWFya2luZyBhbmQNICAgICAgICAgICAgICAgVGhyZXNob2xkLU1hcmtp bmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DSAgICAgICA2LjIuMi4g IFVuaXF1ZSBVc2Ugb2YgRXhjZXNzLVRyYWZmaWMtTWFya2luZyAuIC4gLiAuIC4gLiAuIC4gLiAg OQ0gICAgICAgNi4yLjMuICBVbmlxdWUgVXNlIG9mIFRocmVzaG9sZC1NYXJraW5nICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDkNICAgNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DSAgIDguICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0gICA5LiAg Q29uY2x1c2lvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTANICAgMTAuIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDSAgIDExLiBDb21tZW50cyBTb2xpY2l0ZWQgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0gICAxMi4gUmVmZXJlbmNl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEN ICAgICAxMi4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDExDSAgICAgMTIuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0gICBBdXRob3JzJyBBZGRyZXNzZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINDQ0NDQ1Ccmlz Y29lLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTMsIDIwMTEgICAgICAgICAgICAg ICAgW1BhZ2UgMl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29k aW5nICAgICAgICAgICAgICAgICBKdWx5IDIwMTANDQ0xLiAgSW50cm9kdWN0aW9uDQ0gICBUaGUg b2JqZWN0aXZlIG9mIFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoUENOKSBbUkZDNTU1OV0g aXMgdG8NICAgcHJvdGVjdCB0aGUgcXVhbGl0eSBvZiBzZXJ2aWNlIChRb1MpIG9mIGluZWxhc3Rp YyBmbG93cyB3aXRoaW4gYQ0gICBEaWZmc2VydiBkb21haW4sIGluIGEgc2ltcGxlLCBzY2FsYWJs ZSwgYW5kIHJvYnVzdCBmYXNoaW9uLiAgVHdvDSAgIG1lY2hhbmlzbXMgYXJlIHVzZWQ6IGFkbWlz c2lvbiBjb250cm9sLCB0byBkZWNpZGUgd2hldGhlciB0byBhZG1pdCBvcg0gICBibG9jayBhIG5l dyBmbG93IHJlcXVlc3QsIGFuZCBmbG93IHRlcm1pbmF0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIHRv DSAgIHRlcm1pbmF0ZSBzb21lIGFscmVhZHkgYWRtaXR0ZWQgZmxvd3MgZHVyaW5nIHNlcmlvdXMg cHJlLWNvbmdlc3Rpb24uDSAgIFRvIGFjaGlldmUgdGhpcywgdGhlIG92ZXJhbGwgcmF0ZSBvZiBQ Q04tdHJhZmZpYyBpcyBtZXRlcmVkIG9uIGV2ZXJ5DSAgIGxpbmsgaW4gdGhlIGRvbWFpbiwgYW5k IFBDTi1wYWNrZXRzIGFyZSBhcHByb3ByaWF0ZWx5IG1hcmtlZCB3aGVuDSAgIGNlcnRhaW4gY29u ZmlndXJlZCByYXRlcyBhcmUgZXhjZWVkZWQuICBUaGVzZSBjb25maWd1cmVkIHJhdGVzIGFyZQ0g ICBiZWxvdyB0aGUgcmF0ZSBvZiB0aGUgbGluayB0aHVzIHByb3ZpZGluZyBub3RpZmljYXRpb24g dG8gYm91bmRhcnkNICAgbm9kZXMgYWJvdXQgb3ZlcmxvYWRzIGJlZm9yZSBhbnkgY29uZ2VzdGlv biBvY2N1cnMgKGhlbmNlICJwcmUtDSAgIGNvbmdlc3Rpb24gbm90aWZpY2F0aW9uIikuDQ0gICBU d28gbWV0ZXJpbmcgYW5kIG1hcmtpbmcgZnVuY3Rpb25zIGFyZSBwcm9wb3NlZCBpbiBbUkZDNTY3 MF0gdGhhdCBhcmUNICAgY29uZmlndXJlZCB3aXRoIHJlZmVyZW5jZSByYXRlcy4gIFRocmVzaG9s ZC0gbWFya2luZyBtYXJrcyBhbGwgUENODSAgIHBhY2tldHMgb25jZSB0aGVpciB0cmFmZmljIHJh dGUgb24gYSBsaW5rIGV4Y2VlZHMgdGhlIGNvbmZpZ3VyZWQNICAgcmVmZXJlbmNlIHJhdGUgKFBD Ti10aHJlc2hvbGQtcmF0ZSkuICBFeGNlc3MtdHJhZmZpYy1tYXJraW5nIG1hcmtzDSAgIG9ubHkg dGhvc2UgUENOIHBhY2tldHMgdGhhdCBleGNlZWQgdGhlIGNvbmZpZ3VyZWQgcmVmZXJlbmNlIHJh dGUNICAgKFBDTi1leGNlc3MtcmF0ZSkuICBUaGUgUENOLWV4Y2Vzcy1yYXRlIGlzIHR5cGljYWxs eSBsYXJnZXIgdGhhbiB0aGUNICAgUENOLXRocmVzaG9sZC1yYXRlIFtSRkM1NTU5XS4gIEVncmVz cyBub2RlcyBtb25pdG9yIHRoZSBQQ04tbWFya3Mgb2YNICAgcmVjZWl2ZWQgUENOLXBhY2tldHMg YW5kIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFBDTi1tYXJrcyB0bw0gICBkZWNpc2lv biBwb2ludHMgd2hpY2ggdGFrZSBkZWNpc2lvbnMgYWJvdXQgZmxvdyBhZG1pc3Npb24gYW5kDSAg IHRlcm1pbmF0aW9uIG9uIHRoaXMgYmFzaXMgW0ktRC5pZXRmLXBjbi1jbC1lZGdlLWJlaGF2aW91 cl0sDSAgIFtJLUQuaWV0Zi1wY24tc20tZWRnZS1iZWhhdmlvdXJdLg0NICAgVGhlIGJhc2VsaW5l IGVuY29kaW5nIGRlZmluZWQgaW4gW1JGQzU2OTZdIGRlc2NyaWJlcyBob3cgdHdvIFBDTg0gICBt YXJraW5nIHN0YXRlcyBjYW4gYmUgZW5jb2RlZCB1c2luZyBhIHNpbmdsZSBEaWZmc2VydiBjb2Rl cG9pbnQuDSAgIEhvd2V2ZXIsIHRvIHN1cHBvcnQgdGhlIGFwcGxpY2F0aW9uIG9mIHR3byBkaWZm ZXJlbnQgbWFya2luZw0gICBhbGdvcml0aG1zIGluIGEgUENOLWRvbWFpbiwgZm9yIGV4YW1wbGUg YXMgcmVxdWlyZWQgaW4NICAgW0ktRC5pZXRmLXBjbi1jbC1lZGdlLWJlaGF2aW91cl0sIHRocmVl IFBDTiBtYXJraW5nIHN0YXRlcyBhcmUNICAgbmVlZGVkLiAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBiYXNlbGluZQ0gICBlbmNvZGluZyB0aGF0IGFkZHMgYSB0 aGlyZCBQQ04gbWFya2luZyBzdGF0ZSBpbiB0aGUgSVAgaGVhZGVyLCBzdGlsbA0gICB1c2luZyBh IHNpbmdsZSBEaWZmc2VydiBjb2RlcG9pbnQuICBUaGlzIGVuY29kaW5nIHNjaGVtZSBpcyBjYWxs ZWQNICAgYW8mIzczMTsiMy1pbi0xIFBDTiBlbmNvZGluZ2FvJiM3MTE7Ii4NDSAgIEFsbCBQQ04g ZW5jb2Rpbmcgc2NoZW1lcyByZXF1aXJlIGFuIGFkZGl0aW9uYWwgbWFya2luZyBzdGF0ZSB0bw0g ICBpbmRpY2F0ZSBub24tUENOIHRyYWZmaWMuICBUaGVyZWZvcmUsIGZvdXIgY29kZXBvaW50cyBh cmUgcmVxdWlyZWQgdG8NICAgZW5jb2RlIHRocmVlIFBDTiBtYXJraW5nIHN0YXRlcy4NDSAgIFRo aXMgZG9jdW1lbnQgb25seSBjb25jZXJucyB0aGUgUENOIHdpcmUgcHJvdG9jb2wgZW5jb2Rpbmcg Zm9yIGFsbCBJUA0gICBoZWFkZXJzLCB3aGV0aGVyIElQdjQgb3IgSVB2Ni4gIEl0IG1ha2VzIG5v IGNoYW5nZXMgb3INICAgcmVjb21tZW5kYXRpb25zIGNvbmNlcm5pbmcgYWxnb3JpdGhtcyBmb3Ig Y29uZ2VzdGlvbiBtYXJraW5nIG9yDSAgIGNvbmdlc3Rpb24gcmVzcG9uc2UuICBPdGhlciBkb2N1 bWVudHMgZGVmaW5lIHRoZSBQQ04gd2lyZSBwcm90b2NvbA0gICBmb3Igb3RoZXIgaGVhZGVyIHR5 cGVzLiAgRm9yIGV4YW1wbGUsIHRoZSBNUExTIGVuY29kaW5nIGlzIGRlZmluZWQgaW4NICAgW1JG QzUxMjldLiAgQXBwZW5kaXggQSBwcm92aWRlcyBhbiBpbmZvcm1hdGl2ZSBleGFtcGxlIGZvciBh IG1hcHBpbmcNICAgYmV0d2VlbiB0aGUgZW5jb2RpbmdzIGluIElQIGFuZCBpbiBNUExTLg0NDQ1C cmlzY29lLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTMsIDIwMTEgICAgICAgICAg ICAgICAgW1BhZ2UgM10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVu Y29kaW5nICAgICAgICAgICAgICAgICBKdWx5IDIwMTANDQ0xLjEuICBDaGFuZ2VzIGluIFRoaXMg VmVyc2lvbiAodG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKQ0NICAgRnJvbSBkcmFmdC1pZXRm LXBjbi0zLWluLTEtZW5jb2RpbmctMDIgdG8gLTAzOg0NICAgICAgKiAgQ29ycmVjdGVkIG1pc3Rh a2VzIGluIGludHJvZHVjdGlvbiBhbmQgaW1wcm92ZWQgb3ZlcmFsbA0gICAgICAgICByZWFkYWJp bGl0eS4NDSAgICAgICogIEFkZGVkIG5ldyB0ZXJtaW5vbG9neS4NDSAgICAgICogIFJld3JvdGUg YSBnb29kIHBhcnQgb2YgU2VjdGlvbiA0IGFuZCA1IHRvIGFjaGlldmUgbW9yZSBjbGFyaXR5Lg0N ICAgICAgKiAgQWRkZWQgYXBwZW5kaXggZXhwbGFpbmluZyB3aGVuIHRvIHVzZSB3aGljaCBlbmNv ZGluZyBzY2hlbWUgYW5kDSAgICAgICAgIGhvdyB0byBlbmNvZGUgdGhlbSBpbiBNUExTIHNoaW0g aGVhZGVycy4NDSAgICAgICogIEFkZGVkIG5ldyBjby1hdXRob3IuDQ0gICBGcm9tIGRyYWZ0LWll dGYtcGNuLTMtaW4tMS1lbmNvZGluZy0wMSB0byAtMDI6DQ0gICAgICAqICBDb3JyZWN0ZWQgbWlz dGFrZSBpbiBpbnRyb2R1Y3Rpb24sIHdoaWNoIHdyb25nbHkgc3RhdGVkIHRoYXQNICAgICAgICAg dGhlIHRocmVzaG9sZC10cmFmZmljIHJhdGUgaXMgaGlnaGVyIHRoYW4gdGhlIGV4Y2Vzcy10cmFm ZmljDSAgICAgICAgIHJhdGUuICBPdGhlciBtaW5vciBjb3JyZWN0aW9ucy4NDSAgICAgICogIFVw ZGF0ZWQgYWNrcyAmIHJlZnMuDQ0gICBGcm9tIGRyYWZ0LWlldGYtcGNuLTMtaW4tMS1lbmNvZGlu Zy0wMCB0byAtMDE6DQ0gICAgICAqICBBbHRlcmVkIHRoZSB3b3JkaW5nIHRvIG1ha2Ugc2Vuc2Ug aWYNICAgICAgICAgW0ktRC5pZXRmLXRzdndnLWVjbi10dW5uZWxdIG1vdmVzIHRvIHByb3Bvc2Vk IHN0YW5kYXJkLg0NICAgICAgKiAgUmVmZXJlbmNlcyB1cGRhdGVkDQ0gICBGcm9tIGRyYWZ0LWJy aXNjb2UtcGNuLTMtaW4tMS1lbmNvZGluZy0wMCB0bw0gICBkcmFmdC1pZXRmLXBjbi0zLWluLTEt ZW5jb2RpbmctMDA6DQ0gICAgICAqICBGaWxlbmFtZSBjaGFuZ2VkIHRvIGRyYWZ0LWlldGYtcGNu LTMtaW4tMS1lbmNvZGluZy4NDSAgICAgICogIEludHJvZHVjdGlvbiBhbHRlcmVkIHRvIGluY2x1 ZGUgbmV3IHRlbXBsYXRlIGRlc2NyaXB0aW9uIG9mDSAgICAgICAgIFBDTi4NDSAgICAgICogIFJl ZmVyZW5jZXMgdXBkYXRlZC4NDSAgICAgICogIFRlcm1pbm9sb2d5IGJyb3VnaHQgaW50byBsaW5l IHdpdGggW1JGQzU2NzBdLg0NICAgICAgKiAgTWlub3IgY29ycmVjdGlvbnMuDQ0NDQ0NDQ1Ccmlz Y29lLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTMsIDIwMTEgICAgICAgICAgICAg ICAgW1BhZ2UgNF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29k aW5nICAgICAgICAgICAgICAgICBKdWx5IDIwMTANDQ0yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdl DQ0gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsDSAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDSAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0NMi4xLiAgVGVybWlub2xvZ3kNDSAg IEdlbmVyYWwgUENOLXJlbGF0ZWQgdGVybWlub2xvZ3kgaXMgZGVmaW5lZCBpbiB0aGUgUENOIGFy Y2hpdGVjdHVyZQ0gICBbUkZDNTU1OV0sIGFuZCB0ZXJtaW5vbG9neSBzcGVjaWZpYyB0byBwYWNr ZXQgZW5jb2RpbmcgaXMgZGVmaW5lZCBpbg0gICB0aGUgUENOIGJhc2VsaW5lIGVuY29kaW5nIFtS RkM1Njk2XS4gIEFkZGl0aW9uYWwgdGVybWlub2xvZ3kgaXMNICAgZGVmaW5lZCBiZWxvdy4NDSAg IFBDTiBlbmNvZGluZzogIG1hcHBpbmcgb2YgUENOIG1hcmtpbmcgc3RhdGVzIHRvIHNwZWNpZmlj IGNvZGVwb2ludHMNICAgICAgaW4gdGhlIHBhY2tldCBoZWFkZXIuDQ0NMy4gIFJlcXVpcmVtZW50 cyBmb3IgYW5kIEFwcGxpY2FiaWxpdHkgb2YgMy1pbi0xIFBDTiBFbmNvZGluZw0NMy4xLiAgUENO IFJlcXVpcmVtZW50cw0NICAgVGhlIFBDTiBhcmNoaXRlY3R1cmUgW1JGQzU1NTldIGRlZmluZXMg dGhhdCBQQ04taW5ncmVzcy1ub2RlcyBvZiBhDSAgIFBDTi1kb21haW4gY29udHJvbCBpbmNvbWlu ZyBwYWNrZXRzLiAgUGFja2V0cyBiZWxvbmdpbmcgdG8gUENOLQ0gICBjb250cm9sbGVkIGZsb3dz IGFyZSBzdWJqZWN0IHRvIFBDTiBtZXRlcmluZyBhbmQgbWFya2luZywgdGhleSBhcmUNICAgdGVy bWVkIFBDTi1wYWNrZXRzLCBhbmQgUENOLWluZ3Jlc3Mtbm9kZXMgbWFyayB0aGVtIGFzIG5vdC1t YXJrZWQNICAgKFBDTi1jb2xvdXJpbmcpLiAgQW55IG5vZGUgaW4gdGhlIFBDTi1kb21haW4gbWF5 IHBlcmZvcm0gUENOIG1ldGVyaW5nDSAgIGFuZCBtYXJraW5nIGFuZCBtYXJrIFBDTi1wYWNrZXRz IGlmIG5lZWRlZC4gIFRoZXJlIGFyZSB0d28gZGlmZmVyZW50DSAgIG1ldGVyaW5nIGFuZCBtYXJr aW5nIHNjaGVtZXM6IHRocmVzaG9sZC1tYXJraW5nIGFuZCBleGNlc3MtdHJhZmZpYy0NICAgbWFy a2luZyBbUkZDNTY3MF0uICBTb21lIGVkZ2UgYmVoYXZpb3JzIHJlcXVpcmUgb25seSBhIHNpbmds ZSBtYXJraW5nDSAgIHNjaGVtZSBbSS1ELmlldGYtcGNuLXNtLWVkZ2UtYmVoYXZpb3VyXSwgb3Ro ZXJzIHJlcXVpcmUgYm90aA0gICBbSS1ELmlldGYtcGNuLWNsLWVkZ2UtYmVoYXZpb3VyXS4gIElu IHRoZSBsYXR0ZXIgY2FzZSwgdGhyZWUgUENODSAgIG1hcmtpbmcgc3RhdGVzIGFyZSBuZWVkZWQ6 IG5vdC1tYXJrZWQgKE5NKSB0byBpbmRpY2F0ZSBub3QtbWFya2VkDSAgIHBhY2tldHMsIHRocmVz aG9sZC1tYXJrZWQgKFRoTSkgdG8gaW5kaWNhdGUgcGFja2V0cyBtYXJrZWQgYnkgdGhlDSAgIHRo cmVzaG9sZC1tYXJrZXIsIGFuZCBleGNlc3MtdHJhZmZpYy1tYXJrZWQgKEVUTSkgdG8gaW5kaWNh dGUgcGFja2V0cw0gICBtYXJrZWQgYnkgdGhlIGV4Y2Vzcy10cmFmZmljLW1hcmtlciBbUkZDNTY3 MF0uDQ0gICBBcyB0aHJlc2hvbGQtbWFya2luZw0gICBhbmQgZXhjZXNzLXRyYWZmaWMtbWFya2lu ZyBzdGFydCBtYXJraW5nIHBhY2tldHMgYXQgZGlmZmVyZW50IGxvYWQNICAgY29uZGl0aW9ucywg b25lIG1hcmtpbmcgc2NoZW1lIGluZGljYXRlcyBtb3JlIHNldmVyZSBwcmUtY29uZ2VzdGlvbg0g ICB0aGFuIHRoZSBvdGhlciBpbiB0ZXJtcyBvZiBoaWdoZXIgbG9hZC4gIElmIGEgcGFja2V0IGhh cyBiZWVuIG1hcmtlZA0gICBieSBib3RoIGEgdGhyZXNob2xkLW1hcmtlciBhbmQgYW4gZXhjZXNz LXRyYWZmaWMtbWFya2VyLCBpdCBpcyBtYXJrZWQNICAgd2l0aCB0aGUgbW9yZSBzZXZlcmUgc3Rh dGUuICBUaGVyZWZvcmUsIGEgZm91cnRoIFBDTiBtYXJraW5nIHN0YXRlDSAgIGluZGljYXRpbmcg dGhhdCBhIHBhY2tldCBpcyBtYXJrZWQgYnkgYm90aCBtYXJrZXJzIGlzIG5vdCBuZWVkZWQuDQ0g ICBOb25ldGhlbGVzcywgaW4gYWRkaXRpb24gdG8gY29kZXBvaW50cyBmb3IgdGhlIHRocmVlIFBD TiBtYXJraW5nDSAgIHN0YXRlcyBhIGZvdXJ0aCBjb2RlcG9pbnQgaXMgcmVxdWlyZWQgdG8gaW5k aWNhdGUgcGFja2V0cyB0aGF0IGFyZQ0gICBub3QgUENOLWNhcGFibGUgKHRlcm1lZCB0aGUgbm90 LVBDTiBjb2RlcG9pbnQpLg0NICAgT25jZSB0d28gc2V2ZXJpdHkgbGV2ZWxzIG9mIHByZS1jb25n ZXN0aW9uIG1hcmtpbmcgYXJlIHN1cHBvcnRlZCwgaXQgaXMgbmVjZXNzYXJ5IHRvIGRlZmluZSB3 aGljaCBpcyBtb3JlIHNldmVyZS4gW1JGQzU1NTldIHNwZWNpZmllcyB0aGF0IHRoZSBQQ04tZXhj ZXNzLXJhdGUgaXMgaGlnaGVyIHRoYW4gdGhlIFBDTi10aHJlc2hvbGQtcmF0ZSwgdGhlcmVmb3Jl IHdlICANDSAgIEluIGFsbCBjdXJyZW50IFBDTiBlZGdlIGJlaGF2aW9ycyB0aGF0IHVzZSB0d28g bWFya2luZyBzY2hlbWVzDSAgIFtSRkM1NTU5XSwgW0ktRC5pZXRmLXBjbi1jbC1lZGdlLWJlaGF2 aW91cl0sIGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcNDQ0NQnJpc2NvZSwgZXQgYWwuICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDEzLCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDVdDQwNSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgMy1pbi0xIFBDTiBFbmNvZGluZyAgICAgICAgICAgICAgICAg SnVseSAyMDEwDQ0NICAgaXMgY29uZmlndXJlZCB3aXRoIGEgbGFyZ2VyIHJlZmVyZW5jZSByYXRl IHRoYW4gdGhyZXNob2xkLW1hcmtpbmcuDSAgIFdlIHRha2UgdGhpcyBhcyBhIHJ1bGUgYW5kIGRl ZmluZSBleGNlc3MtdHJhZmZpYy1tYXJrZWQgYXMgYSBtb3JlDSAgIHNldmVyZSBQQ04tbWFyayB0 aGFuIHRocmVzaG9sZC1tYXJrZWQuDQUNMy4yLiAgUmVxdWlyZW1lbnRzIEltcG9zZWQgYnkgQmFz ZWxpbmUgRW5jb2RpbmcNDSAgIFRoZSBiYXNlbGluZSBlbmNvZGluZyBzY2hlbWUgW1JGQzU2OTZd IHdhcyBkZWZpbmVkIHNvIHRoYXQgaXQgY291bGQNICAgYmUgZXh0ZW5kZWQgdG8gYWNjb21tb2Rh dGUgYW4gYWRkaXRpb25hbCBtYXJraW5nIHN0YXRlLiAgSXQgcHJvdmlkZXMNICAgcnVsZXMgdG8g ZW1iZWQgdGhlIGVuY29kaW5nIG9mIHR3byBQQ04gc3RhdGVzIGluIHRoZSBJUCBoZWFkZXIuDSAg IEZpZ3VyZSAxIHNob3dzIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGZvcm1lciB0eXBlLW9mLXNlcnZp Y2UgZmllbGQuICBJdA0gICBjb250YWlucyB0aGUgNi1iaXQgRGlmZmVyZW50aWF0ZWQgU2Vydmlj ZXMgKERTKSBmaWVsZCB0aGF0IGhvbGRzIHRoZQ0gICBEUyBjb2RlcG9pbnQgKERTQ1ApIFtSRkMy NDc0XSBhbmQgdGhlIDItYml0IEVDTiBmaWVsZCBbUkZDMzE2OF0uDSAgICAgICAgICAgIDAgICAg IDEgICAgIDIgICAgIDMgICAgIDQgICAgIDUgICAgIDYgICAgIDcNICAgICAgICAgKy0tLS0tKy0t LS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKw0gICAgICAgICB8ICAgICAg ICAgICAgICBEUyBGSUVMRCAgICAgICAgICAgICB8IEVDTiBGSUVMRCB8DSAgICAgICAgICstLS0t LSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSstLS0tLSsNDSAgICAgICBGaWd1 cmUgMTogU3RydWN0dXJlIG9mIHRoZSBmb3JtZXIgdHlwZS1vZi1zZXJ2aWNlIGZpZWxkIGluIElQ DQ0gICBCYXNlbGluZSBlbmNvZGluZyBkZWZpbmVzIHRoYXQgdGhlIERTQ1AgbXVzdCBiZSBzZXQg dG8gYSBQQ04tDSAgIGNvbXBhdGlibGUgRFNDUCBuIGFuZCB0aGUgRUNOLWZpZWxkIFtSRkMzMTY4 XSBpbmRpY2F0ZXMgdGhlIHNwZWNpZmljDSAgIFBDTi1tYXJrLiAgQmFzZWxpbmUgZW5jb2Rpbmcg b2ZmZXJzIGZvdXIgcG9zc2libGUgZW5jb2Rpbmcgc3RhdGVzDSAgIHdpdGhpbiBhIHNpbmdsZSBE U0NQIHdpdGggdGhlIGZvbGxvd2luZyByZXN0cmljdGlvbnMuDQ0gICBvICBDb2RlcG9pbnQgYDAw JyAobm90LUVDVCkgaXMgdXNlZCB0byBpbmRpY2F0ZSBub24tUENOIHRyYWZmaWMgYXMNICAgICAg Im5vdC1QQ04iLiAgVGhpcyBhbGxvd3MgdGhlIHVzZSBvZiBhIERTQ1AgZm9yIGJvdGggUENOIGFu ZCBub24tUENODSAgICAgIHRyYWZmaWMuDQ0gICBvICBDb2RlcG9pbnQgYDEwJyAoRUNUKDApKSBp cyB1c2VkIHRvIGluZGljYXRlIE5vdC1tYXJrZWQgUENODSAgICAgIHRyYWZmaWMuDQ0gICBvICBD b2RlcG9pbnQgYDExJyAoQ0UpIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhlIG1vc3Qgc2V2ZXJlIFBD Ti1tYXJrLg0NICAgbyAgQ29kZXBvaW50IGAwMScgKEVDVCgxKSkgaXMgYXZhaWxhYmxlIGZvciBl eHBlcmltZW50YWwgdXNlIGFuZCBtYXkNICAgICAgYmUgcmUtdXNlZCBieSBvdGhlciBQQ04gZW5j b2RpbmdzIHN1Y2ggYXMgdGhlIHByZXNlbnRseSBkZWZpbmVkDSAgICAgIDMtaW4tMSBQQ04gZW5j b2RpbmcuDQ0zLjMuICBBcHBsaWNhYmlsaXR5IG9mIDMtaW4tMSBQQ04gRW5jb2RpbmcNDSAgIFdo ZW4gUENOIHRyYWZmaWMgaXMgdHVubmVsZWQgSVAtaW4tSVAgd2l0aGluIGEgUENOLWRvbWFpbiwg UENOLW1hcmtzDSAgIG11c3QgYmUgcHJlc2VydmVkIGluIGFsbCBvdXRlciBJUCBoZWFkZXJzIGFm dGVyIGVuY2Fwc3VsYXRpb24gYW5kDSAgIGRlY2Fwc3VsYXRpb24uICBUaGlzIHByb3BlcnR5IGlz IHZpb2xhdGVkIGJ5IGxlZ2FjeSBlbmNhcHN1bGF0aW9uIGFuZA0gICBkZWNhcHN1bGF0aW9uIHJ1 bGVzIFtSRkMzMTY4XSwgWwVSRkM0MzAxXSBkdWUgdG8gdGhlIHdheSB0aGV5IHRyZWF0DSAgIHRo ZSBFQ04gZmllbGQuICBUaGlzIGxlZCB0byBzdHJvbmcgbGltaXRhdGlvbnMgcmVnYXJkaW5nIGhv dyBQQ04tDSAgIG1hcmtzIGNhbiBiZSBlbmNvZGVkIHVzaW5nIHRoZSBFQ04gZmllbGQgb2YgdGhl IElQIGhlYWRlcg0gICBbSS1ELmlldGYtcGNuLWVuY29kaW5nLWNvbXBhcmlzb25dLiAgVGhlcmVm b3JlLCBiYXNlbGluZSBlbmNvZGluZw0gICBbUkZDNTY5Nl0gd2FzIGRlZmluZWQgd2hpY2ggd29y a3Mgd2VsbCB3aXRoIGxlZ2FjeSB0dW5uZWxzIGJ1dA0gICBzdXBwb3J0cyBvbmx5IHR3byBQQ04g bWFya2luZyBzdGF0ZXMuDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFy eSAxMywgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA2XQ0MDUludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAgICAgICAgICAgIEp1bHkgMjAxMA0NDSAg IFNpbmNlIHRoZW4sIG5ldyBydWxlcyBoYXZlIGJlZW4gZGVmaW5lZCBmb3IgSVAtaW4tSVAgdHVu bmVsaW5nDSAgIFtJLUQuaWV0Zi10c3Z3Zy1lY24tdHVubmVsXSBzbyB0aGF0IHRoZSBwcmVzZW50 IDMtaW4tMSBQQ04gZW5jb2RpbmcNICAgaGFzIG1vcmUgZnJlZWRvbSB0byBhY2NvbW1vZGF0ZSBQ Q04tbWFya3MgdXNpbmcgdGhlIEVDTiBmaWVsZC4gIEZyb20NICAgdGhpcyBpdCBmb2xsb3dzIHRo YXQgMy1pbi0xIFBDTiBlbmNvZGluZyBtYXkgYmUgYXBwbGllZCBvbmx5IGlub25seSBpZiBhbGwg dHVubmVsIGVuZHBvaW50cyB3aXRoaW4gYSBQQ04tDSAgIGRvbWFpbnMgBXRoYXQgIGNvbXBseSB3 aXRoIFtJLUQuaWV0Zi10c3Z3Zy1lY24tdHVubmVsXSBvciB0aGVyZSBhcmUgbm8gdHVubmVsIGVu ZHBvaW50cyB3aXRoaW4gdGhlIFBDTiBkb21haW5kbyBub3QgdXNlDSAgIHR1bm5lbGluZy4gVGhl cmUgYXJlIG5vIGlzc3VlcyB3aXRoIHR1bm5lbHMgdGhhdCBzcGFuIGEgUENOIGRvbWFpbiB3aXRo IGJvdGggZW5kcG9pbnRzIG91dHNpZGUgaXQuDQ0NNC4gIERlZmluaXRpb24gb2YgMy1pbi0xIFBD TiBFbmNvZGluZw0NICAgVGhlIDMtaW4tMSBQQ04gZW5jb2Rpbmcgc2NoZW1lIGlzIGFuIGV4dGVu c2lvbiBvZiB0aGUgYmFzZWxpbmUNICAgZW5jb2Rpbmcgc2NoZW1lIGRlZmluZWQgaW4gW1JGQzU2 OTZdLiAgVGhlIFBDTiByZXF1aXJlbWVudHMgYW5kIHRoZQ0gICBleHRlbnNpb24gcnVsZXMgZm9y IGJhc2VsaW5lIGVuY29kaW5nIHByZXNlbnRlZCBpbiB0aGUgcHJldmlvdXMNICAgc2VjdGlvbiBk ZXRlcm1pbmUgaG93IFBDTiBlbmNvZGluZyBzdGF0ZXMgYXJlIGNhcnJpZWQgaW4gdGhlIElQDSAg IGhlYWRlcnMuICBUaGlzIGlzIHNob3duIGluIEZpZ3VyZSAyLg0gICAgICAgICArLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgICAgQ29kZXBvaW50IGluIEVDTiBmaWVsZCBvZiBJUCBo ZWFkZXIgICAgICB8DSAgICAgICAgIHwgIERTQ1AgIHwgICAgICAgICAgICAgICA8UkZDMzE2OCBj b2RlcG9pbnQgbmFtZT4gICAgICAgICAgICAgfA0gICAgICAgICB8ICAgICAgICArLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsNICAgICAgICAgfCAg ICAgICAgfCAwMCA8Tm90LUVDVD4gfCAxMCA8RUNUKDApPiB8IDAxIDxFQ1QoMSk+IHwgMTEgPENF PiB8DSAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tKw0gICAgICAgICB8IERTQ1AgbiB8ICAgIE5vdC1QQ04gICB8ICAg ICAgTk0gICAgIHwgICAgIFRoTSAgICAgfCAgIEVUTSAgIHwNICAgICAgICAgKy0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rDQ0gICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiAzLWluLTEgUENOIEVuY29kaW5nDQ0gICBMaWtl IGJhc2VsaW5lIGVuY29kaW5nLCAzLWluLTEgUENOIGVuY29kaW5nIGFsc28gdXNlcyBhIFBDTg0g ICBjb21wYXRpYmxlIERTQ1AgbiBhbmQgdGhlIEVDTiBmaWVsZCBmb3IgdGhlIGVuY29kaW5nIG9m IFBDTi1tYXJrcy4NICAgVGhlIFBDTi1tYXJrcyBoYXZlIHRoZSBmb2xsb3dpbmcgbWVhbmluZy4N DSAgIE5vdC1QQ046ICBpbmRpY2F0ZXMgYSBub24tUENOLXBhY2tldCwgaS5lLiwgYSBwYWNrZXQg dGhhdCBpcyBub3QNICAgICAgc3ViamVjdCB0byBQQ04gbWV0ZXJpbmcgYW5kIG1hcmtpbmcuDQ0g ICBOTTogIE5vdC1tYXJrZWQuICBJbmRpY2F0ZXMgYSBQQ04tcGFja2V0IHRoYXQgaGFzIG5vdCB5 ZXQgYmVlbiBtYXJrZWQNICAgICAgYnkgYW55IFBDTiBtYXJrZXIuDQ0gICBUaE06ICBUaHJlc2hv bGQtbWFya2VkLiAgSW5kaWNhdGVzIGEgUENOLXBhY2tldCB0aGF0IGhhcyBiZWVuIG1hcmtlZA0g ICAgICBieSBhIHRocmVzaG9sZC1tYXJrZXIgW1JGQzU2NzBdLg0NICAgRVRNOiAgRXhjZXNzLXRy YWZmaWMtbWFya2VkLiAgSW5kaWNhdGVzIGEgUENOLXBhY2tldCB0aGF0IGhhcyBiZWVuDSAgICAg IG1hcmtlZCBieSBhbiBleGNlc3MtdHJhZmZpYy1tYXJrZXIgW1JGQzU2NzBdLg0NDTUuICBCZWhh dmlvdXIgb2YgYSBQQ04gTm9kZSBDb21wbGlhbnQgd2l0aCB0aGUgMy1pbi0xIFBDTiBFbmNvZGlu Zw0NICAgVG8gYmUgY29tcGxpYW50IHdpdGggdGhlIDMtaW4tMSBQQ04gRW5jb2RpbmcsIGFuIFBD TiBpbnRlcmlvciBub2RlDSAgIGJlaGF2ZXMgYXMgZm9sbG93czoNDQ0NDUJyaXNjb2UsIGV0IGFs LiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMywgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA3 XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAg ICAgICAgICAgIEp1bHkgMjAxMA0NDSAgIG8gIEl0IE1VU1QgY2hhbmdlIE5NIHRvIFRoTSBpZiB0 aGUgdGhyZXNob2xkLW1ldGVyIGZ1bmN0aW9uIGluZGljYXRlcw0gICAgICB0byBtYXJrIHRoZSBw YWNrZXQuDQ0gICBvICBJdCBNVVNUIGNoYW5nZSBOTSBvciBUaE0gdG8gRVRNIGlmIHRoZSBleGNl c3MtdHJhZmZpYy1tZXRlcg0gICAgICBmdW5jdGlvbiBpbmRpY2F0ZXMgdG8gbWFyayB0aGUgcGFj a2V0Lg0NICAgbyAgSXQgTVVTVCBOT1QgY2hhbmdlIG5vdC1QQ04gdG8gTk0sIFRoTSwgb3IgRVRN LCBhbmQgTVVTVCBOT1QgY2hhbmdlDSAgICAgIGEgTk0sIFRoTSwgb3IgRVRNIHRvIG5vdC1QQ047 DQ0gICBvICBJdCBNVVNUIE5PVCBjaGFuZ2UgVGhNIHRvIE5NOw0NICAgbyAgSXQgTVVTVCBOT1Qg Y2hhbmdlIEVUTSB0byBUaE0gb3IgdG8gTk07DQ0gICBJbiBvdGhlciB3b3JkcywgYSBQQ04gaW50 ZXJpb3Igbm9kZSBNVVNUIE5PVCBtYXJrIFBDTi1wYWNrZXRzIGludG8NICAgbm9uLVBDTiBwYWNr ZXRzIGFuZCB2aWNlLXZlcnNhLCBhbmQgaXQgbWF5IGluY3JlYXNlIHRoZSBzZXZlcml0eSBvZg0g ICB0aGUgUENOLW1hcmsgb2YgYSBQQ04tcGFja2V0LCBidXQgaXQgTVVTVCBOT1QgZGVjcmVhc2Ug aXQuDQ0NNi4gIEJhY2t3YXJkIENvbXBhdGliaWxpdHkNDSAgIERpc2N1c3Npb24gb2YgYmFja3dh cmQgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIFBDTiBlbmNvZGluZyBzY2hlbWVzIGFuZA0gICBwcmV2 aW91cyB1c2VzIG9mIHRoZSBFQ04gZmllbGQgaXMgZ2l2ZW4gaW4gU2VjdGlvbiA2IG9mIFtSRkM1 Njk2XS4NDTYuMS4gIEJhY2t3YXJkIENvbXBhdGliaWxpdHkgd2l0aCBQcmUtZXhpc3RpbmcgUENO IEltcGxlbWVudGF0aW9ucw0NICAgVGhpcyBlbmNvZGluZyBjb21wbGllcyB3aXRoIHRoZSBydWxl cyBmb3IgZXh0ZW5kaW5nIHRoZSBiYXNlbGluZSBQQ04NICAgZW5jb2Rpbmcgc2NoZW1lcyBpbiBT ZWN0aW9uIDUgb2YgW1JGQzU2OTZdLg0NBSAgIEluIGEgUENOIGRvbWFpbiB1c2luZyB0d28gbGV2 ZWxzIG9mIFBDTi1tYXJraW5nLCBlLmcuIHdoZW4gdXNpbmcgdGhlIENMIGVkZ2UgYmVoYXZpb3Vy LCBpdCBNQVkgYmUgZmVhc2libGUgZm9yIHNvbWUgaW50ZXJpb3Igbm9kZXMgdG8gcGVyZm9ybSBv bmx5IGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcgYW5kIG9ubHkgdXNlIHRoZSBiYXNlbGluZSBlbmNv ZGluZyBbSS1ELmlldGYtcGNuLWNsLWVkZ2UtYmVoYXZpb3VyXS4gICAgVXNpbmcgbm9kZXMgdGhh dCBwZXJmb3JtIG9ubHkgZXhjZXNzLXRyYWZmaWMtbWFya2luZyBtYXkgbWFrZSBzZW5zZQ0gICBp biBuZXR3b3JrcyB1c2luZyB0aGUgQ0wgZWRnZSBiZWhhdmlvcg0gICBbSS1ELmlldGYtcGNuLWNs LWVkZ2UtYmVoYXZpb3VyXS4gIFN1Y2ggbm9kZXMgYXJlIGFibGUgdG8gbm90aWZ5IHRoZQ0gICBl Z3Jlc3Mgb25seSBhYm91dCBzZXZlcmUgcHJlLWNvbmdlc3Rpb24gd2hlbiB0cmFmZmljIG5lZWRz IHRvIGJlDSAgIHRlcm1pbmF0ZWQuICBUaGlzIHNlZW1zIE1BWSBiZSByZWFzb25hYmxlIGZvciBs b2NhdGlvbnMgdGhhdCBhcmUgbm90DSAgIGV4cGVjdGVkIHRvIHNlZSBhbnkgcHJlLWNvbmdlc3Rp b24sIGJ1dCBleGNlc3MtdHJhZmZpYy1tYXJraW5nIGdpdmVzDSAgIHRoZW0gYSBtZWFucyB0byB0 ZXJtaW5hdGUgdHJhZmZpYyBpZiB1bmV4cGVjdGVkIG92ZXJsb2FkIHN0aWxsDSAgIG9jY3Vycy4N DSAgIFRoZSAzLWluLTEgUENOIGVuY29kaW5nIGlzIHRoZXJlZm9yZSBiYWNrd2FyZCBjb21wYXRp YmxlIHdpdGggdGhlIGJhc2VsaW5lIGVuY29kaW5nICAgIFRoZSB0ZXJtICJjb21wYXRpYmlsaXR5 IiBpcyBtZWFudCBpbiB0aGUgZm9sbG93aW5nIHNlbnNlLiAgSXQgaXMNICAgcG9zc2libGUgdG8g b3BlcmF0ZSBub2RlcyB3aXRoIGJhc2VsaW5lIGVuY29kaW5nIFtSRkM1Njk2XSBhbmQgMy1pbi0x DSAgIGVuY29kaW5nIGluIHRoZSBzYW1lIFBDTiBkb21haW4gYXMgbG9uZyBhcyB0aGUgbm9kZXMg c2F0aXNmeSB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6DQ0uICAgbyBUaGUgQW55IG5vZGVzIHdp dGggdGhhdCBvbmx5IHN1cHBvcnRzIHRoZSBiYXNlbGluZSBlbmNvZGluZw0gICBNVVNUIHBlcmZv cm0gZXhjZXNzLXRyYWZmaWMtbWFya2luZywgYmVjYXVzZSB0aGUgaXQgd2lsbCBvbmx5IHVzZSB0 aGUgMTEgY29kZXBvaW50LCB3aGljaCBvZg0gICAzLWluLTEgZW5jb2RpbmcgYWxzbyBtZWFucyBl eGNlc3MtdHJhZmZpYy1tYXJrZWQgdG8gYSBub2RlIHN1cHBvcnRpbmcgdGhlDSAgIDMtaW4tMSBl bmNvZGluZy4gIA0NICAgbyBBbnkgbm9kZSBhY3RpbmcgYXMgYSBQQ04tYm91bmRhcnktbm9kZXMN ICAgb2YgYXJvdW5kIHN1Y2ggYSBtaXhlZCBkb21haW5zIGFyZSByZXF1aXJlZCB0byBpbnRlcnBy ZXQgTVVTVCBzdXBwb3J0IHRoZSBmdWxsIDMtaW4tMSBlbmNvZGluZw0gICBhbmQgbm90IGp1c3Qg dGhlIGJhc2VsaW5lIGVuY29kaW5nLCBvdGhlcndpc2UgdGhleSBpdCBjYW5ub3QgaW50ZXJwcmV0 IHRoZQ0gICAwMSBjb2RlcG9pbnQuDQUNDQ0NDQ1CcmlzY29lLCBldCBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTMsIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgOF0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29kaW5nICAgICAgICAgICAgICAgICBKdWx5 IDIwMTANDQ02LjIuICBSZWNvbW1lbmRhdGlvbnMgZm9yIHRoZSBVc2Ugb2YgUENOIEVuY29kaW5n IFNjaGVtZXMNDSAgIFRoaXMgc3ViLXNlY3Rpb24gaXMgaW5mb3JtYXRpdmUgbm90IG5vcm1hdGl2 ZS4NICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDSAgICAgICAgIHwgIFVzZWQgbWFya2luZyBzY2hlbWVzICB8ICBS ZWNvbW1lbmRlZCBQQ04gZW5jb2Rpbmcgc2NoZW1lICAgfA0gICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNICAgICAg ICAgfCBUaHJlc2hvbGQtbWFya2luZyBhbmQgIHwgICAgIDMtaW4tMSBQQ04gZW5jb2RpbmcgICAg ICAgICAgICB8DSAgICAgICAgIHwgZXhjZXNzLXRyYWZmaWMtbWFya2luZyB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgBXwNICAgICAgICAgfCBPbmx5IHRocmVzaG9sZC1tYXJr aW5nIHwgICAgIEJhc2VsaW5lIGVuY29kaW5nIFtSRkM1Njk2XSAgICB8DSAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0gICAgICAgICB8IE9ubHkgZXhjZXNzLXRyYWZmaWMtICAgfCAgICAgQmFzZWxpbmUgZW5jb2Rp bmcgW1JGQzU2OTZdICAgIHwNICAgICAgICAgfCAgICAgICBtYXJraW5nICAgICAgICAgIHwgIG9y IDMtaW4tMSBQQ04gZW5jb2RpbmcgICAgICAgICAgICB8DSAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0gICAgICAg ICB8IE9ubHkgdGhyZXNob2xkLW1hcmtpbmcgfCAgICAgQmFzZWxpbmUgZW5jb2RpbmcgW1JGQzU2 OTZdICAgIHwNICAgICAgICAgfCBUaHJlc2hvbGQtbWFya2luZyBhbmQgIHwgICAgIDMtaW4tMSBQ Q04gZW5jb2RpbmcgICAgICAgICAgICB8DSAgICAgICAgIHwgZXhjZXNzLXRyYWZmaWMtbWFya2lu ZyB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0gICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN DSAgICAgICAgICAgICAgICAgICBGaWd1cmUgMzogVXNlIG9mIFBDTiBlbmNvZGluZyBzY2hlbWVz DQ0gICBGaWd1cmUgMyBnaXZlcyBndWlkZWxpbmVzIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMgYmFz ZWxpbmUgZW5jb2RpbmcNICAgYW5kIDMtaW4tMSBQQ04gZW5jb2Rpbmcgd291bGQgdHlwaWNhbGx5 IGJlIHVzZWQuDQ02LjIuMS4gIFVzZSBvZiBCb3RoIEV4Y2Vzcy1UcmFmZmljLU1hcmtpbmcgYW5k IFRocmVzaG9sZC1NYXJraW5nDQ0gICBJZiBib3RoIGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcgYW5k IHRocmVzaG9sZC1tYXJraW5nIGFyZSBlbmFibGVkIGluIGENICAgUENOLWRvbWFpbiwgMy1pbi0x IGVuY29kaW5nIHNob3VsZCBiZSB1c2VkIGFzIGRlc2NyaWJlZCBpbiB0aGlzDSAgIGRvY3VtZW50 Lg0NNi4yLjIuICBVbmlxdWUgVXNlIG9mIEV4Y2Vzcy1UcmFmZmljLU1hcmtpbmcNDSAgIElmIG9u bHkgZXhjZXNzLXRyYWZmaWMtbWFya2luZyBpcyBlbmFibGVkIGluIGEgUENOLWRvbWFpbiwgYmFz ZWxpbmUNICAgZW5jb2Rpbmcgb3IgMy1pbi0xIGVuY29kaW5nIG1heSBiZSB1c2VkLiAgVGhleSBs ZWFkIHRvIHRoZSBzYW1lDSAgIGVuY29kaW5nIGJlY2F1c2UgUENOLWJvdW5kYXJ5IG5vZGVzIHdp bGwgaW50ZXJwcmV0IGJhc2VsaW5lICJQQ04tDSAgIG1hcmtlZCAoUE0pIiBhcyAiZXhjZXNzLXRy YWZmaWMtbWFya2VkIChFVE0pIi4NDTYuMi4zLiAgVW5pcXVlIFVzZSBvZiBUaHJlc2hvbGQtTWFy a2luZw0NICAgTm8gc2NoZW1lIGlzIGN1cnJlbnRseSBwcm9wb3NlZCB0byBzb2xlbHkgdXNlIHRo cmVzaG9sZC1tYXJraW5nLg0gICBIb3dldmVyLCBpZiBvbmx5IHRocmVzaG9sZC1tYXJraW5nIGlz IGVuYWJsZWQgaW4gYSBQQ04tZG9tYWluLA0gICBiYXNlbGluZSBlbmNvZGluZyBTSE9VTEQgYmUg dXNlZC4gIFRoaXMgaXMgYmVjYXVzZSB0aHJlc2hvbGQgbWFya2luZw0gICB3aWxsIHdvcmsgaW4g Y29tYmluYXRpb24gd2l0aCBsZWdhY3kgdHVubmVsIGRlY2Fwc3VsYXRvcnMgd2l0aGluIHRoZQ0g ICBQQ04tZG9tYWluLCB3aGlsZSB1c2luZyB0aHJlc2hvbGQgbWFya2luZyB3aXRoIHRoZSAzLWlu LTEgZW5jb2RpbmcNICAgcmVxdWlyZXMgdGhhdCB0dW5uZWwgZGVjYXBzdWxhdG9ycyB3aXRoaW4g YSBQQ04tZG9tYWluIGNvbXBseSB3aXRoDSAgIFtJLUQuaWV0Zi10c3Z3Zy1lY24tdHVubmVsXS4N DQ03LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0NICAgVGhpcyBtZW1vIGluY2x1ZGVzIG5vIHJlcXVl c3QgdG8gSUFOQS4NDQ0NDUJyaXNjb2UsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAx MywgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA5XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAg ICAgIDMtaW4tMSBQQ04gRW5jb2RpbmcgICAgICAgICAgICAgICAgIEp1bHkgMjAxMA0NDSAgIE5v dGUgdG8gUkZDIEVkaXRvcjogdGhpcyBzZWN0aW9uIG1heSBiZSByZW1vdmVkIG9uIHB1YmxpY2F0 aW9uIGFzIGFuDSAgIFJGQy4NDQ04LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNDSAgIFRoZSBz ZWN1cml0eSBjb25jZXJucyByZWxhdGluZyB0byB0aGlzIGV4dGVuZGVkIFBDTiBlbmNvZGluZyBh cmUgdGhlDSAgIHNhbWUgYXMgdGhvc2UgaW4gW1JGQzU2OTZdLiAgSW4gc3VtbWFyeSwgUENOLWJv dW5kYXJ5IG5vZGVzIGFyZQ0gICByZXNwb25zaWJsZSBmb3IgZW5zdXJpbmcgaW5hcHByb3ByaWF0 ZSBQQ04gbWFya2luZ3MgZG8gbm90IGxlYWsgaW50bw0gICBvciBvdXQgb2YgYSBQQ04gZG9tYWlu LCBhbmQgdGhlIGN1cnJlbnQgcGhhc2Ugb2YgdGhlIFBDTiBhcmNoaXRlY3R1cmUNICAgYXNzdW1l cyB0aGF0IGFsbCB0aGUgbm9kZXMgb2YgYSBQQ04tZG9tYWluIGFyZSBlbnRpcmVseSB1bmRlciB0 aGUNICAgY29udHJvbCBvZiBhIHNpbmdsZSBvcGVyYXRvciwgb3IgYSBzZXQgb2Ygb3BlcmF0b3Jz IHdobyB0cnVzdCBlYWNoDSAgIG90aGVyLg0NICAgR2l2ZW4gdGhlIG9ubHkgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSBiYXNlbGluZSBlbmNvZGluZyBhbmQgdGhlDSAgIHByZXNlbnQgMy1pbi0xIGVu Y29kaW5nIGlzIHRoZSB1c2Ugb2YgdGhlIDAxIGNvZGVwb2ludCwgbm8gbmV3DSAgIHNlY3VyaXR5 IGlzc3VlcyBhcmUgcmFpc2VkLCBhcyB0aGlzIGNvZGVwb2ludCB3YXMgYWxyZWFkeSBhdmFpbGFi bGUNICAgZm9yIGV4cGVyaW1lbnRhbCB1c2UgaW4gdGhlIGJhc2VsaW5lIGVuY29kaW5nLg0NDTku ICBDb25jbHVzaW9ucw0NICAgVGhlIDMtaW4tMSBQQ04gZW5jb2RpbmcgdXNlcyBhIFBDTi1jb21w YXRpYmxlIERTQ1AgYW5kIHRoZSBFQ04gZmllbGQNICAgdG8gZW5jb2RlIFBDTi1tYXJrcy4gIE9u ZSBjb2RlcG9pbnQgYWxsb3dzIG5vbi1QQ04gdHJhZmZpYyB0byBiZQ0gICBjYXJyaWVkIHdpdGgg dGhlIHNhbWUgUENOLWNvbXBhdGlibGUgRFNDUCBhbmQgdGhyZWUgb3RoZXIgY29kZXBvaW50cw0g ICBzdXBwb3J0IHRocmVlIFBDTiBtYXJraW5nIHN0YXRlcyB3aXRoIGRpZmZlcmVudCBsZXZlbHMg b2Ygc2V2ZXJpdHkuDSAgIFRoZSB1c2Ugb2YgdGhpcyBQQ04gZW5jb2Rpbmcgc2NoZW1lIHByZXN1 cHBvc2VzIHRoYXQgYW55IHR1bm5lbCBlbmRwb2ludHMgaW4NICAgdGhlIFBDTiByZWdpb24gaGF2 ZSBiZWVuIHVwZGF0ZWQgdG8gY29tcGx5IHdpdGgNICAgW0ktRC5pZXRmLXRzdndnLWVjbi10dW5u ZWxdLg0NDTEwLiAgQWNrbm93bGVkZ2VtZW50cw0NICAgVGhhbmtzIHRvIFBoaWwgRWFyZGxleSwg VGVjbyBCb290LCBhbmQgS3dvayBIbyBDaGFuIGZvciByZXZpZXdpbmcNICAgdGhpcyBkb2N1bWVu dC4NDQ0xMS4gIENvbW1lbnRzIFNvbGljaXRlZA0NICAgVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRp dG9yOiBDb21tZW50cyBhbmQgcXVlc3Rpb25zIGFyZSBlbmNvdXJhZ2VkDSAgIGFuZCB2ZXJ5IHdl bGNvbWUuICBUaGV5IGNhbiBiZSBhZGRyZXNzZWQgdG8gdGhlIElFVEYgQ29uZ2VzdGlvbiBhbmQN ICAgUHJlLUNvbmdlc3Rpb24gd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgPHBjbkBpZXRmLm9y Zz4sIGFuZC9vciB0bw0gICB0aGUgYXV0aG9ycy4NDQ0xMi4gIFJlZmVyZW5jZXMNDQ0NDQ1Ccmlz Y29lLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTMsIDIwMTEgICAgICAgICAgICAg ICBbUGFnZSAxMF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAzLWluLTEgUENOIEVuY29k aW5nICAgICAgICAgICAgICAgICBKdWx5IDIwMTANDQ0xMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMNDSAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNz IHRvIEluZGljYXRlDSAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4NDSAgIFtSRkMyNDc0XSAgTmljaG9scywgSy4sIEJsYWtlLCBT LiwgQmFrZXIsIEYuLCBhbmQgRC4gQmxhY2ssDSAgICAgICAgICAgICAgIkRlZmluaXRpb24gb2Yg dGhlIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIEZpZWxkIChEUw0gICAgICAgICAgICAgIEZpZWxk KSBpbiB0aGUgSVB2NCBhbmQgSVB2NiBIZWFkZXJzIiwgUkZDIDI0NzQsDSAgICAgICAgICAgICAg RGVjZW1iZXIgMTk5OC4NDSAgIFtSRkMzMTY4XSAgUmFtYWtyaXNobmFuLCBLLiwgRmxveWQsIFMu LCBhbmQgRC4gQmxhY2ssICJUaGUgQWRkaXRpb24NICAgICAgICAgICAgICBvZiBFeHBsaWNpdCBD b25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBJUCIsDSAgICAgICAgICAgICAgUkZDIDMx NjgsIFNlcHRlbWJlciAyMDAxLg0NBSAgIFtSRkM0MzAxXSAgS2VudCwgUy4gYW5kIEsuIFNlbywg IlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlDSAgICAgICAgICAgICAgSW50ZXJuZXQgUHJv dG9jb2wiLCBSRkMgNDMwMSwgRGVjZW1iZXIgMjAwNS4NDSAgIFtSRkM1MTI5XSAgRGF2aWUsIEIu LCBCcmlzY29lLCBCLiwgYW5kIEouIFRheSwgIkV4cGxpY2l0IENvbmdlc3Rpb24NICAgICAgICAg ICAgICBNYXJraW5nIGluIE1QTFMiLCBSRkMgNTEyOSwgSmFudWFyeSAyMDA4Lg0NICAgW1JGQzU1 NTldICBFYXJkbGV5LCBQLiwgIlByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoUENOKQ0gICAg ICAgICAgICAgIEFyY2hpdGVjdHVyZSIsIFJGQyA1NTU5LCBKdW5lIDIwMDkuDQ0FICAgW1JGQzU2 NzBdICBFYXJkbGV5LCBQLiwgIk1ldGVyaW5nIGFuZCBNYXJraW5nIEJlaGF2aW91ciBvZiBQQ04t DSAgICAgICAgICAgICAgTm9kZXMiLCBSRkMgNTY3MCwgTm92ZW1iZXIgMjAwOS4NDSAgIFtSRkM1 Njk2XSAgTW9uY2FzdGVyLCBULiwgQnJpc2NvZSwgQi4sIGFuZCBNLiBNZW50aCwgIkJhc2VsaW5l DSAgICAgICAgICAgICAgRW5jb2RpbmcgYW5kIFRyYW5zcG9ydCBvZiBQcmUtQ29uZ2VzdGlvbiBJ bmZvcm1hdGlvbiIsDSAgICAgICAgICAgICAgUkZDIDU2OTYsIE5vdmVtYmVyIDIwMDkuDSAgIFtJ LUQuaWV0Zi10c3Z3Zy1lY24tdHVubmVsXQ0gICAgICAgICAgICAgIEJyaXNjb2UsIEIuLCAiVHVu bmVsbGluZyBvZiBFeHBsaWNpdCBDb25nZXN0aW9uDSAgICAgICAgICAgICAgTm90aWZpY2F0aW9u IiwgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tdHVubmVsLTA4ICh3b3JrIGluDSAgICAgICAgICAgICAg cHJvZ3Jlc3MpLCBNYXJjaCAyMDEwLg0NDTEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQ0g ICBbUkZDNDMwMV0gIEtlbnQsIFMuIGFuZCBLLiBTZW8sICJTZWN1cml0eSBBcmNoaXRlY3R1cmUg Zm9yIHRoZQ0gICAgICAgICAgICAgIEludGVybmV0IFByb3RvY29sIiwgUkZDIDQzMDEsIERlY2Vt YmVyIDIwMDUuDQ0gICBbUkZDNTEyOV0gIERhdmllLCBCLiwgQnJpc2NvZSwgQi4sIGFuZCBKLiBU YXksICJFeHBsaWNpdCBDb25nZXN0aW9uDSAgICAgICAgICAgICAgTWFya2luZyBpbiBNUExTIiwg UkZDIDUxMjksIEphbnVhcnkgMjAwOC4NDSAgIFtSRkM1NTU5XSAgRWFyZGxleSwgUC4sICJQcmUt Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKFBDTikNICAgICAgICAgICAgICBBcmNoaXRlY3R1cmUi LCBSRkMgNTU1OSwgSnVuZSAyMDA5Lg0NICAgW0ktRC5pZXRmLXBjbi1jbC1lZGdlLWJlaGF2aW91 cl0NICAgICAgICAgICAgICBDaGFybnksIEEuLCBIdWFuZywgRi4sIEthcmFnaWFubmlzLCBHLiwg TWVudGgsIE0uLCBhbmQgVC4NICAgICAgICAgICAgICBUYXlsb3IsICJQQ04gQm91bmRhcnkgTm9k ZSBCZWhhdmlvdXIgZm9yIHRoZSBDb250cm9sbGVkDSAgICAgICAgICAgICAgTG9hZCAoQ0wpIE1v ZGUgb2YgT3BlcmF0aW9uIiwNICAgICAgICAgICAgICBkcmFmdC1pZXRmLXBjbi1jbC1lZGdlLWJl aGF2aW91ci0wNiAod29yayBpbiBwcm9ncmVzcyksDSAgICAgICAgICAgICAgSnVuZSAyMDEwLg0N ICAgW0ktRC5pZXRmLXBjbi1lbmNvZGluZy1jb21wYXJpc29uXQ0gICAgICAgICAgICAgIENoYW4s IEsuLCBLYXJhZ2lhbm5pcywgRy4sIE1vbmNhc3RlciwgVC4sIE1lbnRoLCBNLiwNICAgICAgICAg ICAgICBFYXJkbGV5LCBQLiwgYW5kIEIuIEJyaXNjb2UsICJQcmUtQ29uZ2VzdGlvbiBOb3RpZmlj YXRpb24NICAgICAgICAgICAgICBFbmNvZGluZyBDb21wYXJpc29uIiwNICAgICAgICAgICAgICBk cmFmdC1pZXRmLXBjbi1lbmNvZGluZy1jb21wYXJpc29uLTAyICh3b3JrIGluIHByb2dyZXNzKSwN ICAgICAgICAgICAgICBNYXJjaCAyMDEwLg0NICAgW0ktRC5pZXRmLXBjbi1zbS1lZGdlLWJlaGF2 aW91cl0NICAgICAgICAgICAgICBDaGFybnksIEEuLCBLYXJhZ2lhbm5pcywgRy4sIE1lbnRoLCBN LiwgYW5kIFQuIFRheWxvciwNDQ0NQnJpc2NvZSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDEzLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgMy1pbi0xIFBDTiBFbmNvZGluZyAgICAgICAgICAgICAgICAgSnVseSAyMDEwDQ0N ICAgICAgICAgICAgICAiUENOIEJvdW5kYXJ5IE5vZGUgQmVoYXZpb3VyIGZvciB0aGUgU2luZ2xl IE1hcmtpbmcgKFNNKQ0gICAgICAgICAgICAgIE1vZGUgb2YgT3BlcmF0aW9uIiwgZHJhZnQtaWV0 Zi1wY24tc20tZWRnZS1iZWhhdmlvdXItMDMNICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVz cyksIEp1bmUgMjAxMC4NDSAgIFtJLUQuaWV0Zi10c3Z3Zy1lY24tdHVubmVsXQ0gICAgICAgICAg ICAgIEJyaXNjb2UsIEIuLCAiVHVubmVsbGluZyBvZiBFeHBsaWNpdCBDb25nZXN0aW9uDSAgICAg ICAgICAgICAgTm90aWZpY2F0aW9uIiwgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tdHVubmVsLTA4ICh3 b3JrIGluDSAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBNYXJjaCAyMDEwLg0NDUF1dGhvcnMnIEFk ZHJlc3Nlcw0NICAgQm9iIEJyaXNjb2UNICAgQlQNICAgQjU0Lzc3LCBBZGFzdHJhbCBQYXJrDSAg IE1hcnRsZXNoYW0gSGVhdGgNICAgSXBzd2ljaCAgSVA1IDNSRQ0gICBVSw0NICAgUGhvbmU6ICs0 NCAxNDczIDY0NTE5Ng0gICBFbWFpbDogYm9iLmJyaXNjb2VAYnQuY29tDSAgIFVSSTogICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQ0NICAgVG9ieSBNb25jYXN0ZXINICAgSW5kZXBlbmRlbnQNDSAg IEVtYWlsOiB0b2J5QG1vbmNhc3Rlci5jb20NDQ0gICBNaWNoYWVsIE1lbnRoDSAgIFVuaXZlcnNp dHkgb2YgV3VlcnpidXJnDSAgIHJvb20gQjIwNiwgSW5zdGl0dXRlIG9mIENvbXB1dGVyIFNjaWVu Y2UNICAgQW0gSHVibGFuZA0gICBXdWVyemJ1cmcgIDk3MDc0DSAgIEdlcm1hbnkNDSAgIFBob25l OiArNDkgOTMxIDMxIDg2NjQ0DSAgIEVtYWlsOiBtZW50aEBpbmZvcm1hdGlrLnVuaS13dWVyemJ1 cmcuZGUNDQ0NBQ0NBQ0NDQ0NDQ1CcmlzY29lLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVh cnkgMTMsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxMl0NDA1BcHBlbmRpeCBBLiBSZWNvbW1l bmRhdGlvbiBmb3IgdGhlIEV4YW1wbGUgTWFwcGluZyBiZXR3ZWVuIEVuY29kaW5nIG9mIFBDTi1N YXJrcyBpbiBJUCBhbmQgaW4gTVBMUyBTaGltIEhlYWRlcnMNDVRoaXMgYXBwZW5kaXggaXMgaW5m b3JtYXRpdmUgbm90IG5vcm1hdGl2ZS4NDVRoZSA4IGJpdHMgb2YgdGhlIERTIGZpZWxkIGluIHRo ZSBJUCBoZWFkZXIgcHJvdmlkZSBmb3IgMjU2IGNvZGVwb2ludHMuIFdoZW4gZW5jYXBzdWxhdGlu ZyBJUCB0cmFmZmljIGluIE1QTFMsIGl0IGlzIHVzZWZ1bCB0byBtYWtlIHRoZSBEUyBmaWVsZCBp bmZvcm1hdGlvbiBhY2Nlc3NpYmxlIGluIHRoZSBNUExTIGhlYWRlci4gSG93ZXZlciwgdGhlIE1Q TFMgc2hpbSBoZWFkZXIgaGFzIG9ubHkgYSAzIGJpdHMgdHJhZmZpYyBjbGFzcyAoVEMpIGZpZWxk IFtSRkM1NDYyXSBwcm92aWRpbmcgZm9yIDggY29kZXBvaW50cy4gVGhlIG9wZXJhdG9yIGhhcyB0 aGUgZnJlZWRvbSB0byBkZWZpbmUgYSBzaXRlLWxvY2FsIG1hcHBpbmcgb2YgYSBzdWJzZXQgb2Yg dGhlIDI1NiBjb2RlcG9pbnRzIG9mIHRoZSBEUyB0byB0aGUgOCBjb2RlcG9pbnRzIGluIHRoZSBU QyBmaWVsZC4gDQ1bUkZDNTEyOV0gZGVzY3JpYmVzIGhvdyBFQ04gbWFya2luZ3MgaW4gdGhlIElQ IGhlYWRlciBjYW4gYmUgbWFwcGVkIHRvIGNvZGVwb2ludHMgaW4gdGhlIE1QTFMgVEMgZmllbGQu IEFwcGVuZGl4IEEgb2YgW1JGQzUxMjldIGdpdmVzIGFuIGluZm9ybWF0aXZlIGRlc2NyaXB0aW9u IG9mIGhvdyB0byBleHRlbmQgdGhlIEVDTiBhcHByb2FjaCBmb3IgTVBMUyB0byBQQ04gbWFya2lu ZyBpbiBNUExTLiBCdXQgW1JGQzUxMjldIHdhcyB3cml0dGVuIHdoaWxlIFBDTiBzcGVjaWZpY2F0 aW9ucyB3ZXJlIGluIGVhcmx5IGRyYWZ0IHN0YWdlcy4gVGhlIGZvbGxvd2luZyBwcm92aWRlcyBh IGNsZWFyZXIgZXhhbXBsZSBvZiBhIG1hcHBpbmcgYmV0d2VlbiBQQ04gaW4gSVAgYW5kIGluIE1Q TFMgdXNpbmcgdGhlIFBDTiB0ZXJtaW5vbG9neSBhbmQgY29uY2VwdHMgdGhhdCBoYXZlIHNpbmNl IGJlZW4gc3BlY2lmaWVkLiANDVRvIHN1cHBvcnQgUENOIGluIGEgTVBMUyBkb21haW4sIGNvZGVw b2ludHMgZm9yIGFsbCB1c2VkIFBDTi1tYXJrcyBuZWVkIHRvIGJlIHByb3ZpZGVkIGluIHRoZSBU QyBmaWVsZC4gVGhhdCBtZWFucywgd2hlbiBvbmx5IGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcgb3Ig b25seSB0aHJlc2hvbGQtbWFya2luZyBpcyB1c2VkIGZvciBQQ04gcHVycG9zZXMsIHRoZSBvcGVy YXRvciBuZWVkcyB0byBkZWZpbmUgYSBzaXRlLWxvY2FsIG1hcHBpbmcgdG8gY29kZXBvaW50cyBp biB0aGUgTVBMUyBUQyBmaWVsZCBmb3IgSVAgaGVhZGVycyB3aXRoIHRoZSBQQ04gYmFzZWxpbmUg ZW5jb2RpbmcgW1JGQzU2OTZdOiANIG8gRFNDUCBuIGFuZCBFQ1QoMCkNIG8gRFNDUCBuIGFuZCBD RQ1JZiBib3RoIGV4Y2Vzcy10cmFmZmljLW1hcmtpbmcgYW5kIHRocmVzaG9sZC1tYXJraW5nIGFy ZSB1c2VkLCB0aGUgb3BlcmF0b3IgbmVlZHMgdG8gZGVmaW5lIGEgc2l0ZS1sb2NhbCBtYXBwaW5n IHRvIGNvZGVwb2ludHMgaW4gdGhlIE1QTFMgVEMgZmllbGQgZm9yIElQIGhlYWRlcnMgd2l0aCB0 aGUgMy1pbi0xIGVuY29kaW5nIG9mIHRoZSBwcmVzZW50IGRvY3VtZW50Og0gbyBEU0NQIG4gYW5k IEVDVCgwKQ0gbyBEU0NQIG4gYW5kIEVDVCgxKQ0gbyBEU0NQIG4gYW5kIENFDQ1JbiBlaXRoZXIg Y2FzZSwgaWYgdGhlIG9wZXJhdG9yIHdpc2hlcyB0byBzdXBwb3J0IHRoZSBzYW1lIERpZmZzZXJ2 IFBIQiBidXQgd2l0aG91dCBQQ04gbWFya2luZywgaXQgd2lsbCBhbHNvIGJlIG5lY2Vzc2FyeSB0 byBkZWZpbmUgYSBzaXRlLWxvY2FsIG1hcHBpbmcgdG8gYW4gTVBMUyBUQyBjb2RlcG9pbnQgZm9y IElQIGhlYWRlcnMgbWFya2VkIHdpdGg6DSBvIERTQ1AgbiBhbmQgTm90LUVDVA0FVGhhdCB3YXMg bXkgk2Zhdm91cml0ZSBkZWJhdGWUIHNvbWUgeWVhcnMgYWdvLiBUaGUgcGNuLWFkbWlzc2libGUt cmF0ZSBtdXN0IGJlIHNtYWxsZXIgdGhhbiB0aGUgcGNuLXN1cHBvcnRhYmxlLXJhdGUsIGJ1dCBh bnl0aGluZyBhYm91dCB0aGUgbWFya2luZyBzdHVmZiBkZXBlbmRzIG9uIHRoZSBlZGdlIGJlaGF2 aW91ci4NDUp1c3Qgc2F5aW5nIHRoYXQgdGhlIGluZm9ybWF0aW9uYWwgUkZDIHNheXMgdGhhdCBl eGNlc3MtdHJhZmZpYy1tYXJraW5nIGlzIG1vcmUgc2V2ZXJlIHRoYW4gdGhyZXNob2xkLW1hcmtp bmcgaXMgZnJvbSBteSBwZXJzcGVjdGl2ZSBub3Qgc3VmZmljaWVudC4gQXJlIHRoZXJlIGdvb2Qg cmVhc29ucyB0byBoYXZlIHRoYXQgb3JkZXI/IEkgZG8gbm90IHNlZSBhbnkgcmVhc29uYWJsZSBl ZGdlIGJlaGF2aW91ciB0aGF0IHdvdWxkIHVzZSAgdGhlIHR3byBtYXJraW5nIHNjaGVtZXMgdGhl IG90aGVyIHdheSBhcm91bmQsIGJ1dCBJIGRvIG5vdCBzZWUgYW55IHJlYXNvbnMgZWl0aGVyIHdo eSB3ZSBuZWVkIHRoaXMgY29uc3RyYWludCB0aGF0IHBvc3NpYmx5IG1pZ2h0IHByb2hpYml0IGZ1 dHVyZSB1c2Ugb2YgcGNuLW1hcmtpbmcgZm9yIGRpZmZlcmVudCBhcHBzLg0FWW91IGNhbiBmb3Jt YXQgbGlzdHMgb2YgcmVmZXJlbmNlcyBsaWtlIHRoaXMgaW4gdGhlIFhNTCBzb3VyY2UgYnkgc3Vw cHJlc3NpbmcgdGhlIFsgXSBsZWF2aW5nIG9ubHkgdGhlIGNvdW50ZXIsIGFuZCB0eXBpbmcgeW91 ciBvd24gWyBdIGluc3RlYWQ6DQ1bPHhyZWYgdGFyZ2V0PSJSRkMzMTY4IiBmb3JtYXQ9ImNvdW50 ZXIiLz4sIA0NZXRjDQVBIGRvbWFpbiBjYW5ub3QgY29tcGx5IHdpdGggZWNuLXR1bm5lbCwgb25s eSBhIHR1bm5lbCBlbmRwb2ludCBjYW4gY29tcGx5Lg0FV2hlbiBJIHNhaWQgeW91ciBhbHRlcm5h dGl2ZSB0ZXh0IHdhcyB1c2VmdWwsIEkgZGlkbid0IHJlYWxpc2UgeW91IGludGVuZGVkIHRvIHJl cGxhY2UgdGhlIHdob2xlIHNlY3Rpb24gSSBoYWQgc3VnZ2VzdGVkLg0NSSBoYXZlIGFsdGVyZWQg dGhlIHRleHQgdG8gbWFrZSBpdCBjbGVhcmVyIHdoYXQgaW1wbGVtZW50ZXJzIG5lZWQgdG8gcHJv dmlkZSBpbiBlYWNoIG5vZGUgaW4gb3JkZXIgZm9yIG9wZXJhdG9ycyB0byBidWlsZCBhIG1peGVk IGRvbWFpbi4NBUV4Y2VsbGVudC4NBUNoYW5nZWQgb3JkZXIgb2Ygcm93cyB0byBtYXRjaCBvcmRl ciBvZiB0ZXh0IGJlbG93Lg0FTmVlZCB0byB1bmRlcnN0YW5kIHRoZSBndWlkZWxpbmVzIG9uIG5v cm1hdGl2ZSBhbmQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcy4gSXQgaXMgbm90aGluZyB0byBkbyB3 aXRoIHdoZXRoZXIgYSByZWZlcmVuY2UgaXMgYW4gUkZDIG9yIG5vdC4gSXQgaXMgdG8gZG8gd2l0 aCB3aGV0aGVyIHRoaXMgZG9jIGVmZmVjdGl2ZWx5IGluY2x1ZGVzIHRoZSB0ZXh0IGJ5IGNpdGlu ZyB0aGUgcmVmZXJlbmNlLg0NQSBnb29kIHRlc3QgaXMgd2hldGhlciB0aGlzIHN0YW5kYXJkIHdv dWxkIGNoYW5nZSBpZiB0aGUgcmVsZXZhbnQgYXNwZWN0IG9mIHRoZSBjaXRlZCBkb2N1bWVudCB3 ZXJlIHRvIGNoYW5nZSAoJ3JlbGV2YW50JyBtZWFuaW5nIHdpdGggcmVzcGVjdCB0byB0aGUgY29u dGV4dCB0aGF0IGl0IGlzIGNpdGVkKS4gIElmIHllcywgaXQncyBub3JtYXRpdmUuDQ1Zb3UgZ2Vu ZXJhbGx5IGdldCB5b3Vyc2VsZiBpbnRvIElFVEYgcHJvY2VzcyB0cm91YmxlcyBpZiB5b3UgbWFr ZSBhIG5vcm1hdGl2ZSBjaXRhdGlvbiB0byBhIGxvd2VyIHJhbmtlZCBkb2N1bWVudCBmcm9tIGEg aGlnaGVyIHJhbmtlZCBkb2N1bWVudC4gSXQgY2FuIGJlIGRvbmUsIGJ1dCB5b3UgaGF2ZSB0byBn byB0aHJvdWdoIHRoZSB1cC1yZWYgcHJvY2Vzcy4NDU5vdGUgdGhhdCBlY24tdHVubmVsIGlzIG5v cm1hdGl2ZSBmb3IgdGhpcyBkb2MsIGJlY2F1c2UgdGhpcyBkb2MgZGVwZW5kcyBvbiBpdC4gVGhh dCdzIE9LIGJlY2F1c2UgZWNuLXR1bm5lbCBpcyBpbnRlbmRlZCBmb3Igc3RhbmRhcmRzIHRyYWNr LiBCdXQgaXQgbWVhbnMgMy1pbi0xIHdpbGwgbm90IGJlIGFibGUgdG8gYmVjb21lIGFuIFJGQyB1 bnRpbCBlY24tdHVubmVsIGhhcy4NDU9uZSBkb2MgYmxvY2tpbmcgd2FpdGluZyBmb3IgYSBub3Jt YXRpdmUgY2l0YXRpb24gdG8gYmVjb21lIFJGQyAgaXMgdmVyeSBjb21tb24gaW4gdGhlIElFVEYg liBpdCdzIHdoeSBtYW55IFJGQ3MgZ28gdGhyb3VnaCBpbiBzZXRzLg0FQWgsIG9rISBJbnRlcmVz dGluZy4gV2UgZGlkIG5vdCBjaGFuZ2UgdGhhdCBpbnRlbnRpb25hbGx5Lg0FRGlkIHlvdSBpbnRl bmQgdG8gZGVsZXRlIHRoZSBNUExTIGd1aWRhbmNlIGFwcGVuZGl4PyBJIHRob3VnaHQgd2UgYm90 aCBhZ3JlZWQgaXQgd291bGQgYmUgdXNlZnVsLg0FTm8sIEkgd2FzIGxvc3QgYnkgYWNjaWRlbnQg d2hlbiBwdXR0aW5nIHRoZSAuZG9jIHRvIC54bWwgYXMgdGhlIHN0dWZmIHdhcyBvbiB0aGUgbGFz dCBwYWdlIG9mIHRoZSBmaWxlLiBJIHJlaW5zZXJ0ZWQgdGhlIHRleHQuDQ0NAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAEIAAACCAAA 8AgAABwJAAArCQAASAkAAIYRAADREQAAbyUAAHclAAB4JQAAiyUAAJMlAACUJQAAFCgAAF8oAACF LQAAui0AAJA0AACTNAAAEjcAABU3AAAaNwAAHjcAACc3AABHNwAAVTcAAHE3AACGNwAA9e7nybSn 55znhnznhnznnOec53zncmheVF5oXlQAAAAAAAAAAAAAAAAAAAAAAAAAEwEIgQRIAgAFaOdy52YW aHVkJgATAQiBBEgCAAVo5XLnZhZodWQmABMBCIEESAIABWjmcudmFmh1ZCYAEwEIgQRIAgAFaORy 52YWaHVkJgATAQiBBEgCAAVo0HLnZhZoika2ACsACIEVaCQS+QAWaCQS+QAXaIpGtgBjSAIAZGgA AAAAZGgAAAAAZGjQcudmFBVoKSz8ABZoJBL5AG1IDARzSAwEABkBCIEESAIABWjOcudmFWgkEvkA FmiKRrYAKQEIAQRIAgAFaM5y52YVaIpGtgAWaIpGtgCJygcBAgDPcudmgyoBDCoHOwAIARVoika2 ABZoJBL5ABdoika2AGNIAgBkaAAAAABkaAAAAABkaM5y52aJygcBAgDPcudmgyoBDCoHDBVoJBL5 ABZoJBL5AAAMFWgkEvkAFmi0Zz0AABMBCIEESAEABWhBdedmFmgkEvkAAB0ABgAAAQgAAAIIAAAD CAAABAgAAE0IAACWCAAA3wgAAFQJAACdCQAA5gkAAC8KAAAwCgAAMQoAAHMKAACoCgAAqQoAALIK AACzCgAA+woAAEQLAACMCwAA0QsAABkMAABiDAAAqwwAAO8MAAD+DAAA/wwAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQAGdkika2AAAEEABnZCks/AAAHAAGAADEfQAAjYcAAP7+ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQEC/wwAAEYNAACHDQAA0A0A ABQOAABbDgAAow4AALAOAACxDgAAxQ4AAMYOAAAHDwAAKw8AACwPAABxDwAAsw8AAPsPAAA4EAAA ORAAAIIQAADKEAAADBEAAEoRAABLEQAAgxEAAIQRAACFEQAAhhEAAM8RAADREQAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABBAAZ2QpLPwAAB3REQAAGhIAABsSAAAcEgAA LRIAAC4SAABxEgAAnBIAAJ0SAADeEgAABxMAAEoTAACKEwAA0xMAABsUAABhFAAApBQAANAUAADR FAAA0hQAAOQUAADlFAAALhUAAHcVAADAFQAACRYAAFIWAACbFgAA5BYAAC0XAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEEABnZCks/AAAHS0XAAB2FwAAsxcAAPwXAABF GAAAfRgAAMYYAAAPGQAARRkAAI4ZAADXGQAAIBoAAGkaAACyGgAA+xoAAEQbAACNGwAA1hsAAB8c AABoHAAAsRwAALIcAACzHAAAtBwAALUcAAC2HAAA/xwAAAEdAABKHQAASx0AAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQQAGdkKSz8AAAdSx0AAEwdAABdHQAAXh0AAKQd AADoHQAALB4AAHUeAAC8HgAABB8AAEwfAACRHwAA1x8AAB0gAABgIAAAfiAAAH8gAADIIAAADiEA AFIhAACYIQAA3CEAACQiAABsIgAAsyIAAPQiAAAzIwAAWCMAAFkjAACdIwAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABBAAZ2QpLPwAAB2dIwAA4SMAACEkAABbJAAAnSQA AN4kAAAmJQAAbCUAAJYlAACXJQAA2iUAACMmAABHJgAASCYAAJEmAADLJgAADicAAFQnAACdJwAA 5ScAABEoAAASKAAAEygAABQoAABdKAAAXygAAKgoAACpKAAAqigAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQQAGdkika2AAAEEABnZCks/AAAHKooAADmKAAA5ygAABkpAAAaKQAA WykAAHEpAAByKQAAkikAAJMpAADcKQAA3SkAACYqAABYKgAAWSoAAHcqAAB4KgAAqioAAKsqAADx KgAANysAAGArAABhKwAAfysAAIArAACyKwAAsysAAOErAAAiLAAAIywAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQQAGdkKSz8AAAdIywAAD8sAABALAAAcCwAAJYsAACX LAAA1CwAANUsAAAaLQAAKC0AACktAABGLQAARy0AAH4tAAB/LQAAmy0AAJwtAACdLQAAni0AAJ8t AACgLQAAoS0AAKItAADrLQAA7S0AADYuAAA3LgAAOC4AAFIuAABTLgAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABBAAZ2QpLPwAAB1TLgAAmi4AAOIuAAAfLwAAIC8AADIv AAAzLwAAeS8AAMEvAAAEMAAAFjAAABcwAABeMAAAejAAAHswAAB8MAAAujAAALswAADSMAAA0zAA ABkxAABcMQAAojEAAOcxAAAwMgAAeDIAAL8yAAAIMwAASDMAAIwzAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEEABnZCks/AAAHYwzAADRMwAAFjQAAF80AACRNAAAkjQA AKo0AADwNAAANzUAAH81AADINQAADjYAAFM2AABUNgAAmDYAAN42AAARNwAAEjcAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAA sgAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcQAEMkAUXG gAAAAgDQcudmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAZ2QpLPwAAAQQAGdkKSz8AAARhjcAAIc3AACQNwAApDcAAMc3AADkNwAA 6DcAAOk3AADrNwAAJTgAACw4AAB1OAAAdzgAAMI4AAANOQAAcTkAAMI5AADDOQAA2EAAANlAAADb QAAA3EAAAN1AAAA1QgAAgEIAAKNDAACmQwAA10MAAPXo9d711PXKtJ60l4yXtJd8l2aXZlSXjJdK lwAAAAAAAAAAABMBCIEESAIABWjvcudmFmgsAsMAIgNqAAAAABZosEHKADBKEgA8CIFPSgAAUUoA AFUIAV5KAAAAKwAIgRVoJBL5ABZoJBL5ABdosEHKAGNIAgBkaAAAAABkaAAAAABkaBlz52YfA2oA AAAAFmi0Zz0AMEoSAE9KAABRSgAAVQgBXkoAABQVaCks/AAWaCQS+QBtSAwEc0gMBAAMFWgkEvkA FmgkEvkAACsACIEVaCQS+QAWaCQS+QAXaIpGtgBjSAIAZGgAAAAAZGgAAAAAZGjRcudmKwAIgRVo JBL5ABZoJBL5ABdoLALDAGNIAgBkaAAAAABkaAAAAABkaO1y52YTAQiBBEgCAAVo5HLnZhZodWQm ABMBCIEESAIABWjucudmFmgsAsMAEwEIgQRIAgAFaOxy52YWaCwCwwAZAQiBBEgCAAVo63LnZhVo JBL5ABZoLALDABMBCIEESAIABWjrcudmFmgsAsMAABsSNwAA6jcAAOs3AAAtOAAAdDgAAHU4AAB2 OAAAdzgAAMA4AADCOAAACzkAAAw5AAC3AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAGoAAAAAAAAA AAAAAABlAAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAGUAAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAA ZQAAAAAAAAAAAAAAAGUAAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQQAGdkKSz8AAAEEABnZIpGtgAARxAAQyQBRcaAAAACAORy52YAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZIpGtgAA RxAAQyQBRcaAAAACAORy52YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZCwCwwAACww5AAANOQAAUzkAAJg5AADCOQAAxDkAAPQ5 AAD1OQAAPDoAAIQ6AADHOgAAEDsAAFg7AACcOwAA1DsAAA88AABKPAAAhTwAAIY8AADLPAAAzDwA AA09AABVPQAAmj0AANM9AADUPQAAGj4AAGM+AAByPgAAcz4AAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQQAGdkKSz8AAAdcz4AALQ+AADDPgAAxD4AAAw/AAANPwAAVT8A AJs/AAC2PwAAtz8AAOI/AADjPwAAK0AAAHBAAAC5QAAAAEEAAEVBAACCQQAAx0EAAAlCAAAyQgAA M0IAADRCAAA1QgAAfkIAAIBCAADJQgAAykIAAMtCAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEEABnZLBBygAABBAAZ2QpLPwAABzLQgAADUMAAFRDAACcQwAACUQAAIREAADqRAAA 60QAAOxEAAASRQAAE0UAAFVFAACcRQAA30UAACJGAABKRgAAk0YAANxGAAAlRwAAbkcAALdHAAAA SAAASUgAAJJIAACTSAAAyEgAAMlIAAAISQAATkkAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAABBAA Z2R/cVoAAAQQAGdkPhhDAAAEEABnZCks/AAAHNdDAADeQwAA5EMAAOZDAADqQwAAA0QAABJEAAAU RAAAFUQAABpEAAAbRAAARkQAAGNEAAB5RAAAkEQAAJFEAACSRAAArEQAALNEAAC9RAAAykQAAM9E AADpRAAA6d/Vy9XE6aONg8R5b1nET0U7b0VvRQAAAAATAQiBBEgCAAVo9XLnZhZoLALDABMBCIEE SAIABWj2cudmFmh/cVoAEwEIgQRIAgAFaPRy52YWaCwCwwArAAiBFWgkEvkAFmgkEvkAF2gsAsMA Y0gCAGRoAAAAAGRoAAAAAGRo83LnZhMBCIEESAIABWj4cudmFmh/cVoAEwEIgQRIAgAFaPNy52YW aCwCwwATAQiBBEgCAAVo8HLnZhZoLALDACsACIEVaCQS+QAWaCQS+QAXaCwCwwBjSAIAZGgAAAAA ZGgAAAAAZGjwcudmQQAIgQNqAAAAABZoLALDABdof3FaADBKEgA8CIFPSgAAUUoAAFUIAV5KAABj SAIAZGgAAAAAZGgAAAAAZGj3cudmDBVoJBL5ABZoJBL5AAATAQiBBEgCAAVoF3PnZhZoPhhDABMB CIEESAIABWj3cudmFmh/cVoAEwEIgQRIAgAFaBZz52YWaD4YQwArAAiBFWgkEvkAFmgkEvkAF2h/ cVoAY0gCAGRoAAAAAGRoAAAAAGRo93LnZgAWTkkAAHtJAAB8SQAAwEkAAOtJAADsSQAANUoAAE5K AABPSgAAl0oAAL5KAAC/SgAABUsAADlLAAA6SwAAO0sAAH5LAAB/SwAAxUsAANxLAADdSwAA3ksA AN9LAADgSwAAKUwAACtMAAB0TAAAdUwAAHZMAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEEABnZLBBygAABBAAZ2QpLPwAABzpRAAAsUsAALJLAABBUAAAQlAAAFtQAACAUAAAklAA AKBQAADLUAAA71AAABFRAAAyUQAANFEAAMtRAABGUgAATFIAAFNSAAAGUwAAD1MAABpTAABmUwAA +eP5y8G3qregk4mqf2liaX9iW1FHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwEI gQRIAgAFaCNz52YWaE4M5gATAQiBBEgCAAVoInPnZhZoTgzmAAwVaAcBFwAWaAcBFwAADBVoJBL5 ABZoBwEXAAArAAiBFWgkEvkAFmgHARcAF2gDTIQAY0gCAGRoAAAAAGRoAAAAAGRoQXPnZhMBCIEE SAIABWhBc+dmFmgHARcAEwEIgQRIAgAFaEBz52YWaAcBFwAZAQiBBEgCAAVoQHPnZhVoJBL5ABZo BwEXABMBCIEESAIABWg7c+dmFmgHARcAGQEIgQRIAgAFaDpz52YVaCQS+QAWaAcBFwATAQiBBEgC AAVoOnPnZhZoBwEXABMBCIEESAIABWg5c+dmFmgHARcALwEIgQNqAAAAAARIAgAFaClz52YWaE4M 5gAwShIAPAiBT0oAAFFKAABVCAFeSgAAKwAIgRVoJBL5ABZoJBL5ABdosEHKAGNIAgBkaAAAAABk aAAAAABkaB9z52YMFWgkEvkAFmgkEvkAFXZMAAC/TAAA2UwAANpMAAAcTQAASU0AAEpNAACTTQAA t00AALhNAADcTQAA3U0AAAtOAAAMTgAAUk4AAJlOAADXTgAA2E4AANlOAAD0TgAA9U4AAD5PAACE TwAAhU8AAMhPAADJTwAAEVAAAEBQAABBUAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQQAGdkKSz8AAAcQVAAAHtRAAClUQAA7VEAADFSAAB5UgAAwVIAAANTAAAO UwAAD1MAAKpTAADzUwAATVQAAE5UAAD5AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAA AAAAAAAAAACiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEcQAEMkAUXGgAAAAgAoc+dmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2RODOYAAAQQAGdkszW3AAAEEABnZCks/AAA BBAAZ2QHARcABhAAQyQBZ2QHARcAAA1mUwAAi1MAABVUAAAWVAAAKlQAACtUAAA3VAAATlQAAE9U AABRVAAAVFQAAFhUAABbVAAAXFQAAGBUAABhVAAAYlQAAGdUAABsVAAAcFQAAHFUAAB+VAAAtlQA ALdUAADAVAAA6eLYztjO2LjirpiOgeKY4mthV0ph4kDiAAAAABMBCIEESAIABWgxc+dmFmizNbcA GQEIgQRIAgAFaCRz52YVaCQS+QAWaE4M5gATAQiBBEgCAAVoJHPnZhZoTgzmABMBCIEESAIABWgw c+dmFmizNbcAKwAIgRVoJBL5ABZoJBL5ABdoTgzmAGNIAgBkaAAAAABkaAAAAABkaCRz52YZAQiB BEgCAAVoL3PnZhVoJBL5ABZoszW3ABMBCIEESAIABWgvc+dmFmizNbcAKwAIgRVoJBL5ABZoJBL5 ABdoszW3AGNIAgBkaAAAAABkaAAAAABkaC9z52YTAQiBBEgCAAVoLXPnZhZoszW3ACsACIEVaCQS +QAWaCQS+QAXaE4M5gBjSAIAZGgAAAAAZGgAAAAAZGgoc+dmEwEIgQRIAgAFaCtz52YWaLM1twAT AQiBBEgCAAVoKHPnZhZoTgzmAAwVaCQS+QAWaCQS+QAAKwAIgRVoJBL5ABZoJBL5ABdoTgzmAGNI AgBkaAAAAABkaAAAAABkaCNz52YAGE5UAACQVAAA8FQAAD1VAABTVQAAtwAAAAAAAAAAAAAAALIA AAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAA Z2RODOYAAEcQAEMkAUXGgAAAAgAkc+dmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2RODOYAAAQQAGdkszW3AABHEABDJAFFxoAA AAIAKHPnZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdkszW3AAAEwFQAAMRUAADLVAAA2VQAAOVUAADsVAAA7VQAAAhVAAAjVQAA J1UAADxVAABPVQAAUlUAAFlVAABiVQAAaFUAAG5VAAB/VQAAgFUAAIRVAACHVQAAjlUAAJNVAACV VQAAm1UAAKFVAACiVQAAo1UAAL1VAADKVQAAzlUAAOnf1c7VzunO1cS3zq2jmaPOg85txM6ZxM6D zldNzhMBCIEESAIABWgmc+dmFmhODOYAKwAIgRVoJBL5ABZoJBL5ABdoTgzmAGNIAgBkaAAAAABk aAAAAABkaCZz52YrAAiBFWgkEvkAFmgkEvkAF2hODOYAY0gCAGRoAAAAAGRoAAAAAGRoJXPnZisA CIEVaCQS+QAWaCQS+QAXaLM1twBjSAIAZGgAAAAAZGgAAAAAZGgwc+dmEwEIgQRIAgAFaDBz52YW aLM1twATAQiBBEgCAAVoLnPnZhZoszW3ABMBCIEESAIABWgtc+dmFmizNbcAGQEIgQRIAgAFaCRz 52YVaCQS+QAWaE4M5gATAQiBBEgCAAVoJXPnZhZoTgzmAAwVaCQS+QAWaCQS+QAAEwEIgQRIAgAF aCRz52YWaE4M5gATAQiBBEgCAAVoL3PnZhZoszW3ACsACIEVaCQS+QAWaCQS+QAXaE4M5gBjSAIA ZGgAAAAAZGgAAAAAZGgkc+dmAB5TVQAAVFUAAIFVAADjVQAAMVYAAEJWAABEVgAARVYAAEZWAABH VgAASFYAALcAAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAGoAAAAAAAAAAAAA AABfAAAAAAAAAAAAAAAAWgAAAAAAAAAAAAAAAFoAAAAAAAAAAAAAAABaAAAAAAAAAAAAAAAAWgAA AAAAAAAAAAAAAFoAAAAAAAAAAAAAAAAAAAAAAAAABBAAZ2QpLPwACxAAZ2QDTIQAb8YHAQIAOHPn ZmQmAQAEEABnZLM1twAARxAAQyQBRcaAAAACAC1z52YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZLM1twAARxAAQyQBRcaAAAAC AC1z52YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABnZE4M5gAACs5VAADTVQAA81UAAPdVAAAUVgAAGVYAABtWAAAcVgAAQlYAAENW AABEVgAAlFYAACdYAAC3WAAAuFgAALpYAAADWQAAJ1oAAHBaAAACWwAA218AAPpfAABBYAAAjGAA AGZlAADp4tjiwrir4pvikOKDa4NV4oNV4krikOIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUFWiK RrYAFmgkEvkAbUgQBHNIEAQAKwAIgRVoJBL5ABZoJBL5ABdoBwEXAGNIAgBkaAAAAABkaAAAAABk aEhz52YvAQiBA2oAAAAABEgCAAVoSHPnZhZoBwEXADBKEgA8CIFPSgAAUUoAAFUIAV5KAAAZAQiB BEgCAAVoSHPnZhVoJBL5ABZoBwEXABQVaIpGtgAWaCQS+QBtSAwEc0gMBAAfA2oAAAAAFmheS9AA MEoSAE9KAABRSgAAVQgBXkoAABkBCIEESAIABWgxc+dmFWgkEvkAFmizNbcAEwEIgQRIAgAFaDFz 52YWaLM1twArAAiBFWgkEvkAFmgkEvkAF2izNbcAY0gCAGRoAAAAAGRoAAAAAGRoMXPnZhMBCIEE SAIABWgmc+dmFmhODOYADBVoJBL5ABZoJBL5AAArAAiBFWgkEvkAFmgkEvkAF2hODOYAY0gCAGRo AAAAAGRoAAAAAGRoJnPnZgAYSFYAAElWAACSVgAAlFYAAN1WAADeVgAA31YAABlXAAAaVwAATFcA AJVXAADeVwAAJ1gAAHBYAAC6WAAAA1kAAExZAACVWQAA3lkAACdaAABwWgAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAALIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARxAAQyQBRcaAAAACAEhz52YAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABn ZAcBFwAABBAAZ2QpLPwAABRwWgAAuVoAAAJbAABLWwAATFsAAIVbAACGWwAAzFsAAABcAAABXAAA QlwAAENcAACMXAAAz1wAANxcAADdXAAACl0AAAtdAABSXQAAlV0AANpdAAAMXgAADV4AADVeAAA2 XgAAel4AALxeAAAEXwAATF8AAJJfAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEEABnZCks/AAAHZJfAADYXwAA+F8AAPlfAAD6XwAAEmAAABNgAAA9YAAAPmAAAD9gAABA YAAAQWAAAIpgAACMYAAA1WAAANZgAADXYAAAH2EAACdhAAAoYQAAKWEAAEVhAABGYQAAjmEAANFh AAAZYgAAYmIAAKdiAADtYgAA92IAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA AAAAAAQQAGdkKSz8AAAd92IAAPhiAAA7YwAAfWMAAMRjAAD2YwAA92MAAPhjAAAIZAAACWQAAFFk AACVZAAA3WQAACRlAAB0ZQAAp2UAAMdlAADIZQAAyWUAAN9lAADgZQAAJWYAADdmAAA4ZgAAOWYA AFFmAABSZgAAmGYAAN9mAAAmZwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABBAAZ2QpLPwAAB1mZQAAb2UAAKplAADJZQAAEmoAABNqAACCawAAg2sAAKRsAADRbAAAbG0A AIxtAAD7bgAA3XEAAChyAAAucwAA9nMAAKd1AADTdQAA1HUAANZ1AADXdQAA9nUAACl2AAA1dgAA 9e7j7tG7q+6eke6E7nnuY+55UXmree5DAAAAAAAAAAAAABsBCIEESAEABWhTdedmFmheS9AAbUgJ BHNICQQiA2oAAAAAFmg7fdoAMEoSADwIgU9KAABRSgAAVQgBXkoAAAArAAiBFWgkEvkAFmgkEvkA F2hpOmUAY0gCAGRoAAAAAGRoAAAAAGRoU3PnZhQVaIpGtgAWaCQS+QBtSAwEc0gMBAAZAQiBBEgC AAVoUnPnZhVoJBL5ABZoaTplABkBCIEESAIABWhTc+dmFWgkEvkAFmhpOmUAGQEIgQRIAgAFaFNz 52YVaGk6ZQAWaGk6ZQAfA2oAAAAAFmheS9AAMEoSAE9KAABRSgAAVQgBXkoAACsACIEVaCQS+QAW aCQS+QAXaGk6ZQBjSAIAZGgAAAAAZGgAAAAAZGhSc+dmIgNqAAAAABZoaTplADBKEgA8CIFPSgAA UUoAAFUIAV5KAAAAFBVoika2ABZoJBL5AG1IEARzSBAEAAwVaCQS+QAWaCQS+QAAEwEIgQRIAgAF aElz52YWaAcBFwAAGCZnAAA2ZwAAN2cAADhnAABIZwAASWcAAEpnAABLZwAATGcAAE1nAACWZwAA mGcAAOFnAADiZwAA42cAAP9nAAAAaAAAQmgAAINoAACEaAAAw2gAAAZpAABEaQAAYWkAAGJpAACp aQAA6WkAABFqAAASagAAVWoAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQQAGdkKSz8AAAdVWoAAJBqAACRagAA2GoAABBrAAARawAAT2sAAIFrAACCawAAxmsAAPVrAAD2 awAAOGwAAH1sAACkbAAAw2wAAAFtAABGbQAAa20AAGxtAABtbQAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAACyAAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARxAAQyQBRcaAAAACAFNz52YAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZGk6ZQAA BBAAZ2QpLPwAABRtbQAAi20AAIxtAADObQAACW4AAApuAABRbgAAiW4AAIpuAADIbgAA+m4AAPtu AAAfbwAAZ28AAK1vAADZbwAAH3AAADhwAAA5cAAAX3AAAKJwAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAA AACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABHEABDJAFFxoAAAAIAUnPnZgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkaTplAAAE EABnZCks/AAAFKJwAADqcAAADnEAAFZxAABwcQAAcXEAAJVxAADacQAA23EAANxxAADdcQAAJnIA AChyAABxcgAAcnIAAHNyAAC6cgAAAHMAAC1zAAAucwAATXMAAItzAADQcwAA9XMAAPZzAAD3cwAA CnQAAAt0AAAadAAAIHQAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQQ AGdkKSz8AAAdIHQAADl0AABNdAAAYXQAAGd0AABodAAAgnQAAJ90AADAdAAAwXQAAMJ0AADUdAAA 43QAAOR0AAABdQAAAnUAAAN1AAAUdQAAL3UAAFt1AABpdQAAfXUAAIh1AACJdQAApHUAANB1AADR dQAA0nUAANN1AADVdQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABBAA Z2QpLPwAAB3VdQAA1nUAANh1AADZdQAA2nUAANt1AADcdQAA3XUAAN51AAAndgAAKXYAAJl2AACa dgAAxnYAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAJwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOEABDJAFFxoAAAAIAc53nJgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AGdkeQPvAG/GBwECAHOd5yZkJgEABBAAZ2ReS9AACxAAZ2R5A+8Ab8YHAQIAdJ3nJmQmAQAEEABn ZCks/AAADTV2AABMdgAAZHYAAH12AACHdgAAmnYAAMd2AACBeAAApHgAAOh4AAABeQAAJXkAAER5 AABIeQAATHkAAFt5AABjeQAAoHkAALN5AAC0eQAAtXkAAAh6AADi1MbUxrjGqpyOgHJkcmRWckic OkgAAAAAAAAAGwEIgQRIAgAFaIOd5yYWaLZ8tgBtSAkEc0gJBBsBCIEESAIABWiBnecmFmi2fLYA bUgJBHNICQQbAQiBBEgCAAVoip3nJhZo6DrvAG1ICQRzSAkEGwEIgQRIAgAFaImd5yYWaOg67wBt SAkEc0gJBBsBCIEESAIABWiAnecmFmi2fLYAbUgJBHNICQQbAQiBBEgCAAVoiZ3nJhZotny2AG1I CQRzSAkEGwEIgQRIAgAFaHud5yYWaLZ8tgBtSAkEc0gJBBsBCIEESAIABWh3necmFmh5A+8AbUgJ BHNICQQbAQiBBEgCAAVodp3nJhZoeQPvAG1ICQRzSAkEGwEIgQRIAgAFaHOd5yYWaHkD7wBtSAkE c0gJBBsBCIEESAEABWhTdedmFmheS9AAbUgJBHNICQQbAQiBBEgCAAVodJ3nJhZoeQPvAG1ICQRz SAkEOgAIgQEIgQRIAQAFaFN152YWaF5L0AAXaHkD7wBjSAIAZGgAAAAAZGgAAAAAZGh0necmbUgJ BHNICQQVxnYAAMd2AACAeAAAgXgAAFB6AABRegAAqXsAAL57AADPewAApHwAALl8AAC3AAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAAWQAAAAAAAAAAAAAA AFkAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAA AAAAAAAAAAAAAAAAAE4QAEMkAUXGgAAAAgCCnecmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2S2fLYAb8YHAQIAgp3nJmQmAQsQ AGdk6DrvAG/GBwECAIqd5yZkJgEABBAAZ2ReS9AAAEcQAEMkAUXGgAAAAgBznecmAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Re S9AAAAoIegAAEnoAACJ6AABNegAAT3oAAFF6AABMewAAb3sAAHJ7AACCewAApnsAAKd7AABAfAAA Y3wAAGZ8AAB2fAAAonwAAKN8AADffAAA4HwAAPB8AABBfQAARH0AAEl9AABlfQAAfX0AAJV9AACf fQAAoH0AAKF9AACsfQAAw30AAMR9AADFfQAANIAAADWAAAD5gAAA+oAAAEWBAABGgQAA8ePx4/HV x9W5q7nVudW5q7nVoZeNl42Xg5eDeYN5l3JoZGhkaGRoAAYWaLZ8tgAAEwNqAAAAABZotny2ADBK EgBVCAEMFWgkEvkAFmi2fLYAABMBCIEESAIABWiLnecmFmjoOu8AEwEIgQRIAgAFaIid5yYWaLZ8 tgATAQiBBEgCAAVoh53nJhZotny2ABMBCIEESAIABWiGnecmFmi2fLYAEwEIgQRIAgAFaIad5yYW aCQS+QAbAQiBBEgCAAVohZ3nJhZotny2AG1ICQRzSAkEGwEIgQRIAgAFaISd5yYWaLZ8tgBtSAkE c0gJBBsBCIEESAIABWiDnecmFmi2fLYAbUgJBHNICQQbAQiBBEgBAAVoU3XnZhZoXkvQAG1ICQRz SAkEGwEIgQRIAgAFaIGd5yYWaLZ8tgBtSAkEc0gJBBsBCIEESAIABWiCnecmFmi2fLYAbUgJBHNI CQQAJ7l8AADOfAAA33wAAOB8AACufQAAxH0AAH9+AACAfgAANIAAAMaAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAAWQAAAAAAAAAAAAAAAFcAAAAA AAAAAAAAAABXAAAAAAAAAAAAAAAAVwAAAAAAAAAAAAAAAFIAAAAAAAAAAAAAAAAAAAAAAAAAAAQT AGdksEHKAAABEwBOEABDJAFFxoAAAAIAhp3nJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdktny2AG/GBwECAIad5yZkJgELEABn ZOg67wBvxgcBAgCLnecmZCYBAEcQAEMkAUXGgAAAAgCGnecmAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QpLPwAAAQQAGdkXkvQ AAAJxoAAAMeAAAD0gAAA9YAAAPmAAABFgQAAwIEAAMGBAABLggAAV4IAAIyCAABwgwAAcYMAADuE AAA8hAAADIUAAA2FAADnhQAA6IUAAG2GAACphgAADIcAAIyHAACNhwAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAA AAAAAAAA6wAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAA AN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADaAAAA AAAAAAAAAAAA2gAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA2gAAAAAAAAAA AAAAAOQAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAEEwBnZDt92gAABBMAZ2Rp OmUAAAETAAAEEwBnZLM1twAABBMAZ2RODOYAAAQTAGdkBwEXAAAEEwBnZCwCwwAABBMAZ2SwQcoA ABdGgQAAEYIAABaCAABLggAATIIAAFeCAABYggAAjIIAAI2CAABthgAAboYAAKmGAACqhgAADIcA AA2HAACMhwAAjYcAAI6HAAD88vzo/Oj86Pzo/Oj86Pzk3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBVoJBL5ABZotny2 AAAGFmjoOu8AABMDagAAAAAWaLZ8tgAwShIAVQgBEhVoszW3ABZotny2ADYIgV0IgQAGFmi2fLYA EY2HAACOhwAAsQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAE4QAEMkAUXGgAAAAgCGnecmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2S2fLYAb8YHAQIAhp3nJmQmAQAB MgAxkGgBOnApLPwAH7CCLiCwxkEhsIAEIrCABCOQoAUkkKAFJbAAABewxAIYsMQCDJDEAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAXABIAAQCc AA8AAwAAAAMAAAAAAEQAAEDx/wIARAAMEAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAcAENK GABfSAEEYUoYAG1ICQhuSAQIc0gJCHRIBAgAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAEA AAAAAAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAA UgBpQPP/swBSAAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTW BgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwA aQBzAHQAAAACAAwAAAAAAIAA/g/EAPEAgAAAAAAAUizuAAAAMQBTAHQAeQBsAGUAIABOAHUAbQBi AGUAcgBlAGQAIABCAGUAZgBvAHIAZQA6ACAAIAAwAC4ANwA0ACAAYwBtACAASABhAG4AZwBpAG4A ZwA6ACAAIAAwAC4ANgAzACAAYwBtAAAABgAPAAtGAQBEAFpAAQACAUQADAAWAMBuiwAAAAoAUABs AGEAaQBuACAAVABlAHgAdAAAAAIAEAAUAENKFABPSgQAUUoEAF5KBABhShQASACZQAEAEgFIAAwB AACKRrYAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgARABQAQ0oQAE9KBQBRSgUAXkoF AGFKEABCACdAogAhAUIADAEAAIpGtgAAABEAQwBvAG0AbQBlAG4AdAAgAFIAZQBmAGUAcgBlAG4A YwBlAAAACABDShAAYUoQADwAHkABADIBPAAMAQAAika2AAAADABDAG8AbQBtAGUAbgB0ACAAVABl AHgAdAAAAAIAEwAIAENKFABhShQAQABqADEBMgFAAAwBAACKRrYAAAAPAEMAbwBtAG0AZQBuAHQA IABTAHUAYgBqAGUAYwB0AAAAAgAUAAYANQiBXAiBiABlQAEAUgGIAAwAAAB1ZCYAAAARAEgAVABN AEwAIABQAHIAZQBmAG8AcgBtAGEAdAB0AGUAZAAAADcAFQANxjIAEJQDKAe8ClAO5BF4FQwZoBw0 IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAAAUAENKFABPSgQAUUoEAF5KBABhShQAPgD+ T6IAYQE+AAwAEABeS9AAAAAFACAAQwBoAGEAcgAAABwAT0oEAFFKBABeSgQAbUgJCG5IBAhzSAkI dEgECB0ATABlAGgAcgBzAHQAdQBoAGwAIABmAHUAZQByACAASQBuAGYAbwByAG0AYQB0AGkAawAg AEkASQBJAAsAQgBvAGIAIABCAHIAaQBzAGMAbwBlAMIxAADcOAAAFDwAAEFIAABCTgAAt1AAABJi AACCYwAA020AANZtAACOfwAABABMAGYASQBJAAAAAAAAAAAAAAAAAAAAAACNpOgPAwBSAEoAQgAA AAAAAAAAAAAAAAABAAAAAAAsK+gPAwBSAEoAQgAAAAAAAAAAAAAAAAABAAAAAAD/////AwBSAEoA QgAAAAAAAAAAAAAAAAABAAAAAAD/////BABMAGYASQBJAAAAAAAAAAAAAAAAAAAAAAAQp+gPAwBS AEoAQgAAAAAAAAAAAAAAAAABAAAAAAD/////AwBSAEoAQgAAAAAAAAAAAAAAAAABAAAAAAD///// BABMAGYASQBJAAAAAAAAAAAAAAAAAAAAAACrp+gPAwBSAEoAQgAAAAAAAAAAAAAAAAABAAAAAAD/ ////BABMAGYASQBJAAAAAAAAAAAAAAAAAAAAAABeqOgPSHXnZgAAAAAAAAAAAAAAAAAAX3PnZgAA AAAAAAAAAAAAAAAAX3PnZgAAAAAAAAAAAAAAAAAAX3PnZgAAAAAAAAAAAAAAAAAATXXnZgAAAAAA AAAAAAAAAAAAX3PnZgAAAAAAAAAAAAAAAAAAUHXnZgAAAAAAAAAAAAAAAAAAUXXnZgAAAAAAAAAA AAAAAAAAYHPnZgAAAAAAAAAAAAAAAAAAVHXnZgAAAAAAAAAAAAAAAAAAAAAAAHACAAA1AwAAgQMA AIcEAACTBAAAyAQAAKkIAADlCAAASAkAAMgJAADLCQAAAAAAAI5/AAAIAADiAAAHAP////8AAAAA AQAAAAIAAAADAAAABAAAAE0AAACWAAAA3wAAAFQBAACdAQAA5gEAAC8CAAAwAgAAMQIAAHMCAACo AgAAqQIAALICAACzAgAA+wIAAEQDAACMAwAA0QMAABkEAABiBAAAqwQAAO8EAAD+BAAA/wQAAEYF AACHBQAA0AUAABQGAABbBgAAowYAALAGAACxBgAAxQYAAMYGAAAHBwAAKwcAACwHAABxBwAAswcA APsHAAA4CAAAOQgAAIIIAADKCAAADAkAAEoJAABLCQAAgwkAAIQJAACFCQAAhgkAAM8JAADRCQAA GgoAABsKAAAcCgAALQoAAC4KAABxCgAAnAoAAJ0KAADeCgAABwsAAEoLAACKCwAA0wsAABsMAABh DAAApAwAANAMAADRDAAA0gwAAOQMAADlDAAALg0AAHcNAADADQAACQ4AAFIOAACbDgAA5A4AAC0P AAB2DwAAsw8AAPwPAABFEAAAfRAAAMYQAAAPEQAARREAAI4RAADXEQAAIBIAAGkSAACyEgAA+xIA AEQTAACNEwAA1hMAAB8UAABoFAAAsRQAALIUAACzFAAAtBQAALUUAAC2FAAA/xQAAAEVAABKFQAA SxUAAEwVAABdFQAAXhUAAKQVAADoFQAALBYAAHUWAAC8FgAABBcAAEwXAACRFwAA1xcAAB0YAABg GAAAfhgAAH8YAADIGAAADhkAAFIZAACYGQAA3BkAACQaAABsGgAAsxoAAPQaAAAzGwAAWBsAAFkb AACdGwAA4RsAACEcAABbHAAAnRwAAN4cAAAmHQAAbB0AAJYdAACXHQAA2h0AACMeAABHHgAASB4A AJEeAADLHgAADh8AAFQfAACdHwAA5R8AABEgAAASIAAAEyAAABQgAABdIAAAXyAAAKggAACpIAAA qiAAAOYgAADnIAAAGSEAABohAABbIQAAcSEAAHIhAACSIQAAkyEAANwhAADdIQAAJiIAAFgiAABZ IgAAdyIAAHgiAACqIgAAqyIAAPEiAAA3IwAAYCMAAGEjAAB/IwAAgCMAALIjAACzIwAA4SMAACIk AAAjJAAAPyQAAEAkAABwJAAAliQAAJckAADUJAAA1SQAABolAAAoJQAAKSUAAEYlAABHJQAAfiUA AH8lAACbJQAAnCUAAJ0lAACeJQAAnyUAAKAlAAChJQAAoiUAAOslAADtJQAANiYAADcmAAA4JgAA UiYAAFMmAACaJgAA4iYAAB8nAAAgJwAAMicAADMnAAB5JwAAwScAAAQoAAAWKAAAFygAAF4oAAB6 KAAAeygAAHwoAAC6KAAAuygAANIoAADTKAAAGSkAAFwpAACiKQAA5ykAADAqAAB4KgAAvyoAAAgr AABIKwAAjCsAANErAAAWLAAAXywAAJEsAACSLAAAqiwAAPAsAAA3LQAAfy0AAMgtAAAOLgAAUy4A AFQuAACYLgAA3i4AABEvAAASLwAA6i8AAOsvAAAtMAAAdDAAAHUwAAB2MAAAdzAAAMAwAADCMAAA CzEAAAwxAAANMQAAUzEAAJgxAADCMQAAxDEAAPQxAAD1MQAAPDIAAIQyAADHMgAAEDMAAFgzAACc MwAA1DMAAA80AABKNAAAhTQAAIY0AADLNAAAzDQAAA01AABVNQAAmjUAANM1AADUNQAAGjYAAGM2 AAByNgAAczYAALQ2AADDNgAAxDYAAAw3AAANNwAAVTcAAJs3AAC2NwAAtzcAAOI3AADjNwAAKzgA AHA4AAC5OAAAADkAAEU5AACCOQAAxzkAAAk6AAAyOgAAMzoAADQ6AAA1OgAAfjoAAIA6AADJOgAA yjoAAMs6AAANOwAAVDsAAJw7AAAJPAAAhDwAAOo8AADrPAAA7DwAABI9AAATPQAAVT0AAJw9AADf PQAAIj4AAEo+AACTPgAA3D4AACU/AABuPwAAtz8AAABAAABJQAAAkkAAAJNAAADIQAAAyUAAAAhB AABOQQAAe0EAAHxBAADAQQAA60EAAOxBAAA1QgAATkIAAE9CAACXQgAAvkIAAL9CAAAFQwAAOUMA ADpDAAA7QwAAfkMAAH9DAADFQwAA3EMAAN1DAADeQwAA30MAAOBDAAApRAAAK0QAAHREAAB1RAAA dkQAAL9EAADZRAAA2kQAABxFAABJRQAASkUAAJNFAAC3RQAAuEUAANxFAADdRQAAC0YAAAxGAABS RgAAmUYAANdGAADYRgAA2UYAAPRGAAD1RgAAPkcAAIRHAACFRwAAyEcAAMlHAAARSAAAQEgAAEFI AAB7SQAApUkAAO1JAAAxSgAAeUoAAMFKAAADSwAADksAAA9LAACqSwAA80sAAE1MAABOTAAAkEwA APBMAAA9TQAAU00AAFRNAACBTQAA400AADFOAABCTgAARE4AAEVOAABGTgAAR04AAEhOAABJTgAA kk4AAJROAADdTgAA3k4AAN9OAAAZTwAAGk8AAExPAACVTwAA3k8AACdQAABwUAAAulAAAANRAABM UQAAlVEAAN5RAAAnUgAAcFIAALlSAAACUwAAS1MAAExTAACFUwAAhlMAAMxTAAAAVAAAAVQAAEJU AABDVAAAjFQAAM9UAADcVAAA3VQAAApVAAALVQAAUlUAAJVVAADaVQAADFYAAA1WAAA1VgAANlYA AHpWAAC8VgAABFcAAExXAACSVwAA2FcAAPhXAAD5VwAA+lcAABJYAAATWAAAPVgAAD5YAAA/WAAA QFgAAEFYAACKWAAAjFgAANVYAADWWAAA11gAAB9ZAAAnWQAAKFkAAClZAABFWQAARlkAAI5ZAADR WQAAGVoAAGJaAACnWgAA7VoAAPdaAAD4WgAAO1sAAH1bAADEWwAA9lsAAPdbAAD4WwAACFwAAAlc AABRXAAAlVwAAN1cAAAkXQAAdF0AAKddAADHXQAAyF0AAMldAADfXQAA4F0AACVeAAA3XgAAOF4A ADleAABRXgAAUl4AAJheAADfXgAAJl8AADZfAAA3XwAAOF8AAEhfAABJXwAASl8AAEtfAABMXwAA TV8AAJZfAACYXwAA4V8AAOJfAADjXwAA/18AAABgAABCYAAAg2AAAIRgAADDYAAABmEAAERhAABh YQAAYmEAAKlhAADpYQAAEWIAABJiAABVYgAAkGIAAJFiAADYYgAAEGMAABFjAABPYwAAgWMAAIJj AADGYwAA9WMAAPZjAAA4ZAAAfWQAAKRkAADDZAAAAWUAAEZlAABrZQAAbGUAAG1lAACLZQAAjGUA AM5lAAAJZgAACmYAAFFmAACJZgAAimYAAMhmAAD6ZgAA+2YAAB9nAABnZwAArWcAANlnAAAfaAAA OGgAADloAABfaAAAomgAAOpoAAAOaQAAVmkAAHBpAABxaQAAlWkAANppAADbaQAA3GkAAN1pAAAm agAAKGoAAHFqAAByagAAc2oAALpqAAAAawAALWsAAC5rAABNawAAi2sAANBrAAD1awAA9msAAPdr AAAKbAAAC2wAABpsAAAgbAAAOWwAAE1sAABhbAAAZ2wAAGhsAACCbAAAn2wAAMBsAADBbAAAwmwA ANRsAADjbAAA5GwAAAFtAAACbQAAA20AABRtAAAvbQAAW20AAGltAAB9bQAAiG0AAIltAACkbQAA 0G0AANFtAADSbQAA020AANVtAADWbQAA2G0AANltAADabQAA220AANxtAADdbQAA3m0AACduAAAp bgAAmW4AAJpuAADGbgAAx24AAIBwAACBcAAAUHIAAFFyAACpcwAAvnMAAM9zAACkdAAAuXQAAM50 AADfdAAA4HQAAK51AADEdQAAf3YAAIB2AAA0eAAAxngAAMd4AAD0eAAA9XgAAPl4AABFeQAAwHkA AMF5AABLegAAV3oAAIx6AABwewAAcXsAADt8AAA8fAAADH0AAA19AADnfQAA6H0AAG1+AACpfgAA DH8AAIx/AACPfwAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAgAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAACACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAIAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAACACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA CACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAI AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAACACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAACACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQ MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAA AAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAA ABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAA EACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQ AJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAA mAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACY AAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgA AAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAEDAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAA ABAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAQMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAA EDAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmkAAABMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAT MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAEzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABMw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAATMAAAAAAAAACAAAAAgAAAuAaeAFQOAASYQAAAEzAA AAAAAAAAgAAAAIAAALgGngBUDgAEmEAAABMwAAAAAAAAAIAAAACAAAC4Bp4AVA4ABJhAAAATMAAA AAAAAACAAAAAgAAAuAaeAFQOAASYQAAAEzAAAAAAAAAAgAAAAIAAALgGngBUDgAEmEAAABMwAAAA AAAAAIAAAACAAAC4Bp4AVA4ABJhAAAATMAAAAAAAAACAAAAAgAAAuAaeAFQOAASYQAAAEzAAAAAA AAAAgAAAAIAAALgGngBUDgAEmEAAABMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAATMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYQAAAEzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABMwAAAAAAAA AIAAAACAAAC4Bp4AVA4ABJhAAAATMAAAAAAAAACAAAAAgAAAuAaeAFQOAASYQAAAEzAAAAAAAAAA gAAAAIAAALgGngBUDgAEmEAAABMwAAAAAAAAAIAAAACAAAC4Bp4AVA4ABJhAAAATMAAAAAAAAACA AAAAgAAAuAaeAFQOAASYQAAAEzAAAAAAAAAAgAAAAIAAALgGngBUDgAEmEAAABMwAAAAAAAAAIAA AACAAAC4Bp4AVA4ABJhAAAATMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAEzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAABMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAATMAAAAAAAAACAAAAA gAAAAAAAAAAAAAAKAAAAADAAAAAAAAAAAAAAAAAAAKSUMAUcAAAHAAAAANxtAADdbQAA3m0AACdu AAApbgAAmW4AAJpuAADGbgAAx24AAIBwAACBcAAAUHIAAFFyAACpcwAAvnMAAM9zAACkdAAAuXQA AM50AADfdAAA4HQAAK51AADEdQAAj38AAE05ATAAMAAAAAAAAAEAAAABAAAAPAueAHgkMAdNOQEw ADAAAAAAAAABAAAAAQAAAAAIAAAAAAABTTkBMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAAAU05ATAA MAAAAAAAAAEAAAABAAAAAAgAAAAAAAFNOQEwADAAAAAAAAACAAAAAQAAAAAIAAAAAAABAEAAAAAw AAAAAAAAAAD/////AAAAAAAAAAAQB005ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAkAdNOQEwADAA AAAAAAABAAAAAQAAAAAAAAAAAJABTTkBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACQAU05ATAAMAAA AAAAAAEAAAABAAAAAAAAAAAAkAFNOQEwADAAAAAAAAABAAAAAQAAAAAAAAAAAJABTTkBMAswAAAA AAAAAQAAAAEAAAAACAAAAAAQB005ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAkAFNOQEwADAAAAAA AAABAAAAAQAAAAAAAAAAAJABTTkBMA4AAAAAAAAAAgAAAAEAAAAACAAAAAAQAZgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAkAFNOQEwADAAAAAAAAABAAAAAQAAAAAAAAAAAJAHTTkBMBEAAAAAAAAA AQAAAAEAAAAACAAAAAAQAU05ATARAAAAAAAAAAIAAAABAAAAAAgAAAAAEAGYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAJABTTkBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACQAU05ATAAMAAAAAAAAAEA AAABAAAAAAAAAAAAkAdNOQEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIAHTTkBMAAAAAAAAAAAAQAA AAEAAAAAAAAAkA2eBwAGAACGNwAA10MAAOlEAABmUwAAwFQAAM5VAABmZQAANXYAAAh6AABGgQAA jocAAEQAAABQAAAAVQAAAFcAAABaAAAAXAAAAF4AAABjAAAAagAAAGwAAABvAAAAAAYAAP8MAADR EQAALRcAAEsdAACdIwAAqigAACMsAABTLgAAjDMAABI3AAAMOQAAcz4AAMtCAABOSQAAdkwAAEFQ AABOVAAAU1UAAEhWAABwWgAAkl8AAPdiAAAmZwAAVWoAAG1tAACicAAAIHQAANV1AADGdgAAuXwA AMaAAACNhwAAjocAAEUAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABRAAAA UgAAAFMAAABUAAAAVgAAAFgAAABZAAAAWwAAAF0AAABfAAAAYAAAAGEAAABiAAAAZAAAAGUAAABm AAAAZwAAAGgAAABpAAAAawAAAG0AAABuAAAAcAAAAAAGAACNhwAARgAAAA8AAPA4AAAAAAAG8BgA AAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIA AAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsB AAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP//MAAAAAYA/AtdAAAAAQB0FBwABgD9 C10AAAABAKTKcgMGAP4LXQABAAEAXC94BAYA/wtdAAEAAQDsYXUDBgAADF0AAAABANSOewMGAAEM XQAIAAIAFI97AwYAAgxdAAgAAgCEb3MDBgADDF0ACAACANSCfAQGAAQMXQAAAAEAvC11AwYABQxd AAgAAgCEDXIDBgAGDF0AAAABAMSTfQMGAAcMXQAAAAEABJR9AwYACAxdAAgAAgBUTx8ABgAJDF0A CAACABRPHwAGAAoMXQAIAAIAJLQXAAYACwxdAAgAAgCksxcABgAMDF0ACAACAPQFdgQGAA0MXQAI AAIA9Mt1AwYADgxdAAgAAgC033EDBgAPDF0AAAABAPRZeQMGABAMXQAIAAIAhIR1AwYAEQxdAAAA AQB0NHgEBgASDF0ACAACAPSEGAAGABMMXQAAAAEANIUYAAYAFAxdAAEAAQA0BnYEBgAVDF0AAAAB AHQGdgQGABYMXQABAAEANG8YAAYAFwxdAAAAAQB0bxgABgAYDF0AAQABALRvGAAGABkMXQABAAEA LP5yAwYAGgxdAAAAAQBs/nIDBgAbDF0AAAABAKz+cgMGABwMXQABAAEALHgYAAYAHQxdAAAAAQBs eBgABgAeDF0AAQABAKx4GAAGAB8MXQABAAEA7HgYAAYAIAxdAAAAAQDcgRgABgAhDF0AAQABAByC GAAGACIMXQABAAEAXIIYAAYAIwxdAAAAAQCcghgABgAkDF0AAQABANyCGAAGACUMXQAAAAEAhI1y AwYAJgxdAAAAAgAEjnIDBgAnDF0AAAACAESOcgMGACgMXQAAAAIAhI5yAwYAKQxdAAAAAgBMDnQE BgAqDF0AAAACAIwOdAQGACsMXQAAAAIAzA50BF0BAADOAQAAzgEAANwBAAAhAgAALQYAABgHAAAj BwAAcQkAALwKAADWFAAAwiUAANMmAADyNAAAGzUAAK01AADoPgAAC0AAABZBAAAARAAAvVwAAG1f AABlYAAAGGYAABhmAAB1ZwAAdWcAACtsAAArbAAANGwAAFBsAABkbAAAZGwAABdtAAAXbQAAJW0A AD1tAAA9bQAASm0AAIBtAACAbQAA/m0AAKxzAADBcwAAp3QAALx0AADRdAAAsXUAAI9/AAAAAAAA AQACAAAAAgABAAAAAgADAAAAAgAEAAAAAQAFAAAAAQAGAAAAAQAHAAAAAQAIAAAAAQAJAAAAAQAK AAAAAQALAAAAAQAMAAAAAQANAAAAAQAOAAAAAQAPAAAAAQAQAAAAAQARAAAAAQASAAAAAQATAAAA AQAUAAAAAQAVAAAAAQAWAAAAAQAXAAAAAgAYAAAAAgAZAAAAAgAaAAAAAgAcAAAAAgAbAAAAAgAd AAAAAgAeAAAAAQAfAAAAAgAgAAAAAgAiAAAAAgAhAAAAAgAjAAAAAgAlAAAAAgAkAAAAAgAmAAAA AgAnAAAAAgAoAAAAAgApAAAAAQAqAAAAAQArAAAAAQAsAAAAAQAtAAAAAQAuAAAAAQAvAAAAAQBt AQAA2AEAAOUBAADlAQAALgIAADEGAAAbBwAAJgcAAIEJAAC/CgAA5hQAANIlAADXJgAA9jQAAB81 AACxNQAA7D4AAA9AAAAaQQAAEEQAAMFcAAB9XwAAaGAAAB1mAAAdZgAAe2cAAHtnAAAzbAAAOGwA ADhsAABXbAAAZmwAAGZsAAAhbQAALm0AAC5tAABGbQAAWm0AAFptAACHbQAAh20AAA5uAACwcwAA xXMAAKt0AADAdAAA1XQAALV1AACPfwAAAAAAAAIAAQABAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAHAABABsAAAAdAAAAHgAAAB8AAAAgAAAAIgABACEAAAAjAAAAJQAB ACQAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAABwAAAD0AAAAuAAAA KoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MJgFBsYWNlVHlwZQCA PQAAAC0AAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwmAUGxh Y2VOYW1lAIA5AAAALwAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0 YWdzBYBwbGFjZQCAOAAAABgAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncwSAQ2l0eQCAQgAAABAAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OnNtYXJ0dGFncw6AY291bnRyeS1yZWdpb24AgD8AAAArAAAAKoB1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOm9mZmljZTpzbWFydHRhZ3MLgHN0b2NrdGlja2VyAIA4AAAAMAAAACqAdXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBIBkYXRlAIAMAAABAQAAAAkAAAABgDEC gDEyAoAxMwSAMjAxMASAMjAxMQGANwOARGF5BYBNb250aASAWWVhcjAAAwAAAAgAAAAEAAAABgAA AAIAAAAHAAAAAAAAAC8AAAAAAC4AAAAAAC0AAAAAADAAAwAAAAgAAAADAAAABgAAAAEAAAAHAAAA BQAAACsAAAAAACsAAAAAACsAAAAAADAAAwAAAAgAAAAEAAAABgAAAAIAAAAHAAAAAAAAACsAAAAA ADAAAwAAAAgAAAAEAAAABgAAAAIAAAAHAAAAAAAAADAAAwAAAAgAAAAEAAAABgAAAAIAAAAHAAAA AAAAACsAAAAAACsAAAAAACsAAAAAACsAAAAAACsAAAAAACsAAAAAACsAAAAAADAAAwAAAAgAAAAE AAAABgAAAAIAAAAHAAAAAAAAACsAAAAAADAAAwAAAAgAAAAEAAAABgAAAAIAAAAHAAAAAAAAACsA AAAAAC8AAAAAABgAAAAAAC8AAAAAABgAAAAAAC8AAAAAAC0AAAAAAC4AAAAAAC8AAAAAAC8AAAAA ABAAAAAAAC8AAAAAAC4AAAAAAC0AAAAAAC8AAAAAAC4AAAAAAC0AAAAAAC8AAAAAABAAAAAAADAA AwAAAAgAAAAEAAAABgAAAAIAAAAHAAAAAAAAACsAAAAAACsAAAAAACsAAAAAACsAAAAAACsAAAAA ACsAAAAAAP//BQAKAAAAAAGNpOgP/////wAAAAEsK+gP/////wAAAAEQp+gP/////wAAAAGrp+gP /////wAAAAFeqOgP/////xIvAADYOAAAzEcAABNiAADUbQAAxnUAAAAAAAABAAAAAgAAAAMAAAAE AAAAwjEAANw4AABCTgAAgmMAANZtAADGdQAAAAAAANUAAADeAAAAlwEAAJwBAADcAQAA5QEAABID AAAVAwAAMwMAADsDAACKBQAAlAUAAFYGAABZBgAApggAAK8IAACmCQAArQkAAMcVAADKFQAA6xUA APMVAAAUGwAAMBsAADkbAABVGwAAzRsAANUbAADWGwAA3xsAAGEcAAB9HAAAOB0AAEAdAABBHQAA Sh0AAAgeAAASHgAANCAAADsgAAByIwAAdiMAAO0jAAAEJAAAiCUAAI0lAABTKAAAXSgAAOAqAADp KgAAFSsAADErAABOKwAAaisAAO8rAADyKwAAcy4AAH0uAACrLgAAtC4AAAUvAAAOLwAAlzAAAJ4w AABeMwAAZzMAANo1AADjNQAAeTYAAII2AADKNgAA0zYAABM3AAAcNwAA+jcAAAI4AABzOAAAgDgA ALw4AADJOAAAiDkAAKY5AABVOgAAXDoAAAM7AAAMOwAAEzsAACo7AAAqPAAAQTwAALE+AAC6PgAA Bz8AABA/AAA1QAAAOEAAAFJCAABVQgAAkUQAAJREAAD1RAAA+EQAAHJFAAB1RQAAn0UAAKJFAADR RQAA1EUAAP1FAAAARgAAFUkAADFJAADcTAAA5UwAADdOAABATgAAaU4AAHBOAAAzVwAAQFcAAKpX AAC3VwAA3FcAAPhXAABhWAAAaFgAAGtbAAB0WwAApFsAAK1bAABuXAAAd1wAANJcAADcXAAAq10A AMddAADyXQAA+V0AAPtdAAD/XQAADmAAABVgAABwYQAAfGEAAJFjAACYYwAABGQAAA1kAAAnZAAA LGQAAKpkAADBZAAAqmUAAK1lAACYZgAAn2YAAAFnAAAdZwAALWcAADNnAABEZwAAT2cAAFVnAABa ZwAAP2gAAF1oAAB3aAAAgmgAAIhoAACRaAAAl2gAAJxoAACwaAAAt2gAAHdpAACTaQAAo2kAAKlp AACvaQAAumkAAMBpAADFaQAA/WkAAARqAAArbAAAM2wAADxsAABGbAAAymwAANNsAAAObQAAE20A ACVtAAAubQAAYW0AAGhtAABsbQAAdW0AAANvAAANbwAA5m8AAPBvAABFcAAAT3AAAGNwAABtcAAA yHAAANJwAABycgAAfHIAAE9zAABZcwAAQ3QAAE10AAAbdQAAI3UAAIh1AACRdQAAxHUAAPh1AAD7 dQAAJXYAACh2AAAUeAAAF3gAAMl4AADNeAAAFnkAABl5AAAXfQAAGn0AAG99AAByfQAA130AANp9 AACPfwAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcABQAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAACGAgAApwIAAP4CAAAFAwAAjwMAAJEDAADUAwAA3gMA ABwEAAAgBAAAZQQAAGcEAACuBAAAsQQAAPIEAAD8BAAASQUAAE8FAACKBQAAlAUAANMFAADbBQAA FwYAAB0GAABeBgAAYQYAAKYGAACuBgAACgcAABQHAAC2BwAAvQcAAP4HAAAHCAAAhQgAAIgIAADN CAAA0QgAAA8JAAAXCQAAdAoAAHwKAABNCwAAWAsAAI0LAACWCwAA1gsAANgLAAAeDAAAJQwAAGQM AABnDAAApwwAALAMAAA2DQAAQA0AAMgNAADWDQAAQQ4AAEwOAABaDgAAYA4AAKMOAACyDgAA7A4A APwOAABNEAAAWBAAAM4QAADgEAAAGxEAACERAACaEQAAoxEAAOMRAADsEQAAthQAAMUUAACnFQAA rhUAAOsVAAAmFgAALxYAADkWAAB4FgAAfRYAAL8WAADIFgAATxcAAFMXAACUFwAAmxcAANoXAADf FwAAIBgAACUYAABjGAAAbRgAAMsYAADVGAAAERkAABgZAABVGQAAXhkAAJsZAACfGQAA3xkAAPEZ AABvGgAAdxoAALYaAAC+GgAA9xoAAAIbAAA2GwAAVxsAAKAbAACnGwAAJBwAAC4cAACgHAAAphwA AOEcAADpHAAAKR0AAC4dAAB3HQAAlR0AAN0dAADlHQAAJh4AACweAACUHgAAmx4AAM4eAADdHgAA ER8AABsfAABXHwAAWh8AAOgfAADvHwAArSAAALcgAAAgIQAALCEAAGQhAABvIQAAeCEAAIAhAACZ IQAAoyEAAOMhAADrIQAALyIAADIiAABfIgAAZyIAALEiAAC9IgAA+iIAAP0iAABAIwAARCMAAEcj AABfIwAAZyMAAHEjAAC5IwAAwyMAACkkAAA2JAAAcyQAAJQkAACdJAAAqCQAANskAADqJAAAIyUA ACclAAAvJQAAPCUAAE0lAABbJQAA5SYAAO0mAAAjJwAAMScAAMQnAADHJwAABygAAA4oAABkKAAA ZigAAL4oAADEKAAAXykAAGkpAAClKQAAqykAAOopAAD6KQAAMyoAADYqAAB7KgAAgyoAAMIqAADJ KgAACysAABErAABrKwAAcCsAAI8rAACWKwAA1CsAANsrAAAZLAAAKSwAAGIsAABoLAAArSwAALAs AADzLAAA/SwAADotAAA+LQAAgi0AAIQtAADLLQAAzy0AABEuAAAbLgAAmy4AAKEuAADhLgAA5C4A AHExAAB3MQAAmzEAAKExAADHMQAA1jEAAD8yAABBMgAAhzIAAIwyAAATMwAAGzMAABA1AAAaNQAA WDUAAGE1AACdNQAAozUAANc1AADjNQAAITYAACg2AABpNgAAcDYAAHY2AACCNgAAujYAAME2AADH NgAA0zYAABA3AAAcNwAAWzcAAF03AAChNwAAtTcAALo3AADKNwAALjgAADI4AABzOAAAgDgAALw4 AADJOAAAAzkAAAY5AABIOQAATTkAAKc5AACzOQAADDoAABQ6AABXOwAAWjsAAJ87AACjOwAADDwA ABI8AABYPQAAYD0AAJ89AACoPQAA4j0AAOk9AAAlPgAALD4AAOU+AADsPgAAlT8AAJk/AAALQQAA FUEAAMZBAADNQQAAO0IAAD1CAACdQgAAn0IAAAtDAAARQwAAyEMAAM9DAADgQwAA70MAAHlEAAB+ RAAAxUQAAMdEAADdRAAA4kQAACJFAAAqRQAATUUAAFJFAACZRQAAmkUAALtFAADARQAA4EUAAOVF AABVRgAAXEYAAJxGAACfRgAAQUcAAElHAACIRwAAk0cAABRIAAAcSAAA8EkAAPZJAAA0SgAAPkoA AHxKAACESgAAxEoAAMhKAAAGSwAADEsAAK1LAAC1SwAA9ksAAP5LAABSTAAAU0wAAAhNAAANTQAA QE0AAFBNAABXTQAAWE0AAIdNAACNTQAA5k0AAOlNAAA0TgAAQU4AAOJOAAD0TgAAnk8AAKVPAABE UAAASlAAAHtQAACRUAAAt1EAALxRAADPUwAA0lMAAAZUAAAMVAAA0lQAANpUAADiVAAA61QAAFVV AABdVQAAmFUAAKBVAADdVQAA41UAABJWAAAbVgAAv1YAAMdWAAAHVwAAC1cAAJVXAACdVwAA21cA APdXAAAiWQAAJlkAAJFZAACVWQAA1FkAAN9ZAAAcWgAAHloAAGVaAABsWgAAqloAALFaAADwWgAA 9VoAAD5bAABFWwAAgFsAAIhbAADHWwAAylsAAFRcAABWXAAAmFwAAJ9cAADgXAAA51wAAHddAAB6 XQAAql0AAMZdAAAoXgAALF4AAJteAACeXgAAKV8AACxfAABNXwAAXF8AAOdfAADzXwAAt2EAALlh AABUZQAAXGUAAHFlAAB/ZQAALWcAAGZnAADnZwAACmgAAJ9oAAChaAAAHGkAAEFpAAAPawAAE2sA AFBsAABcbAAAMm0AADZtAABsbQAAfG0AABBzAAAZcwAAqnMAAKtzAAC/cwAAwHMAAKV0AACmdAAA unQAALt0AADPdAAA0HQAAK91AACwdQAAxHUAAPV4AAD4eAAAJH4AACt+AACPfwAABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHAAUABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHAAUABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAcAMwAHADMA BwAAAAAAbB0AAJodAACSLAAArSwAAMQxAADKMQAAczgAAIM4AABATQAAUk0AAAJTAABfUwAAVGUA AG1lAADPdAAA33QAAMR1AAD1eAAA+XgAAEt6AABXegAAdX8AAIt/AACPfwAABwAFAAcABQAHAAUA BwAFAAcABQAHAAUABwAFAAcABQAHAAcABQAHAAUABwAFAAcAAAAAAMR1AACPfwAABwAHAP//AgAA AAsAQgBvAGIAIABCAHIAaQBzAGMAbwBlAAAAAgA5WyVMYHL+yP8P/w//D/8P/w//D/8P/w//DwAA aU2pdDJBxor/D/8P/w//D/8P/w//D/8P/w8AAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAcQAAAP hO4CEYQS/V6E7gJghBL9XkoAAG8oAAIAAAAuAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAcQAAAP hO4CEYQS/V6E7gJghBL9XkoAAG8oAAQAAAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAH EAAAD4Q4BBGEyPtehDgEYITI+15KAABvKAAGAAAALgABAC4AAgAuAAEAAAAAAAEDBQcAAAAAAAAA AAAAAAAAAAcQAAAPhDgEEYTI+16EOARghMj7XkoAAG8oAAgAAAAuAAEALgACAC4AAwAuAAEAAAAA AAEDBQcJAAAAAAAAAAAAAAAAAAcQAAAPhKAFEYRg+l6EoAVghGD6XkoAAG8oAAoAAAAuAAEALgAC AC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAHEAAAD4QIBxGE+PhehAgHYIT4+F5K AABvKAAMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAcQ AAAPhAgHEYT4+F6ECAdghPj4XkoAAG8oAA4AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAEA AAAAAAEDBQcJCw0PAAAAAAAAAAAAAAcQAAAPhHAIEYSQ916EcAhghJD3XkoAAG8oABAAAAAuAAEA LgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAHEAAAD4TY CRGEKPZehNgJYIQo9l5KAABvKAASAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAu AAEAAAAAEAIAAAAAAAAAAABoAQAAAAAAAB4YAAAPhAwDEYSY/hXGBQABDAMGXoQMA2CEmP5DShYA T0oAAFBKBgBRSgAAYUoYAIdoAAAAAIhIAAADAFsAAABdAAEAAAAEEAEAAAAAAAAAAABoAQAAAAAA AAoYAAAPhNwFEYSY/hXGBQAB3AUGXoTcBWCEmP6HaAAAAACISAAAAgABAC4AAQAAAAISAQAAAAAA AAAAAGgBAAAAAAAAChgAAA+ErAgRhEz/FcYFAAGsCAZehKwIYIRM/4doAAAAAIhIAAACAAIALgAB AAAAABABAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4R8CxGEmP4VxgUAAXwLBl6EfAtghJj+h2gAAAAA iEgAAAIAAwAuAAEAAAAEEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhEwOEYSY/hXGBQABTA4GXoRM DmCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAISAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EHBERhEz/ FcYFAAEcEQZehBwRYIRM/4doAAAAAIhIAAACAAUALgABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAK GAAAD4TsExGEmP4VxgUAAewTBl6E7BNghJj+h2gAAAAAiEgAAAIABgAuAAEAAAAEEAEAAAAAAAAA AABoAQAAAAAAAAoYAAAPhLwWEYSY/hXGBQABvBYGXoS8FmCEmP6HaAAAAACISAAAAgAHAC4AAQAA AAISAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EjBkRhEz/FcYFAAGMGQZehIwZYIRM/4doAAAAAIhI AAACAAgALgACAAAAaU2pdAAAAAAAAAAAAAAAADlbJUwAAAAAAAAAAAAAAAD/////////////AgAA AAAAAAD//wIAAAAAAAAAAQCwO8NLAAAAAAAAAAAAAQIAAgAWAAAABAAAAAgAAADlAAAAAAAAABUA AAAHARcAdWQmALRnPQA+GEMAf3FaAGk6ZQADTIQAeSGNAIpGtgC2fLYAszW3ACwCwwCwQcoAc3XK AF5L0AA7fdoATgzmAFIs7gB5A+8A6DrvACQS+QApLPwAAAAAAN90AACPfwAAAAAAAAEAAAD/QAGA AQCudQAArnUAAOw6LgUBAAEArnUAAAAAAACudQAAAAAAAAIQAAAAAAAAAI5/AACAAAAQAEAAAP// AwAAAAcAVQBuAGsAbgBvAHcAbgAdAEwAZQBoAHIAcwB0AHUAaABsACAAZgB1AGUAcgAgAEkAbgBm AG8AcgBtAGEAdABpAGsAIABJAEkASQALAEIAbwBiACAAQgByAGkAcwBjAG8AZQD//wMACAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAgD//wMAAAAAAAAAAAD//wAAAgD//wAAAAD//wAAAgD/ /wAAAAAHAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUA cwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAA AACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAA AAAAAEEAcgBpAGEAbAAAADsGkAGGBwIBBgADAQEBAQEDAAAAAAAOCBAAAAAAAAAAAQAEAAAAAABT AGkAbQBTAHUAbgAAAItbU08AAD81kAEAAAIHAwkCAgUCBASHegAgAAAAgAgAAAAAAAAA/wEAAAAA AABDAG8AdQByAGkAZQByACAATgBlAHcAAAA1JpABAAACCwYEAwUEBAIEh3oAYQAAAIAIAAAAAAAA AP8BAQAAAAAAVABhAGgAbwBtAGEAAABHNZABgAoCAgYJBAIFCAMEvwIAoPv8x2gQAAAAAAAAAJ8A AgAAAAAATQBTACAATQBpAG4AYwBoAG8AAAAt/zP/IAAOZh1nAAAiAAQAcYiIGADw0AIAAGgBAAAA AFV152aLnecmAAAAAAQAFAAAAJMRAAAxZAAAAQA8AAAABAADENUAAACTEQAAMWQAAAEAPAAAANUA AAAAAAAAIQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgASgBbQAtACBgTI0AAAAAAAA AAAAAAAAAACIdQAAiHUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAABM4NRAPAQAAgg//0BAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEhQAAAAAChw/w8BAAE/AAAAAAAAAAAAAP///3////9/AAAAAP///3////9///// f1Is7gD//xIAAAAAAAAAPwBDAG8AbgBnAGUAcwB0AGkAbwBuACAAYQBuAGQAIABQAHIAZQAtAEMA bwBuAGcAZQBzAHQAaQBvAG4AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAQgAAAAAAAAALAEIAbwBiACAAQgByAGkAcwBjAG8A ZQALAEIAbwBiACAAQgByAGkAcwBjAG8AZQAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAGAAAAAgAA AAAADAABAA8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAAB AAAA4IWf8vlPaBCrkQgAKyez2TAAAACsAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA4AAAAAQA AADsAAAABQAAAAABAAAGAAAADAEAAAcAAAAYAQAACAAAACwBAAAJAAAAQAEAABIAAABMAQAACgAA AGgBAAAMAAAAdAEAAA0AAACAAQAADgAAAIwBAAAPAAAAlAEAABAAAACcAQAAEwAAAKQBAAACAAAA 5AQAAB4AAABAAAAAQ29uZ2VzdGlvbiBhbmQgUHJlLUNvbmdlc3Rpb24gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBCAB4AAAABAAAAAG9uZx4AAAAMAAAAQm9iIEJyaXNjb2UAHgAAAAEA AAAAb2IgHgAAAAEAAAAAb2IgHgAAAAsAAABOb3JtYWwuZG90AAAeAAAADAAAAEJvYiBCcmlzY29l AB4AAAACAAAANABiIB4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMABAAAAAAHhBywIAAABAAAAA AF7uEpIjywFAAAAAAMoi44YnywEDAAAAAQAAAAMAAACTEQAAAwAAADFkAAADAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWc LhsQk5cIACss+a4wAAAAKAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAGAAAAhAAAABEA AACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAADAAA AAgBAAACAAAA5AQAAB4AAAADAAAAQlQAAAMAAADVAAAAAwAAADwAAAADAAAAiHUAAAMAAABBCgoA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAEAAAABDb25nZXN0aW9uIGFu ZCBQcmUtQ29uZ2VzdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIADBAAAAIA AAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAAL AAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkA AAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAA ACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA NgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABE AAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIA AABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAA AGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAA bwAAAHAAAABxAAAA/v///3MAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAD+////ewAAAHwAAAB9 AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsA AACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAA AJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAA qAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2 AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAA/v///8QA AADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAAD+////zAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAA AP7////9/////f///9YAAAD+/////v////7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA AAAAAAAAAACgGxH5hifLAdgAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAA BgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB6AAAABZEAAAAAAABX AG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA04gAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAwwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3Jk IERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA== --=====================_17385529==_-- --------------070504010501000702090805-- From slblake@petri-meat.com Fri Jun 10 21:32:26 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEE09E8011 for ; Fri, 10 Jun 2011 21:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHwuBL4WU0SM for ; Fri, 10 Jun 2011 21:32:25 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF399E8009 for ; Fri, 10 Jun 2011 21:32:25 -0700 (PDT) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1QVFrz-0000ZR-7t for pcn@ietf.org; Sat, 11 Jun 2011 00:32:23 -0400 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-9rbTEljohwT7M3bYgRZY" Date: Sat, 11 Jun 2011 00:32:23 -0400 Message-ID: <1307766743.23322.3.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] [Fwd: Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 04:32:26 -0000 --=-9rbTEljohwT7M3bYgRZY Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI // Steve --=-9rbTEljohwT7M3bYgRZY Content-Disposition: inline Content-Description: Forwarded message - Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Content-Type: message/rfc822 Return-path: Envelope-to: slblake@petri-meat.com Delivery-date: Fri, 10 Jun 2011 13:58:21 -0400 Received: from zinfandel.tools.ietf.org ([64.170.98.42]) by elom.tchmachines.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QV5yP-000077-0v for slblake@petri-meat.com; Fri, 10 Jun 2011 13:58:21 -0400 Received: from b.painless.aaisp.net.uk ([2001:8b0:0:30::51bb:1e34]) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1QV5yC-0006HL-Uq for draft-ietf-pcn-cl-edge-behaviour.all@tools.ietf.org; Fri, 10 Jun 2011 10:58:11 -0700 Received: from 250.254.187.81.in-addr.arpa ([81.187.254.250]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QV5y2-0007mN-1f; Fri, 10 Jun 2011 18:57:58 +0100 From: Elwyn Davies To: General Area Review Team Cc: draft-ietf-pcn-cl-edge-behaviour.all@tools.ietf.org, "A. Jean Mahoney" , ietf@ietf.org Content-Type: text/plain Date: Fri, 10 Jun 2011 19:01:54 +0100 Message-Id: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-SA-Exim-Connect-IP: 2001:8b0:0:30::51bb:1e34 X-SA-Exim-Rcpt-To: draft-ietf-pcn-cl-edge-behaviour.all@tools.ietf.org X-SA-Exim-Mail-From: elwynd@dial.pipex.com X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on zinfandel.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,X_IPV6_ADDRESS autolearn=ham version=3.3.1 Subject: Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) List-ID: Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcn-cl-edge-behaviour-08 Reviewer: Elwyn Davies Review Date: 10 June 2011 IETF LC End Date: 10 June 2011 IESG Telechat date: (if known) - Summary: In my opinion, there are a number of areas that need significant work and at least one open issue (the stability question from s3.3.1) that needs to be addressed before this document is ready for the IESG. Major issues: The draft contains partial definitions of two control protocols (egress -> decision point; decision point -> ingress). It does not make it clear whether the reader is expected to get full definitions of these protocols here or whether there will be another document that specifies these protocols completely. As is stands one could build the protocols and pretty much guarantee that they would not be interoperable with other implementations since message formats are not included although high level specs are. The document needs to be much clearer about what is expected to happen here. Use of EXP codepoint: My understanding of what is said in RFC 5696 is that EXP is supposed to be left for other (non=PCN) systems to use. This draft uses it. Is this sensible? Is this whole draft experimental really? s3.3.1: > [CL-specific] The outcome of the comparison is not very sensitive > to the value of the CLE-limit in practice, because when threshold- > marking occurs it tends to persist long enough that threshold- > marked traffic becomes a large proportion of the received traffic > in a given interval. This statement worries me. It sounds like a characteristic of an unstable system. If the value is that non-critical why are we bothering? Minor issues: s1.1: definition of PCN-Traffic etc: > The same network will carry traffic of other Diffserv BAs. Just to be sure: Does this or does this not imply that *all* traffic in a PCN network must have a non-empty DSCP marking, i.e. that *all* traffic must be attached to some specific Diffserv BA? This should be clarified whichever is true. s1.1: T-fail: I notice from s3.1 that PCN-ingress nodes also have to make reports on request. Should T-fail or some other timer apply to non-return of info from ingress points? What would a (probably non-colocated) decision point do if it lost contact with the ingress? s2/s3.2.1: The use of PM and EXP codepoints for ThM and ETM appear to be reversed in these two sections!! Which way round is intended? s3.2.1/s3.2.2: Neither section mentions T-meas but I assume that this is supposed to be (either or both) the sampling period in the egress node or the period between reports. It is unclear if they are allowed to be different and if they are which one is T-meas. However s3.2.3 appears to imply that T-meas is probably the time between reports. This all needs to be much clearer. s3.2.1/3.2.2: In s3.2.2, para 2: > If so configured (e.g., because multipath routing is > being used, as explained in the previous section), the PCN-egress- > node MUST also report the set of flow identifiers of PCN-flows for > which excess-traffic-marking was observed in the most recent > measurement interval. This is a requirement for a protocol that you may or may not be defining. Confusing. s3.2.3/s3.2.2: The first paragraph of s3.2.3 suggests that the report from an egress may not always contain the calculated value of the CLE, but s3.2.2 has a MUST for the report to contain this value. Consistency!!! s6: The potential introduction of a centralized decision point appears to provide additional attack points beyond the architecture in RFC 5559. It appears to me that the requests for information about specific flows to the ingress are ighly vulnerable as they (probably) contain all the information needed to craft a DoS attack on the flow. Nits/editorial comments: General: Consistency of naming for timing paramters t-meas/T-meas, etc. s1.1: I think it would be worth reproducing the CL-specific definitions: PCN-threshold-rate and threshold-marked since they are specific. s1.1: > Congestion level estimate (CLE) > A value derived from the measurement of PCN-packets received at a > PCN-egress-node for a given ingress-egress-aggregate, representing > the ratio of marked to total PCN-traffic (measured in octets) ^^^^^ ^^^^^^^^^^^^^^^^^^ > received over a short period. The ratio is (hopefully) dimensionless. Maybe '(each measured in octets)' ? s2: > the PCN-domain satisfies the conditions specified in [RFC5696]; This may be a bit pedantic but I am not sure that RFC 5696 actually sets out conditions for the domain. It sets out rules for encoding markings and allowed transitions. Maybe s/conditions/packet markings and allowed transitions/. s3.1, para 1 and several other instances: s/collocated/co(-)located/ s3.2.1, para 5: s/statistical variance/statistical variation/ --=-9rbTEljohwT7M3bYgRZY-- From tom111.taylor@bell.net Sun Jun 12 07:48:47 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF0111E80B2; Sun, 12 Jun 2011 07:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYPBxg2wgb3K; Sun, 12 Jun 2011 07:48:46 -0700 (PDT) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9C11E80AB; Sun, 12 Jun 2011 07:48:46 -0700 (PDT) Received: from BLU0-SMTP80 ([65.55.111.72]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 07:48:46 -0700 X-Originating-IP: [76.70.76.63] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.76.63]) by BLU0-SMTP80.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Jun 2011 07:48:46 -0700 Date: Sun, 12 Jun 2011 10:48:45 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf@ietf.org References: <20110527203800.13071.15398.idtracker@ietfa.amsl.com> In-Reply-To: <20110527203800.13071.15398.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2011 14:48:46.0141 (UTC) FILETIME=[D4FB9ED0:01CC290F] Cc: pcn@ietf.org, The IESG , IETF-Announce Subject: Re: [PCN] Last Call: (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 14:48:47 -0000 Through confusion, I have perpetrated a major screw-up regarding this document and its companion, draft-ietf-pcn-sm-edge-behaviour. Somewhere around Christmas I received a number of comments on the two documents. I have fixed all of them except the comment requesting sections on operations and management considerations sections. I am wishing now that I had submitted interim updates reflecting that work, pending completion of the new sections. For various reasons I haven't had the time or energy to finish the job. When our AD came out with a revised set of comments I was confused and failed to respond. At first when Last Call was issued I thought this would do no real harm, since many of the fixes were really just editorial. Unfortunately, now that I look over some of the reviews, I realize that some substantive fixes were also included. As a result, I have wasted the time of a lot of people. I apologize to the community for this. What I propose is that I submit the documents with the fixes that were carried out, and the IESG restart the Last Call process. Failing that, I will go through and identify the substantive issues that need correction in any event. I note the discomfort with using the EXP code point. This is indirectly a matter of extensive debate in the PCN WG. My own view is that the solution is as suggested, make the CL-edge-behaviour draft Experimental rather than Informational. Tom Taylor, Editor On 27/05/2011 4:38 PM, The IESG wrote: > > The IESG has received a request from the Congestion and Pre-Congestion > Notification WG (pcn) to consider the following document: > - 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of > Operation' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Pre-congestion notification (PCN) is a means for protecting the > 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 a form of > measurement-based load control using three PCN marking states, not- > marked, threshold-marked, and excess-traffic-marked. This behaviour > is known informally as the Controlled Load (CL) PCN-boundary-node > behaviour. > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From philip.eardley@bt.com Mon Jun 13 09:19:32 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835C811E8093 for ; Mon, 13 Jun 2011 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIM-T7kF7knC for ; Mon, 13 Jun 2011 09:19:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 66D5A11E814E for ; Mon, 13 Jun 2011 09:19:31 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 13 Jun 2011 17:19:29 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.239]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 13 Jun 2011 17:19:30 +0100 From: To: Date: Mon, 13 Jun 2011 17:19:29 +0100 Thread-Topic: [PCN] Last Call: (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC Thread-Index: AcwpD9qYzLzKM1SZReKADO3BABZ73QA1FpzQ Message-ID: <9510D26531EF184D9017DF24659BB87F32DF7BF553@EMV65-UKRD.domain1.systemhost.net> References: <20110527203800.13071.15398.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Last Call: (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:19:32 -0000 Tom Your efforts are much appreciated. Speaking personally, you're not the only= one who gets confused by PCN!=20 I must admit I thought you had solved several of the minor points that Elwy= n raises in his Gen-Art review (is this what you're referring to?). But he = raises a couple of new issues that are non-trivial Thanks, phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: 12 June 2011 15:49 To: ietf@ietf.org Cc: pcn@ietf.org; The IESG; IETF-Announce Subject: Re: [PCN] Last Call: (PC= N Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) t= o Informational RFC Through confusion, I have perpetrated a major screw-up regarding this=20 document and its companion, draft-ietf-pcn-sm-edge-behaviour. Somewhere=20 around Christmas I received a number of comments on the two documents. I=20 have fixed all of them except the comment requesting sections on=20 operations and management considerations sections. I am wishing now that=20 I had submitted interim updates reflecting that work, pending completion=20 of the new sections. For various reasons I haven't had the time or energy to finish the job.=20 When our AD came out with a revised set of comments I was confused and=20 failed to respond. At first when Last Call was issued I thought this=20 would do no real harm, since many of the fixes were really just=20 editorial. Unfortunately, now that I look over some of the reviews, I=20 realize that some substantive fixes were also included. As a result, I have wasted the time of a lot of people. I apologize to=20 the community for this. What I propose is that I submit the documents=20 with the fixes that were carried out, and the IESG restart the Last Call=20 process. Failing that, I will go through and identify the substantive=20 issues that need correction in any event. I note the discomfort with using the EXP code point. This is indirectly=20 a matter of extensive debate in the PCN WG. My own view is that the=20 solution is as suggested, make the CL-edge-behaviour draft Experimental=20 rather than Informational. Tom Taylor, Editor On 27/05/2011 4:38 PM, The IESG wrote: > > The IESG has received a request from the Congestion and Pre-Congestion > Notification WG (pcn) to consider the following document: > - 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of > Operation' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-10. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Pre-congestion notification (PCN) is a means for protecting the > 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 a form of > measurement-based load control using three PCN marking states, not- > marked, threshold-marked, and excess-traffic-marked. This behaviour > is known informally as the Controlled Load (CL) PCN-boundary-node > behaviour. > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > 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 philip.eardley@bt.com Mon Jun 13 10:04:37 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053AD11E8172 for ; Mon, 13 Jun 2011 10:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgoSh4tJ3JZF for ; Mon, 13 Jun 2011 10:04:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA311E8171 for ; Mon, 13 Jun 2011 10:04:35 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 13 Jun 2011 18:04:35 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.239]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 13 Jun 2011 18:04:34 +0100 From: To: , Date: Mon, 13 Jun 2011 18:04:32 +0100 Thread-Topic: Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwn8JOMh3R3n1XmQWuSe9Bj3jiL8gB9SLpA Message-ID: <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> In-Reply-To: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:04:37 -0000 Elwyn, Thanks for the detailed review. A few follow-ups in-line Thanks phil -- Major issues: The draft contains partial definitions of two control protocols (egress -> decision point; decision point -> ingress). It does not make it clear whether the reader is expected to get full definitions of these protocols here or whether there will be another document that specifies these protocols completely. As is stands one could build the protocols and pretty much guarantee that they would not be interoperable with other implementations since message formats are not included although high level specs are. The document needs to be much clearer about what is expected to happen here. [phil] there is another document, " Requirements for Signaling of (Pre-) Co= ngestion Information in a DiffServ Domain" [http://tools.ietf.org/html/draf= t-ietf-pcn-signaling-requirements-04] that deals with your issue to some ex= tent. It doesn't specify message formats but does at least specify better w= hat information the messages must contain. My understanding is that unfortu= nately the WG doesn't feel it has the effort to specify these protocols com= pletely.=20 =20 Use of EXP codepoint: My understanding of what is said in RFC 5696 is that EXP is supposed to be left for other (non=3DPCN) systems to use. This draft uses it. Is this sensible? Is this whole draft experimental really? [phil] the intention of rfc5696 was that the EXP codepoint is for experimen= tal *PCN* encodings - ie beyond the baseline. For instance, the CL behaviou= r needs separate codepoints for (PCN) threshold-marking and (PCN) excess-tr= affic-marking & this would require using the EXP codepoint. However...... There is currently some discussion on what PCN encodings to s= pecify beyond the baseline. At the time we wrote the baseline, we envisaged= the need for several encodings - however it now seems that one may be enou= gh, in which case there may possibly be just one PCN encoding (ie a revised= 5696 that now uses the 01 codepoint), so possibly may be Standards track -= ?? Anyway, i take your point that we need to think about Status. s3.3.1: > [CL-specific] The outcome of the comparison is not very sensitive > to the value of the CLE-limit in practice, because when threshold- > marking occurs it tends to persist long enough that threshold- > marked traffic becomes a large proportion of the received traffic > in a given interval. This statement worries me. It sounds like a characteristic of an unstable system. If the value is that non-critical why are we bothering? [phil] admission control system. imagine the pcn-domain has one bottleneck = link. If it can cope with the current number of calls (their bandwidth), th= en no pkts gets threshold-marked, so the CLE =3D 0. If there are too many, = then all pkts gets threshold-marked, so the CLE =3D 1. If there is almost e= xactly the right number of calls, then threshold-marking will tend to be on= for a while, then off for a while (perhaps when several flows are transmit= ting less traffic than normal), so the CLE will jiggle about between 0 & 1.= If the CLE is < CLE-limit (say CLE-limit =3D 0.6 & current CLE =3D 0.5), w= hen a new call admission request happens to arrive then it gets admitted. B= ut then there's more traffic and it's likely that the CLE will rise to 1 - = hence another admission request will get blocked. When a call finishes, the= n the reverse is true.=20 Now suppose we had in fact configured CLE-limit =3D 0.4, then in the scenar= io above the call request would have been blocked. However, (1) the PCN-dom= ain has only admitted one fewer call, (2) a short time later, either the CL= E happens to be lower or a call departs, and then the next admission reques= t is accepted. All this means that it doesn't matter much exactly what you set CLE-limit t= o - it barely affects the average number of calls admitted. The argument ab= ove is hand-wavy, but lots of simulations have been done that show this is = true (I hope i'm representing the results correctly) So the lack of sensitivity to CLE-limit seems like a good thing.=20 Minor issues: s6: The potential introduction of a centralized decision point appears to provide additional attack points beyond the architecture in RFC 5559. It appears to me that the requests for information about specific flows to the ingress are ighly vulnerable as they (probably) contain all the information needed to craft a DoS attack on the flow. [phil] seems a good point to me From philip.eardley@bt.com Mon Jun 13 10:06:48 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7AF11E8154 for ; Mon, 13 Jun 2011 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.746 X-Spam-Level: X-Spam-Status: No, score=-102.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY3iM3IFWe0a for ; Mon, 13 Jun 2011 10:06:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9511E80AC for ; Mon, 13 Jun 2011 10:06:47 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 13 Jun 2011 18:06:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.239]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 13 Jun 2011 18:06:47 +0100 From: To: , , Date: Mon, 13 Jun 2011 18:06:45 +0100 Thread-Topic: Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwn8JOMh3R3n1XmQWuSe9Bj3jiL8gB9SLpAAAGSbWA= Message-ID: <9510D26531EF184D9017DF24659BB87F32DF7BF59C@EMV65-UKRD.domain1.systemhost.net> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:06:49 -0000 I forgot to add - I tweaked the distribution list, since it looks like we w= ill need quite a few mods, which it would seem better to discuss on the PCN= than IETF ML phil Philip Eardley=A0=A0=A0 Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of phili= p.eardley@bt.com Sent: 13 June 2011 18:05 To: elwynd@dial.pipex.com; pcn@ietf.org Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Elwyn, Thanks for the detailed review. A few follow-ups in-line Thanks phil -- Major issues: The draft contains partial definitions of two control protocols (egress -> decision point; decision point -> ingress). It does not make it clear whether the reader is expected to get full definitions of these protocols here or whether there will be another document that specifies these protocols completely. As is stands one could build the protocols and pretty much guarantee that they would not be interoperable with other implementations since message formats are not included although high level specs are. The document needs to be much clearer about what is expected to happen here. [phil] there is another document, " Requirements for Signaling of (Pre-) Co= ngestion Information in a DiffServ Domain" [http://tools.ietf.org/html/draf= t-ietf-pcn-signaling-requirements-04] that deals with your issue to some ex= tent. It doesn't specify message formats but does at least specify better w= hat information the messages must contain. My understanding is that unfortu= nately the WG doesn't feel it has the effort to specify these protocols com= pletely.=20 =20 Use of EXP codepoint: My understanding of what is said in RFC 5696 is that EXP is supposed to be left for other (non=3DPCN) systems to use. This draft uses it. Is this sensible? Is this whole draft experimental really? [phil] the intention of rfc5696 was that the EXP codepoint is for experimen= tal *PCN* encodings - ie beyond the baseline. For instance, the CL behaviou= r needs separate codepoints for (PCN) threshold-marking and (PCN) excess-tr= affic-marking & this would require using the EXP codepoint. However...... There is currently some discussion on what PCN encodings to s= pecify beyond the baseline. At the time we wrote the baseline, we envisaged= the need for several encodings - however it now seems that one may be enou= gh, in which case there may possibly be just one PCN encoding (ie a revised= 5696 that now uses the 01 codepoint), so possibly may be Standards track -= ?? Anyway, i take your point that we need to think about Status. s3.3.1: > [CL-specific] The outcome of the comparison is not very sensitive > to the value of the CLE-limit in practice, because when threshold- > marking occurs it tends to persist long enough that threshold- > marked traffic becomes a large proportion of the received traffic > in a given interval. This statement worries me. It sounds like a characteristic of an unstable system. If the value is that non-critical why are we bothering? [phil] admission control system. imagine the pcn-domain has one bottleneck = link. If it can cope with the current number of calls (their bandwidth), th= en no pkts gets threshold-marked, so the CLE =3D 0. If there are too many, = then all pkts gets threshold-marked, so the CLE =3D 1. If there is almost e= xactly the right number of calls, then threshold-marking will tend to be on= for a while, then off for a while (perhaps when several flows are transmit= ting less traffic than normal), so the CLE will jiggle about between 0 & 1.= If the CLE is < CLE-limit (say CLE-limit =3D 0.6 & current CLE =3D 0.5), w= hen a new call admission request happens to arrive then it gets admitted. B= ut then there's more traffic and it's likely that the CLE will rise to 1 - = hence another admission request will get blocked. When a call finishes, the= n the reverse is true.=20 Now suppose we had in fact configured CLE-limit =3D 0.4, then in the scenar= io above the call request would have been blocked. However, (1) the PCN-dom= ain has only admitted one fewer call, (2) a short time later, either the CL= E happens to be lower or a call departs, and then the next admission reques= t is accepted. All this means that it doesn't matter much exactly what you set CLE-limit t= o - it barely affects the average number of calls admitted. The argument ab= ove is hand-wavy, but lots of simulations have been done that show this is = true (I hope i'm representing the results correctly) So the lack of sensitivity to CLE-limit seems like a good thing.=20 Minor issues: s6: The potential introduction of a centralized decision point appears to provide additional attack points beyond the architecture in RFC 5559. It appears to me that the requests for information about specific flows to the ingress are ighly vulnerable as they (probably) contain all the information needed to craft a DoS attack on the flow. [phil] seems a good point to me _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Tue Jun 14 02:59:21 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEA11E80F0 for ; Tue, 14 Jun 2011 02:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgXm8FpuQRZ7 for ; Tue, 14 Jun 2011 02:59:21 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5972311E80FE for ; Tue, 14 Jun 2011 02:59:19 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jun 2011 11:57:30 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by he110890 ([10.134.92.131]) with mapi; Tue, 14 Jun 2011 11:57:13 +0200 From: To: Date: Tue, 14 Jun 2011 11:57:11 +0200 Thread-Topic: [PCN] PCN encoding for MPLS shim headers Thread-Index: AcwnjbRlSftpG7hySwWFLnxTGL1aKAC61FvQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB3E8@HE111648.emea1.cds.t-internal.com> References: <4DF249D6.2080807@informatik.uni-tuebingen.de> In-Reply-To: <4DF249D6.2080807@informatik.uni-tuebingen.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB3E8HE111648emea1_" MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding for MPLS shim headers X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 09:59:21 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB3E8HE111648emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Toby, thanks to Michael for pointing out the gap and the solution in the state th= at has been reached. I agree that the text worked out by Michael and Bob sh= ould be added as informative appendix. Regards, Ruediger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: Friday, June 10, 2011 6:44 PM To: Toby Moncaster Cc: pcn@ietf.org Subject: [PCN] PCN encoding for MPLS shim headers Hi Toby, I just realized that the introduction of the 3-in-1 doc says "For example, = the MPLS encoding is defined in [RFC5129] and Appendix A of that document provides an informative example for a mapp= ing between the encodings in IP and in MPLS." but the Appendix does not pro= vide such information. We agreed about a year ago to provide such information in an appendix of th= e 3-in-1 encoding doc as RFC5129 is not explicit enough about how PCN may b= e encoded in MPLS shim headers. Somehow this information was lost. I digged= in my emails. You find the lost appendix in the Word file attachment in th= e attached private email. Can you please add that before it is lost again? Best wishes, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB3E8HE111648emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Toby,
 
thanks to Michael for pointing out the gap an= d the=20 solution in the state that has been reached. I agree that the text worked o= ut by=20 Michael and Bob should be added as informative appendix.
 
Regards,
 
Ruediger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth
Sent:= =20 Friday, June 10, 2011 6:44 PM
To: Toby Moncaster
Cc:=20 pcn@ietf.org
Subject: [PCN] PCN encoding for MPLS shim=20 headers

Hi Toby,

I just realized that the introduction of the 3-i= n-1=20 doc says "For example, the MPLS encoding is defined in [RFC5129] and Appendix=20 A of that document provides an informative example for a mapping betwee= n the=20 encodings in IP and in MPLS." but the Appendix does not provide such=20 information.

We agreed about a year ago to provide such information = in an=20 appendix of the 3-in-1 encoding doc as RFC5129 is not explicit enough about= how=20 PCN may be encoded in MPLS shim headers. Somehow this information was lost.= I=20 digged in my emails. You find the lost appendix in the Word file attachment= in=20 the attached private email. Can you please add that before it is lost=20 again?

Best wishes,

    Michael
--=20
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mai=
lto:menth@uni-tuebingen.de
http://www-kn.informatik.uni-tuebingen.de
--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB3E8HE111648emea1_-- From elwynd@dial.pipex.com Tue Jun 14 10:20:57 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCF59E800B; Tue, 14 Jun 2011 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZRuPGc46wQ2; Tue, 14 Jun 2011 10:20:55 -0700 (PDT) Received: from a.painless.aaisp.net.uk (auth.a.painless.aaisp.net.uk [IPv6:2001:8b0:0:30:230:48ff:fe72:d05c]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13A9E800A; Tue, 14 Jun 2011 10:20:53 -0700 (PDT) Received: from study.folly.org.uk ([81.187.254.244]) by a.painless.aaisp.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1QWXIG-0003if-Pz; Tue, 14 Jun 2011 18:20:49 +0100 Message-ID: <4DF7986B.5020108@dial.pipex.com> Date: Tue, 14 Jun 2011 18:20:43 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: philip.eardley@bt.com References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Jun 2011 10:24:57 -0700 Cc: pcn@ietf.org, General Area Reviwing Team Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 17:20:57 -0000 Hi, Phil. It strikes me that the first and second points below are something which David Harrington perhaps ought to give an opinion on. He has got to defend it to the IESG. On the first point, my feeling is that neither the requirements doc nor this doc is sufficient to guarantee an interoperable implementation. There seems to me to be a cleft stick here (irrespective of whether this ends up as informational or experimental.) The WG is is specifying pieces of functionality that go in two or more different types of boxes (three if there is a separate implementation of the central decision point). If the system is going to be generally deployable or even to be experimented with there may be different implementations. The box types communicate using the information specifications in the doc. This appears to require protocol definitions. Where they are defined is another issue but I feel it has either to be in this doc or in another doc referenced from this. If they aren't specified I can't see that anybody will be interested in making commercial implementations. I see David didn't make any comment about this situation in his write up, so maybe I am over reacting. Regards, Elwyn On 13/06/2011 18:04, philip.eardley@bt.com wrote: > Elwyn, > > Thanks for the detailed review. > A few follow-ups in-line > Thanks > phil > > -- > Major issues: > The draft contains partial definitions of two control protocols (egress > -> decision point; decision point -> ingress). It does not make it > clear whether the reader is expected to get full definitions of these > protocols here or whether there will be another document that specifies > these protocols completely. As is stands one could build the protocols > and pretty much guarantee that they would not be interoperable with > other implementations since message formats are not included although > high level specs are. The document needs to be much clearer about what > is expected to happen here. > > [phil] there is another document, " Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain" [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requirements-04] that deals with your issue to some extent. It doesn't specify message formats but does at least specify better what information the messages must contain. My understanding is that unfortunately the WG doesn't feel it has the effort to specify these protocols completely. > > > Use of EXP codepoint: My understanding of what is said in RFC 5696 is > that EXP is supposed to be left for other (non=PCN) systems to use. > This draft uses it. Is this sensible? Is this whole draft experimental > really? > [phil] the intention of rfc5696 was that the EXP codepoint is for experimental *PCN* encodings - ie beyond the baseline. For instance, the CL behaviour needs separate codepoints for (PCN) threshold-marking and (PCN) excess-traffic-marking& this would require using the EXP codepoint. > However...... There is currently some discussion on what PCN encodings to specify beyond the baseline. At the time we wrote the baseline, we envisaged the need for several encodings - however it now seems that one may be enough, in which case there may possibly be just one PCN encoding (ie a revised 5696 that now uses the 01 codepoint), so possibly may be Standards track - ?? > Anyway, i take your point that we need to think about Status. > > s3.3.1: >> [CL-specific] The outcome of the comparison is not very sensitive >> to the value of the CLE-limit in practice, because when threshold- >> marking occurs it tends to persist long enough that threshold- >> marked traffic becomes a large proportion of the received traffic >> in a given interval. > This statement worries me. It sounds like a characteristic of an > unstable system. If the value is that non-critical why are we > bothering? > > [phil] admission control system. imagine the pcn-domain has one bottleneck link. If it can cope with the current number of calls (their bandwidth), then no pkts gets threshold-marked, so the CLE = 0. If there are too many, then all pkts gets threshold-marked, so the CLE = 1. If there is almost exactly the right number of calls, then threshold-marking will tend to be on for a while, then off for a while (perhaps when several flows are transmitting less traffic than normal), so the CLE will jiggle about between 0& 1. If the CLE is< CLE-limit (say CLE-limit = 0.6& current CLE = 0.5), when a new call admission request happens to arrive then it gets admitted. But then there's more traffic and it's likely that the CLE will rise to 1 - hence another admission request will get blocked. When a call finishes, then the reverse is true. > > Now suppose we had in fact configured CLE-limit = 0.4, then in the scenario above the call request would have been blocked. However, (1) the PCN-domain has only admitted one fewer call, (2) a short time later, either the CLE happens to be lower or a call departs, and then the next admission request is accepted. > > All this means that it doesn't matter much exactly what you set CLE-limit to - it barely affects the average number of calls admitted. The argument above is hand-wavy, but lots of simulations have been done that show this is true (I hope i'm representing the results correctly) > So the lack of sensitivity to CLE-limit seems like a good thing. > > > Minor issues: > > s6: The potential introduction of a centralized decision point appears > to provide additional attack points beyond the architecture in RFC 5559. > It appears to me that the requests for information about specific flows > to the ingress are ighly vulnerable as they (probably) contain all the > information needed to craft a DoS attack on the flow. > > [phil] seems a good point to me > -- Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. For more information, see http://www.oxfam.org.uk/get_involved/fundraise/walk/ and follow us on Twitter at http://twitter.com/CambOxfamWalk. From tom111.taylor@bell.net Tue Jun 14 11:20:15 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9A11E816D; Tue, 14 Jun 2011 11:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.652 X-Spam-Level: X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K-rw4NCh-sx; Tue, 14 Jun 2011 11:20:14 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6264011E812E; Tue, 14 Jun 2011 11:20:14 -0700 (PDT) Received: from BLU0-SMTP55 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 11:20:13 -0700 X-Originating-IP: [76.70.76.63] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.76.63]) by BLU0-SMTP55.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 11:20:12 -0700 Date: Tue, 14 Jun 2011 14:20:12 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Elwyn Davies References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> In-Reply-To: <4DF7986B.5020108@dial.pipex.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2011 18:20:13.0214 (UTC) FILETIME=[B3E4D3E0:01CC2ABF] Cc: pcn@ietf.org, General Area Reviwing Team Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:20:15 -0000 Well, Elwyn, here's the problem: apparently the likelihood of these ever being deployed is vanishingly small. So a protocol could be defined, but it would be wasted effort. (It's also outside the PCN charter, most likely because RSVP was supposed to be the transport. But that's another story ...) In fact, I and a couple of others started to define a Diameter application to do the job. I'm not sure how realistic that would have been, in terms of messaging load. Diameter transport is supposed to be over TLS these days. Tom T. On 14/06/2011 1:20 PM, Elwyn Davies wrote: > Hi, Phil. > > It strikes me that the first and second points below are something which > David Harrington perhaps ought to give an opinion on. He has got to > defend it to the IESG. > > On the first point, my feeling is that neither the requirements doc nor > this doc is sufficient to guarantee an interoperable implementation. > There seems to me to be a cleft stick here (irrespective of whether this > ends up as informational or experimental.) The WG is is specifying > pieces of functionality that go in two or more different types of boxes > (three if there is a separate implementation of the central decision > point). If the system is going to be generally deployable or even to be > experimented with there may be different implementations. The box types > communicate using the information specifications in the doc. This > appears to require protocol definitions. Where they are defined is > another issue but I feel it has either to be in this doc or in another > doc referenced from this. If they aren't specified I can't see that > anybody will be interested in making commercial implementations. > > I see David didn't make any comment about this situation in his write > up, so maybe I am over reacting. > > Regards, > Elwyn > > ... From internet-drafts@ietf.org Wed Jun 15 14:50:35 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E89E8036; Wed, 15 Jun 2011 14:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVDwTz5+2Igb; Wed, 15 Jun 2011 14:50:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0C9E8032; Wed, 15 Jun 2011 14:50:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615215034.17040.78482.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 14:50:34 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:50:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Requirements for Signaling of (Pre-) Congestion Informat= ion in a DiffServ Domain Author(s) : Georgios Karagiannis Tom Taylor Kwok Ho Chan Michael Menth Philip Eardley Filename : draft-ietf-pcn-signaling-requirements-05.txt Pages : 8 Date : 2011-06-15 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: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the latter case, (2) is not required). The signaling requirements pertain in particular to two edge behaviours, "controlled load (CL)" and "single marking (SM)" [draft-ietf-pcn-cl-edge- behaviour-08], [draft-ietf-pcn-sm-edge-behaviour-05]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-0= 5.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-05= .txt From slblake@petri-meat.com Wed Jun 15 14:54:33 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6AD11E81CC for ; Wed, 15 Jun 2011 14:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJtK9wbaoUbV for ; Wed, 15 Jun 2011 14:54:33 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 04CE411E81AF for ; Wed, 15 Jun 2011 14:54:32 -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 1QWy2d-0002Ru-92; Wed, 15 Jun 2011 17:54:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Jun 2011 17:54:22 -0400 From: Steven Blake To: In-Reply-To: <20110615215034.17040.78482.idtracker@ietfa.amsl.com> References: <20110615215034.17040.78482.idtracker@ietfa.amsl.com> Message-ID: <288c96f28db17af6eb1ac425eb1bfe5b@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/0.4.2 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] I-D Action: draft-ietf-pcn-signaling-requirements-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:54:33 -0000 FYI - This version just fixes the ID-nits; there are no textual changes. I am currently working on fixing the nits in draft-ietf-pcn-encoding-comparison. On Wed, 15 Jun 2011 14:50:34 -0700, internet-drafts@ietf.org wrote: > 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 : Requirements for Signaling of (Pre-) Congestion > Information in a DiffServ Domain > Author(s) : Georgios Karagiannis > Tom Taylor > Kwok Ho Chan > Michael Menth > Philip Eardley > Filename : draft-ietf-pcn-signaling-requirements-05.txt > Pages : 8 > Date : 2011-06-15 > > 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: (1) PCN-feedback-information is carried from the > PCN-egress- > node to the decision point;(2) the decision point may ask the PCN- > ingress-node to measure, and report back, the rate of sent PCN- > traffic between that PCN-ingress-node and PCN-egress-node. The > decision point may be either collocated with the PCN-ingress-node > or > a centralized node (in the latter case, (2) is not required). The > signaling requirements pertain in particular to two edge > behaviours, > "controlled load (CL)" and "single marking (SM)" > [draft-ietf-pcn-cl-edge- behaviour-08], > [draft-ietf-pcn-sm-edge-behaviour-05]. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-05.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Regards, // Steve From internet-drafts@ietf.org Thu Jun 16 18:23:30 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823A011E8126; Thu, 16 Jun 2011 18:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsCLFXoHysxJ; Thu, 16 Jun 2011 18:23:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55811E80E8; Thu, 16 Jun 2011 18:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110617012328.4830.36217.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 18:23:28 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:23:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Overview of Pre-Congestion Notification Encoding Author(s) : Georgios Karagiannis Kwok Ho Chan Toby Moncaster Michael Menth Philip Eardley Bob Briscoe Filename : draft-ietf-pcn-encoding-comparison-06.txt Pages : 18 Date : 2011-06-16 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-06.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-06.txt From slblake@petri-meat.com Thu Jun 16 18:28:39 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ABF11E8130 for ; Thu, 16 Jun 2011 18:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcmzHB7Ku9a8 for ; Thu, 16 Jun 2011 18:28:35 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id DF6B211E8104 for ; Thu, 16 Jun 2011 18:28:34 -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 1QXNrJ-0004JD-J8; Thu, 16 Jun 2011 21:28:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Jun 2011 21:28:29 -0400 From: Steven Blake To: In-Reply-To: <20110617012328.4830.36217.idtracker@ietfa.amsl.com> References: <20110617012328.4830.36217.idtracker@ietfa.amsl.com> Message-ID: X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/0.4.2 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] I-D Action: draft-ietf-pcn-encoding-comparison-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:28:39 -0000 FYI - this is a fixed-nits version of the draft. The only textual changes are the deletion of several unused references. I would appreciate it if someone could take a look at the draft and make sure that I didn't screw anything up. On Thu, 16 Jun 2011 18:23:28 -0700, internet-drafts@ietf.org wrote: > 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 : Overview of Pre-Congestion Notification Encoding > Author(s) : Georgios Karagiannis > Kwok Ho Chan > Toby Moncaster > Michael Menth > Philip Eardley > Bob Briscoe > Filename : draft-ietf-pcn-encoding-comparison-06.txt > Pages : 18 > Date : 2011-06-16 > > The objective of Pre-Congestion Notification (PCN) is to protect > the > quality of service (QoS) of inelastic flows within a Diffserv > domain. > On every link in the PCN domain, the overall rate of the > PCN-traffic > is metered, and PCN-packets are appropriately marked when certain > configured rates are exceeded. Egress nodes provide decision > points > with information about the PCN-marks of PCN-packets which allows > them > to take decisions about whether to admit or block a new flow > request, > and to terminate some already admitted flows during serious pre- > congestion. > > The PCN Working Group explored a number of approaches for encoding > this pre-congestion information into the IP header. This document > provides details of all those approaches along with an explanation > of > the constraints that had to be met by any solution. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-06.txt > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn Regards, // Steve From karagian@cs.utwente.nl Thu Jun 16 23:27:36 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203921F0C3F for ; Thu, 16 Jun 2011 23:27:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4oRiJLn08Io for ; Thu, 16 Jun 2011 23:27:35 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B51F0C3B for ; Thu, 16 Jun 2011 23:27:34 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5H6QKNt008770; Fri, 17 Jun 2011 08:26:21 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 17 Jun 2011 06:27:35 +0000 To: "Steven Blake" , "pcn@ietf.org" Date: Fri, 17 Jun 2011 06:27:35 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <6kgzuiuG.1308292055.0593820.karagian@ewi.utwente.nl> In-Reply-To: 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.11 Subject: Re: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 06:27:36 -0000 Hi Steve, Thanks very much! I will do that! Best regards, Georgios On 6/17/2011, "Steven Blake" wrote: > FYI - this is a fixed-nits version of the draft. The only textual > changes are the deletion of several unused references. I would > appreciate it if someone could take a look at the draft and make sure > that I didn't screw anything up. > > > On Thu, 16 Jun 2011 18:23:28 -0700, internet-drafts@ietf.org wrote: > >> 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. >> >> =09Title : Overview of Pre-Congestion Notification Encoding >> =09Author(s) : Georgios Karagiannis >> Kwok Ho Chan >> Toby Moncaster >> Michael Menth >> Philip Eardley >> Bob Briscoe >> =09Filename : draft-ietf-pcn-encoding-comparison-06.txt >> =09Pages : 18 >> =09Date : 2011-06-16 >> >> The objective of Pre-Congestion Notification (PCN) is to protect >> the >> quality of service (QoS) of inelastic flows within a Diffserv >> domain. >> On every link in the PCN domain, the overall rate of the >> PCN-traffic >> is metered, and PCN-packets are appropriately marked when certain >> configured rates are exceeded. Egress nodes provide decision >> points >> with information about the PCN-marks of PCN-packets which allows >> them >> to take decisions about whether to admit or block a new flow >> request, >> and to terminate some already admitted flows during serious pre- >> congestion. >> >> The PCN Working Group explored a number of approaches for encoding >> this pre-congestion information into the IP header. This document >> provides details of all those approaches along with an explanation >> of >> the constraints that had to be met by any solution. >> >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-06.= txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-06.t= xt >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > > > Regards, > > // Steve >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From ietfdbh@comcast.net Tue Jun 21 12:49:34 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E15C1F0C72 for ; Tue, 21 Jun 2011 12:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Bxp9bPT+eID for ; Tue, 21 Jun 2011 12:49:32 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4D11F0C6F for ; Tue, 21 Jun 2011 12:49:32 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id yjmc1g0011vXlb856jpZba; Tue, 21 Jun 2011 19:49:33 +0000 Received: from davidPC ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id yjpX1g0082JQnJT3djpXCA; Tue, 21 Jun 2011 19:49:32 +0000 From: "David Harrington" To: "'Elwyn Davies'" , References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> In-Reply-To: <4DF7986B.5020108@dial.pipex.com> Date: Tue, 21 Jun 2011 15:49:25 -0400 Message-ID: <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> 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.1.7600.16807 Thread-Index: Acwqt2w5hFeN+fVjQuWGiyHiFNXbHAFjCY5A Cc: pcn@ietf.org, 'General Area Reviwing Team' Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:49:35 -0000 Hi, The WG was chartered to specify the (3) encoding and transport of (pre-)congestion information between the interior and domain egress ... and ... (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress I interpret that to mean the transport protocol and the message formats should be specified in the documents. I have to agree with Elwyn that lack of such formats means implementations are likely to not be interoperable. I am not sure what protocols would be suitable for these tasks; other readers may have similar concerns. I think the specification would benefit from a mandatory-to-implement protocol expected to carry the configuration and reported information. At a minimum, there should be a clear information model (RFC3444) about the information to be transported. The data type and range of values should be included in the information model for each counter and configuration variable. I think it would be better to specify a mandatory-to-implement protocol, or at least a recommended-to-implement protocol, and a corresponding data model to ensure interoperability. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > Sent: Tuesday, June 14, 2011 1:21 PM > To: philip.eardley@bt.com > Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > Subject: Re: Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 > > Hi, Phil. > > It strikes me that the first and second points below are > something which > David Harrington perhaps ought to give an opinion on. He has got to > defend it to the IESG. > > On the first point, my feeling is that neither the > requirements doc nor > this doc is sufficient to guarantee an interoperable implementation. > There seems to me to be a cleft stick here (irrespective of > whether this > ends up as informational or experimental.) The WG is is specifying > pieces of functionality that go in two or more different > types of boxes > (three if there is a separate implementation of the central decision > point). If the system is going to be generally deployable or > even to be > experimented with there may be different implementations. > The box types > communicate using the information specifications in the doc. This > appears to require protocol definitions. Where they are defined is > another issue but I feel it has either to be in this doc or > in another > doc referenced from this. If they aren't specified I can't see that > anybody will be interested in making commercial implementations. > > I see David didn't make any comment about this situation in his write > up, so maybe I am over reacting. > > Regards, > Elwyn > > > > > > On 13/06/2011 18:04, philip.eardley@bt.com wrote: > > Elwyn, > > > > Thanks for the detailed review. > > A few follow-ups in-line > > Thanks > > phil > > > > -- > > Major issues: > > The draft contains partial definitions of two control > protocols (egress > > -> decision point; decision point -> ingress). It does > not make it > > clear whether the reader is expected to get full > definitions of these > > protocols here or whether there will be another document > that specifies > > these protocols completely. As is stands one could build > the protocols > > and pretty much guarantee that they would not be interoperable with > > other implementations since message formats are not > included although > > high level specs are. The document needs to be much > clearer about what > > is expected to happen here. > > > > [phil] there is another document, " Requirements for > Signaling of (Pre-) Congestion Information in a DiffServ > Domain" > [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > nts-04] that deals with your issue to some extent. It doesn't > specify message formats but does at least specify better what > information the messages must contain. My understanding is > that unfortunately the WG doesn't feel it has the effort to > specify these protocols completely. > > > > > > Use of EXP codepoint: My understanding of what is said in > RFC 5696 is > > that EXP is supposed to be left for other (non=PCN) systems to use. > > This draft uses it. Is this sensible? Is this whole draft > experimental > > really? > > [phil] the intention of rfc5696 was that the EXP codepoint > is for experimental *PCN* encodings - ie beyond the baseline. > For instance, the CL behaviour needs separate codepoints for > (PCN) threshold-marking and (PCN) excess-traffic-marking& > this would require using the EXP codepoint. > > However...... There is currently some discussion on what > PCN encodings to specify beyond the baseline. At the time we > wrote the baseline, we envisaged the need for several > encodings - however it now seems that one may be enough, in > which case there may possibly be just one PCN encoding (ie a > revised 5696 that now uses the 01 codepoint), so possibly may > be Standards track - ?? > > Anyway, i take your point that we need to think about Status. > > > > s3.3.1: > >> [CL-specific] The outcome of the comparison is not very sensitive > >> to the value of the CLE-limit in practice, because > when threshold- > >> marking occurs it tends to persist long enough that > threshold- > >> marked traffic becomes a large proportion of the > received traffic > >> in a given interval. > > This statement worries me. It sounds like a characteristic of an > > unstable system. If the value is that non-critical why are we > > bothering? > > > > [phil] admission control system. imagine the pcn-domain has > one bottleneck link. If it can cope with the current number > of calls (their bandwidth), then no pkts gets > threshold-marked, so the CLE = 0. If there are too many, then > all pkts gets threshold-marked, so the CLE = 1. If there is > almost exactly the right number of calls, then > threshold-marking will tend to be on for a while, then off > for a while (perhaps when several flows are transmitting less > traffic than normal), so the CLE will jiggle about between 0& > 1. If the CLE is< CLE-limit (say CLE-limit = 0.6& current > CLE = 0.5), when a new call admission request happens to > arrive then it gets admitted. But then there's more traffic > and it's likely that the CLE will rise to 1 - hence another > admission request will get blocked. When a call finishes, > then the reverse is true. > > > > Now suppose we had in fact configured CLE-limit = 0.4, then > in the scenario above the call request would have been > blocked. However, (1) the PCN-domain has only admitted one > fewer call, (2) a short time later, either the CLE happens to > be lower or a call departs, and then the next admission > request is accepted. > > > > All this means that it doesn't matter much exactly what you > set CLE-limit to - it barely affects the average number of > calls admitted. The argument above is hand-wavy, but lots of > simulations have been done that show this is true (I hope i'm > representing the results correctly) > > So the lack of sensitivity to CLE-limit seems like a good thing. > > > > > > Minor issues: > > > > s6: The potential introduction of a centralized decision > point appears > > to provide additional attack points beyond the architecture > in RFC 5559. > > It appears to me that the requests for information about > specific flows > > to the ingress are ighly vulnerable as they (probably) > contain all the > > information needed to craft a DoS attack on the flow. > > > > [phil] seems a good point to me > > > > > -- > Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > For more information, see > http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > follow us on Twitter at http://twitter.com/CambOxfamWalk. > > From tom111.taylor@bell.net Tue Jun 21 17:31:08 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED2F11E8092; Tue, 21 Jun 2011 17:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCQTjohAFlqo; Tue, 21 Jun 2011 17:31:07 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by ietfa.amsl.com (Postfix) with ESMTP id C50BE11E8079; Tue, 21 Jun 2011 17:31:06 -0700 (PDT) Received: from BLU0-SMTP78 ([65.55.111.72]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 17:31:05 -0700 X-Originating-IP: [76.70.76.63] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.76.63]) by BLU0-SMTP78.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 17:31:05 -0700 Date: Tue, 21 Jun 2011 20:31:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Harrington References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> In-Reply-To: <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2011 00:31:05.0597 (UTC) FILETIME=[AC3D42D0:01CC3073] Cc: pcn@ietf.org, 'Elwyn Davies' , 'General Area Reviwing Team' Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 00:31:08 -0000 OK, I'll take up the good work. Just to start with, I propose to submit interim updates as I wished I had back a few months ago. I'll go on from there. On 21/06/2011 3:49 PM, David Harrington wrote: > Hi, > > The WG was chartered to specify the > (3) encoding and transport of (pre-)congestion information > between the interior and domain egress > ... and ... > (5) encoding and transport of (pre-)congestion information > between the egress and the controlling domain ingress > > I interpret that to mean the transport protocol and the message > formats should be specified in the documents. > I have to agree with Elwyn that lack of such formats means > implementations are likely to not be interoperable. > I am not sure what protocols would be suitable for these tasks; other > readers may have similar concerns. > > I think the specification would benefit from a mandatory-to-implement > protocol expected to carry the configuration and reported information. > At a minimum, there should be a clear information model (RFC3444) > about the information to be transported. > The data type and range of values should be included in the > information model for each counter and configuration variable. > I think it would be better to specify a mandatory-to-implement > protocol, or at least a recommended-to-implement protocol, and a > corresponding data model to ensure interoperability. > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > >> -----Original Message----- >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] >> Sent: Tuesday, June 14, 2011 1:21 PM >> To: philip.eardley@bt.com >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team >> Subject: Re: Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 >> >> Hi, Phil. >> >> It strikes me that the first and second points below are >> something which >> David Harrington perhaps ought to give an opinion on. He has got to >> defend it to the IESG. >> >> On the first point, my feeling is that neither the >> requirements doc nor >> this doc is sufficient to guarantee an interoperable implementation. > >> There seems to me to be a cleft stick here (irrespective of >> whether this >> ends up as informational or experimental.) The WG is is specifying >> pieces of functionality that go in two or more different >> types of boxes >> (three if there is a separate implementation of the central decision > >> point). If the system is going to be generally deployable or >> even to be >> experimented with there may be different implementations. >> The box types >> communicate using the information specifications in the doc. This >> appears to require protocol definitions. Where they are defined is >> another issue but I feel it has either to be in this doc or >> in another >> doc referenced from this. If they aren't specified I can't see that > >> anybody will be interested in making commercial implementations. >> >> I see David didn't make any comment about this situation in his > write >> up, so maybe I am over reacting. >> >> Regards, >> Elwyn >> >> >> >> >> >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: >>> Elwyn, >>> >>> Thanks for the detailed review. >>> A few follow-ups in-line >>> Thanks >>> phil >>> >>> -- >>> Major issues: >>> The draft contains partial definitions of two control >> protocols (egress >>> -> decision point; decision point -> ingress). It does >> not make it >>> clear whether the reader is expected to get full >> definitions of these >>> protocols here or whether there will be another document >> that specifies >>> these protocols completely. As is stands one could build >> the protocols >>> and pretty much guarantee that they would not be interoperable > with >>> other implementations since message formats are not >> included although >>> high level specs are. The document needs to be much >> clearer about what >>> is expected to happen here. >>> >>> [phil] there is another document, " Requirements for >> Signaling of (Pre-) Congestion Information in a DiffServ >> Domain" >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme >> nts-04] that deals with your issue to some extent. It doesn't >> specify message formats but does at least specify better what >> information the messages must contain. My understanding is >> that unfortunately the WG doesn't feel it has the effort to >> specify these protocols completely. >>> >>> >>> Use of EXP codepoint: My understanding of what is said in >> RFC 5696 is >>> that EXP is supposed to be left for other (non=PCN) systems to > use. >>> This draft uses it. Is this sensible? Is this whole draft >> experimental >>> really? >>> [phil] the intention of rfc5696 was that the EXP codepoint >> is for experimental *PCN* encodings - ie beyond the baseline. >> For instance, the CL behaviour needs separate codepoints for >> (PCN) threshold-marking and (PCN) excess-traffic-marking& >> this would require using the EXP codepoint. >>> However...... There is currently some discussion on what >> PCN encodings to specify beyond the baseline. At the time we >> wrote the baseline, we envisaged the need for several >> encodings - however it now seems that one may be enough, in >> which case there may possibly be just one PCN encoding (ie a >> revised 5696 that now uses the 01 codepoint), so possibly may >> be Standards track - ?? >>> Anyway, i take your point that we need to think about Status. >>> >>> s3.3.1: >>>> [CL-specific] The outcome of the comparison is not very sensitive >>>> to the value of the CLE-limit in practice, because >> when threshold- >>>> marking occurs it tends to persist long enough that >> threshold- >>>> marked traffic becomes a large proportion of the >> received traffic >>>> in a given interval. >>> This statement worries me. It sounds like a characteristic of an >>> unstable system. If the value is that non-critical why are we >>> bothering? >>> >>> [phil] admission control system. imagine the pcn-domain has >> one bottleneck link. If it can cope with the current number >> of calls (their bandwidth), then no pkts gets >> threshold-marked, so the CLE = 0. If there are too many, then >> all pkts gets threshold-marked, so the CLE = 1. If there is >> almost exactly the right number of calls, then >> threshold-marking will tend to be on for a while, then off >> for a while (perhaps when several flows are transmitting less >> traffic than normal), so the CLE will jiggle about between 0& >> 1. If the CLE is< CLE-limit (say CLE-limit = 0.6& current >> CLE = 0.5), when a new call admission request happens to >> arrive then it gets admitted. But then there's more traffic >> and it's likely that the CLE will rise to 1 - hence another >> admission request will get blocked. When a call finishes, >> then the reverse is true. >>> >>> Now suppose we had in fact configured CLE-limit = 0.4, then >> in the scenario above the call request would have been >> blocked. However, (1) the PCN-domain has only admitted one >> fewer call, (2) a short time later, either the CLE happens to >> be lower or a call departs, and then the next admission >> request is accepted. >>> >>> All this means that it doesn't matter much exactly what you >> set CLE-limit to - it barely affects the average number of >> calls admitted. The argument above is hand-wavy, but lots of >> simulations have been done that show this is true (I hope i'm >> representing the results correctly) >>> So the lack of sensitivity to CLE-limit seems like a good thing. >>> >>> >>> Minor issues: >>> >>> s6: The potential introduction of a centralized decision >> point appears >>> to provide additional attack points beyond the architecture >> in RFC 5559. >>> It appears to me that the requests for information about >> specific flows >>> to the ingress are ighly vulnerable as they (probably) >> contain all the >>> information needed to craft a DoS attack on the flow. >>> >>> [phil] seems a good point to me >>> >> >> >> -- >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. >> For more information, see >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and >> follow us on Twitter at http://twitter.com/CambOxfamWalk. >> >> > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From Ruediger.Geib@telekom.de Tue Jun 21 23:21:40 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8175F11E8070; Tue, 21 Jun 2011 23:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMkESjCZkqc1; Tue, 21 Jun 2011 23:21:39 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6B45711E8094; Tue, 21 Jun 2011 23:21:37 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 22 Jun 2011 08:21:29 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by he110890 ([10.134.92.131]) with mapi; Wed, 22 Jun 2011 08:21:29 +0200 From: To: , Date: Wed, 22 Jun 2011 08:21:27 +0200 Thread-Topic: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 06:21:40 -0000 Hi Tom, which work are you taking up? - specifying the madatory to implement protocol. - or specifying a minimum clear information model (RFC3444). I prefer the latter above the former. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: Wednesday, June 22, 2011 2:31 AM To: David Harrington Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 OK, I'll take up the good work. Just to start with, I propose to submit interim updates as I wished I had back a few months ago. I'll go on from there. On 21/06/2011 3:49 PM, David Harrington wrote: > Hi, > > The WG was chartered to specify the > (3) encoding and transport of (pre-)congestion information > between the interior and domain egress > ... and ... > (5) encoding and transport of (pre-)congestion information > between the egress and the controlling domain ingress > > I interpret that to mean the transport protocol and the message > formats should be specified in the documents. > I have to agree with Elwyn that lack of such formats means > implementations are likely to not be interoperable. > I am not sure what protocols would be suitable for these tasks; other > readers may have similar concerns. > > I think the specification would benefit from a mandatory-to-implement > protocol expected to carry the configuration and reported information. > At a minimum, there should be a clear information model (RFC3444) > about the information to be transported. > The data type and range of values should be included in the > information model for each counter and configuration variable. > I think it would be better to specify a mandatory-to-implement > protocol, or at least a recommended-to-implement protocol, and a > corresponding data model to ensure interoperability. > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > >> -----Original Message----- >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] >> Sent: Tuesday, June 14, 2011 1:21 PM >> To: philip.eardley@bt.com >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team >> Subject: Re: Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 >> >> Hi, Phil. >> >> It strikes me that the first and second points below are >> something which >> David Harrington perhaps ought to give an opinion on. He has got to >> defend it to the IESG. >> >> On the first point, my feeling is that neither the >> requirements doc nor >> this doc is sufficient to guarantee an interoperable implementation. > >> There seems to me to be a cleft stick here (irrespective of >> whether this >> ends up as informational or experimental.) The WG is is specifying >> pieces of functionality that go in two or more different >> types of boxes >> (three if there is a separate implementation of the central decision > >> point). If the system is going to be generally deployable or >> even to be >> experimented with there may be different implementations. >> The box types >> communicate using the information specifications in the doc. This >> appears to require protocol definitions. Where they are defined is >> another issue but I feel it has either to be in this doc or >> in another >> doc referenced from this. If they aren't specified I can't see that > >> anybody will be interested in making commercial implementations. >> >> I see David didn't make any comment about this situation in his > write >> up, so maybe I am over reacting. >> >> Regards, >> Elwyn >> >> >> >> >> >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: >>> Elwyn, >>> >>> Thanks for the detailed review. >>> A few follow-ups in-line >>> Thanks >>> phil >>> >>> -- >>> Major issues: >>> The draft contains partial definitions of two control >> protocols (egress >>> -> decision point; decision point -> ingress). It does >> not make it >>> clear whether the reader is expected to get full >> definitions of these >>> protocols here or whether there will be another document >> that specifies >>> these protocols completely. As is stands one could build >> the protocols >>> and pretty much guarantee that they would not be interoperable > with >>> other implementations since message formats are not >> included although >>> high level specs are. The document needs to be much >> clearer about what >>> is expected to happen here. >>> >>> [phil] there is another document, " Requirements for >> Signaling of (Pre-) Congestion Information in a DiffServ >> Domain" >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme >> nts-04] that deals with your issue to some extent. It doesn't >> specify message formats but does at least specify better what >> information the messages must contain. My understanding is >> that unfortunately the WG doesn't feel it has the effort to >> specify these protocols completely. >>> >>> >>> Use of EXP codepoint: My understanding of what is said in >> RFC 5696 is >>> that EXP is supposed to be left for other (non=3DPCN) systems to > use. >>> This draft uses it. Is this sensible? Is this whole draft >> experimental >>> really? >>> [phil] the intention of rfc5696 was that the EXP codepoint >> is for experimental *PCN* encodings - ie beyond the baseline. >> For instance, the CL behaviour needs separate codepoints for >> (PCN) threshold-marking and (PCN) excess-traffic-marking& >> this would require using the EXP codepoint. >>> However...... There is currently some discussion on what >> PCN encodings to specify beyond the baseline. At the time we >> wrote the baseline, we envisaged the need for several >> encodings - however it now seems that one may be enough, in >> which case there may possibly be just one PCN encoding (ie a >> revised 5696 that now uses the 01 codepoint), so possibly may >> be Standards track - ?? >>> Anyway, i take your point that we need to think about Status. >>> >>> s3.3.1: >>>> [CL-specific] The outcome of the comparison is not very sensitive >>>> to the value of the CLE-limit in practice, because >> when threshold- >>>> marking occurs it tends to persist long enough that >> threshold- >>>> marked traffic becomes a large proportion of the >> received traffic >>>> in a given interval. >>> This statement worries me. It sounds like a characteristic of an >>> unstable system. If the value is that non-critical why are we >>> bothering? >>> >>> [phil] admission control system. imagine the pcn-domain has >> one bottleneck link. If it can cope with the current number >> of calls (their bandwidth), then no pkts gets >> threshold-marked, so the CLE =3D 0. If there are too many, then >> all pkts gets threshold-marked, so the CLE =3D 1. If there is >> almost exactly the right number of calls, then >> threshold-marking will tend to be on for a while, then off >> for a while (perhaps when several flows are transmitting less >> traffic than normal), so the CLE will jiggle about between 0& >> 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current >> CLE =3D 0.5), when a new call admission request happens to >> arrive then it gets admitted. But then there's more traffic >> and it's likely that the CLE will rise to 1 - hence another >> admission request will get blocked. When a call finishes, >> then the reverse is true. >>> >>> Now suppose we had in fact configured CLE-limit =3D 0.4, then >> in the scenario above the call request would have been >> blocked. However, (1) the PCN-domain has only admitted one >> fewer call, (2) a short time later, either the CLE happens to >> be lower or a call departs, and then the next admission >> request is accepted. >>> >>> All this means that it doesn't matter much exactly what you >> set CLE-limit to - it barely affects the average number of >> calls admitted. The argument above is hand-wavy, but lots of >> simulations have been done that show this is true (I hope i'm >> representing the results correctly) >>> So the lack of sensitivity to CLE-limit seems like a good thing. >>> >>> >>> Minor issues: >>> >>> s6: The potential introduction of a centralized decision >> point appears >>> to provide additional attack points beyond the architecture >> in RFC 5559. >>> It appears to me that the requests for information about >> specific flows >>> to the ingress are ighly vulnerable as they (probably) >> contain all the >>> information needed to craft a DoS attack on the flow. >>> >>> [phil] seems a good point to me >>> >> >> >> -- >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. >> For more information, see >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and >> follow us on Twitter at http://twitter.com/CambOxfamWalk. >> >> > > _______________________________________________ > 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 Ruediger.Geib@telekom.de Tue Jun 21 23:27:30 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E7011E8090 for ; Tue, 21 Jun 2011 23:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7-msN90J9uX for ; Tue, 21 Jun 2011 23:27:29 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEB211E8070 for ; Tue, 21 Jun 2011 23:27:28 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 22 Jun 2011 08:27:14 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 22 Jun 2011 08:27:13 +0200 From: To: Date: Wed, 22 Jun 2011 08:27:13 +0200 Thread-Topic: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwqt2w5hFeN+fVjQuWGiyHiFNXbHAFjCY5AABhNMAA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF042F@HE111648.emea1.cds.t-internal.com> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> In-Reply-To: <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 06:27:30 -0000 Hi Phil, as mentioned earlier on that list, there's a proposal from Michael and me to standradise an edge behaviour working without feedback signalling. Looking at the new work item resulting from the Gen art LC, it may have merits to continue without feedback signaling as an alternative approach (I'm not looking at it as an exclusive option, it is however a valid alternative to me). Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of David= Harrington Sent: Tuesday, June 21, 2011 9:49 PM To: 'Elwyn Davies'; philip.eardley@bt.com Cc: pcn@ietf.org; 'General Area Reviwing Team' Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Hi, The WG was chartered to specify the (3) encoding and transport of (pre-)congestion information between the interior and domain egress ... and ... (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress I interpret that to mean the transport protocol and the message formats should be specified in the documents. I have to agree with Elwyn that lack of such formats means implementations are likely to not be interoperable. I am not sure what protocols would be suitable for these tasks; other readers may have similar concerns. I think the specification would benefit from a mandatory-to-implement protocol expected to carry the configuration and reported information. At a minimum, there should be a clear information model (RFC3444) about the information to be transported. The data type and range of values should be included in the information model for each counter and configuration variable. I think it would be better to specify a mandatory-to-implement protocol, or at least a recommended-to-implement protocol, and a corresponding data model to ensure interoperability. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > Sent: Tuesday, June 14, 2011 1:21 PM > To: philip.eardley@bt.com > Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > Subject: Re: Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 > > Hi, Phil. > > It strikes me that the first and second points below are > something which > David Harrington perhaps ought to give an opinion on. He has got to > defend it to the IESG. > > On the first point, my feeling is that neither the > requirements doc nor > this doc is sufficient to guarantee an interoperable implementation. > There seems to me to be a cleft stick here (irrespective of > whether this > ends up as informational or experimental.) The WG is is specifying > pieces of functionality that go in two or more different > types of boxes > (three if there is a separate implementation of the central decision > point). If the system is going to be generally deployable or > even to be > experimented with there may be different implementations. > The box types > communicate using the information specifications in the doc. This > appears to require protocol definitions. Where they are defined is > another issue but I feel it has either to be in this doc or > in another > doc referenced from this. If they aren't specified I can't see that > anybody will be interested in making commercial implementations. > > I see David didn't make any comment about this situation in his write > up, so maybe I am over reacting. > > Regards, > Elwyn > > > > > > On 13/06/2011 18:04, philip.eardley@bt.com wrote: > > Elwyn, > > > > Thanks for the detailed review. > > A few follow-ups in-line > > Thanks > > phil > > > > -- > > Major issues: > > The draft contains partial definitions of two control > protocols (egress > > -> decision point; decision point -> ingress). It does > not make it > > clear whether the reader is expected to get full > definitions of these > > protocols here or whether there will be another document > that specifies > > these protocols completely. As is stands one could build > the protocols > > and pretty much guarantee that they would not be interoperable with > > other implementations since message formats are not > included although > > high level specs are. The document needs to be much > clearer about what > > is expected to happen here. > > > > [phil] there is another document, " Requirements for > Signaling of (Pre-) Congestion Information in a DiffServ > Domain" > [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > nts-04] that deals with your issue to some extent. It doesn't > specify message formats but does at least specify better what > information the messages must contain. My understanding is > that unfortunately the WG doesn't feel it has the effort to > specify these protocols completely. > > > > > > Use of EXP codepoint: My understanding of what is said in > RFC 5696 is > > that EXP is supposed to be left for other (non=3DPCN) systems to use. > > This draft uses it. Is this sensible? Is this whole draft > experimental > > really? > > [phil] the intention of rfc5696 was that the EXP codepoint > is for experimental *PCN* encodings - ie beyond the baseline. > For instance, the CL behaviour needs separate codepoints for > (PCN) threshold-marking and (PCN) excess-traffic-marking& > this would require using the EXP codepoint. > > However...... There is currently some discussion on what > PCN encodings to specify beyond the baseline. At the time we > wrote the baseline, we envisaged the need for several > encodings - however it now seems that one may be enough, in > which case there may possibly be just one PCN encoding (ie a > revised 5696 that now uses the 01 codepoint), so possibly may > be Standards track - ?? > > Anyway, i take your point that we need to think about Status. > > > > s3.3.1: > >> [CL-specific] The outcome of the comparison is not very sensitive > >> to the value of the CLE-limit in practice, because > when threshold- > >> marking occurs it tends to persist long enough that > threshold- > >> marked traffic becomes a large proportion of the > received traffic > >> in a given interval. > > This statement worries me. It sounds like a characteristic of an > > unstable system. If the value is that non-critical why are we > > bothering? > > > > [phil] admission control system. imagine the pcn-domain has > one bottleneck link. If it can cope with the current number > of calls (their bandwidth), then no pkts gets > threshold-marked, so the CLE =3D 0. If there are too many, then > all pkts gets threshold-marked, so the CLE =3D 1. If there is > almost exactly the right number of calls, then > threshold-marking will tend to be on for a while, then off > for a while (perhaps when several flows are transmitting less > traffic than normal), so the CLE will jiggle about between 0& > 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current > CLE =3D 0.5), when a new call admission request happens to > arrive then it gets admitted. But then there's more traffic > and it's likely that the CLE will rise to 1 - hence another > admission request will get blocked. When a call finishes, > then the reverse is true. > > > > Now suppose we had in fact configured CLE-limit =3D 0.4, then > in the scenario above the call request would have been > blocked. However, (1) the PCN-domain has only admitted one > fewer call, (2) a short time later, either the CLE happens to > be lower or a call departs, and then the next admission > request is accepted. > > > > All this means that it doesn't matter much exactly what you > set CLE-limit to - it barely affects the average number of > calls admitted. The argument above is hand-wavy, but lots of > simulations have been done that show this is true (I hope i'm > representing the results correctly) > > So the lack of sensitivity to CLE-limit seems like a good thing. > > > > > > Minor issues: > > > > s6: The potential introduction of a centralized decision > point appears > > to provide additional attack points beyond the architecture > in RFC 5559. > > It appears to me that the requests for information about > specific flows > > to the ingress are ighly vulnerable as they (probably) > contain all the > > information needed to craft a DoS attack on the flow. > > > > [phil] seems a good point to me > > > > > -- > Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > For more information, see > http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > follow us on Twitter at http://twitter.com/CambOxfamWalk. > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Wed Jun 22 01:16:48 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA0F21F846D; Wed, 22 Jun 2011 01:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.971 X-Spam-Level: X-Spam-Status: No, score=-102.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzkdj9VtJWnE; Wed, 22 Jun 2011 01:16:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 035BD21F8469; Wed, 22 Jun 2011 01:16:47 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 22 Jun 2011 09:16:46 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.222]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 22 Jun 2011 09:16:45 +0100 From: To: , , Date: Wed, 22 Jun 2011 09:16:43 +0100 Thread-Topic: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQAAPKtvA= Message-ID: <9510D26531EF184D9017DF24659BB87F32E07BCC20@EMV65-UKRD.domain1.systemhost.net> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 08:16:48 -0000 Personally I think it unlikely that the WG would ever complete the former The latter might be plausible, though having flicked at 3444 i can't tell e= xactly what we're missing. It seems to say that an information model is an = absrtact model about relationships between objects and can be defined infor= mally - (since I havent consciously written one, I'm being vague) - the com= bination of CL & signalling reqts seems quite close to this? Thanks for progressing Tom. phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Ruedi= ger.Geib@telekom.de Sent: 22 June 2011 07:21 To: tom111.taylor@bell.net; ietfdbh@comcast.net Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Hi Tom, which work are you taking up? - specifying the madatory to implement protocol. - or specifying a minimum clear information model (RFC3444). I prefer the latter above the former. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: Wednesday, June 22, 2011 2:31 AM To: David Harrington Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 OK, I'll take up the good work. Just to start with, I propose to submit interim updates as I wished I had back a few months ago. I'll go on from there. On 21/06/2011 3:49 PM, David Harrington wrote: > Hi, > > The WG was chartered to specify the > (3) encoding and transport of (pre-)congestion information > between the interior and domain egress > ... and ... > (5) encoding and transport of (pre-)congestion information > between the egress and the controlling domain ingress > > I interpret that to mean the transport protocol and the message > formats should be specified in the documents. > I have to agree with Elwyn that lack of such formats means > implementations are likely to not be interoperable. > I am not sure what protocols would be suitable for these tasks; other > readers may have similar concerns. > > I think the specification would benefit from a mandatory-to-implement > protocol expected to carry the configuration and reported information. > At a minimum, there should be a clear information model (RFC3444) > about the information to be transported. > The data type and range of values should be included in the > information model for each counter and configuration variable. > I think it would be better to specify a mandatory-to-implement > protocol, or at least a recommended-to-implement protocol, and a > corresponding data model to ensure interoperability. > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > >> -----Original Message----- >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] >> Sent: Tuesday, June 14, 2011 1:21 PM >> To: philip.eardley@bt.com >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team >> Subject: Re: Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 >> >> Hi, Phil. >> >> It strikes me that the first and second points below are >> something which >> David Harrington perhaps ought to give an opinion on. He has got to >> defend it to the IESG. >> >> On the first point, my feeling is that neither the >> requirements doc nor >> this doc is sufficient to guarantee an interoperable implementation. > >> There seems to me to be a cleft stick here (irrespective of >> whether this >> ends up as informational or experimental.) The WG is is specifying >> pieces of functionality that go in two or more different >> types of boxes >> (three if there is a separate implementation of the central decision > >> point). If the system is going to be generally deployable or >> even to be >> experimented with there may be different implementations. >> The box types >> communicate using the information specifications in the doc. This >> appears to require protocol definitions. Where they are defined is >> another issue but I feel it has either to be in this doc or >> in another >> doc referenced from this. If they aren't specified I can't see that > >> anybody will be interested in making commercial implementations. >> >> I see David didn't make any comment about this situation in his > write >> up, so maybe I am over reacting. >> >> Regards, >> Elwyn >> >> >> >> >> >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: >>> Elwyn, >>> >>> Thanks for the detailed review. >>> A few follow-ups in-line >>> Thanks >>> phil >>> >>> -- >>> Major issues: >>> The draft contains partial definitions of two control >> protocols (egress >>> -> decision point; decision point -> ingress). It does >> not make it >>> clear whether the reader is expected to get full >> definitions of these >>> protocols here or whether there will be another document >> that specifies >>> these protocols completely. As is stands one could build >> the protocols >>> and pretty much guarantee that they would not be interoperable > with >>> other implementations since message formats are not >> included although >>> high level specs are. The document needs to be much >> clearer about what >>> is expected to happen here. >>> >>> [phil] there is another document, " Requirements for >> Signaling of (Pre-) Congestion Information in a DiffServ >> Domain" >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme >> nts-04] that deals with your issue to some extent. It doesn't >> specify message formats but does at least specify better what >> information the messages must contain. My understanding is >> that unfortunately the WG doesn't feel it has the effort to >> specify these protocols completely. >>> >>> >>> Use of EXP codepoint: My understanding of what is said in >> RFC 5696 is >>> that EXP is supposed to be left for other (non=3DPCN) systems to > use. >>> This draft uses it. Is this sensible? Is this whole draft >> experimental >>> really? >>> [phil] the intention of rfc5696 was that the EXP codepoint >> is for experimental *PCN* encodings - ie beyond the baseline. >> For instance, the CL behaviour needs separate codepoints for >> (PCN) threshold-marking and (PCN) excess-traffic-marking& >> this would require using the EXP codepoint. >>> However...... There is currently some discussion on what >> PCN encodings to specify beyond the baseline. At the time we >> wrote the baseline, we envisaged the need for several >> encodings - however it now seems that one may be enough, in >> which case there may possibly be just one PCN encoding (ie a >> revised 5696 that now uses the 01 codepoint), so possibly may >> be Standards track - ?? >>> Anyway, i take your point that we need to think about Status. >>> >>> s3.3.1: >>>> [CL-specific] The outcome of the comparison is not very sensitive >>>> to the value of the CLE-limit in practice, because >> when threshold- >>>> marking occurs it tends to persist long enough that >> threshold- >>>> marked traffic becomes a large proportion of the >> received traffic >>>> in a given interval. >>> This statement worries me. It sounds like a characteristic of an >>> unstable system. If the value is that non-critical why are we >>> bothering? >>> >>> [phil] admission control system. imagine the pcn-domain has >> one bottleneck link. If it can cope with the current number >> of calls (their bandwidth), then no pkts gets >> threshold-marked, so the CLE =3D 0. If there are too many, then >> all pkts gets threshold-marked, so the CLE =3D 1. If there is >> almost exactly the right number of calls, then >> threshold-marking will tend to be on for a while, then off >> for a while (perhaps when several flows are transmitting less >> traffic than normal), so the CLE will jiggle about between 0& >> 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current >> CLE =3D 0.5), when a new call admission request happens to >> arrive then it gets admitted. But then there's more traffic >> and it's likely that the CLE will rise to 1 - hence another >> admission request will get blocked. When a call finishes, >> then the reverse is true. >>> >>> Now suppose we had in fact configured CLE-limit =3D 0.4, then >> in the scenario above the call request would have been >> blocked. However, (1) the PCN-domain has only admitted one >> fewer call, (2) a short time later, either the CLE happens to >> be lower or a call departs, and then the next admission >> request is accepted. >>> >>> All this means that it doesn't matter much exactly what you >> set CLE-limit to - it barely affects the average number of >> calls admitted. The argument above is hand-wavy, but lots of >> simulations have been done that show this is true (I hope i'm >> representing the results correctly) >>> So the lack of sensitivity to CLE-limit seems like a good thing. >>> >>> >>> Minor issues: >>> >>> s6: The potential introduction of a centralized decision >> point appears >>> to provide additional attack points beyond the architecture >> in RFC 5559. >>> It appears to me that the requests for information about >> specific flows >>> to the ingress are ighly vulnerable as they (probably) >> contain all the >>> information needed to craft a DoS attack on the flow. >>> >>> [phil] seems a good point to me >>> >> >> >> -- >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. >> For more information, see >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and >> follow us on Twitter at http://twitter.com/CambOxfamWalk. >> >> > > _______________________________________________ > 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tom111.taylor@bell.net Wed Jun 22 02:49:15 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126611E80CE; Wed, 22 Jun 2011 02:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.307 X-Spam-Level: X-Spam-Status: No, score=-100.307 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsvST++YjooP; Wed, 22 Jun 2011 02:49:15 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by ietfa.amsl.com (Postfix) with ESMTP id 10FAE11E807F; Wed, 22 Jun 2011 02:49:14 -0700 (PDT) Received: from BLU0-SMTP15 ([65.55.111.72]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 02:46:09 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP15.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 02:46:08 -0700 Date: Wed, 22 Jun 2011 05:46:07 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk> <9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net> <4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2011 09:46:08.0875 (UTC) FILETIME=[368A33B0:01CC30C1] Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 09:49:15 -0000 The CL and SM drafts should definitely specify the information models. In my own mind, the actual protocol specification belongs in another document, since it would be common to the two models. Other edge behaviours (e.g. the piggybacking approach) would require their own protocol solutions. Seriously, would Diameter make sense as the protocol? If so, the work is mostly done and I would just revive draft-huang-dime-pcn-collection and bring it up to date. On 22/06/2011 2:21 AM, Ruediger.Geib@telekom.de wrote: > Hi Tom, > > which work are you taking up? > > - specifying the madatory to implement protocol. > - or specifying a minimum clear information model (RFC3444). > > I prefer the latter above the former. > > >.. From karagian@cs.utwente.nl Wed Jun 22 02:52:07 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728C911E807F; Wed, 22 Jun 2011 02:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-1.198, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8KiQagqtoD1; Wed, 22 Jun 2011 02:52:06 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9911E80CF; Wed, 22 Jun 2011 02:52:05 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5M9oR83023533; Wed, 22 Jun 2011 11:50:27 +0200 (MEST) Received: from 130.89.12.129 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 22 Jun 2011 09:51:47 +0000 To: "philip.eardley@bt.com" , "Ruediger.Geib@telekom.de" , "tom111.taylor@bell.net" , "ietfdbh@comcast.net" Date: Wed, 22 Jun 2011 09:51:47 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E07BCC20@EMV65-UKRD.domain1.systemhost.net> 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 22 Jun 2011 11:50:39 +0200 (MEST) Cc: "pcn@ietf.org" , "gen-art@ietf.org" , "elwynd@dial.pipex.com" Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 09:52:07 -0000 Hi all, I agree with Phil regarding the fact that the Information model can be described as an abstract model informally to show the relationships between objects. In particular RFC 3444 mentions: "IMs can be defined in an informal way, using natural languages such as English. An example of such an IM is provided by RFC 3290 [9], which describes a conceptual model of a Diffserv Router and specifies the relationships between the components of such a router that need to be managed." Regarding the possible options to support interoperability, I also think that the latter might be plausible. I see three options of implementing this: 1) each PCN edge behaviour draft will contain such an information model 2) a default information model will be included in the signaling requirements draft 3) a new draft should be started by the PCN WG to describe such an information model With which option should we proceed? Please also note that I have started modifying the following draft that can be used as an example of how a signaling protocol can be applied to support an PCN edge behaviour. http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01 The target is to submit this draft to tsvwg. However, I do not think that I will be able to submit this draft before the submission deadline (4th of July). Tom and Francois were willing to help on commenting and/or contributing to this. Best regards, Georgios On 6/22/2011, "philip.eardley@bt.com" wrote: >Personally I think it unlikely that the WG would ever complete the former > >The latter might be plausible, though having flicked at 3444 i can't tell ex= actly what we're missing. It seems to say that an information model is an abs= rtact model about relationships between objects and can be defined informally= - (since I havent consciously written one, I'm being vague) - the combinatio= n of CL & signalling reqts seems quite close to this? > >Thanks for progressing Tom. >phil > >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Ruedig= er.Geib@telekom.de >Sent: 22 June 2011 07:21 >To: tom111.taylor@bell.net; ietfdbh@comcast.net >Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com >Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 > >Hi Tom, > >which work are you taking up? > >- specifying the madatory to implement protocol. >- or specifying a minimum clear information model (RFC3444). > >I prefer the latter above the former. > > >Regards, > >Ruediger > >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Ta= ylor >Sent: Wednesday, June 22, 2011 2:31 AM >To: David Harrington >Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' >Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 > >OK, I'll take up the good work. Just to start with, I propose to submit >interim updates as I wished I had back a few months ago. I'll go on from >there. > >On 21/06/2011 3:49 PM, David Harrington wrote: >> Hi, >> >> The WG was chartered to specify the >> (3) encoding and transport of (pre-)congestion information >> between the interior and domain egress >> ... and ... >> (5) encoding and transport of (pre-)congestion information >> between the egress and the controlling domain ingress >> >> I interpret that to mean the transport protocol and the message >> formats should be specified in the documents. >> I have to agree with Elwyn that lack of such formats means >> implementations are likely to not be interoperable. >> I am not sure what protocols would be suitable for these tasks; other >> readers may have similar concerns. >> >> I think the specification would benefit from a mandatory-to-implement >> protocol expected to carry the configuration and reported information. >> At a minimum, there should be a clear information model (RFC3444) >> about the information to be transported. >> The data type and range of values should be included in the >> information model for each counter and configuration variable. >> I think it would be better to specify a mandatory-to-implement >> protocol, or at least a recommended-to-implement protocol, and a >> corresponding data model to ensure interoperability. >> >> David Harrington >> Director, IETF Transport Area >> ietfdbh@comcast.net (preferred for ietf) >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >> >>> -----Original Message----- >>> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] >>> Sent: Tuesday, June 14, 2011 1:21 PM >>> To: philip.eardley@bt.com >>> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team >>> Subject: Re: Gen-art LC review of >> draft-ietf-pcn-cl-edge-behaviour-08 >>> >>> Hi, Phil. >>> >>> It strikes me that the first and second points below are >>> something which >>> David Harrington perhaps ought to give an opinion on. He has got to >>> defend it to the IESG. >>> >>> On the first point, my feeling is that neither the >>> requirements doc nor >>> this doc is sufficient to guarantee an interoperable implementation. >> >>> There seems to me to be a cleft stick here (irrespective of >>> whether this >>> ends up as informational or experimental.) The WG is is specifying >>> pieces of functionality that go in two or more different >>> types of boxes >>> (three if there is a separate implementation of the central decision >> >>> point). If the system is going to be generally deployable or >>> even to be >>> experimented with there may be different implementations. >>> The box types >>> communicate using the information specifications in the doc. This >>> appears to require protocol definitions. Where they are defined is >>> another issue but I feel it has either to be in this doc or >>> in another >>> doc referenced from this. If they aren't specified I can't see that >> >>> anybody will be interested in making commercial implementations. >>> >>> I see David didn't make any comment about this situation in his >> write >>> up, so maybe I am over reacting. >>> >>> Regards, >>> Elwyn >>> >>> >>> >>> >>> >>> On 13/06/2011 18:04, philip.eardley@bt.com wrote: >>>> Elwyn, >>>> >>>> Thanks for the detailed review. >>>> A few follow-ups in-line >>>> Thanks >>>> phil >>>> >>>> -- >>>> Major issues: >>>> The draft contains partial definitions of two control >>> protocols (egress >>>> -> decision point; decision point -> ingress). It does >>> not make it >>>> clear whether the reader is expected to get full >>> definitions of these >>>> protocols here or whether there will be another document >>> that specifies >>>> these protocols completely. As is stands one could build >>> the protocols >>>> and pretty much guarantee that they would not be interoperable >> with >>>> other implementations since message formats are not >>> included although >>>> high level specs are. The document needs to be much >>> clearer about what >>>> is expected to happen here. >>>> >>>> [phil] there is another document, " Requirements for >>> Signaling of (Pre-) Congestion Information in a DiffServ >>> Domain" >>> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme >>> nts-04] that deals with your issue to some extent. It doesn't >>> specify message formats but does at least specify better what >>> information the messages must contain. My understanding is >>> that unfortunately the WG doesn't feel it has the effort to >>> specify these protocols completely. >>>> >>>> >>>> Use of EXP codepoint: My understanding of what is said in >>> RFC 5696 is >>>> that EXP is supposed to be left for other (non=3DPCN) systems to >> use. >>>> This draft uses it. Is this sensible? Is this whole draft >>> experimental >>>> really? >>>> [phil] the intention of rfc5696 was that the EXP codepoint >>> is for experimental *PCN* encodings - ie beyond the baseline. >>> For instance, the CL behaviour needs separate codepoints for >>> (PCN) threshold-marking and (PCN) excess-traffic-marking& >>> this would require using the EXP codepoint. >>>> However...... There is currently some discussion on what >>> PCN encodings to specify beyond the baseline. At the time we >>> wrote the baseline, we envisaged the need for several >>> encodings - however it now seems that one may be enough, in >>> which case there may possibly be just one PCN encoding (ie a >>> revised 5696 that now uses the 01 codepoint), so possibly may >>> be Standards track - ?? >>>> Anyway, i take your point that we need to think about Status. >>>> >>>> s3.3.1: >>>>> [CL-specific] The outcome of the comparison is not very sensitive >>>>> to the value of the CLE-limit in practice, because >>> when threshold- >>>>> marking occurs it tends to persist long enough that >>> threshold- >>>>> marked traffic becomes a large proportion of the >>> received traffic >>>>> in a given interval. >>>> This statement worries me. It sounds like a characteristic of an >>>> unstable system. If the value is that non-critical why are we >>>> bothering? >>>> >>>> [phil] admission control system. imagine the pcn-domain has >>> one bottleneck link. If it can cope with the current number >>> of calls (their bandwidth), then no pkts gets >>> threshold-marked, so the CLE =3D 0. If there are too many, then >>> all pkts gets threshold-marked, so the CLE =3D 1. If there is >>> almost exactly the right number of calls, then >>> threshold-marking will tend to be on for a while, then off >>> for a while (perhaps when several flows are transmitting less >>> traffic than normal), so the CLE will jiggle about between 0& >>> 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current >>> CLE =3D 0.5), when a new call admission request happens to >>> arrive then it gets admitted. But then there's more traffic >>> and it's likely that the CLE will rise to 1 - hence another >>> admission request will get blocked. When a call finishes, >>> then the reverse is true. >>>> >>>> Now suppose we had in fact configured CLE-limit =3D 0.4, then >>> in the scenario above the call request would have been >>> blocked. However, (1) the PCN-domain has only admitted one >>> fewer call, (2) a short time later, either the CLE happens to >>> be lower or a call departs, and then the next admission >>> request is accepted. >>>> >>>> All this means that it doesn't matter much exactly what you >>> set CLE-limit to - it barely affects the average number of >>> calls admitted. The argument above is hand-wavy, but lots of >>> simulations have been done that show this is true (I hope i'm >>> representing the results correctly) >>>> So the lack of sensitivity to CLE-limit seems like a good thing. >>>> >>>> >>>> Minor issues: >>>> >>>> s6: The potential introduction of a centralized decision >>> point appears >>>> to provide additional attack points beyond the architecture >>> in RFC 5559. >>>> It appears to me that the requests for information about >>> specific flows >>>> to the ingress are ighly vulnerable as they (probably) >>> contain all the >>>> information needed to craft a DoS attack on the flow. >>>> >>>> [phil] seems a good point to me >>>> >>> >>> >>> -- >>> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. >>> For more information, see >>> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and >>> follow us on Twitter at http://twitter.com/CambOxfamWalk. >>> >>> >> >> _______________________________________________ >> 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 >_______________________________________________ >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 ietfdbh@comcast.net Wed Jun 22 07:10:05 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBFA21F84F5 for ; Wed, 22 Jun 2011 07:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acq-yzYvOpm6 for ; Wed, 22 Jun 2011 07:10:04 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2506621F84F9 for ; Wed, 22 Jun 2011 07:10:04 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id z27u1g0061c6gX85C2A4Tp; Wed, 22 Jun 2011 14:10:04 +0000 Received: from davidPC ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id z2A01g0272JQnJT3j2A1m6; Wed, 22 Jun 2011 14:10:03 +0000 From: "David Harrington" To: , , References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk><9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net><4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> <9510D26531EF184D9017DF24659BB87F32E07BCC20@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E07BCC20@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 22 Jun 2011 10:09:55 -0400 Message-ID: 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.1.7600.16807 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQAAPKtvAAC27UgA== Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:10:05 -0000 Hi, The main thing you are missing is an explanation of how you will achieve interoperability. The charter calls for specification of the encoding and transport of the information between points in the system: > > (3) encoding and transport of (pre-)congestion information > > between the interior and domain egress > > ... and ... > > (5) encoding and transport of (pre-)congestion information > > between the egress and the controlling domain ingress How will the information get from the interior to the domain egress, if the PCN processing for the interior node is implemented by vendor A and the PCN processing for the domain egress node is implemented by vendor B? In what message format will vendor A send it so that it can be interpreted consistently by the receiver, regardless of which vendor implements the receiver? What format validation shoudl be performed by teh receiever, what conditions constitute a receiving error, and what error codes should be returned by the receiver that will be understood by the sender? Ditto for the players in 5) The specification as written seems imcomplete because it does not deal with specifying the encoding and transport of the information. Am I just missing it, or is it really just not there? An information model can help to understand the properties of the data to be transported, but it doesn't really solve the problem of transporting the data in a standardized, interoperable manner. You will need to work hard to convince me that there is strong TECHNICAL justification for not providing REQUIRED (or at least RECOMMENDED) protocols and message formats/data models involved. I would likely need to work hard subsequently to convince the IESG. If the problem is that the WG has no energy, we can solve that in a much simpler way than updating these documents - we can just close the WG. If the WG doesn't have enough energy to complete these documents first, we can abandon the documents. That could save everybody a lot of time - WG editors, WG reviewers, WG chairs, the AD, IETF Last Call reviewers from various directorates, the IESG, IANA ... I think the Internet would benefit from this technology, and I would consider abandoning these documents at this point an awful waste of time, given how much work has been put into them already, so I STRONGLY encourage the WG to find the energy to complete their agreed-upon deliverables, but if it is WG consensus to abandon them, I guess I would have to accept that WG consensus. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Wednesday, June 22, 2011 4:17 AM > To: Ruediger.Geib@telekom.de; tom111.taylor@bell.net; > ietfdbh@comcast.net > Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com > Subject: RE: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > Personally I think it unlikely that the WG would ever > complete the former > > The latter might be plausible, though having flicked at 3444 > i can't tell exactly what we're missing. It seems to say that > an information model is an absrtact model about relationships > between objects and can be defined informally - (since I > havent consciously written one, I'm being vague) - the > combination of CL & signalling reqts seems quite close to this? > > Thanks for progressing Tom. > phil > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Ruediger.Geib@telekom.de > Sent: 22 June 2011 07:21 > To: tom111.taylor@bell.net; ietfdbh@comcast.net > Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com > Subject: Re: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > Hi Tom, > > which work are you taking up? > > - specifying the madatory to implement protocol. > - or specifying a minimum clear information model (RFC3444). > > I prefer the latter above the former. > > > Regards, > > Ruediger > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Wednesday, June 22, 2011 2:31 AM > To: David Harrington > Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' > Subject: Re: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > OK, I'll take up the good work. Just to start with, I propose > to submit > interim updates as I wished I had back a few months ago. I'll > go on from > there. > > On 21/06/2011 3:49 PM, David Harrington wrote: > > Hi, > > > > The WG was chartered to specify the > > (3) encoding and transport of (pre-)congestion information > > between the interior and domain egress > > ... and ... > > (5) encoding and transport of (pre-)congestion information > > between the egress and the controlling domain ingress > > > > I interpret that to mean the transport protocol and the message > > formats should be specified in the documents. > > I have to agree with Elwyn that lack of such formats means > > implementations are likely to not be interoperable. > > I am not sure what protocols would be suitable for these > tasks; other > > readers may have similar concerns. > > > > I think the specification would benefit from a > mandatory-to-implement > > protocol expected to carry the configuration and reported > information. > > At a minimum, there should be a clear information model (RFC3444) > > about the information to be transported. > > The data type and range of values should be included in the > > information model for each counter and configuration variable. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure interoperability. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > >> -----Original Message----- > >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > >> Sent: Tuesday, June 14, 2011 1:21 PM > >> To: philip.eardley@bt.com > >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > >> Subject: Re: Gen-art LC review of > > draft-ietf-pcn-cl-edge-behaviour-08 > >> > >> Hi, Phil. > >> > >> It strikes me that the first and second points below are > >> something which > >> David Harrington perhaps ought to give an opinion on. He has got to > >> defend it to the IESG. > >> > >> On the first point, my feeling is that neither the > >> requirements doc nor > >> this doc is sufficient to guarantee an interoperable > implementation. > > > >> There seems to me to be a cleft stick here (irrespective of > >> whether this > >> ends up as informational or experimental.) The WG is is specifying > >> pieces of functionality that go in two or more different > >> types of boxes > >> (three if there is a separate implementation of the > central decision > > > >> point). If the system is going to be generally deployable or > >> even to be > >> experimented with there may be different implementations. > >> The box types > >> communicate using the information specifications in the doc. This > >> appears to require protocol definitions. Where they are defined is > >> another issue but I feel it has either to be in this doc or > >> in another > >> doc referenced from this. If they aren't specified I > can't see that > > > >> anybody will be interested in making commercial implementations. > >> > >> I see David didn't make any comment about this situation in his > > write > >> up, so maybe I am over reacting. > >> > >> Regards, > >> Elwyn > >> > >> > >> > >> > >> > >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: > >>> Elwyn, > >>> > >>> Thanks for the detailed review. > >>> A few follow-ups in-line > >>> Thanks > >>> phil > >>> > >>> -- > >>> Major issues: > >>> The draft contains partial definitions of two control > >> protocols (egress > >>> -> decision point; decision point -> ingress). It does > >> not make it > >>> clear whether the reader is expected to get full > >> definitions of these > >>> protocols here or whether there will be another document > >> that specifies > >>> these protocols completely. As is stands one could build > >> the protocols > >>> and pretty much guarantee that they would not be interoperable > > with > >>> other implementations since message formats are not > >> included although > >>> high level specs are. The document needs to be much > >> clearer about what > >>> is expected to happen here. > >>> > >>> [phil] there is another document, " Requirements for > >> Signaling of (Pre-) Congestion Information in a DiffServ > >> Domain" > >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > >> nts-04] that deals with your issue to some extent. It doesn't > >> specify message formats but does at least specify better what > >> information the messages must contain. My understanding is > >> that unfortunately the WG doesn't feel it has the effort to > >> specify these protocols completely. > >>> > >>> > >>> Use of EXP codepoint: My understanding of what is said in > >> RFC 5696 is > >>> that EXP is supposed to be left for other (non=PCN) systems to > > use. > >>> This draft uses it. Is this sensible? Is this whole draft > >> experimental > >>> really? > >>> [phil] the intention of rfc5696 was that the EXP codepoint > >> is for experimental *PCN* encodings - ie beyond the baseline. > >> For instance, the CL behaviour needs separate codepoints for > >> (PCN) threshold-marking and (PCN) excess-traffic-marking& > >> this would require using the EXP codepoint. > >>> However...... There is currently some discussion on what > >> PCN encodings to specify beyond the baseline. At the time we > >> wrote the baseline, we envisaged the need for several > >> encodings - however it now seems that one may be enough, in > >> which case there may possibly be just one PCN encoding (ie a > >> revised 5696 that now uses the 01 codepoint), so possibly may > >> be Standards track - ?? > >>> Anyway, i take your point that we need to think about Status. > >>> > >>> s3.3.1: > >>>> [CL-specific] The outcome of the comparison is not very sensitive > >>>> to the value of the CLE-limit in practice, because > >> when threshold- > >>>> marking occurs it tends to persist long enough that > >> threshold- > >>>> marked traffic becomes a large proportion of the > >> received traffic > >>>> in a given interval. > >>> This statement worries me. It sounds like a characteristic of an > >>> unstable system. If the value is that non-critical why are we > >>> bothering? > >>> > >>> [phil] admission control system. imagine the pcn-domain has > >> one bottleneck link. If it can cope with the current number > >> of calls (their bandwidth), then no pkts gets > >> threshold-marked, so the CLE = 0. If there are too many, then > >> all pkts gets threshold-marked, so the CLE = 1. If there is > >> almost exactly the right number of calls, then > >> threshold-marking will tend to be on for a while, then off > >> for a while (perhaps when several flows are transmitting less > >> traffic than normal), so the CLE will jiggle about between 0& > >> 1. If the CLE is< CLE-limit (say CLE-limit = 0.6& current > >> CLE = 0.5), when a new call admission request happens to > >> arrive then it gets admitted. But then there's more traffic > >> and it's likely that the CLE will rise to 1 - hence another > >> admission request will get blocked. When a call finishes, > >> then the reverse is true. > >>> > >>> Now suppose we had in fact configured CLE-limit = 0.4, then > >> in the scenario above the call request would have been > >> blocked. However, (1) the PCN-domain has only admitted one > >> fewer call, (2) a short time later, either the CLE happens to > >> be lower or a call departs, and then the next admission > >> request is accepted. > >>> > >>> All this means that it doesn't matter much exactly what you > >> set CLE-limit to - it barely affects the average number of > >> calls admitted. The argument above is hand-wavy, but lots of > >> simulations have been done that show this is true (I hope i'm > >> representing the results correctly) > >>> So the lack of sensitivity to CLE-limit seems like a good thing. > >>> > >>> > >>> Minor issues: > >>> > >>> s6: The potential introduction of a centralized decision > >> point appears > >>> to provide additional attack points beyond the architecture > >> in RFC 5559. > >>> It appears to me that the requests for information about > >> specific flows > >>> to the ingress are ighly vulnerable as they (probably) > >> contain all the > >>> information needed to craft a DoS attack on the flow. > >>> > >>> [phil] seems a good point to me > >>> > >> > >> > >> -- > >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > >> For more information, see > >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > >> follow us on Twitter at http://twitter.com/CambOxfamWalk. > >> > >> > > > > _______________________________________________ > > 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 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From ietfdbh@comcast.net Wed Jun 22 07:18:34 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4BB21F84C5 for ; Wed, 22 Jun 2011 07:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiJk1qoDoLsx for ; Wed, 22 Jun 2011 07:18:32 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 82E9521F84C0 for ; Wed, 22 Jun 2011 07:18:32 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id z2GK1g0020vyq2s5F2JZEm; Wed, 22 Jun 2011 14:18:33 +0000 Received: from davidPC ([67.189.235.106]) by omta05.westchester.pa.mail.comcast.net with comcast id z2JX1g00u2JQnJT3R2JXWR; Wed, 22 Jun 2011 14:18:32 +0000 From: "David Harrington" To: , References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk><9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net><4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> Date: Wed, 22 Jun 2011 10:18:25 -0400 Message-ID: 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.1.7600.16807 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQABCht2A= Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:18:34 -0000 Hi, Let me clear that an abstract information model alone is not likely to satisfy the concern, which is interoperability. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure interoperability. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, June 22, 2011 2:21 AM > To: tom111.taylor@bell.net; ietfdbh@comcast.net > Cc: pcn@ietf.org; elwynd@dial.pipex.com; gen-art@ietf.org > Subject: RE: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > Hi Tom, > > which work are you taking up? > > - specifying the madatory to implement protocol. > - or specifying a minimum clear information model (RFC3444). > > I prefer the latter above the former. > > > Regards, > > Ruediger > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Wednesday, June 22, 2011 2:31 AM > To: David Harrington > Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' > Subject: Re: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > OK, I'll take up the good work. Just to start with, I propose > to submit > interim updates as I wished I had back a few months ago. I'll > go on from > there. > > On 21/06/2011 3:49 PM, David Harrington wrote: > > Hi, > > > > The WG was chartered to specify the > > (3) encoding and transport of (pre-)congestion information > > between the interior and domain egress > > ... and ... > > (5) encoding and transport of (pre-)congestion information > > between the egress and the controlling domain ingress > > > > I interpret that to mean the transport protocol and the message > > formats should be specified in the documents. > > I have to agree with Elwyn that lack of such formats means > > implementations are likely to not be interoperable. > > I am not sure what protocols would be suitable for these > tasks; other > > readers may have similar concerns. > > > > I think the specification would benefit from a > mandatory-to-implement > > protocol expected to carry the configuration and reported > information. > > At a minimum, there should be a clear information model (RFC3444) > > about the information to be transported. > > The data type and range of values should be included in the > > information model for each counter and configuration variable. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure interoperability. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > >> -----Original Message----- > >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > >> Sent: Tuesday, June 14, 2011 1:21 PM > >> To: philip.eardley@bt.com > >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > >> Subject: Re: Gen-art LC review of > > draft-ietf-pcn-cl-edge-behaviour-08 > >> > >> Hi, Phil. > >> > >> It strikes me that the first and second points below are > >> something which > >> David Harrington perhaps ought to give an opinion on. He has got to > >> defend it to the IESG. > >> > >> On the first point, my feeling is that neither the > >> requirements doc nor > >> this doc is sufficient to guarantee an interoperable > implementation. > > > >> There seems to me to be a cleft stick here (irrespective of > >> whether this > >> ends up as informational or experimental.) The WG is is specifying > >> pieces of functionality that go in two or more different > >> types of boxes > >> (three if there is a separate implementation of the > central decision > > > >> point). If the system is going to be generally deployable or > >> even to be > >> experimented with there may be different implementations. > >> The box types > >> communicate using the information specifications in the doc. This > >> appears to require protocol definitions. Where they are defined is > >> another issue but I feel it has either to be in this doc or > >> in another > >> doc referenced from this. If they aren't specified I > can't see that > > > >> anybody will be interested in making commercial implementations. > >> > >> I see David didn't make any comment about this situation in his > > write > >> up, so maybe I am over reacting. > >> > >> Regards, > >> Elwyn > >> > >> > >> > >> > >> > >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: > >>> Elwyn, > >>> > >>> Thanks for the detailed review. > >>> A few follow-ups in-line > >>> Thanks > >>> phil > >>> > >>> -- > >>> Major issues: > >>> The draft contains partial definitions of two control > >> protocols (egress > >>> -> decision point; decision point -> ingress). It does > >> not make it > >>> clear whether the reader is expected to get full > >> definitions of these > >>> protocols here or whether there will be another document > >> that specifies > >>> these protocols completely. As is stands one could build > >> the protocols > >>> and pretty much guarantee that they would not be interoperable > > with > >>> other implementations since message formats are not > >> included although > >>> high level specs are. The document needs to be much > >> clearer about what > >>> is expected to happen here. > >>> > >>> [phil] there is another document, " Requirements for > >> Signaling of (Pre-) Congestion Information in a DiffServ > >> Domain" > >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > >> nts-04] that deals with your issue to some extent. It doesn't > >> specify message formats but does at least specify better what > >> information the messages must contain. My understanding is > >> that unfortunately the WG doesn't feel it has the effort to > >> specify these protocols completely. > >>> > >>> > >>> Use of EXP codepoint: My understanding of what is said in > >> RFC 5696 is > >>> that EXP is supposed to be left for other (non=PCN) systems to > > use. > >>> This draft uses it. Is this sensible? Is this whole draft > >> experimental > >>> really? > >>> [phil] the intention of rfc5696 was that the EXP codepoint > >> is for experimental *PCN* encodings - ie beyond the baseline. > >> For instance, the CL behaviour needs separate codepoints for > >> (PCN) threshold-marking and (PCN) excess-traffic-marking& > >> this would require using the EXP codepoint. > >>> However...... There is currently some discussion on what > >> PCN encodings to specify beyond the baseline. At the time we > >> wrote the baseline, we envisaged the need for several > >> encodings - however it now seems that one may be enough, in > >> which case there may possibly be just one PCN encoding (ie a > >> revised 5696 that now uses the 01 codepoint), so possibly may > >> be Standards track - ?? > >>> Anyway, i take your point that we need to think about Status. > >>> > >>> s3.3.1: > >>>> [CL-specific] The outcome of the comparison is not very sensitive > >>>> to the value of the CLE-limit in practice, because > >> when threshold- > >>>> marking occurs it tends to persist long enough that > >> threshold- > >>>> marked traffic becomes a large proportion of the > >> received traffic > >>>> in a given interval. > >>> This statement worries me. It sounds like a characteristic of an > >>> unstable system. If the value is that non-critical why are we > >>> bothering? > >>> > >>> [phil] admission control system. imagine the pcn-domain has > >> one bottleneck link. If it can cope with the current number > >> of calls (their bandwidth), then no pkts gets > >> threshold-marked, so the CLE = 0. If there are too many, then > >> all pkts gets threshold-marked, so the CLE = 1. If there is > >> almost exactly the right number of calls, then > >> threshold-marking will tend to be on for a while, then off > >> for a while (perhaps when several flows are transmitting less > >> traffic than normal), so the CLE will jiggle about between 0& > >> 1. If the CLE is< CLE-limit (say CLE-limit = 0.6& current > >> CLE = 0.5), when a new call admission request happens to > >> arrive then it gets admitted. But then there's more traffic > >> and it's likely that the CLE will rise to 1 - hence another > >> admission request will get blocked. When a call finishes, > >> then the reverse is true. > >>> > >>> Now suppose we had in fact configured CLE-limit = 0.4, then > >> in the scenario above the call request would have been > >> blocked. However, (1) the PCN-domain has only admitted one > >> fewer call, (2) a short time later, either the CLE happens to > >> be lower or a call departs, and then the next admission > >> request is accepted. > >>> > >>> All this means that it doesn't matter much exactly what you > >> set CLE-limit to - it barely affects the average number of > >> calls admitted. The argument above is hand-wavy, but lots of > >> simulations have been done that show this is true (I hope i'm > >> representing the results correctly) > >>> So the lack of sensitivity to CLE-limit seems like a good thing. > >>> > >>> > >>> Minor issues: > >>> > >>> s6: The potential introduction of a centralized decision > >> point appears > >>> to provide additional attack points beyond the architecture > >> in RFC 5559. > >>> It appears to me that the requests for information about > >> specific flows > >>> to the ingress are ighly vulnerable as they (probably) > >> contain all the > >>> information needed to craft a DoS attack on the flow. > >>> > >>> [phil] seems a good point to me > >>> > >> > >> > >> -- > >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > >> For more information, see > >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > >> follow us on Twitter at http://twitter.com/CambOxfamWalk. > >> > >> > > > > _______________________________________________ > > 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 philip.eardley@bt.com Wed Jun 22 07:36:35 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9821F8440; Wed, 22 Jun 2011 07:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njvZjua5W5rp; Wed, 22 Jun 2011 07:36:34 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id B09D421F843A; Wed, 22 Jun 2011 07:36:33 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 22 Jun 2011 15:36:26 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.222]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 22 Jun 2011 15:36:26 +0100 From: To: , , Date: Wed, 22 Jun 2011 15:36:24 +0100 Thread-Topic: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQAAPKtvAAC27UgAABWtlQ Message-ID: <9510D26531EF184D9017DF24659BB87F32E084F2BB@EMV65-UKRD.domain1.systemhost.net> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk><9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net><4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> <9510D26531EF184D9017DF24659BB87F32E07BCC20@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:36:36 -0000 I take your point that ideally there would be an explanation of how to achi= eve interoperability and that it would have formats, error codes etc specif= ied. I guess this would be a rfc3444 Data Model. Reading your (DH's) latest email, it sounds like you'd need this (rather th= an what I thought an Information Model might be - which it sounded earlier = would be sufficient) I agree with all your comments about shutting the WG; I guess something wor= th discussing f2f in Quebec, informally & in the wg session. Whatever, there is still the stuff on standardising the 3-in-1 encoding - w= hich can proceed whatever we decide on this. We had some discussions a week= or two back, which seem to have stopped (not sure we really reached a conc= lusion though!) Best wishes, phil -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: 22 June 2011 15:10 To: Eardley,PL,Philip,DES8 R; Ruediger.Geib@telekom.de; tom111.taylor@bell.= net Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com Subject: RE: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Hi, The main thing you are missing is an explanation of how you will achieve interoperability. The charter calls for specification of the encoding and transport of the information between points in the system: > > (3) encoding and transport of (pre-)congestion information > > between the interior and domain egress > > ... and ... > > (5) encoding and transport of (pre-)congestion information > > between the egress and the controlling domain ingress How will the information get from the interior to the domain egress, if the PCN processing for the interior node is implemented by vendor A and the PCN processing for the domain egress node is implemented by vendor B? In what message format will vendor A send it so that it can be interpreted consistently by the receiver, regardless of which vendor implements the receiver? What format validation shoudl be performed by teh receiever, what conditions constitute a receiving error, and what error codes should be returned by the receiver that will be understood by the sender? Ditto for the players in 5) The specification as written seems imcomplete because it does not deal with specifying the encoding and transport of the information. Am I just missing it, or is it really just not there? An information model can help to understand the properties of the data to be transported, but it doesn't really solve the problem of transporting the data in a standardized, interoperable manner. You will need to work hard to convince me that there is strong TECHNICAL justification for not providing REQUIRED (or at least RECOMMENDED) protocols and message formats/data models involved. I would likely need to work hard subsequently to convince the IESG. If the problem is that the WG has no energy, we can solve that in a much simpler way than updating these documents - we can just close the WG. If the WG doesn't have enough energy to complete these documents first, we can abandon the documents. That could save everybody a lot of time - WG editors, WG reviewers, WG chairs, the AD, IETF Last Call reviewers from various directorates, the IESG, IANA ... I think the Internet would benefit from this technology, and I would consider abandoning these documents at this point an awful waste of time, given how much work has been put into them already, so I STRONGLY encourage the WG to find the energy to complete their agreed-upon deliverables, but if it is WG consensus to abandon them, I guess I would have to accept that WG consensus. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Wednesday, June 22, 2011 4:17 AM > To: Ruediger.Geib@telekom.de; tom111.taylor@bell.net; > ietfdbh@comcast.net > Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com > Subject: RE: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > Personally I think it unlikely that the WG would ever > complete the former > > The latter might be plausible, though having flicked at 3444 > i can't tell exactly what we're missing. It seems to say that > an information model is an absrtact model about relationships > between objects and can be defined informally - (since I > havent consciously written one, I'm being vague) - the > combination of CL & signalling reqts seems quite close to this? > > Thanks for progressing Tom. > phil > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Ruediger.Geib@telekom.de > Sent: 22 June 2011 07:21 > To: tom111.taylor@bell.net; ietfdbh@comcast.net > Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com > Subject: Re: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > Hi Tom, > > which work are you taking up? > > - specifying the madatory to implement protocol. > - or specifying a minimum clear information model (RFC3444). > > I prefer the latter above the former. > > > Regards, > > Ruediger > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Wednesday, June 22, 2011 2:31 AM > To: David Harrington > Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' > Subject: Re: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > OK, I'll take up the good work. Just to start with, I propose > to submit > interim updates as I wished I had back a few months ago. I'll > go on from > there. > > On 21/06/2011 3:49 PM, David Harrington wrote: > > Hi, > > > > The WG was chartered to specify the > > (3) encoding and transport of (pre-)congestion information > > between the interior and domain egress > > ... and ... > > (5) encoding and transport of (pre-)congestion information > > between the egress and the controlling domain ingress > > > > I interpret that to mean the transport protocol and the message > > formats should be specified in the documents. > > I have to agree with Elwyn that lack of such formats means > > implementations are likely to not be interoperable. > > I am not sure what protocols would be suitable for these > tasks; other > > readers may have similar concerns. > > > > I think the specification would benefit from a > mandatory-to-implement > > protocol expected to carry the configuration and reported > information. > > At a minimum, there should be a clear information model (RFC3444) > > about the information to be transported. > > The data type and range of values should be included in the > > information model for each counter and configuration variable. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure interoperability. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > >> -----Original Message----- > >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > >> Sent: Tuesday, June 14, 2011 1:21 PM > >> To: philip.eardley@bt.com > >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > >> Subject: Re: Gen-art LC review of > > draft-ietf-pcn-cl-edge-behaviour-08 > >> > >> Hi, Phil. > >> > >> It strikes me that the first and second points below are > >> something which > >> David Harrington perhaps ought to give an opinion on. He has got to > >> defend it to the IESG. > >> > >> On the first point, my feeling is that neither the > >> requirements doc nor > >> this doc is sufficient to guarantee an interoperable > implementation. > > > >> There seems to me to be a cleft stick here (irrespective of > >> whether this > >> ends up as informational or experimental.) The WG is is specifying > >> pieces of functionality that go in two or more different > >> types of boxes > >> (three if there is a separate implementation of the > central decision > > > >> point). If the system is going to be generally deployable or > >> even to be > >> experimented with there may be different implementations. > >> The box types > >> communicate using the information specifications in the doc. This > >> appears to require protocol definitions. Where they are defined is > >> another issue but I feel it has either to be in this doc or > >> in another > >> doc referenced from this. If they aren't specified I > can't see that > > > >> anybody will be interested in making commercial implementations. > >> > >> I see David didn't make any comment about this situation in his > > write > >> up, so maybe I am over reacting. > >> > >> Regards, > >> Elwyn > >> > >> > >> > >> > >> > >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: > >>> Elwyn, > >>> > >>> Thanks for the detailed review. > >>> A few follow-ups in-line > >>> Thanks > >>> phil > >>> > >>> -- > >>> Major issues: > >>> The draft contains partial definitions of two control > >> protocols (egress > >>> -> decision point; decision point -> ingress). It does > >> not make it > >>> clear whether the reader is expected to get full > >> definitions of these > >>> protocols here or whether there will be another document > >> that specifies > >>> these protocols completely. As is stands one could build > >> the protocols > >>> and pretty much guarantee that they would not be interoperable > > with > >>> other implementations since message formats are not > >> included although > >>> high level specs are. The document needs to be much > >> clearer about what > >>> is expected to happen here. > >>> > >>> [phil] there is another document, " Requirements for > >> Signaling of (Pre-) Congestion Information in a DiffServ > >> Domain" > >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > >> nts-04] that deals with your issue to some extent. It doesn't > >> specify message formats but does at least specify better what > >> information the messages must contain. My understanding is > >> that unfortunately the WG doesn't feel it has the effort to > >> specify these protocols completely. > >>> > >>> > >>> Use of EXP codepoint: My understanding of what is said in > >> RFC 5696 is > >>> that EXP is supposed to be left for other (non=3DPCN) systems to > > use. > >>> This draft uses it. Is this sensible? Is this whole draft > >> experimental > >>> really? > >>> [phil] the intention of rfc5696 was that the EXP codepoint > >> is for experimental *PCN* encodings - ie beyond the baseline. > >> For instance, the CL behaviour needs separate codepoints for > >> (PCN) threshold-marking and (PCN) excess-traffic-marking& > >> this would require using the EXP codepoint. > >>> However...... There is currently some discussion on what > >> PCN encodings to specify beyond the baseline. At the time we > >> wrote the baseline, we envisaged the need for several > >> encodings - however it now seems that one may be enough, in > >> which case there may possibly be just one PCN encoding (ie a > >> revised 5696 that now uses the 01 codepoint), so possibly may > >> be Standards track - ?? > >>> Anyway, i take your point that we need to think about Status. > >>> > >>> s3.3.1: > >>>> [CL-specific] The outcome of the comparison is not very sensitive > >>>> to the value of the CLE-limit in practice, because > >> when threshold- > >>>> marking occurs it tends to persist long enough that > >> threshold- > >>>> marked traffic becomes a large proportion of the > >> received traffic > >>>> in a given interval. > >>> This statement worries me. It sounds like a characteristic of an > >>> unstable system. If the value is that non-critical why are we > >>> bothering? > >>> > >>> [phil] admission control system. imagine the pcn-domain has > >> one bottleneck link. If it can cope with the current number > >> of calls (their bandwidth), then no pkts gets > >> threshold-marked, so the CLE =3D 0. If there are too many, then > >> all pkts gets threshold-marked, so the CLE =3D 1. If there is > >> almost exactly the right number of calls, then > >> threshold-marking will tend to be on for a while, then off > >> for a while (perhaps when several flows are transmitting less > >> traffic than normal), so the CLE will jiggle about between 0& > >> 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current > >> CLE =3D 0.5), when a new call admission request happens to > >> arrive then it gets admitted. But then there's more traffic > >> and it's likely that the CLE will rise to 1 - hence another > >> admission request will get blocked. When a call finishes, > >> then the reverse is true. > >>> > >>> Now suppose we had in fact configured CLE-limit =3D 0.4, then > >> in the scenario above the call request would have been > >> blocked. However, (1) the PCN-domain has only admitted one > >> fewer call, (2) a short time later, either the CLE happens to > >> be lower or a call departs, and then the next admission > >> request is accepted. > >>> > >>> All this means that it doesn't matter much exactly what you > >> set CLE-limit to - it barely affects the average number of > >> calls admitted. The argument above is hand-wavy, but lots of > >> simulations have been done that show this is true (I hope i'm > >> representing the results correctly) > >>> So the lack of sensitivity to CLE-limit seems like a good thing. > >>> > >>> > >>> Minor issues: > >>> > >>> s6: The potential introduction of a centralized decision > >> point appears > >>> to provide additional attack points beyond the architecture > >> in RFC 5559. > >>> It appears to me that the requests for information about > >> specific flows > >>> to the ingress are ighly vulnerable as they (probably) > >> contain all the > >>> information needed to craft a DoS attack on the flow. > >>> > >>> [phil] seems a good point to me > >>> > >> > >> > >> -- > >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > >> For more information, see > >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > >> follow us on Twitter at http://twitter.com/CambOxfamWalk. > >> > >> > > > > _______________________________________________ > > 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 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From Ruediger.Geib@telekom.de Wed Jun 22 08:01:59 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8057011E808E; Wed, 22 Jun 2011 08:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WHsODZc-duJ; Wed, 22 Jun 2011 08:01:58 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6352E11E807A; Wed, 22 Jun 2011 08:01:57 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 22 Jun 2011 17:01:42 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 22 Jun 2011 17:01:42 +0200 From: To: , Date: Wed, 22 Jun 2011 17:01:41 +0200 Thread-Topic: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQABCht2AAAQKP8A== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0D0A@HE111648.emea1.cds.t-internal.com> References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk><9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net><4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:01:59 -0000 Hi David, Interoperability would result if no feedback signaling is required. I'm co-author of a draft describing such a solution. Unfortunately the remaining participants of the WG favour signaling based solutions, hence perspectives aren't bright for the draft supported by me. To me, the WG has worked largely successfully. The mechanisms standardised so far are fairly good. Regards, Ruediger -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, June 22, 2011 4:18 PM To: Geib, R=FCdiger; tom111.taylor@bell.net Cc: pcn@ietf.org; elwynd@dial.pipex.com; gen-art@ietf.org Subject: RE: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 Hi, Let me clear that an abstract information model alone is not likely to satisfy the concern, which is interoperability. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure interoperability. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, June 22, 2011 2:21 AM > To: tom111.taylor@bell.net; ietfdbh@comcast.net > Cc: pcn@ietf.org; elwynd@dial.pipex.com; gen-art@ietf.org > Subject: RE: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > Hi Tom, > > which work are you taking up? > > - specifying the madatory to implement protocol. > - or specifying a minimum clear information model (RFC3444). > > I prefer the latter above the former. > > > Regards, > > Ruediger > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Wednesday, June 22, 2011 2:31 AM > To: David Harrington > Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' > Subject: Re: [PCN] Gen-art LC review of > draft-ietf-pcn-cl-edge-behaviour-08 > > OK, I'll take up the good work. Just to start with, I propose > to submit > interim updates as I wished I had back a few months ago. I'll > go on from > there. > > On 21/06/2011 3:49 PM, David Harrington wrote: > > Hi, > > > > The WG was chartered to specify the > > (3) encoding and transport of (pre-)congestion information > > between the interior and domain egress > > ... and ... > > (5) encoding and transport of (pre-)congestion information > > between the egress and the controlling domain ingress > > > > I interpret that to mean the transport protocol and the message > > formats should be specified in the documents. > > I have to agree with Elwyn that lack of such formats means > > implementations are likely to not be interoperable. > > I am not sure what protocols would be suitable for these > tasks; other > > readers may have similar concerns. > > > > I think the specification would benefit from a > mandatory-to-implement > > protocol expected to carry the configuration and reported > information. > > At a minimum, there should be a clear information model (RFC3444) > > about the information to be transported. > > The data type and range of values should be included in the > > information model for each counter and configuration variable. > > I think it would be better to specify a mandatory-to-implement > > protocol, or at least a recommended-to-implement protocol, and a > > corresponding data model to ensure interoperability. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > >> -----Original Message----- > >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > >> Sent: Tuesday, June 14, 2011 1:21 PM > >> To: philip.eardley@bt.com > >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > >> Subject: Re: Gen-art LC review of > > draft-ietf-pcn-cl-edge-behaviour-08 > >> > >> Hi, Phil. > >> > >> It strikes me that the first and second points below are > >> something which > >> David Harrington perhaps ought to give an opinion on. He has got to > >> defend it to the IESG. > >> > >> On the first point, my feeling is that neither the > >> requirements doc nor > >> this doc is sufficient to guarantee an interoperable > implementation. > > > >> There seems to me to be a cleft stick here (irrespective of > >> whether this > >> ends up as informational or experimental.) The WG is is specifying > >> pieces of functionality that go in two or more different > >> types of boxes > >> (three if there is a separate implementation of the > central decision > > > >> point). If the system is going to be generally deployable or > >> even to be > >> experimented with there may be different implementations. > >> The box types > >> communicate using the information specifications in the doc. This > >> appears to require protocol definitions. Where they are defined is > >> another issue but I feel it has either to be in this doc or > >> in another > >> doc referenced from this. If they aren't specified I > can't see that > > > >> anybody will be interested in making commercial implementations. > >> > >> I see David didn't make any comment about this situation in his > > write > >> up, so maybe I am over reacting. > >> > >> Regards, > >> Elwyn > >> > >> > >> > >> > >> > >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: > >>> Elwyn, > >>> > >>> Thanks for the detailed review. > >>> A few follow-ups in-line > >>> Thanks > >>> phil > >>> > >>> -- > >>> Major issues: > >>> The draft contains partial definitions of two control > >> protocols (egress > >>> -> decision point; decision point -> ingress). It does > >> not make it > >>> clear whether the reader is expected to get full > >> definitions of these > >>> protocols here or whether there will be another document > >> that specifies > >>> these protocols completely. As is stands one could build > >> the protocols > >>> and pretty much guarantee that they would not be interoperable > > with > >>> other implementations since message formats are not > >> included although > >>> high level specs are. The document needs to be much > >> clearer about what > >>> is expected to happen here. > >>> > >>> [phil] there is another document, " Requirements for > >> Signaling of (Pre-) Congestion Information in a DiffServ > >> Domain" > >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > >> nts-04] that deals with your issue to some extent. It doesn't > >> specify message formats but does at least specify better what > >> information the messages must contain. My understanding is > >> that unfortunately the WG doesn't feel it has the effort to > >> specify these protocols completely. > >>> > >>> > >>> Use of EXP codepoint: My understanding of what is said in > >> RFC 5696 is > >>> that EXP is supposed to be left for other (non=3DPCN) systems to > > use. > >>> This draft uses it. Is this sensible? Is this whole draft > >> experimental > >>> really? > >>> [phil] the intention of rfc5696 was that the EXP codepoint > >> is for experimental *PCN* encodings - ie beyond the baseline. > >> For instance, the CL behaviour needs separate codepoints for > >> (PCN) threshold-marking and (PCN) excess-traffic-marking& > >> this would require using the EXP codepoint. > >>> However...... There is currently some discussion on what > >> PCN encodings to specify beyond the baseline. At the time we > >> wrote the baseline, we envisaged the need for several > >> encodings - however it now seems that one may be enough, in > >> which case there may possibly be just one PCN encoding (ie a > >> revised 5696 that now uses the 01 codepoint), so possibly may > >> be Standards track - ?? > >>> Anyway, i take your point that we need to think about Status. > >>> > >>> s3.3.1: > >>>> [CL-specific] The outcome of the comparison is not very sensitive > >>>> to the value of the CLE-limit in practice, because > >> when threshold- > >>>> marking occurs it tends to persist long enough that > >> threshold- > >>>> marked traffic becomes a large proportion of the > >> received traffic > >>>> in a given interval. > >>> This statement worries me. It sounds like a characteristic of an > >>> unstable system. If the value is that non-critical why are we > >>> bothering? > >>> > >>> [phil] admission control system. imagine the pcn-domain has > >> one bottleneck link. If it can cope with the current number > >> of calls (their bandwidth), then no pkts gets > >> threshold-marked, so the CLE =3D 0. If there are too many, then > >> all pkts gets threshold-marked, so the CLE =3D 1. If there is > >> almost exactly the right number of calls, then > >> threshold-marking will tend to be on for a while, then off > >> for a while (perhaps when several flows are transmitting less > >> traffic than normal), so the CLE will jiggle about between 0& > >> 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current > >> CLE =3D 0.5), when a new call admission request happens to > >> arrive then it gets admitted. But then there's more traffic > >> and it's likely that the CLE will rise to 1 - hence another > >> admission request will get blocked. When a call finishes, > >> then the reverse is true. > >>> > >>> Now suppose we had in fact configured CLE-limit =3D 0.4, then > >> in the scenario above the call request would have been > >> blocked. However, (1) the PCN-domain has only admitted one > >> fewer call, (2) a short time later, either the CLE happens to > >> be lower or a call departs, and then the next admission > >> request is accepted. > >>> > >>> All this means that it doesn't matter much exactly what you > >> set CLE-limit to - it barely affects the average number of > >> calls admitted. The argument above is hand-wavy, but lots of > >> simulations have been done that show this is true (I hope i'm > >> representing the results correctly) > >>> So the lack of sensitivity to CLE-limit seems like a good thing. > >>> > >>> > >>> Minor issues: > >>> > >>> s6: The potential introduction of a centralized decision > >> point appears > >>> to provide additional attack points beyond the architecture > >> in RFC 5559. > >>> It appears to me that the requests for information about > >> specific flows > >>> to the ingress are ighly vulnerable as they (probably) > >> contain all the > >>> information needed to craft a DoS attack on the flow. > >>> > >>> [phil] seems a good point to me > >>> > >> > >> > >> -- > >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > >> For more information, see > >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > >> follow us on Twitter at http://twitter.com/CambOxfamWalk. > >> > >> > > > > _______________________________________________ > > 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 ietfdbh@comcast.net Wed Jun 22 08:40:42 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F248011E80BA for ; Wed, 22 Jun 2011 08:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjNQAAfXKgZu for ; Wed, 22 Jun 2011 08:40:40 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 85AD111E80BF for ; Wed, 22 Jun 2011 08:40:24 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id z3Zy1g0020bG4ec583gRag; Wed, 22 Jun 2011 15:40:25 +0000 Received: from davidPC ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id z3gK1g0032JQnJT3P3gLmh; Wed, 22 Jun 2011 15:40:22 +0000 From: "David Harrington" To: , References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk><9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net><4DF7986B.5020108@dial.pipex.com><33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0D0A@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0D0A@HE111648.emea1.cds.t-internal.com> Date: Wed, 22 Jun 2011 11:40:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16807 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQABCht2AAAQKP8AABTocg Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:40:42 -0000 Hi Ruediger, Off the top of my head, I would think a signaling approach could provide for a more coordinated response. YMMV. I trust the WG had technical reasons for prefering a feedback signaling approach.=20 I consider the WG to be the experts in this space, so you don't need to convince me, you need to convince them. I think this WG has produced some very good documents, including those under review now. I think the WG is busy working on other specs right now, thinking they had completed the CL and SM docs. However, as Elwyn and I observed in GenArt and AD reviews, the CL and SM documents still seem incomplete. They seem to be missing interoperable transport and interoperable data models. I hope the WG still has energy, and can redirect some of its energy to completing these documents so we can get them approved as RFCs.=20 David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 > Sent: Wednesday, June 22, 2011 11:02 AM > To: ietfdbh@comcast.net; tom111.taylor@bell.net > Cc: pcn@ietf.org; elwynd@dial.pipex.com; gen-art@ietf.org > Subject: RE: [PCN] Gen-art LC review of=20 > draft-ietf-pcn-cl-edge-behaviour-08 >=20 > Hi David, >=20 > Interoperability would result if no feedback signaling is required. > I'm co-author of a draft describing such a solution. Unfortunately > the remaining participants of the WG favour signaling based solutions, > hence perspectives aren't bright for the draft supported by me. >=20 > To me, the WG has worked largely successfully. The mechanisms > standardised so far are fairly good. >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, June 22, 2011 4:18 PM > To: Geib, R=FCdiger; tom111.taylor@bell.net > Cc: pcn@ietf.org; elwynd@dial.pipex.com; gen-art@ietf.org > Subject: RE: [PCN] Gen-art LC review of=20 > draft-ietf-pcn-cl-edge-behaviour-08 >=20 > Hi, >=20 > Let me clear that an abstract information model alone is not likely to > satisfy the concern, which is interoperability. >=20 > > > I think it would be better to specify a mandatory-to-implement > > > protocol, or at least a recommended-to-implement protocol, and a > > > corresponding data model to ensure interoperability. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Wednesday, June 22, 2011 2:21 AM > > To: tom111.taylor@bell.net; ietfdbh@comcast.net > > Cc: pcn@ietf.org; elwynd@dial.pipex.com; gen-art@ietf.org > > Subject: RE: [PCN] Gen-art LC review of > > draft-ietf-pcn-cl-edge-behaviour-08 > > > > Hi Tom, > > > > which work are you taking up? > > > > - specifying the madatory to implement protocol. > > - or specifying a minimum clear information model (RFC3444). > > > > I prefer the latter above the former. > > > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of Tom Taylor > > Sent: Wednesday, June 22, 2011 2:31 AM > > To: David Harrington > > Cc: pcn@ietf.org; 'Elwyn Davies'; 'General Area Reviwing Team' > > Subject: Re: [PCN] Gen-art LC review of > > draft-ietf-pcn-cl-edge-behaviour-08 > > > > OK, I'll take up the good work. Just to start with, I propose > > to submit > > interim updates as I wished I had back a few months ago. I'll > > go on from > > there. > > > > On 21/06/2011 3:49 PM, David Harrington wrote: > > > Hi, > > > > > > The WG was chartered to specify the > > > (3) encoding and transport of (pre-)congestion information > > > between the interior and domain egress > > > ... and ... > > > (5) encoding and transport of (pre-)congestion information > > > between the egress and the controlling domain ingress > > > > > > I interpret that to mean the transport protocol and the message > > > formats should be specified in the documents. > > > I have to agree with Elwyn that lack of such formats means > > > implementations are likely to not be interoperable. > > > I am not sure what protocols would be suitable for these > > tasks; other > > > readers may have similar concerns. > > > > > > I think the specification would benefit from a > > mandatory-to-implement > > > protocol expected to carry the configuration and reported > > information. > > > At a minimum, there should be a clear information model (RFC3444) > > > about the information to be transported. > > > The data type and range of values should be included in the > > > information model for each counter and configuration variable. > > > I think it would be better to specify a mandatory-to-implement > > > protocol, or at least a recommended-to-implement protocol, and a > > > corresponding data model to ensure interoperability. > > > > > > David Harrington > > > Director, IETF Transport Area > > > ietfdbh@comcast.net (preferred for ietf) > > > dbharrington@huaweisymantec.com > > > +1 603 828 1401 (cell) > > > > > >> -----Original Message----- > > >> From: Elwyn Davies [mailto:elwynd@dial.pipex.com] > > >> Sent: Tuesday, June 14, 2011 1:21 PM > > >> To: philip.eardley@bt.com > > >> Cc: pcn@ietf.org; ietfdbh@comcast.net; General Area Reviwing Team > > >> Subject: Re: Gen-art LC review of > > > draft-ietf-pcn-cl-edge-behaviour-08 > > >> > > >> Hi, Phil. > > >> > > >> It strikes me that the first and second points below are > > >> something which > > >> David Harrington perhaps ought to give an opinion on. He has got > to > > >> defend it to the IESG. > > >> > > >> On the first point, my feeling is that neither the > > >> requirements doc nor > > >> this doc is sufficient to guarantee an interoperable > > implementation. > > > > > >> There seems to me to be a cleft stick here (irrespective of > > >> whether this > > >> ends up as informational or experimental.) The WG is is > specifying > > >> pieces of functionality that go in two or more different > > >> types of boxes > > >> (three if there is a separate implementation of the > > central decision > > > > > >> point). If the system is going to be generally deployable or > > >> even to be > > >> experimented with there may be different implementations. > > >> The box types > > >> communicate using the information specifications in the doc. > This > > >> appears to require protocol definitions. Where they are defined > is > > >> another issue but I feel it has either to be in this doc or > > >> in another > > >> doc referenced from this. If they aren't specified I > > can't see that > > > > > >> anybody will be interested in making commercial implementations. > > >> > > >> I see David didn't make any comment about this situation in his > > > write > > >> up, so maybe I am over reacting. > > >> > > >> Regards, > > >> Elwyn > > >> > > >> > > >> > > >> > > >> > > >> On 13/06/2011 18:04, philip.eardley@bt.com wrote: > > >>> Elwyn, > > >>> > > >>> Thanks for the detailed review. > > >>> A few follow-ups in-line > > >>> Thanks > > >>> phil > > >>> > > >>> -- > > >>> Major issues: > > >>> The draft contains partial definitions of two control > > >> protocols (egress > > >>> -> decision point; decision point -> ingress). It does > > >> not make it > > >>> clear whether the reader is expected to get full > > >> definitions of these > > >>> protocols here or whether there will be another document > > >> that specifies > > >>> these protocols completely. As is stands one could build > > >> the protocols > > >>> and pretty much guarantee that they would not be interoperable > > > with > > >>> other implementations since message formats are not > > >> included although > > >>> high level specs are. The document needs to be much > > >> clearer about what > > >>> is expected to happen here. > > >>> > > >>> [phil] there is another document, " Requirements for > > >> Signaling of (Pre-) Congestion Information in a DiffServ > > >> Domain" > > >> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme > > >> nts-04] that deals with your issue to some extent. It doesn't > > >> specify message formats but does at least specify better what > > >> information the messages must contain. My understanding is > > >> that unfortunately the WG doesn't feel it has the effort to > > >> specify these protocols completely. > > >>> > > >>> > > >>> Use of EXP codepoint: My understanding of what is said in > > >> RFC 5696 is > > >>> that EXP is supposed to be left for other (non=3DPCN) systems to > > > use. > > >>> This draft uses it. Is this sensible? Is this whole draft > > >> experimental > > >>> really? > > >>> [phil] the intention of rfc5696 was that the EXP codepoint > > >> is for experimental *PCN* encodings - ie beyond the baseline. > > >> For instance, the CL behaviour needs separate codepoints for > > >> (PCN) threshold-marking and (PCN) excess-traffic-marking& > > >> this would require using the EXP codepoint. > > >>> However...... There is currently some discussion on what > > >> PCN encodings to specify beyond the baseline. At the time we > > >> wrote the baseline, we envisaged the need for several > > >> encodings - however it now seems that one may be enough, in > > >> which case there may possibly be just one PCN encoding (ie a > > >> revised 5696 that now uses the 01 codepoint), so possibly may > > >> be Standards track - ?? > > >>> Anyway, i take your point that we need to think about Status. > > >>> > > >>> s3.3.1: > > >>>> [CL-specific] The outcome of the comparison is not very > sensitive > > >>>> to the value of the CLE-limit in practice, because > > >> when threshold- > > >>>> marking occurs it tends to persist long enough that > > >> threshold- > > >>>> marked traffic becomes a large proportion of the > > >> received traffic > > >>>> in a given interval. > > >>> This statement worries me. It sounds like a characteristic of > an > > >>> unstable system. If the value is that non-critical why are we > > >>> bothering? > > >>> > > >>> [phil] admission control system. imagine the pcn-domain has > > >> one bottleneck link. If it can cope with the current number > > >> of calls (their bandwidth), then no pkts gets > > >> threshold-marked, so the CLE =3D 0. If there are too many, then > > >> all pkts gets threshold-marked, so the CLE =3D 1. If there is > > >> almost exactly the right number of calls, then > > >> threshold-marking will tend to be on for a while, then off > > >> for a while (perhaps when several flows are transmitting less > > >> traffic than normal), so the CLE will jiggle about between 0& > > >> 1. If the CLE is< CLE-limit (say CLE-limit =3D 0.6& current > > >> CLE =3D 0.5), when a new call admission request happens to > > >> arrive then it gets admitted. But then there's more traffic > > >> and it's likely that the CLE will rise to 1 - hence another > > >> admission request will get blocked. When a call finishes, > > >> then the reverse is true. > > >>> > > >>> Now suppose we had in fact configured CLE-limit =3D 0.4, then > > >> in the scenario above the call request would have been > > >> blocked. However, (1) the PCN-domain has only admitted one > > >> fewer call, (2) a short time later, either the CLE happens to > > >> be lower or a call departs, and then the next admission > > >> request is accepted. > > >>> > > >>> All this means that it doesn't matter much exactly what you > > >> set CLE-limit to - it barely affects the average number of > > >> calls admitted. The argument above is hand-wavy, but lots of > > >> simulations have been done that show this is true (I hope i'm > > >> representing the results correctly) > > >>> So the lack of sensitivity to CLE-limit seems like a good thing. > > >>> > > >>> > > >>> Minor issues: > > >>> > > >>> s6: The potential introduction of a centralized decision > > >> point appears > > >>> to provide additional attack points beyond the architecture > > >> in RFC 5559. > > >>> It appears to me that the requests for information about > > >> specific flows > > >>> to the ingress are ighly vulnerable as they (probably) > > >> contain all the > > >>> information needed to craft a DoS attack on the flow. > > >>> > > >>> [phil] seems a good point to me > > >>> > > >> > > >> > > >> -- > > >> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011. > > >> For more information, see > > >> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and > > >> follow us on Twitter at http://twitter.com/CambOxfamWalk. > > >> > > >> > > > > > > _______________________________________________ > > > 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 > > >=20 >=20 From toby@moncaster.com Wed Jun 22 08:58:11 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0BE11E8144; Wed, 22 Jun 2011 08:58:11 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BB59pPBLjeSX; Wed, 22 Jun 2011 08:58:10 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6E08811E807A; Wed, 22 Jun 2011 08:58:10 -0700 (PDT) Received: from TobysHP (host81-156-178-213.range81-156.btcentralplus.com [81.156.178.213]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M5Kwt-1RXqAH3g1H-00zSm3; Wed, 22 Jun 2011 17:58:05 +0200 From: "Toby Moncaster" To: "'David Harrington'" , , , References: <1307728914.22973.2654.camel@mightyatom.folly.org.uk><9510D26531EF184D9017DF24659BB87F32DF7BF594@EMV65-UKRD.domain1.systemhost.net><4DF7986B.5020108@dial.pipex.com> <33B5B2B1686A45B6A3739D9D9EB234C7@davidPC> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF041B@HE111648.emea1.cds.t-internal.com> <9510D26531EF184D9017DF24659BB87F32E07BCC20@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Date: Wed, 22 Jun 2011 16:57:57 +0100 Message-ID: <001c01cc30f5$2a82d5c0$7f888140$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acwwc7boE6jGovIWQu6iS4tZohCwJQAMITDQAAPKtvAAC27UgAAEu0pA Content-Language: en-gb X-Provags-ID: V02:K0:d4O/3gN4qUkLNds+3bVcpRTBah5Yk/jBI23Q/Y+eq9s zbmHoLw/66qd1e8DJhg/0Fiu3bh/YeDu2zrjCxNZldeLblcmTE N8tj76NfkLg751ag0yvzwean5GP9MypB5M8RYyXiUrOiADpx0V Oo2NrkLMhoe84oOEjjYhadgP0g5zmvoVCSLqKnBTrD3/Ik8XUz qDpmbwQsh+cXL7IGbEuYBnjewrjF/JjaitOARR5PvM= Cc: pcn@ietf.org, gen-art@ietf.org, elwynd@dial.pipex.com Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:58:11 -0000 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > David Harrington > Sent: 22 June 2011 15:10 > To: philip.eardley@bt.com; Ruediger.Geib@telekom.de; > tom111.taylor@bell.net > Cc: pcn@ietf.org; gen-art@ietf.org; elwynd@dial.pipex.com > Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge- > behaviour-08 > > Hi, > > If the problem is that the WG has no energy, we can solve that in a > much simpler way than updating these documents - we can just close the > WG. If the WG doesn't have enough energy to complete these documents > first, we can abandon the documents. That could save everybody a lot > of time - WG editors, WG reviewers, WG chairs, the AD, IETF Last Call > reviewers from various directorates, the IESG, IANA ... I think the issue may not be as simple as lack of WG energy so much as lack of time available. Many in the WG are funded by external sources or work for large companies, in the current straitened times they probably have to justify their work to their bosses. In theory I should have time to do lots of PCN stuff (as I am currently out of work). However right now I am committed to doing lots of decorating, DIY etc. My hope is that I can spend a productive few days at the start of July and I will happily include reviewing other peoples work (as well as getting 3-in-1 encoding shipped). I would volunteer to write the interoperability stuff, but I have zero experience of that so I would just get it wrong! > > I think the Internet would benefit from this technology, and I would > consider abandoning these documents at this point an awful waste of > time, given how much work has been put into them already, so I > STRONGLY encourage the WG to find the energy to complete their > agreed-upon deliverables, but if it is WG consensus to abandon them, I > guess I would have to accept that WG consensus. I strongly feel it would be a waste to bin PCN at this stage. As you say there has been some good work done and it would be a shame to lose it. It sounds like there are a couple of people prepared to put energy into PCN still and hopefully we can wrap this all up quickly. Toby > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) From internet-drafts@ietf.org Wed Jun 22 13:35:26 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B223F21F84CF; Wed, 22 Jun 2011 13:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+NSz2seEO8h; Wed, 22 Jun 2011 13:35:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D8C21F84C8; Wed, 22 Jun 2011 13:35:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110622203526.13780.88161.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2011 13:35:26 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-cl-edge-behaviour-09.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:35:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Controlled Load (CL)= Mode of Operation Author(s) : Anna Charny Fortune Huang Georgios Karagiannis Michael Menth Tom Taylor Filename : draft-ietf-pcn-cl-edge-behaviour-09.txt Pages : 24 Date : 2011-06-22 Pre-congestion notification (PCN) is a means for protecting the 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 a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-09.txt From internet-drafts@ietf.org Wed Jun 22 13:35:42 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C221F84F1; Wed, 22 Jun 2011 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S1o5iQIWzNh; Wed, 22 Jun 2011 13:35:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2703721F84CA; Wed, 22 Jun 2011 13:35:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110622203542.13778.5139.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2011 13:35:42 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-sm-edge-behaviour-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:35:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Single Marking (SM) = Mode of Operation Author(s) : Anna Charny Georgios Karagiannis Michael Menth Tom Taylor Filename : draft-ietf-pcn-sm-edge-behaviour-06.txt Pages : 22 Date : 2011-06-22 Pre-congestion notification (PCN) is a means for protecting the 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 a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN-boundary-node behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-06.txt From tom111.taylor@bell.net Wed Jun 22 13:40:19 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DE021F853E for ; Wed, 22 Jun 2011 13:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.381 X-Spam-Level: X-Spam-Status: No, score=-99.381 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50UslAwt4NFx for ; Wed, 22 Jun 2011 13:40:19 -0700 (PDT) Received: from blu0-omc1-s21.blu0.hotmail.com (blu0-omc1-s21.blu0.hotmail.com [65.55.116.32]) by ietfa.amsl.com (Postfix) with ESMTP id 046D521F8513 for ; Wed, 22 Jun 2011 13:40:18 -0700 (PDT) Received: from BLU0-SMTP86 ([65.55.116.9]) by blu0-omc1-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 13:40:18 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP86.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 13:40:17 -0700 Date: Wed, 22 Jun 2011 16:40:15 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2011 20:40:17.0675 (UTC) FILETIME=[98A5CDB0:01CC311C] Subject: [PCN] CL and SM interim updates X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:40:19 -0000 As I said I would, I have submitted interim versions of the CL and SM edge behaviour drafts. They incorporate all comments previously received except for the operational and management considerations sections. Also to do, of course: the protocols and any other GenArt comments that haven't been covered already. Since the CL behaviour uses the EXP codepoint, I changed the intended status of the draft to Experimental. This is obviously a matter for WG review. Tom Taylor From tom.taylor@huawei.com Fri Jun 24 10:26:18 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8511E8193 for ; Fri, 24 Jun 2011 10:26:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ5WVK4U4pT3 for ; Fri, 24 Jun 2011 10:26:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D728F11E8174 for ; Fri, 24 Jun 2011 10:26:09 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNB00FW81RH38@szxga05-in.huawei.com> for pcn@ietf.org; Sat, 25 Jun 2011 01:26:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNB00L6V1RHZP@szxga05-in.huawei.com> for pcn@ietf.org; Sat, 25 Jun 2011 01:26:05 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1096706092.dsl.bell.ca [65.94.104.44]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNB005LS1RF20@szxml12-in.huawei.com> for pcn@ietf.org; Sat, 25 Jun 2011 01:26:05 +0800 (CST) Date: Fri, 24 Jun 2011 13:26:02 -0400 From: Tom Taylor To: pcn Message-id: <4E04C8AA.3000808@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 X-Mailman-Approved-At: Fri, 24 Jun 2011 10:29:35 -0700 Subject: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 17:26:18 -0000 Rereading the signalling requirements document, I note that we actually need two protocols: 1) A non-reliable protocol carrying reports from the PCN-egress-node to the decision point, whether centralized or collocated with the PCN-ingress-node. 2) A reliable request-response protocol between a centralized decision point and a PCN-ingress-node. 1) Protocol between the PCN-egress-node and the decision point ----------------------------------------------------------- This protocol would be based on UDP, subject to security analysis. (Alternatives are UDP/IPSec or DTLS). For the first protocol, the question arises: do we need back-off in the face of congestion? I argue not, since the very purpose of the protocol is to carry information that may help to mitigate that congestion. (I say "may" because the report path doesn't necessarily coincide with the data path of the received PCN packets.) I await comments on that topic, but I suggest that the protocol itself would consist of two message types. The first is REPORT, and would be the only one used in normal operation. REPORT passes from the PCN-egress-node to the decision point. The second message is REQUEST-REPORT. It is sent under the following circumstances from the decision point to the PCN-egress-node: -- possibly as part of a start-up sequence. Assuming that the decision point knows the address of the PCN-egress-node, this message could push the address of the decision point to the PCN-egress-node, avoiding the need to configure it there. -- possibly as part of a recovery attempt if the failure timer T-rcvFail expires; -- possibly as part of a manual debugging procedure. The response of the PCN-egress-node to a REQUEST-REPORT message would be to immediately send a REPORT message with contents based on the latest measurement interval. 2) Protocol between the decision point and the PCN-ingress-node ------------------------------------------------------------ This one needs a bit of discussion to decide whether we actually want a stand-alone protocol consisting of REQUEST and RESPONSE messages running over TCP. The decision point already needs a protocol to install policy on the PCN-ingress-node. If this protocol is COPS, the PIB could easily be extended to request the estimated PCN-sent-rate from the PCN-ingress-node. In general we should think about protocol integration. Comments? Tom From tom111.taylor@bell.net Fri Jun 24 11:26:37 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0780A11E80BD for ; Fri, 24 Jun 2011 11:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.635 X-Spam-Level: X-Spam-Status: No, score=-100.635 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XnLqvfXizK3 for ; Fri, 24 Jun 2011 11:26:36 -0700 (PDT) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by ietfa.amsl.com (Postfix) with ESMTP id 541BF11E8084 for ; Fri, 24 Jun 2011 11:26:36 -0700 (PDT) Received: from BLU0-SMTP22 ([65.55.116.9]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 11:26:35 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP22.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 11:26:35 -0700 Date: Fri, 24 Jun 2011 14:26:35 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2011 18:26:35.0098 (UTC) FILETIME=[3FA533A0:01CC329C] Subject: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 18:26:37 -0000 Rereading the signalling requirements document, I note that we actually need two protocols: 1) A non-reliable protocol carrying reports from the PCN-egress-node to the decision point, whether centralized or collocated with the PCN-ingress-node. 2) A reliable request-response protocol between a centralized decision point and a PCN-ingress-node. 1) Protocol between the PCN-egress-node and the decision point ----------------------------------------------------------- This protocol would be based on UDP, subject to security analysis. (Alternatives are UDP/IPSec or DTLS). For the first protocol, the question arises: do we need back-off in the face of congestion? I argue not, since the very purpose of the protocol is to carry information that may help to mitigate that congestion. (I say "may" because the report path doesn't necessarily coincide with the data path of the received PCN packets.) I await comments on that topic, but I suggest that the protocol itself would consist of two message types. The first is REPORT, and would be the only one used in normal operation. REPORT passes from the PCN-egress-node to the decision point. The second message is REQUEST-REPORT. It is sent under the following circumstances from the decision point to the PCN-egress-node: -- possibly as part of a start-up sequence. Assuming that the decision point knows the address of the PCN-egress-node, this message could push the address of the decision point to the PCN-egress-node, avoiding the need to configure it there. -- possibly as part of a recovery attempt if the failure timer T-rcvFail expires; -- possibly as part of a manual debugging procedure. The response of the PCN-egress-node to a REQUEST-REPORT message would be to immediately send a REPORT message with contents based on the latest measurement interval. 2) Protocol between the decision point and the PCN-ingress-node ------------------------------------------------------------ This one needs a bit of discussion to decide whether we actually want a stand-alone protocol consisting of REQUEST and RESPONSE messages running over TCP. The decision point already needs a protocol to install policy on the PCN-ingress-node. If this protocol is COPS, the PIB could easily be extended to request the estimated PCN-sent-rate from the PCN-ingress-node. In general we should think about protocol integration. Comments? Tom From menth@informatik.uni-tuebingen.de Fri Jun 24 11:52:25 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF5E11E81A6 for ; Fri, 24 Jun 2011 11:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1bYvoinj7Af for ; Fri, 24 Jun 2011 11:52:24 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 9ED2E11E818E for ; Fri, 24 Jun 2011 11:52:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id EFAF55268; Fri, 24 Jun 2011 20:52:21 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kalj3QES3uka; Fri, 24 Jun 2011 20:52:18 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9F6245131; Fri, 24 Jun 2011 20:52:18 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id AA31C1EE4F76; Fri, 24 Jun 2011 20:52:17 +0200 (CEST) Message-ID: <4E04DCE0.30800@informatik.uni-tuebingen.de> Date: Fri, 24 Jun 2011 20:52:16 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Tom Taylor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 18:52:25 -0000 Hi Tom, Am 24.06.2011 20:26, schrieb Tom Taylor: > Rereading the signalling requirements document, I note that we > actually need two protocols: > > 1) A non-reliable protocol carrying reports from the PCN-egress-node > to the decision point, whether centralized or collocated with the > PCN-ingress-node. > > 2) A reliable request-response protocol between a centralized decision > point and a PCN-ingress-node. > > > 1) Protocol between the PCN-egress-node and the decision point > ----------------------------------------------------------- > > This protocol would be based on UDP, subject to security analysis. > (Alternatives are UDP/IPSec or DTLS). > > For the first protocol, the question arises: do we need back-off in > the face of congestion? I argue not, since the very purpose of the > protocol is to carry information that may help to mitigate that > congestion. (I say "may" because the report path doesn't necessarily > coincide with the data path of the received PCN packets.) I agree. > > I await comments on that topic, but I suggest that the protocol itself > would consist of two message types. The first is REPORT, and would be > the only one used in normal operation. REPORT passes from the > PCN-egress-node to the decision point. > > The second message is REQUEST-REPORT. It is sent under the following > circumstances from the decision point to the PCN-egress-node: > > -- possibly as part of a start-up sequence. Assuming that the > decision point knows the address of the PCN-egress-node, this message > could push the address of the decision point to the PCN-egress-node, > avoiding the need to configure it there. This is useful only for the centralized approach, right? If the decision point is the PCN-ingress-node, then its address needs to be found out by the PCN-egress-node anyway for IEA classification of PCN packets. Correct? > > -- possibly as part of a recovery attempt if the failure timer > T-rcvFail expires; > > -- possibly as part of a manual debugging procedure. > > The response of the PCN-egress-node to a REQUEST-REPORT message would > be to immediately send a REPORT message with contents based on the > latest measurement interval. I agree. > > 2) Protocol between the decision point and the PCN-ingress-node > ------------------------------------------------------------ > > This one needs a bit of discussion to decide whether we actually want > a stand-alone protocol consisting of REQUEST and RESPONSE messages > running over TCP. The decision point already needs a protocol to > install policy on the PCN-ingress-node. If this protocol is COPS, the > PIB could easily be extended to request the estimated PCN-sent-rate > from the PCN-ingress-node. In general we should think about protocol > integration. > > Comments? The protocols you mention are in place only for the centralized approach, right? Then I would expect at least a simple standalone protocol for the case when the PCN ingress node is the decision point to be independent of other technologies. Alternative: we make the use of the other protocol mandatory, but I do not know whether this is acceptable. Michael > > Tom > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From tom111.taylor@bell.net Fri Jun 24 12:45:38 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6999A11E80A3 for ; Fri, 24 Jun 2011 12:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.867 X-Spam-Level: X-Spam-Status: No, score=-100.867 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXphRuIEA6LC for ; Fri, 24 Jun 2011 12:45:37 -0700 (PDT) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4E23F11E8073 for ; Fri, 24 Jun 2011 12:45:37 -0700 (PDT) Received: from BLU0-SMTP24 ([65.55.116.9]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 12:45:36 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP24.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 12:45:35 -0700 Date: Fri, 24 Jun 2011 15:45:35 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael Menth References: <4E04DCE0.30800@informatik.uni-tuebingen.de> In-Reply-To: <4E04DCE0.30800@informatik.uni-tuebingen.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2011 19:45:36.0069 (UTC) FILETIME=[497BF750:01CC32A7] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:45:38 -0000 Thanks for the response, Michael. Answering your two points in reverse order: (a) Protocol 1 is needed even when the decision point resides with the PCN-ingress-node. Protocol 2 is needed only in the centralized case. If you make Protocol 2 optional to implement, then by the same logic you would make the ability to send reports on multiple IEAs in the same message optional to implement in Protocol 1. My own preference would be: mandatory to implement, optional to deploy instead. (b) Are we sure that the address of the PCN-ingress-node will be part of the IEA-classifier? Wouldn't that mean that the PCN-ingress-node changes the source of all incoming PCN-packets to its own address? My intention was that the address of the decision point would be picked up from the source address of the REQUEST-REPORT message. This would provide some protection from NATs in the signalling path, however unlikely their presence might be in the interior of an operator's network. On 24/06/2011 2:52 PM, Michael Menth wrote: > Hi Tom, > > Am 24.06.2011 20:26, schrieb Tom Taylor: >> Rereading the signalling requirements document, I note that we >> actually need two protocols: >> >> 1) A non-reliable protocol carrying reports from the PCN-egress-node >> to the decision point, whether centralized or collocated with the >> PCN-ingress-node. >> >> 2) A reliable request-response protocol between a centralized decision >> point and a PCN-ingress-node. >> >> >> 1) Protocol between the PCN-egress-node and the decision point >> ----------------------------------------------------------- >> >> This protocol would be based on UDP, subject to security analysis. >> (Alternatives are UDP/IPSec or DTLS). >> >> For the first protocol, the question arises: do we need back-off in >> the face of congestion? I argue not, since the very purpose of the >> protocol is to carry information that may help to mitigate that >> congestion. (I say "may" because the report path doesn't necessarily >> coincide with the data path of the received PCN packets.) > I agree. > >> >> I await comments on that topic, but I suggest that the protocol itself >> would consist of two message types. The first is REPORT, and would be >> the only one used in normal operation. REPORT passes from the >> PCN-egress-node to the decision point. >> >> The second message is REQUEST-REPORT. It is sent under the following >> circumstances from the decision point to the PCN-egress-node: >> >> -- possibly as part of a start-up sequence. Assuming that the decision >> point knows the address of the PCN-egress-node, this message could >> push the address of the decision point to the PCN-egress-node, >> avoiding the need to configure it there. > This is useful only for the centralized approach, right? If the decision > point is the PCN-ingress-node, then its address needs to be found out by > the PCN-egress-node anyway for IEA classification of PCN packets. Correct? > >> >> -- possibly as part of a recovery attempt if the failure timer >> T-rcvFail expires; >> >> -- possibly as part of a manual debugging procedure. >> >> The response of the PCN-egress-node to a REQUEST-REPORT message would >> be to immediately send a REPORT message with contents based on the >> latest measurement interval. > I agree. > >> >> 2) Protocol between the decision point and the PCN-ingress-node >> ------------------------------------------------------------ >> >> This one needs a bit of discussion to decide whether we actually want >> a stand-alone protocol consisting of REQUEST and RESPONSE messages >> running over TCP. The decision point already needs a protocol to >> install policy on the PCN-ingress-node. If this protocol is COPS, the >> PIB could easily be extended to request the estimated PCN-sent-rate >> from the PCN-ingress-node. In general we should think about protocol >> integration. >> >> Comments? > The protocols you mention are in place only for the centralized > approach, right? Then I would expect at least a simple standalone > protocol for the case when the PCN ingress node is the decision point to > be independent of other technologies. Alternative: we make the use of > the other protocol mandatory, but I do not know whether this is acceptable. > > Michael > > >> >> Tom >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > From menth@informatik.uni-tuebingen.de Fri Jun 24 12:59:47 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB711E821A for ; Fri, 24 Jun 2011 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJbsMN0wTfLW for ; Fri, 24 Jun 2011 12:59:46 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 55BBC11E80BA for ; Fri, 24 Jun 2011 12:59:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 33901526F; Fri, 24 Jun 2011 21:59:45 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH-olsaIQvMG; Fri, 24 Jun 2011 21:59:37 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 550C35131; Fri, 24 Jun 2011 21:59:37 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id C56C71EE5E04; Fri, 24 Jun 2011 21:59:36 +0200 (CEST) Message-ID: <4E04ECA3.1030102@informatik.uni-tuebingen.de> Date: Fri, 24 Jun 2011 21:59:31 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Tom Taylor References: <4E04DCE0.30800@informatik.uni-tuebingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:59:47 -0000 Hi Tom, Am 24.06.2011 21:45, schrieb Tom Taylor: > Thanks for the response, Michael. > > Answering your two points in reverse order: > > (a) Protocol 1 is needed even when the decision point resides with the > PCN-ingress-node. Protocol 2 is needed only in the centralized case. Sorry, you are so right! I forgot about that. > If you make Protocol 2 optional to implement, then by the same logic > you would make the ability to send reports on multiple IEAs in the > same message optional to implement in Protocol 1. My own preference > would be: mandatory to implement, optional to deploy instead. I prefer just mandatory to avoid different code bases. > > (b) Are we sure that the address of the PCN-ingress-node will be part > of the IEA-classifier? Wouldn't that mean that the PCN-ingress-node > changes the source of all incoming PCN-packets to its own address? The address of the PCN-ingress-node is part of the denomination of an IEA. It is not part of the flow descriptor for classification of packet belonging to a specific IEA. The signalling requirements draft says: For the SM/CL edge behaviour, the report MUST contain: o the identifier of the PCN-ingress-node and the identifier of the PCN-egress-node (typically their IP addresses); together they specify the ingress-egress-aggregate to which the report refers, > > My intention was that the address of the decision point would be > picked up from the source address of the REQUEST-REPORT message. This > would provide some protection from NATs in the signalling path, > however unlikely their presence might be in the interior of an > operator's network. That may be a good solution for the centralized approach as you suggested. I don't believe it's needed when PCN-ingress-node is the decision point. Regards, Michael > > On 24/06/2011 2:52 PM, Michael Menth wrote: >> Hi Tom, >> >> Am 24.06.2011 20:26, schrieb Tom Taylor: >>> Rereading the signalling requirements document, I note that we >>> actually need two protocols: >>> >>> 1) A non-reliable protocol carrying reports from the PCN-egress-node >>> to the decision point, whether centralized or collocated with the >>> PCN-ingress-node. >>> >>> 2) A reliable request-response protocol between a centralized decision >>> point and a PCN-ingress-node. >>> >>> >>> 1) Protocol between the PCN-egress-node and the decision point >>> ----------------------------------------------------------- >>> >>> This protocol would be based on UDP, subject to security analysis. >>> (Alternatives are UDP/IPSec or DTLS). >>> >>> For the first protocol, the question arises: do we need back-off in >>> the face of congestion? I argue not, since the very purpose of the >>> protocol is to carry information that may help to mitigate that >>> congestion. (I say "may" because the report path doesn't necessarily >>> coincide with the data path of the received PCN packets.) >> I agree. >> >>> >>> I await comments on that topic, but I suggest that the protocol itself >>> would consist of two message types. The first is REPORT, and would be >>> the only one used in normal operation. REPORT passes from the >>> PCN-egress-node to the decision point. >>> >>> The second message is REQUEST-REPORT. It is sent under the following >>> circumstances from the decision point to the PCN-egress-node: >>> >>> -- possibly as part of a start-up sequence. Assuming that the decision >>> point knows the address of the PCN-egress-node, this message could >>> push the address of the decision point to the PCN-egress-node, >>> avoiding the need to configure it there. >> This is useful only for the centralized approach, right? If the decision >> point is the PCN-ingress-node, then its address needs to be found out by >> the PCN-egress-node anyway for IEA classification of PCN packets. >> Correct? >> >>> >>> -- possibly as part of a recovery attempt if the failure timer >>> T-rcvFail expires; >>> >>> -- possibly as part of a manual debugging procedure. >>> >>> The response of the PCN-egress-node to a REQUEST-REPORT message would >>> be to immediately send a REPORT message with contents based on the >>> latest measurement interval. >> I agree. >> >>> >>> 2) Protocol between the decision point and the PCN-ingress-node >>> ------------------------------------------------------------ >>> >>> This one needs a bit of discussion to decide whether we actually want >>> a stand-alone protocol consisting of REQUEST and RESPONSE messages >>> running over TCP. The decision point already needs a protocol to >>> install policy on the PCN-ingress-node. If this protocol is COPS, the >>> PIB could easily be extended to request the estimated PCN-sent-rate >>> from the PCN-ingress-node. In general we should think about protocol >>> integration. >>> >>> Comments? >> The protocols you mention are in place only for the centralized >> approach, right? Then I would expect at least a simple standalone >> protocol for the case when the PCN ingress node is the decision point to >> be independent of other technologies. Alternative: we make the use of >> the other protocol mandatory, but I do not know whether this is >> acceptable. >> >> Michael >> >> >>> >>> Tom >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >> -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From tom111.taylor@bell.net Fri Jun 24 19:17:20 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6B11E80B8 for ; Fri, 24 Jun 2011 19:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.022 X-Spam-Level: X-Spam-Status: No, score=-101.022 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXHlsWBr49FY for ; Fri, 24 Jun 2011 19:17:19 -0700 (PDT) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1B11E808E for ; Fri, 24 Jun 2011 19:17:18 -0700 (PDT) Received: from BLU0-SMTP49 ([65.55.116.8]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 19:17:18 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP49.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 19:17:18 -0700 Date: Fri, 24 Jun 2011 22:17:17 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael Menth References: <4E04DCE0.30800@informatik.uni-tuebingen.de> <4E04ECA3.1030102@informatik.uni-tuebingen.de> In-Reply-To: <4E04ECA3.1030102@informatik.uni-tuebingen.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2011 02:17:18.0126 (UTC) FILETIME=[01CD44E0:01CC32DE] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 02:17:20 -0000 Below. On 24/06/2011 3:59 PM, Michael Menth wrote: [PTT1] >> (b) Are we sure that the address of the PCN-ingress-node will be part >> of the IEA-classifier? Wouldn't that mean that the PCN-ingress-node >> changes the source of all incoming PCN-packets to its own address? ============ [MM] > The address of the PCN-ingress-node is part of the denomination of an > IEA. It is not part of the flow descriptor for classification of packet > belonging to a specific IEA. The signalling requirements draft says: > > For the SM/CL edge behaviour, the report MUST contain: > o the identifier of the PCN-ingress-node and the identifier of the > PCN-egress-node (typically their IP addresses); together they > specify the ingress-egress-aggregate to which the report refers, > > > ============== [PTT1] >> >> My intention was that the address of the decision point would be >> picked up from the source address of the REQUEST-REPORT message. This >> would provide some protection from NATs in the signalling path, >> however unlikely their presence might be in the interior of an >> operator's network. ============== [MM] > That may be a good solution for the centralized approach as you > suggested. I don't believe it's needed when PCN-ingress-node is the > decision point. [PTT2] The NAT aspect isn't my primary concern, just a by-product. Would it not be brittle to build in the assumption that the node identifier is an address? What if the node is upgraded to dual stack or to pure IPv6 and thus gets a new address? I'd sooner have the address be drawn from the message IP header, and make the identifers opaque strings, up to the administrator to populate. Tom From slblake@petri-meat.com Fri Jun 24 19:24:08 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5843E11E80B8 for ; Fri, 24 Jun 2011 19:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx2X4zUXDnKB for ; Fri, 24 Jun 2011 19:24:06 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id D588911E807E for ; Fri, 24 Jun 2011 19:24:06 -0700 (PDT) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1QaIXV-0000QU-8M for pcn@ietf.org; Fri, 24 Jun 2011 22:24:05 -0400 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-PEsznKfJid5/KipUzUQv" Date: Fri, 24 Jun 2011 22:24:02 -0400 Message-ID: <1308968642.10420.0.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] [Fwd: PCN - Requested session has been scheduled for IETF 81] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 02:24:08 -0000 --=-PEsznKfJid5/KipUzUQv Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI // Steve --=-PEsznKfJid5/KipUzUQv Content-Disposition: inline Content-Description: Forwarded message - PCN - Requested session has been scheduled for IETF 81 Content-Type: message/rfc822 Return-path: Envelope-to: slblake@petri-meat.com Delivery-date: Thu, 23 Jun 2011 19:06:00 -0400 Received: from mail.ietf.org ([64.170.98.30]) by elom.tchmachines.com with esmtp (Exim 4.69) (envelope-from ) id 1QZsyG-0000pC-EY for slblake@petri-meat.com; Thu, 23 Jun 2011 19:06:00 -0400 Received: by ietfa.amsl.com (Postfix, from userid 30) id A440211E81A0; Thu, 23 Jun 2011 16:05:47 -0700 (PDT) From: IETF Secretariat To: sob@harvard.edu Cc: slblake@petri-meat.com,ietfdbh@comcast.net,wes@mti-systems.com,session-request@ietf.org Subject: PCN - Requested session has been scheduled for IETF 81 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110623230547.A440211E81A0@ietfa.amsl.com> Date: Thu, 23 Jun 2011 16:05:47 -0700 (PDT) Content-Transfer-Encoding: 7bit Dear Scott Bradner, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. PCN Session 1 (1 hour) Monday, Afternoon Session II 1510-1610 Room Name: 204 B ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: pcn Area Name: Transport Area Session Requester: Scott Bradner Number of Sessions: 1 Length of Session(s): 1 hour Number of Attendees: 50 Conflicts to Avoid: First Priority: opsawg Special Requests: --------------------------------------------------------- --=-PEsznKfJid5/KipUzUQv-- From menth@informatik.uni-tuebingen.de Fri Jun 24 23:37:56 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2432611E8074 for ; Fri, 24 Jun 2011 23:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNcOomQv0y-x for ; Fri, 24 Jun 2011 23:37:55 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 2D30211E8071 for ; Fri, 24 Jun 2011 23:37:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7219852C0; Sat, 25 Jun 2011 08:37:52 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3keIp6pj97O5; Sat, 25 Jun 2011 08:37:50 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E6F145270; Sat, 25 Jun 2011 08:37:49 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0E0F011C4455; Sat, 25 Jun 2011 08:37:48 +0200 (CEST) Message-ID: <4E05823B.1050205@informatik.uni-tuebingen.de> Date: Sat, 25 Jun 2011 08:37:47 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Tom Taylor References: <4E04DCE0.30800@informatik.uni-tuebingen.de> <4E04ECA3.1030102@informatik.uni-tuebingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 06:37:56 -0000 Hi Tom, se below Am 25.06.2011 04:17, schrieb Tom Taylor: > Below. > > On 24/06/2011 3:59 PM, Michael Menth wrote: > [PTT1] > >>> (b) Are we sure that the address of the PCN-ingress-node will be part >>> of the IEA-classifier? Wouldn't that mean that the PCN-ingress-node >>> changes the source of all incoming PCN-packets to its own address? > ============ > [MM] > >> The address of the PCN-ingress-node is part of the denomination of an >> IEA. It is not part of the flow descriptor for classification of packet >> belonging to a specific IEA. The signalling requirements draft says: >> >> For the SM/CL edge behaviour, the report MUST contain: >> o the identifier of the PCN-ingress-node and the identifier of the >> PCN-egress-node (typically their IP addresses); together they >> specify the ingress-egress-aggregate to which the report refers, >> >> >> > ============== > [PTT1] > >>> >>> My intention was that the address of the decision point would be >>> picked up from the source address of the REQUEST-REPORT message. This >>> would provide some protection from NATs in the signalling path, >>> however unlikely their presence might be in the interior of an >>> operator's network. > ============== > [MM] > >> That may be a good solution for the centralized approach as you >> suggested. I don't believe it's needed when PCN-ingress-node is the >> decision point. > > [PTT2] The NAT aspect isn't my primary concern, just a by-product. > > Would it not be brittle to build in the assumption that the node > identifier is an address? What if the node is upgraded to dual stack > or to pure IPv6 and thus gets a new address? I'd sooner have the > address be drawn from the message IP header, and make the identifers > opaque strings, up to the administrator to populate. How does RSVP solve that? Nodes need to know the address of the previous hop. Regards, Michael > > Tom -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From karagian@cs.utwente.nl Sat Jun 25 02:45:39 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7956811E808E for ; Sat, 25 Jun 2011 02:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ0IhL5xgxQI for ; Sat, 25 Jun 2011 02:45:39 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9111E8084 for ; Sat, 25 Jun 2011 02:45:37 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5P9iDFt014129; Sat, 25 Jun 2011 11:44:13 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 25 Jun 2011 09:45:38 +0000 To: "Tom Taylor" , "pcn" Date: Sat, 25 Jun 2011 09:45:38 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 25 Jun 2011 11:44:23 +0200 (MEST) Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 09:45:39 -0000 Hi Tom, Please see in line! On 6/24/2011, "Tom Taylor" wrote: >Rereading the signalling requirements document, I note that we actually >need two protocols: > >1) A non-reliable protocol carrying reports from the PCN-egress-node to >the decision point, whether centralized or collocated with the >PCN-ingress-node. Georgios: I do not understand why should we define a new protocol for this purpose, since we can already use for this an existing IETF signaling protocol. For example RSVP. Please note that I have started modifying the following draft that can be used as an example of how a signaling protocol can be applied to support an PCN edge behaviour. http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01 I will try to write a very preliminary version of this draft, which I will submit before/on the submission deadline (4th of July)! > >2) A reliable request-response protocol between a centralized decision >point and a PCN-ingress-node. Georgios: Also for this protocol, please try to use and enhance an existing IETF protocol. What about DIAMETER. I think that you already worked on this, see below: draft-huang-dime-pcn-collection Best regards, Georgios > > >1) Protocol between the PCN-egress-node and the decision point > ----------------------------------------------------------- > >This protocol would be based on UDP, subject to security analysis. >(Alternatives are UDP/IPSec or DTLS). > >For the first protocol, the question arises: do we need back-off in the >face of congestion? I argue not, since the very purpose of the protocol >is to carry information that may help to mitigate that congestion. (I >say "may" because the report path doesn't necessarily coincide with the >data path of the received PCN packets.) > >I await comments on that topic, but I suggest that the protocol itself >would consist of two message types. The first is REPORT, and would be >the only one used in normal operation. REPORT passes from the >PCN-egress-node to the decision point. > >The second message is REQUEST-REPORT. It is sent under the following >circumstances from the decision point to the PCN-egress-node: > > -- possibly as part of a start-up sequence. Assuming that the decision >point knows the address of the PCN-egress-node, this message could push >the address of the decision point to the PCN-egress-node, avoiding the >need to configure it there. > > -- possibly as part of a recovery attempt if the failure timer >T-rcvFail expires; > > -- possibly as part of a manual debugging procedure. > >The response of the PCN-egress-node to a REQUEST-REPORT message would be >to immediately send a REPORT message with contents based on the latest >measurement interval. > >2) Protocol between the decision point and the PCN-ingress-node > ------------------------------------------------------------ > >This one needs a bit of discussion to decide whether we actually want a >stand-alone protocol consisting of REQUEST and RESPONSE messages running >over TCP. The decision point already needs a protocol to install policy >on the PCN-ingress-node. If this protocol is COPS, the PIB could easily >be extended to request the estimated PCN-sent-rate from the >PCN-ingress-node. In general we should think about protocol integration. > >Comments? > >Tom >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From tom111.taylor@bell.net Sat Jun 25 04:42:28 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668D11E8084 for ; Sat, 25 Jun 2011 04:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.133 X-Spam-Level: X-Spam-Status: No, score=-101.133 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3rA9l56YXuA for ; Sat, 25 Jun 2011 04:42:26 -0700 (PDT) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by ietfa.amsl.com (Postfix) with ESMTP id AB4FB11E807E for ; Sat, 25 Jun 2011 04:42:25 -0700 (PDT) Received: from BLU0-SMTP100 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Jun 2011 04:42:24 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP100.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Jun 2011 04:42:24 -0700 Date: Sat, 25 Jun 2011 07:42:24 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2011 11:42:24.0411 (UTC) FILETIME=[F385C6B0:01CC332C] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 11:42:28 -0000 What are the RSVP messages corresponding to REPORT and REQUEST-REPORT? On 25/06/2011 5:45 AM, Georgios Karagiannis wrote: > Hi Tom, > > Please see in line! > > > On 6/24/2011, "Tom Taylor" wrote: > >> Rereading the signalling requirements document, I note that we actually >> need two protocols: >> >> 1) A non-reliable protocol carrying reports from the PCN-egress-node to >> the decision point, whether centralized or collocated with the >> PCN-ingress-node. > > Georgios: I do not understand why should we define a new protocol for > this purpose, since we can already use for this an existing IETF > signaling protocol. For example RSVP. > > Please note that I have started modifying the following draft that > can be used as an example of how a signaling protocol can be applied to > support an PCN edge behaviour. > http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01 > > I will try to write a very preliminary version of this draft, which I > will submit before/on the submission deadline (4th of July)! > > > >> >> 2) A reliable request-response protocol between a centralized decision >> point and a PCN-ingress-node. > > Georgios: Also for this protocol, please try to use and enhance an > existing IETF protocol. What about DIAMETER. I think that you already > worked on this, see below: > > draft-huang-dime-pcn-collection > > Best regards, > Georgios > > >> >> >> 1) Protocol between the PCN-egress-node and the decision point >> ----------------------------------------------------------- >> >> This protocol would be based on UDP, subject to security analysis. >> (Alternatives are UDP/IPSec or DTLS). >> >> For the first protocol, the question arises: do we need back-off in the >> face of congestion? I argue not, since the very purpose of the protocol >> is to carry information that may help to mitigate that congestion. (I >> say "may" because the report path doesn't necessarily coincide with the >> data path of the received PCN packets.) >> >> I await comments on that topic, but I suggest that the protocol itself >> would consist of two message types. The first is REPORT, and would be >> the only one used in normal operation. REPORT passes from the >> PCN-egress-node to the decision point. >> >> The second message is REQUEST-REPORT. It is sent under the following >> circumstances from the decision point to the PCN-egress-node: >> >> -- possibly as part of a start-up sequence. Assuming that the decision >> point knows the address of the PCN-egress-node, this message could push >> the address of the decision point to the PCN-egress-node, avoiding the >> need to configure it there. >> >> -- possibly as part of a recovery attempt if the failure timer >> T-rcvFail expires; >> >> -- possibly as part of a manual debugging procedure. >> >> The response of the PCN-egress-node to a REQUEST-REPORT message would be >> to immediately send a REPORT message with contents based on the latest >> measurement interval. >> >> 2) Protocol between the decision point and the PCN-ingress-node >> ------------------------------------------------------------ >> >> This one needs a bit of discussion to decide whether we actually want a >> stand-alone protocol consisting of REQUEST and RESPONSE messages running >> over TCP. The decision point already needs a protocol to install policy >> on the PCN-ingress-node. If this protocol is COPS, the PIB could easily >> be extended to request the estimated PCN-sent-rate from the >> PCN-ingress-node. In general we should think about protocol integration. >> >> Comments? >> >> Tom >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > > From karagian@cs.utwente.nl Sat Jun 25 13:52:49 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DA411E80C8 for ; Sat, 25 Jun 2011 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nja94j+vI7fW for ; Sat, 25 Jun 2011 13:52:48 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 270E911E807F for ; Sat, 25 Jun 2011 13:52:47 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5PKpM9c014517; Sat, 25 Jun 2011 22:51:22 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 25 Jun 2011 20:52:47 +0000 To: "Tom Taylor" Date: Sat, 25 Jun 2011 20:52:47 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 25 Jun 2011 22:51:34 +0200 (MEST) Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 20:52:49 -0000 Hi Tom, >What are the RSVP messages corresponding to REPORT and REQUEST-REPORT? The REPORT message can be provided by the RESV message. Regarding the features that a REQUEST-REPORT should support see below: >>> -- possibly as part of a start-up sequence. Assuming that the decision >>> point knows the address of the PCN-egress-node, this message could push >>> the address of the decision point to the PCN-egress-node, avoiding the >>> need to configure it there. This is supported by RSVP, using the PATH message in combination with the Previous HOP object carried by a PATH message. >>> >>> -- possibly as part of a recovery attempt if the failure timer >>> T-rcvFail expires; This is supported by RSVP using the PATH message in combination with soft state principle of RSVP. >>> >>> -- possibly as part of a manual debugging procedure. I am not sure if this feature is necesary to be supported by such a protocol. I think that this procedure can be supported by network management protocols. Best regards, Goergios > >On 25/06/2011 5:45 AM, Georgios Karagiannis wrote: >> Hi Tom, >> >> Please see in line! >> >> >> On 6/24/2011, "Tom Taylor" wrote: >> >>> Rereading the signalling requirements document, I note that we actually >>> need two protocols: >>> >>> 1) A non-reliable protocol carrying reports from the PCN-egress-node to >>> the decision point, whether centralized or collocated with the >>> PCN-ingress-node. >> >> Georgios: I do not understand why should we define a new protocol for >> this purpose, since we can already use for this an existing IETF >> signaling protocol. For example RSVP. >> >> Please note that I have started modifying the following draft that >> can be used as an example of how a signaling protocol can be applied to >> support an PCN edge behaviour. >> http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01 >> >> I will try to write a very preliminary version of this draft, which I >> will submit before/on the submission deadline (4th of July)! >> >> >> >>> >>> 2) A reliable request-response protocol between a centralized decision >>> point and a PCN-ingress-node. >> >> Georgios: Also for this protocol, please try to use and enhance an >> existing IETF protocol. What about DIAMETER. I think that you already >> worked on this, see below: >> >> draft-huang-dime-pcn-collection >> >> Best regards, >> Georgios >> >> >>> >>> >>> 1) Protocol between the PCN-egress-node and the decision point >>> ----------------------------------------------------------- >>> >>> This protocol would be based on UDP, subject to security analysis. >>> (Alternatives are UDP/IPSec or DTLS). >>> >>> For the first protocol, the question arises: do we need back-off in the >>> face of congestion? I argue not, since the very purpose of the protocol >>> is to carry information that may help to mitigate that congestion. (I >>> say "may" because the report path doesn't necessarily coincide with the >>> data path of the received PCN packets.) >>> >>> I await comments on that topic, but I suggest that the protocol itself >>> would consist of two message types. The first is REPORT, and would be >>> the only one used in normal operation. REPORT passes from the >>> PCN-egress-node to the decision point. >>> >>> The second message is REQUEST-REPORT. It is sent under the following >>> circumstances from the decision point to the PCN-egress-node: >>> >>> -- possibly as part of a start-up sequence. Assuming that the decision >>> point knows the address of the PCN-egress-node, this message could push >>> the address of the decision point to the PCN-egress-node, avoiding the >>> need to configure it there. >>> >>> -- possibly as part of a recovery attempt if the failure timer >>> T-rcvFail expires; >>> >>> -- possibly as part of a manual debugging procedure. >>> >>> The response of the PCN-egress-node to a REQUEST-REPORT message would be >>> to immediately send a REPORT message with contents based on the latest >>> measurement interval. >>> >>> 2) Protocol between the decision point and the PCN-ingress-node >>> ------------------------------------------------------------ >>> >>> This one needs a bit of discussion to decide whether we actually want a >>> stand-alone protocol consisting of REQUEST and RESPONSE messages running >>> over TCP. The decision point already needs a protocol to install policy >>> on the PCN-ingress-node. If this protocol is COPS, the PIB could easily >>> be extended to request the estimated PCN-sent-rate from the >>> PCN-ingress-node. In general we should think about protocol integration. >>> >>> Comments? >>> >>> Tom >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >> >> From tom111.taylor@bell.net Mon Jun 27 06:50:37 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7A321F8553 for ; Mon, 27 Jun 2011 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.937 X-Spam-Level: X-Spam-Status: No, score=-99.937 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC+9PoVjUBUL for ; Mon, 27 Jun 2011 06:50:36 -0700 (PDT) Received: from blu0-omc2-s23.blu0.hotmail.com (blu0-omc2-s23.blu0.hotmail.com [65.55.111.98]) by ietfa.amsl.com (Postfix) with ESMTP id 405FD21F85AA for ; Mon, 27 Jun 2011 05:58:59 -0700 (PDT) Received: from BLU0-SMTP79 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 05:55:52 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP79.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 05:55:51 -0700 Date: Mon, 27 Jun 2011 08:55:49 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2011 12:55:52.0100 (UTC) FILETIME=[8B893E40:01CC34C9] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 13:50:37 -0000 Not being terribly familiar with RSVP, I started my education with RFC2205. It seems to me that if the basic semantics of RSVP are to be respected, the initial message at start-up is a RESV coming from the egress node. That's not how I pictured it, but it might work. So what we get is a stream of RESV messages from the egress node. A return PATH message is an exceptional occurence -- basically an error condition in our application. Does RSVP give us the freedom to put the information we need to pass in the RESV message, and what mandatory fields do we have to fake to respect the requirements of the protocol? My studies continue. Tom On 25/06/2011 4:52 PM, Georgios Karagiannis wrote: > Hi Tom, > > >> What are the RSVP messages corresponding to REPORT and REQUEST-REPORT? > > The REPORT message can be provided by the RESV message. > > Regarding the features that a REQUEST-REPORT should support see below: > > >>>> -- possibly as part of a start-up sequence. Assuming that the decision >>>> point knows the address of the PCN-egress-node, this message could push >>>> the address of the decision point to the PCN-egress-node, avoiding the >>>> need to configure it there. > > This is supported by RSVP, using the PATH message in combination with the > Previous HOP object carried by a PATH message. > > >>>> >>>> -- possibly as part of a recovery attempt if the failure timer >>>> T-rcvFail expires; > > This is supported by RSVP using the PATH message in combination with soft > state principle of RSVP. > >>>> >>>> -- possibly as part of a manual debugging procedure. > > I am not sure if this feature is necesary to be supported by such a > protocol. I think that this procedure can be supported by network > management protocols. > > Best regards, > Goergios > > >> >> On 25/06/2011 5:45 AM, Georgios Karagiannis wrote: >>> Hi Tom, >>> >>> Please see in line! >>> >>> >>> On 6/24/2011, "Tom Taylor" wrote: >>> >>>> Rereading the signalling requirements document, I note that we actually >>>> need two protocols: >>>> >>>> 1) A non-reliable protocol carrying reports from the PCN-egress-node to >>>> the decision point, whether centralized or collocated with the >>>> PCN-ingress-node. >>> >>> Georgios: I do not understand why should we define a new protocol for >>> this purpose, since we can already use for this an existing IETF >>> signaling protocol. For example RSVP. >>> >>> Please note that I have started modifying the following draft that >>> can be used as an example of how a signaling protocol can be applied to >>> support an PCN edge behaviour. >>> http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01 >>> >>> I will try to write a very preliminary version of this draft, which I >>> will submit before/on the submission deadline (4th of July)! >>> >>> >>> >>>> >>>> 2) A reliable request-response protocol between a centralized decision >>>> point and a PCN-ingress-node. >>> >>> Georgios: Also for this protocol, please try to use and enhance an >>> existing IETF protocol. What about DIAMETER. I think that you already >>> worked on this, see below: >>> >>> draft-huang-dime-pcn-collection >>> >>> Best regards, >>> Georgios >>> >>> >>>> >>>> >>>> 1) Protocol between the PCN-egress-node and the decision point >>>> ----------------------------------------------------------- >>>> >>>> This protocol would be based on UDP, subject to security analysis. >>>> (Alternatives are UDP/IPSec or DTLS). >>>> >>>> For the first protocol, the question arises: do we need back-off in the >>>> face of congestion? I argue not, since the very purpose of the protocol >>>> is to carry information that may help to mitigate that congestion. (I >>>> say "may" because the report path doesn't necessarily coincide with the >>>> data path of the received PCN packets.) >>>> >>>> I await comments on that topic, but I suggest that the protocol itself >>>> would consist of two message types. The first is REPORT, and would be >>>> the only one used in normal operation. REPORT passes from the >>>> PCN-egress-node to the decision point. >>>> >>>> The second message is REQUEST-REPORT. It is sent under the following >>>> circumstances from the decision point to the PCN-egress-node: >>>> >>>> -- possibly as part of a start-up sequence. Assuming that the decision >>>> point knows the address of the PCN-egress-node, this message could push >>>> the address of the decision point to the PCN-egress-node, avoiding the >>>> need to configure it there. >>>> >>>> -- possibly as part of a recovery attempt if the failure timer >>>> T-rcvFail expires; >>>> >>>> -- possibly as part of a manual debugging procedure. >>>> >>>> The response of the PCN-egress-node to a REQUEST-REPORT message would be >>>> to immediately send a REPORT message with contents based on the latest >>>> measurement interval. >>>> >>>> 2) Protocol between the decision point and the PCN-ingress-node >>>> ------------------------------------------------------------ >>>> >>>> This one needs a bit of discussion to decide whether we actually want a >>>> stand-alone protocol consisting of REQUEST and RESPONSE messages running >>>> over TCP. The decision point already needs a protocol to install policy >>>> on the PCN-ingress-node. If this protocol is COPS, the PIB could easily >>>> be extended to request the estimated PCN-sent-rate from the >>>> PCN-ingress-node. In general we should think about protocol integration. >>>> >>>> Comments? >>>> >>>> Tom >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>> >>> > > From karagian@cs.utwente.nl Mon Jun 27 22:21:46 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283FA21F8662 for ; Mon, 27 Jun 2011 22:21:46 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GY+sq-1U8G3 for ; Mon, 27 Jun 2011 22:21:45 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA921F8530 for ; Mon, 27 Jun 2011 22:21:44 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5S5KGL5007575; Tue, 28 Jun 2011 07:20:16 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 28 Jun 2011 05:21:44 +0000 To: "Tom Taylor" Date: Tue, 28 Jun 2011 05:21:44 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 28 Jun 2011 07:20:26 +0200 (MEST) Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 05:21:46 -0000 Hi Tom, Regarding RESV, please note that a new object has to be specified that can carry PCN information. I assume that we can do this in tsvwg. Please also note that RSVP is an on-path signaling protocol. If the decision point is not located on the data path, then we migh not be able to use the current RSVP protocol features. In addiition to the features that you mentioned, a PCN feature is also needed to set and maintain the IEA (Ingress Egress Aggregate) at the PCN-ingress-node and the PCN-egress-node. Therefore, I think that a combination of e2e RSVP and RSVP aggregation is needed. I am currently working on specifying this. I estimate that a draft and preliminary version of this will be ready by Monday. Best regards, Georgios On 6/27/2011, "Tom Taylor" wrote: >Not being terribly familiar with RSVP, I started my education with >RFC2205. It seems to me that if the basic semantics of RSVP are to be >respected, the initial message at start-up is a RESV coming from the >egress node. That's not how I pictured it, but it might work. > >So what we get is a stream of RESV messages from the egress node. A >return PATH message is an exceptional occurence -- basically an error >condition in our application. > >Does RSVP give us the freedom to put the information we need to pass in >the RESV message, and what mandatory fields do we have to fake to >respect the requirements of the protocol? > >My studies continue. > >Tom > >On 25/06/2011 4:52 PM, Georgios Karagiannis wrote: >> Hi Tom, >> >> >>> What are the RSVP messages corresponding to REPORT and REQUEST-REPORT? >> >> The REPORT message can be provided by the RESV message. >> >> Regarding the features that a REQUEST-REPORT should support see below: >> >> >>>>> -- possibly as part of a start-up sequence. Assuming that the decisi= on >>>>> point knows the address of the PCN-egress-node, this message could push >>>>> the address of the decision point to the PCN-egress-node, avoiding the >>>>> need to configure it there. >> >> This is supported by RSVP, using the PATH message in combination with the >> Previous HOP object carried by a PATH message. >> >> >>>>> >>>>> -- possibly as part of a recovery attempt if the failure timer >>>>> T-rcvFail expires; >> >> This is supported by RSVP using the PATH message in combination with soft >> state principle of RSVP. >> >>>>> >>>>> -- possibly as part of a manual debugging procedure. >> >> I am not sure if this feature is necesary to be supported by such a >> protocol. I think that this procedure can be supported by network >> management protocols. >> >> Best regards, >> Goergios >> >> >>> >>> On 25/06/2011 5:45 AM, Georgios Karagiannis wrote: >>>> Hi Tom, >>>> >>>> Please see in line! >>>> >>>> >>>> On 6/24/2011, "Tom Taylor" wrote: >>>> >>>>> Rereading the signalling requirements document, I note that we actually >>>>> need two protocols: >>>>> >>>>> 1) A non-reliable protocol carrying reports from the PCN-egress-node to >>>>> the decision point, whether centralized or collocated with the >>>>> PCN-ingress-node. >>>> >>>> Georgios: I do not understand why should we define a new protocol for >>>> this purpose, since we can already use for this an existing IETF >>>> signaling protocol. For example RSVP. >>>> >>>> Please note that I have started modifying the following draft that >>>> can be used as an example of how a signaling protocol can be applied to >>>> support an PCN edge behaviour. >>>> http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01 >>>> >>>> I will try to write a very preliminary version of this draft, which I >>>> will submit before/on the submission deadline (4th of July)! >>>> >>>> >>>> >>>>> >>>>> 2) A reliable request-response protocol between a centralized decision >>>>> point and a PCN-ingress-node. >>>> >>>> Georgios: Also for this protocol, please try to use and enhance an >>>> existing IETF protocol. What about DIAMETER. I think that you already >>>> worked on this, see below: >>>> >>>> draft-huang-dime-pcn-collection >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>>> >>>>> >>>>> 1) Protocol between the PCN-egress-node and the decision point >>>>> ----------------------------------------------------------- >>>>> >>>>> This protocol would be based on UDP, subject to security analysis. >>>>> (Alternatives are UDP/IPSec or DTLS). >>>>> >>>>> For the first protocol, the question arises: do we need back-off in the >>>>> face of congestion? I argue not, since the very purpose of the protocol >>>>> is to carry information that may help to mitigate that congestion. (I >>>>> say "may" because the report path doesn't necessarily coincide with the >>>>> data path of the received PCN packets.) >>>>> >>>>> I await comments on that topic, but I suggest that the protocol itself >>>>> would consist of two message types. The first is REPORT, and would be >>>>> the only one used in normal operation. REPORT passes from the >>>>> PCN-egress-node to the decision point. >>>>> >>>>> The second message is REQUEST-REPORT. It is sent under the following >>>>> circumstances from the decision point to the PCN-egress-node: >>>>> >>>>> -- possibly as part of a start-up sequence. Assuming that the decisi= on >>>>> point knows the address of the PCN-egress-node, this message could push >>>>> the address of the decision point to the PCN-egress-node, avoiding the >>>>> need to configure it there. >>>>> >>>>> -- possibly as part of a recovery attempt if the failure timer >>>>> T-rcvFail expires; >>>>> >>>>> -- possibly as part of a manual debugging procedure. >>>>> >>>>> The response of the PCN-egress-node to a REQUEST-REPORT message would b= e >>>>> to immediately send a REPORT message with contents based on the latest >>>>> measurement interval. >>>>> >>>>> 2) Protocol between the decision point and the PCN-ingress-node >>>>> ------------------------------------------------------------ >>>>> >>>>> This one needs a bit of discussion to decide whether we actually want a >>>>> stand-alone protocol consisting of REQUEST and RESPONSE messages runnin= g >>>>> over TCP. The decision point already needs a protocol to install policy >>>>> on the PCN-ingress-node. If this protocol is COPS, the PIB could easily >>>>> be extended to request the estimated PCN-sent-rate from the >>>>> PCN-ingress-node. In general we should think about protocol integration= . >>>>> >>>>> Comments? >>>>> >>>>> Tom >>>>> _______________________________________________ >>>>> PCN mailing list >>>>> PCN@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pcn >>>> >>>> >> >> From tom111.taylor@bell.net Tue Jun 28 05:36:22 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17C11E809E for ; Tue, 28 Jun 2011 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.937 X-Spam-Level: X-Spam-Status: No, score=-100.937 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPx10LPr9hJN for ; Tue, 28 Jun 2011 05:36:21 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70211E809C for ; Tue, 28 Jun 2011 05:36:14 -0700 (PDT) Received: from BLU0-SMTP74 ([65.55.111.73]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 05:36:14 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP74.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 05:36:14 -0700 Date: Tue, 28 Jun 2011 08:36:14 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2011 12:36:14.0204 (UTC) FILETIME=[F7DE53C0:01CC358F] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 12:36:22 -0000 I'm not sure I follow all this. Are you sure you are not mixing up the piggybacking case with the CL and SM modes of operation? I'll wait to see your draft, but basically, with CL and SM the end-to-end RSVP (if any) would be handled at the ingress node but at no other node in the PCN domain. On 28/06/2011 1:21 AM, Georgios Karagiannis wrote: > Hi Tom, > > Regarding RESV, please note that a new object has to be specified that > can carry PCN information. I assume that we can do this in tsvwg. > Please also note that RSVP is an on-path signaling protocol. If the > decision point is not located on the data path, then we migh not be able > to use the current RSVP protocol features. > > In addiition to the features that you mentioned, a PCN feature is also > needed to set and maintain the IEA (Ingress Egress Aggregate) at the > PCN-ingress-node and the PCN-egress-node. > > Therefore, I think that a combination of e2e RSVP and RSVP aggregation is > needed. I am currently working on specifying this. I estimate that a > draft and preliminary version of this will be ready by Monday. > > Best regards, > Georgios > ... From karagian@cs.utwente.nl Tue Jun 28 06:00:36 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46ED221F86A1 for ; Tue, 28 Jun 2011 06:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5mUp7Hasxmp for ; Tue, 28 Jun 2011 06:00:35 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE521F8550 for ; Tue, 28 Jun 2011 06:00:09 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5SCwbn7004020; Tue, 28 Jun 2011 14:58:37 +0200 (MEST) Received: from 130.89.12.129 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 28 Jun 2011 13:00:06 +0000 To: "Tom Taylor" Date: Tue, 28 Jun 2011 13:00:06 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 28 Jun 2011 14:58:48 +0200 (MEST) Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:00:36 -0000 Hi Tom, The solution that I was talking about is indeed related to the piggybacking edge behaviour: draft-taylor-pcn-piggybacking-edge-behaviour-01 However, this piggybacking edge behaviour is very much depending on the SM and CL behaviours. My proposal is to somehow integrate each of the CL and SM edge behaviours with the piggybacking edge behaviour. This can be e.g., done by including in each SM and CL drafts an additional section that will describe how each of the CL and SM behaviours can be used when the decision point is co-located with the PCN-ingess-node. In this case the enhanced RSVP can be applied as the signaling protocol used to exchange information between the PCN edge nodes. In addition to this we could also add a section on each CL and SM drafts that describe how each of the CL and SM behaviours can be used when the decision point is not co-located with the PCN-ingess-node. In this case DIAMETER can be used as the signaling protocol for exchanging information between the PCN-egress-node and decision point and between the decision point and the PCN-ingress-node. I think that you already described this solution some tinme ago. Best regards, Georgios On 6/28/2011, "Tom Taylor" wrote: >I'm not sure I follow all this. Are you sure you are not mixing up the >piggybacking case with the CL and SM modes of operation? I'll wait to >see your draft, but basically, with CL and SM the end-to-end RSVP (if >any) would be handled at the ingress node but at no other node in the >PCN domain. > >On 28/06/2011 1:21 AM, Georgios Karagiannis wrote: >> Hi Tom, >> >> Regarding RESV, please note that a new object has to be specified that >> can carry PCN information. I assume that we can do this in tsvwg. >> Please also note that RSVP is an on-path signaling protocol. If the >> decision point is not located on the data path, then we migh not be able >> to use the current RSVP protocol features. >> >> In addiition to the features that you mentioned, a PCN feature is also >> needed to set and maintain the IEA (Ingress Egress Aggregate) at the >> PCN-ingress-node and the PCN-egress-node. >> >> Therefore, I think that a combination of e2e RSVP and RSVP aggregation is >> needed. I am currently working on specifying this. I estimate that a >> draft and preliminary version of this will be ready by Monday. >> >> Best regards, >> Georgios >> >... From tom111.taylor@bell.net Tue Jun 28 07:04:55 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2B421F8608 for ; Tue, 28 Jun 2011 07:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.223 X-Spam-Level: X-Spam-Status: No, score=-101.223 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoKs-+ur++Vz for ; Tue, 28 Jun 2011 07:04:55 -0700 (PDT) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7021F8506 for ; Tue, 28 Jun 2011 07:04:54 -0700 (PDT) Received: from BLU0-SMTP16 ([65.55.111.72]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 07:04:54 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP16.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 07:04:53 -0700 Date: Tue, 28 Jun 2011 10:04:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2011 14:04:54.0051 (UTC) FILETIME=[5ABE8F30:01CC359C] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:04:55 -0000 The piggybacking edge behaviour shares the marking behaviours with the CL and SM modes. Where it differs is that the decision point for admission effectively lies with the egress node. That way, the RSVP signalling and the admission decision share a common fate -- a very natural integration of PCN with RSVP. Less natural is the message autonomously generated by the egress node when flow termination is required, but as we know, with the specification of a new object to represent the IEA, this can be done. (The fact is that I suspect the piggybacking method is far more deployable than the CL and SM methods because far fewer messages have to be transmitted through the network.) I can see the possibility of using RSVP as a transport for PCN reports in the CL and SM cases, but it is a really unnatural use of the protocol. In the first place, the RESV is initiated at a router (the egress node) rather than an end point or a proxy for an end point. I am a bit dubious that the message format for this message would conform in any but the most artificial sense to the specifications in RFC 2205. And the Path message, the normal response to the RESV, is unnecessary in normal operation in the CL and SM cases. I would feel much more comfortable defining a simple and light-weight protocol that could be used regardless of whether the decision point is centralized or decentralized. On 28/06/2011 9:00 AM, Georgios Karagiannis wrote: > Hi Tom, > > The solution that I was talking about is indeed related to the > piggybacking edge behaviour: > draft-taylor-pcn-piggybacking-edge-behaviour-01 > > However, this piggybacking edge behaviour is very much depending on the > SM and CL behaviours. > > My proposal is to somehow integrate each of the CL and SM edge behaviours > with the piggybacking edge behaviour. This can be e.g., done by > including in each SM and CL drafts an additional section that will > describe how each of the CL and SM behaviours can be used when the > decision point is co-located with the PCN-ingess-node. In this case the > enhanced RSVP can be applied as the signaling protocol used to exchange > information between the PCN edge nodes. > > In addition to this we could also add a section on each CL and SM drafts > that describe how each of the CL and SM behaviours can be used when the > decision point is not co-located with the PCN-ingess-node. > In this case DIAMETER can be used as the signaling protocol for > exchanging information between the PCN-egress-node and decision point > and between the decision point and the PCN-ingress-node. I think that > you already described this solution some tinme ago. > > Best regards, > Georgios > ... From tom111.taylor@bell.net Tue Jun 28 07:31:51 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2840221F84D3 for ; Tue, 28 Jun 2011 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.305 X-Spam-Level: X-Spam-Status: No, score=-101.305 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZUjTa3jU-+Y for ; Tue, 28 Jun 2011 07:31:50 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3CE21F84CF for ; Tue, 28 Jun 2011 07:31:50 -0700 (PDT) Received: from BLU0-SMTP47 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 07:31:49 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP47.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 07:31:49 -0700 Date: Tue, 28 Jun 2011 10:31:50 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2011 14:31:50.0103 (UTC) FILETIME=[1DFC8670:01CC35A0] Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:31:51 -0000 As an afterthought, in the CL and SM edge behaviours, it would be much more natural for the RESV to come from the decision point (the receiver) and the reports from the egress node (the sender) to be carried by the PATH message. On 28/06/2011 10:04 AM, Tom Taylor wrote: > The piggybacking edge behaviour shares the marking behaviours with the > CL and SM modes. Where it differs is that the decision point for > admission effectively lies with the egress node. That way, the RSVP > signalling and the admission decision share a common fate -- a very > natural integration of PCN with RSVP. Less natural is the message > autonomously generated by the egress node when flow termination is > required, but as we know, with the specification of a new object to > represent the IEA, this can be done. > > (The fact is that I suspect the piggybacking method is far more > deployable than the CL and SM methods because far fewer messages have to > be transmitted through the network.) > > I can see the possibility of using RSVP as a transport for PCN reports > in the CL and SM cases, but it is a really unnatural use of the > protocol. In the first place, the RESV is initiated at a router (the > egress node) rather than an end point or a proxy for an end point. I am > a bit dubious that the message format for this message would conform in > any but the most artificial sense to the specifications in RFC 2205. And > the Path message, the normal response to the RESV, is unnecessary in > normal operation in the CL and SM cases. > > I would feel much more comfortable defining a simple and light-weight > protocol that could be used regardless of whether the decision point is > centralized or decentralized. > > On 28/06/2011 9:00 AM, Georgios Karagiannis wrote: >> Hi Tom, >> >> The solution that I was talking about is indeed related to the >> piggybacking edge behaviour: >> draft-taylor-pcn-piggybacking-edge-behaviour-01 >> >> However, this piggybacking edge behaviour is very much depending on the >> SM and CL behaviours. >> >> My proposal is to somehow integrate each of the CL and SM edge behaviours >> with the piggybacking edge behaviour. This can be e.g., done by >> including in each SM and CL drafts an additional section that will >> describe how each of the CL and SM behaviours can be used when the >> decision point is co-located with the PCN-ingess-node. In this case the >> enhanced RSVP can be applied as the signaling protocol used to exchange >> information between the PCN edge nodes. >> >> In addition to this we could also add a section on each CL and SM drafts >> that describe how each of the CL and SM behaviours can be used when the >> decision point is not co-located with the PCN-ingess-node. >> In this case DIAMETER can be used as the signaling protocol for >> exchanging information between the PCN-egress-node and decision point >> and between the decision point and the PCN-ingress-node. I think that >> you already described this solution some tinme ago. >> >> Best regards, >> Georgios >> > ... > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From karagian@cs.utwente.nl Tue Jun 28 07:43:48 2011 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05F011E8123 for ; Tue, 28 Jun 2011 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeBsnwzAdRbn for ; Tue, 28 Jun 2011 07:43:48 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 01BC911E8122 for ; Tue, 28 Jun 2011 07:43:47 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5SEgH1J002105; Tue, 28 Jun 2011 16:42:18 +0200 (MEST) Received: from 130.89.12.129 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 28 Jun 2011 14:43:46 +0000 To: "Tom Taylor" Date: Tue, 28 Jun 2011 14:43:46 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 28 Jun 2011 16:42:29 +0200 (MEST) Cc: pcn Subject: Re: [PCN] Signalling protocols for CL and SM modes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:43:49 -0000 Hi Tom, Please see in line! On 6/28/2011, "Tom Taylor" wrote: >The piggybacking edge behaviour shares the marking behaviours with the >CL and SM modes. Where it differs is that the decision point for >admission effectively lies with the egress node.=20 Georgios: the decision point for admission control could also lie on the PCN-ingress-node. The PCN-ingress-node could decide whether an e2e RSVP PATH message (of a flow that belongs to a IEA) is admitted and forwarded towards the PCN-egress-node or not. >That way, the RSVP >signalling and the admission decision share a common fate -- a very >natural integration of PCN with RSVP. Less natural is the message >autonomously generated by the egress node when flow termination is >required, but as we know, with the specification of a new object to >represent the IEA, this can be done. Georgios: This periodical notification from PCN-egress-node to PCN-ingress-node may also be realised using the RSVP aggregation messages (as I mentioned a combination of e2e RSVP (RFC 2205) and RSVP aggregation (RFC3175) is required. Note that the RSVP aggregated messages are started/ended at the aggregator (in this case is the PCN-ingress-node) or the deaggregator (PCN-egress-node). > >(The fact is that I suspect the piggybacking method is far more >deployable than the CL and SM methods because far fewer messages have to >be transmitted through the network.) > >I can see the possibility of using RSVP as a transport for PCN reports >in the CL and SM cases, but it is a really unnatural use of the >protocol. In the first place, the RESV is initiated at a router (the >egress node) rather than an end point or a proxy for an end point. I am >a bit dubious that the message format for this message would conform in >any but the most artificial sense to the specifications in RFC 2205. And >the Path message, the normal response to the RESV, is unnecessary in >normal operation in the CL and SM cases. Georgios: I amk working on this, but I think that if the PCN-ingress-node is collocated with the decision point then the SM and CL can use RSVP in combination with the RSVP aggregation as signaling protocols. Note that the RSVP aggregated messages are started/ended at the aggregator (in this case is the PCN-ingress-node) or the deaggregator (PCN-egress-node). > >I would feel much more comfortable defining a simple and light-weight >protocol that could be used regardless of whether the decision point is >centralized or decentralized. Georgios: In my opinion we will spend more time on specifying and standardizing such a protocol, than just enhancing an existing IETF signaling protocol. Best regards, Georgios > >On 28/06/2011 9:00 AM, Georgios Karagiannis wrote: >> Hi Tom, >> >> The solution that I was talking about is indeed related to the >> piggybacking edge behaviour: >> draft-taylor-pcn-piggybacking-edge-behaviour-01 >> >> However, this piggybacking edge behaviour is very much depending on the >> SM and CL behaviours. >> >> My proposal is to somehow integrate each of the CL and SM edge behaviours >> with the piggybacking edge behaviour. This can be e.g., done by >> including in each SM and CL drafts an additional section that will >> describe how each of the CL and SM behaviours can be used when the >> decision point is co-located with the PCN-ingess-node. In this case the >> enhanced RSVP can be applied as the signaling protocol used to exchange >> information between the PCN edge nodes. >> >> In addition to this we could also add a section on each CL and SM drafts >> that describe how each of the CL and SM behaviours can be used when the >> decision point is not co-located with the PCN-ingess-node. >> In this case DIAMETER can be used as the signaling protocol for >> exchanging information between the PCN-egress-node and decision point >> and between the decision point and the PCN-ingress-node. I think that >> you already described this solution some tinme ago. >> >> Best regards, >> Georgios >> >...